Agentic Flow Architectures

The earlier pages of this site describe parts: the agent loop and its reasoning patterns (Foundations), tool use as the action space (Tool Use & Function Calling), memory and retrieval — RAG included — as the context supply (Memory & Context), and the multi-agent topologies that coordinate several loops (Orchestration Patterns). This page is about the whole machines. By 2025–2026 a handful of end-to-end flow shapes had hardened into the standard architectures that real products ship: the same building blocks, composed differently because the task shape differs — how the run is triggered, what the feedback signal is, how long the loop runs, and where the human sits.

Six architectures cover most of what is deployed today. For each: what it is, the control-flow shape, why it exists, when to use it, its tradeoffs and failure modes, and representative implementations verified against primary sources.

Agentic RAG / knowledge assistant

What it is. The knowledge-assistant flow puts retrieval inside the agent loop instead of in front of it. Classic RAG is a fixed pipeline — embed the question, fetch top-k passages, generate — that runs the same way for every input. The Agentic RAG survey (Singh et al., 2025) pins the limitation precisely: "traditional RAG systems are constrained by static workflows and lack the adaptability required for multi-step reasoning and complex task management," and agentic RAG "transcends these limitations by embedding autonomous AI agents into the RAG pipeline," where the agents apply the familiar design patterns — "reflection, planning, tool use, and multi-agent collaboration" — to "dynamically manage retrieval strategies." In flow terms: retrieval becomes a tool-use call the model may or may not make, as many times as the question requires.

LangGraph's agentic RAG tutorial states the core decision plainly: "Retrieval agents are useful when you want an LLM to make a decision about whether to retrieve context from a vectorstore or respond to the user directly." Its canonical graph adds two more model-driven judgments — after retrieving, grade whether the documents are actually relevant, and if not, rewrite the question and retrieve again rather than generating from bad context.

flowchart TD
    Q[User question] --> D{Agent: retrieve
or answer directly?}
    D -->|answer directly| A[Respond]
    D -->|call retriever tool| R[(Retrieve top-k)]
    R --> G{Grade: are the
documents relevant?}
    G -->|yes| GEN[Generate grounded answer]
    G -->|no| RW[Rewrite the question]
    RW --> D
    GEN --> A

When to use it. Customer support over a product corpus, internal doc Q&A, any assistant whose value is answering from a knowledge base — and whose questions vary enough that a fixed retrieve-then-generate pipeline either retrieves when it shouldn't (chitchat) or retrieves once when the question needs several hops. If every query genuinely needs exactly one retrieval, keep the fixed pipeline; it is cheaper and more predictable.

Tradeoffs and failure modes. Each added judgment (retrieve-or-not, grading, rewriting) is an extra LLM turn of latency and cost. The characteristic failures are the rewrite loop (the agent never judges the corpus good enough and cycles query reformulations — bound the retries), the overconfident skip (the model answers from parametric memory when it should have retrieved, reintroducing exactly the hallucination RAG exists to prevent), and grading errors that discard relevant passages. The retrieval mechanics themselves — embeddings, vector stores, chunking — are covered in Memory & Context.

Deep research

What it is. A deep research flow turns an open-ended question into a long-form, citation-backed report by spending minutes — not seconds — of search and synthesis. The shape is the orchestrator-worker topology of orchestration patterns, specialized for research: clarify and plan, fan out searches (often to parallel subagents), iterate until coverage is sufficient, then synthesize with citations.

Anthropic's multi-agent research system is the best-documented implementation. The lead agent "begins by thinking through the approach and saving its plan to Memory to persist the context, since if the context window exceeds 200,000 tokens it will be truncated and it is important to retain the plan." It then spawns subagents, each of which "independently performs web searches, evaluates tool results using interleaved thinking, and returns findings to the LeadResearcher." Citation handling is a separate, final stage: once enough is gathered, "the system exits the research loop and passes all findings to a CitationAgent, which processes the documents and research report to identify specific locations for citations." The payoff was measured: the multi-agent system with Claude Opus 4 as lead and Claude Sonnet 4 subagents "outperformed single-agent Claude Opus 4 by 90.2%" on their internal research eval. Search strategy matters too — agents were prompted "to start with short, broad queries, evaluate what's available, then progressively narrow focus."

