Diagrams 03 — RAG, Agents & Coding

Diagrams 11–14: AI coding IDE architecture, BYOK, the RAG pipeline, and the agent loop. Pairs with Phase 9, Phase 10, Phase 11.

11. Cursor-style IDE architecture

   Editor (VS Code fork / extension)
      │   user edits, cursor position, open files
      ▼
   ┌──────────────────────────────────────────────┐
   │  CONTEXT ENGINE (the hard part)               │
   │  codebase index (embeddings) + symbol/AST     │
   │  retrieve relevant files/snippets             │
   │  build context under a LATENCY BUDGET         │
   └───────────────┬────────────────────────────────┘
                   ▼
   ┌──────────────────────────────────────────────┐
   │  MODEL ROUTING (latency tiers)                │
   │  autocomplete → tiny/fast FIM model (<<1s)     │
   │  inline edit → mid model                       │
   │  chat/agent → frontier model                   │
   └───────────────┬────────────────────────────────┘
                   ▼
   apply-patch / diff  ──▶  editor (user accepts/rejects)
   + BYOK / provider routing (diagram 12)

flowchart TD
  ED[Editor + cursor + open files] --> CE[Context engine: index + symbol/AST]
  CE --> CB[Build context under latency budget]
  CB --> MR[Model routing by latency tier]
  MR --> AC[Autocomplete: tiny FIM model]
  MR --> IE[Inline edit: mid model]
  MR --> CH[Chat/agent: frontier model]
  AC --> AP[Apply patch/diff]
  IE --> AP
  CH --> AP
  AP --> ED

12. VS Code BYOK flow

   user provides their OWN provider key (BYOK)
        │  stored in editor secret storage (not in code)
        ▼
   extension  ──▶  provider routing (which model/provider)
        │              │
        │              ▼
        │        user's key used for THEIR requests (bills to them)
        ▼
   request → provider → response → editor
   (key never leaves the client boundary except to the chosen provider;
    enterprise: route via org gateway with policy/metering [Phase 8])

flowchart TD
  U[User adds own provider key BYOK] --> SS[Editor secret storage]
  SS --> EXT[Extension]
  EXT --> PR[Provider routing: model/provider]
  PR --> K[Use user's key → bills to user]
  K --> PROV[Provider]
  PROV --> RESP[Response → editor]
  PR -.enterprise.-> GW[Org gateway: policy + metering]

13. RAG architecture

 INGEST (offline)                          QUERY (online)
 docs → clean → CHUNK                       user question
   → EMBED → vector DB                          │ embed
   [+ keyword/BM25 index]                       ▼
        │                              ┌───────────────────────┐
        └─────────────────────────────▶│ RETRIEVE (vector+BM25) │
                                       │  → RRF fuse            │
                                       └──────────┬─────────────┘
                                                  ▼
                                          [ RERANK (cross-encoder) ]
                                                  ▼
                                          [ PACK context (order!) ]
                                                  ▼
                                          [ GENERATE grounded + CITE ]
                                                  ▼
                                            answer + citations
   per-tenant filter/ACL applied at retrieve  [Phase 14.04]

flowchart TD
  subgraph Ingest[Ingest offline]
    D[Docs] --> CL[Clean] --> CK[Chunk] --> EM[Embed] --> VDB[(Vector DB + BM25)]
  end
  Q[User question] --> QE[Embed query]
  QE --> RET[Retrieve vector+BM25 → RRF]
  VDB --> RET
  RET --> RR[Rerank cross-encoder]
  RR --> PK[Pack context: order matters]
  PK --> GEN[Generate grounded + cite]
  GEN --> ANS[Answer + citations]
  RET -.per-tenant filter/ACL.-> RET

14. Agent tool-calling loop

            ┌──────────────────────────────────────────┐
            ▼                                          │
   goal/messages + tool schemas                        │
            │                                          │
            ▼                                          │
   [ MODEL ] proposes tool_call {name, args}           │ (loop until done
            │  (proposes only — does NOT execute)      │  or max steps)
            ▼                                          │
   [ APP ] validate args → CHECK PERMISSIONS →         │
           [approval gate if high-impact] → EXECUTE    │
            │                                          │
            ▼                                          │
   tool_result (untrusted text!) ─────────────────────┘
            │
            ▼  (when model decides it's done)
        final answer
   ★ trust boundary: model proposes / app executes  [Phase 10.05 / 14.01]
   ★ per-step reliability compounds: 0.95^10 ≈ 0.60

flowchart TD
  G[Goal + messages + tool schemas] --> M[Model: propose tool_call]
  M --> AP[App: validate + check permissions]
  AP --> GATE{High-impact?}
  GATE -->|yes| HU[Human approval]
  GATE -->|no| EX[Execute tool]
  HU --> EX
  EX --> TR[tool_result: untrusted text]
  TR --> M
  M -->|done| ANS[Final answer]

Next: Diagrams 04 — Eval, Cost, Deploy & Startup · Concepts: Phase 9, Phase 10.01, Phase 11.00