OpenAI ships the same shape as a product and an API: the deep research models (o3-deep-research and o4-mini-deep-research) "find, analyze, and synthesize hundreds of sources to create a comprehensive report at the level of a research analyst," emitting inline citations with source metadata. Two details of the flow are instructive: in ChatGPT the flow begins with clarification and prompt rewriting, whereas "Deep research via the Responses API does not include a clarification or prompt rewriting step" — the developer owns that stage — and because "deep research requests can take a long time," OpenAI recommends "running them in background mode." NVIDIA's AI-Q blueprint packages the pattern for enterprises: "an open reference example for building intelligent AI agents that connect to your enterprise data, reason using state-of-the-art models, and deliver trusted business insights," with an orchestration node that classifies intent and sets research depth — a bounded "shallow" researcher for quick cited answers versus a "deep research" path of "long-running multi-step planning and research to generate a long-form citation-backed report."

flowchart TD
    U[User question] --> C[Clarify scope
+ plan research]
    C --> S1[Search subagent A]
    C --> S2[Search subagent B]
    C --> S3[Search subagent C]
    S1 --> L{Lead agent:
coverage sufficient?}
    S2 --> L
    S3 --> L
    L -->|no: spawn more
or narrow queries| C
    L -->|yes| SYN[Synthesize report]
    SYN --> CIT[Citation pass:
attach sources to claims]
    CIT --> R[Cited report]

When to use it. Questions whose answer is a survey — market or literature reviews, due diligence, competitive analysis — where breadth exceeds one context window and sub-questions parallelize cleanly. Anthropic is blunt about the economics: multi-agent research burns about 15× the tokens of a chat, so reserve the flow for tasks worth that spend.

Tradeoffs and failure modes. Cost and wall-clock time are the obvious prices. The documented failure modes are over-decomposition — early versions "spawning 50 subagents for simple queries" — and "scouring the web endlessly for nonexistent sources"; a weak synthesis stage can also flatten genuinely conflicting sources into false consensus, which is why the dedicated citation pass (forcing claims back onto specific sources) earns its place in the flow.

Coding agent

What it is. The coding-agent flow is the agent loop grounded in the strongest feedback environment agents have: a repository. Claude Code's own description of the loop is the cleanest statement of the shape — "gather context -> take action -> verify work -> repeat" — locate the relevant code, edit it, then check the edit against reality by running tests, linters, and builds, iterating until the checks pass. Verification is what makes this flow work: "Code linting is an excellent form of rules-based feedback," and the same post argues that for gathering context, agentic search (the model navigating files with grep-like tools) should come first — "we suggest starting with agentic search, and only adding semantic search if you need faster results or more variations."

The research result behind the flow is SWE-agent (Yang et al., 2024), which introduced the agent-computer-interface (ACI): "LM agents represent a new category of end users with their own needs and abilities, and would benefit from specially-built interfaces to the software they use." SWE-agent's custom ACI "significantly enhances an agent's ability to create and edit code files, navigate entire repositories, and execute tests and other programs," and on SWE-bench — the benchmark asking whether models can resolve real-world GitHub issues — it reached "a pass@1 rate of 12.5%," at the time "far exceeding the previous state-of-the-art achieved with non-interactive LMs." The lesson generalizes beyond coding: interface design is agent design — what the agent sees after each action determines what it can fix.

flowchart TD
    T[Task: issue / bug / feature] --> LOC["Gather context:
search + read code (ACI)"]
    LOC --> ED[Take action:
edit files]
    ED --> RUN[Verify: run tests,
linter, build]
    RUN --> OK{Checks pass?}
    OK -->|no: error output
fed back as observation| LOC
    OK -->|yes| PR[Diff / commit / PR
for human review]

Production form: Anthropic's Claude Agent SDK exposes "the same tools, agent loop, and context management that power Claude Code" as a library, with built-in file-reading, editing, command-execution, and search tools — the coding flow as an embeddable component rather than a product.

When to use it. Any task with a machine-checkable definition of done — failing test to make pass, type error to fix, migration to apply. The flow degrades gracefully into assistance: where no automatic check exists (architecture, taste), the human review gate at the end does the verifying.

Tradeoffs and failure modes. The loop is only as good as its verifier: with weak tests the agent confidently "passes" wrong code, and with slow suites each iteration is expensive. Characteristic failures are reward-hacking the checks (editing the test instead of the bug), context bloat from reading too much of the repository, and unbounded edit-test cycles on problems the model cannot actually solve — all arguments for step budgets and diff-size review gates.

Computer-use / browser agent

What it is. When no API exists, the agent operates the interface humans use. The computer-use flow gives the model a screen instead of a schema: it perceives by screenshot and acts with mouse and keyboard. OpenAI's computer-use guide describes one turn of the loop: "The model looks at the current UI through a screenshot, returns actions such as clicks, typing, or scrolling, and your harness executes those actions in a browser or computer environment," after which the harness returns a fresh screenshot. Anthropic's docs name the cycle explicitly: "The core of computer use is the 'agent loop': a cycle where Claude requests tool actions, your application runs them, and returns results to Claude." It is the generic observe-act loop with two twists: the observation is pixels, and the action space is the GUI's, not a typed tool's.

flowchart TD
    G[Goal: operate an app / site] --> SS[Observe: screenshot]
    SS --> M{Model chooses action:
click / type / scroll / key}
    M --> EX["Harness executes action
in sandboxed VM / browser"]
    EX --> V[Observe result:
new screenshot]
    V --> CK{Goal reached
or gate hit?}
    CK -->|no| M
    CK -->|human gate| H[Human confirms
consequential action]
    H --> M
    CK -->|yes| DONE[Report outcome]

Why its safety posture is different. This flow reads arbitrary rendered content, which makes prompt-injection a first-order design constraint rather than an edge case. Anthropic is unusually direct: "In some circumstances, Claude will follow commands found in content even when they conflict with your instructions." Its recommended precautions define the deployment shape: a dedicated virtual machine or container with minimal privileges, no access to sensitive data such as logins, an allowlist of domains, and "asking a human to confirm decisions that might result in meaningful real-world consequences" — with an extra defense layer where classifiers that spot suspected injections in screenshots "automatically steer the model to ask for user confirmation before proceeding with the next action." OpenAI's guidance is the same posture in one sentence: "Run Computer use in an isolated browser or VM, keep a human in the loop for high-impact actions, and treat page content as untrusted input" — and, crucially, "only direct instructions from the user count as permission."

When to use it. Legacy or third-party software with no API, cross-application workflows, and end-to-end UI testing. It is the fallback flow: if a typed tool or API exists, prefer it — structured tool use is faster, cheaper, and far easier to secure.

Tradeoffs and failure modes. Universality is bought with fragility and cost: every step pays for image processing, UI changes break implicit assumptions, and misclicks compound silently — Anthropic's docs recommend prompting the model to screenshot and re-evaluate after each step precisely because it "sometimes assumes outcomes of its actions without explicitly checking their results." Add injection-bearing pages and the case for sandboxing plus human gates (Eval & Ops) makes itself.

Policy-bound conversational agent

What it is. The customer-facing flow: an agent that converses with an end user while executing real transactions under a written domain policy — refunds only under condition X, identity verified before Y, escalate on Z. The benchmark that defined this shape is τ-bench (tau-bench), built as "a benchmark emulating dynamic conversations between a user (simulated by language models) and a language agent provided with domain-specific API tools and policy guidelines," and scored by comparing "the database state at the end of a conversation with the annotated goal state." Its results are the standing caution for this architecture: "even state-of-the-art function calling agents (like gpt-4o) succeed on <50% of the tasks, and are quite inconsistent (pass^8 <25% in retail)" — the pass^k metric measuring whether the agent succeeds on all of k reruns of the same task. What these agents lack, the authors conclude, is the ability "to act consistently and follow rules reliably."

Because the model alone cannot be trusted to hold the policy, the production flow wraps the loop in deterministic guardrails and human-in-the-loop gates. OpenAI's A Practical Guide to Building Agents frames guardrails "as a layered defense mechanism," since "a single one is unlikely to provide sufficient protection" — relevance and safety classifiers, PII filters, moderation, rules-based protections, output validation, and per-tool risk ratings. For escalation it names exactly two triggers: "exceeding failure thresholds" (retry limits, the agent failing to grasp intent after multiple attempts) and "high-risk actions" — "actions that are sensitive, irreversible, or have high stakes should trigger human oversight until confidence in the agent's reliability grows. Examples include canceling user orders, authorizing large refunds, or making payments."

flowchart TD
    U[End user message] --> IG[Input guardrails:
relevance / safety / rules]
    IG --> A{Agent turn:
policy in system prompt}
    A -->|reply / clarify| U
    A -->|low-risk tool| API[(Business API)]
    API --> A
    A -->|high-risk action| HG{Human gate:
approve / deny}
    HG -->|approved| API
    HG -->|denied or over
failure threshold| ESC[Escalate to
human agent]

When to use it. Support, commerce, booking, banking — anywhere the agent acts on real accounts under real rules. This is also where the router and handoff topologies from orchestration patterns most often appear in practice, splitting triage from specialized policy domains.

Tradeoffs and failure modes. The τ-bench numbers are the failure-mode list: policy violations under paraphrased pressure, inconsistency across identical cases (fatal where fairness or compliance matters), and users — adversarial or just confused — steering the agent off-policy. Gates restore safety at the price of latency and staffing, so the design problem becomes calibrating the risk threshold rather than eliminating the human.

Background / event-driven agents

What it is. Every flow above starts when a person asks. Ambient-agent flows start when an event fires — a cron tick, a queue message, a webhook, an inbound email — and run with no human in the session. LangChain, which coined the product framing, defines them in one line: "Ambient agents listen to an event stream and act on it accordingly, potentially acting on multiple events at a time," with two defining characteristics — such an agent "should not (solely) be triggered by human messages" and "should allow for multiple agents running simultaneously." The human is not gone; they are moved after the loop. LangChain is explicit that "we do not think that ambient agents are necessarily completely autonomous," and names three asynchronous touchpoints: notify ("let the user know some event is important, but not take any actions"), question ("ask the user a question to help unblock the agent"), and review ("review an action the agent wants to take" — approve, edit, or give feedback).

flowchart TD
    EV[Event stream:
cron / queue / webhook / email] --> TR[Trigger agent run
no human in session]
    TR --> L[Agent loop: gather context,
act via tools]
    L --> D{Outcome class}
    D -->|informational| N[Notify human]
    D -->|blocked: missing info| QU[Question to human
run pauses]
    D -->|action drafted| RV[Review queue:
approve / edit / reject]
    RV -->|approved| ACT[(Execute action)]
    QU -->|answer| L

When to use it. Work nobody is waiting on: triaging inboxes and alerts, monitoring, scheduled report generation, and long research jobs — OpenAI's deep research API itself recommends background mode for exactly this reason, and NVIDIA's AI-Q blueprint ships async deep-research jobs alongside its interactive UI. Because no user is watching a spinner, the flow tolerates long runs and heavy concurrency that chat never could.

Tradeoffs and failure modes. Removing the human from the session removes the cheapest error correction there is, so review must be designed in, not bolted on — LangChain's argument for human-in-the-loop here is that "it lowers the stakes, making it easier to ship agents to production." The characteristic failures are silent ones (a misfiring agent processing events wrongly for days), notification fatigue (a review queue nobody reads becomes a rubber stamp), runaway costs on noisy event streams, and duplicate actions when event delivery retries — which makes idempotency and observability load-bearing rather than optional.

Choosing a flow

flowchart TD
    S{What starts the run?} -->|an event, not a person| AMB[Background / ambient]
    S -->|an end user, under rules| POL[Policy-bound conversational]
    S -->|a user question| K{Answer from a corpus
or from the open world?}
    K -->|corpus, seconds| ARAG[Agentic RAG assistant]
    K -->|open world, minutes| DR[Deep research]
    S -->|a task in an environment| E{Is there a typed interface
with checkable feedback?}
    E -->|"yes (repo, tests)"| CODE[Coding agent]
    E -->|no, GUI only| CU[Computer-use agent]

Two closing observations. First, these architectures compose: a background trigger can launch a deep research flow whose subagents do agentic RAG over an internal corpus, and a coding agent can drive a browser to verify the UI it just built. Second, the deciding questions are always the same four — trigger, feedback signal, loop duration, human placement — and they matter more than any framework choice (frameworks compared here). Get the flow shape right and the topology, tools, and memory choices from the earlier pages slot into place; get it wrong and no amount of prompt engineering will save the product.