Diagram library
The reusable ASCII diagrams the Review uses across its articles. They are released for re-use under the same terms as our textual content: quote freely with attribution, write to the editors for republication. Click the "Copy" button on any diagram to drop it into your own document.
Audit
Audit envelope around an agent action
┌───────────────────────────────────────────┐
│ envelope: │
│ principal: user:andrew@example.com │
│ agent_id: wf://web4os/ceo/v3 │
│ capability: read:repo write:branch │
│ timestamp: 2026-05-23T14:22:11Z │
│ parent_action: audit://act/a91f... │
│ reason: "owner card: ship v0.2" │
│ │
│ ┌─────────────────────────────────┐ │
│ │ action: git_commit │ │
│ │ args: { branch: "feature/x", │ │
│ │ message: "..." } │ │
│ │ result: { sha: "a91fcc...", │ │
│ │ status: "success" } │ │
│ └─────────────────────────────────┘ │
└───────────────────────────────────────────┘ A proposed audit envelope around an agent action. The fields above the inner block are the envelope; the inner block is the action itself. The envelope is the reason an action is auditable; without it, you have a log line.
Memory
Memory tiers (Letta-shaped)
recall query
│
┌──────▼──────┐
│ working │ ~thousands of tokens
│ set │ always in context
└──────┬──────┘
│ promote / demote
┌──────▼──────┐
│ recall │ ~tens of thousands
│ cache │ retrieved on demand
└──────┬──────┘
│ archive
┌──────▼──────┐
│ archive │ unbounded
│ (vector + │ retrieved by query
│ keyword) │
└─────────────┘ Tiered memory in the shape Letta sketches and that the category is converging on: a working set always in context, a recall cache promoted on demand, an unbounded archive retrieved by hybrid vector + keyword search.
Orchestration
Planner / Specialist / Tools
┌──────────────────────────────┐
│ owner · structured cards │
└──────────────┬───────────────┘
│ intents
┌──────▼──────┐
│ planner │ planning
│ agent │ routing
└──┬───┬───┬──┘
│ │ │
┌───▼┐ ┌▼─┐ ┌▼───┐
│ S1 │ │S2│ │ S3 │ specialists
└─┬──┘ └┬─┘ └─┬──┘
│ │ │
┌▼─────▼─────▼┐
│ tools │ fs · git · http
│ memory │ state · audit
└─────────────┘ The canonical reference architecture for the Review. Owner-driven inputs, a planning agent that routes work to typed specialists, specialists that share a tool-and-memory substrate. Handoffs, not chat turns.
ReAct loop (single-agent)
┌────────────┐
│ observe │◄─────────────┐
└─────┬──────┘ │
│ state │
┌─────▼──────┐ │
│ think │ │
│ (model) │ │
└─────┬──────┘ │
│ action │
┌─────▼──────┐ │
│ act │ tool call │
│ (tools) ├──────────────┤
└────────────┘ result │
│
loop until terminal ───┘ The single-agent ReAct loop, the simplest model in this category. Most frameworks ship a more elaborate version of this; almost all reduce to it under the hood.
Workflow as state machine (LangGraph-shaped)
┌──────────┐
│ start │
└────┬─────┘
│
┌────▼─────┐ fail ┌──────────┐
│ fetch ├──────────►│ retry │
└────┬─────┘ └────┬─────┘
│ ok │
┌────▼─────┐ │
│ plan │◄───────────────┘
└────┬─────┘
│
┌────▼─────┐
│ execute │ (parallel branch)
└────┬─────┘
│ ok
┌────▼─────┐
│ verify │
└────┬─────┘
│
┌────▼─────┐
│ done │
└──────────┘ A workflow as a state machine. The shape that LangGraph popularized and that AutoGen, CrewAI's task-graph mode, and Web4OS's specialist routing all converge on. The checkpoint primitive sits on the edges, not the nodes.
Tool-use loop with structured outputs
┌──────────┐
│ prompt │
└────┬─────┘
│
┌────▼─────────┐
│ model │
│ + schema │
└────┬─────────┘
│ structured output
│ { tool: "...", args: {...} }
│
┌────▼─────────┐
│ dispatcher │
└──┬──┬──┬──┬──┘
│ │ │ │
▼ ▼ ▼ ▼ (tools)
│ │ │ │
└──┴──┴──┴──► result
│
│ feed back into context
│
▼
┌──────────┐
│ next │
│ turn │
└──────────┘ The tool-use loop with structured outputs. The model emits a typed schema; a dispatcher routes to tools; results re-enter the context. The interesting design choices are in the schema (how strict?) and the dispatcher (how much retry / mediation logic?).
Multi-agent supervisor topology
┌────────────────┐
│ supervisor │
└────┬─────┬─────┘
│ │
┌──────┘ └──────┐
│ │
┌────▼─────┐ ┌────▼─────┐
│ worker A │ │ worker B │
└────┬─────┘ └────┬─────┘
│ │
└──────┐ ┌──────┘
▼ ▼
┌───────────────┐
│ shared scratchpad │
└───────────────┘ The supervisor topology: a single supervisor delegates to a small set of workers that may share a scratchpad for cross-coordination. Common in AutoGen and CrewAI orchestrations; less common at scale, where flat topologies start to fail.
Runtime
Long-horizon checkpoint and resume
t=0 t=1 t=2 t=3
┌─┐ ┌─┐ ┌─┐ ┌─┐
│A│ ──ckpt──►│A│ ──ckpt──►│A│ ──ckpt──►│A│
└─┘ └─┘ └─┘ └─┘
│ │ ✗ crash ▲
│ │ │
└───────────┴────── restore ─────────┘
from checkpoint at t=2 A long-horizon agent with periodic checkpoints. On crash, the runtime restores from the most recent checkpoint and resumes. The hard design choices are in (a) what state the checkpoint includes (memory? tool side-effects?) and (b) what idempotency primitives the tools expose so a resume doesn't double-write.
Sandbox
Sandbox architecture (agent tool isolation)
┌────────────────────────────────┐
│ agent runtime │
│ ┌──────────────────────────┐ │
│ │ reasoning loop │ │
│ └──────────┬───────────────┘ │
│ │ tool call │
│ ┌──────────▼───────────────┐ │
│ │ capability mediator │ │
│ └──────────┬───────────────┘ │
└─────────────┼──────────────────┘
│ syscall / RPC
┌──────────▼───────────────┐
│ sandbox boundary │
│ ┌──────┐ ┌──────┐ ┌───┐ │
│ │ FS │ │ net │ │exec│ │
│ └──────┘ └──────┘ └───┘ │
└──────────────────────────┘ A typical agent-runtime sandbox: the reasoning loop emits tool calls, a mediator checks them against the agent's capability set, and the underlying primitives (filesystem, network, exec) sit behind a sandbox boundary the agent cannot cross.
Standards
MCP client / server topology
┌──────────────────┐
│ LLM host │
│ (client app) │
└────────┬─────────┘
│ JSON-RPC over stdio or SSE
│
┌─────┴──────────────────────┐
│ MCP client │
└─────┬──────┬──────┬────────┘
│ │ │
┌─────▼┐ ┌─▼──┐ ┌─▼────┐
│ srv │ │srv │ │ srv │ per-source MCP servers
│ FS │ │ DB │ │ HTTP │
└──────┘ └────┘ └──────┘ MCP's deployment topology: an LLM host runs a client; the client speaks JSON-RPC to one or more MCP servers, each wrapping a source of context or tools. The transport is host-side; the spec stays out of it.
A2A — agent-to-agent message flow
agent A agent B
─────── ───────
│ │
│ capability discovery │
├────────────────────────────►│
│ │
│ manifest │
│◄────────────────────────────┤
│ │
│ task.create(...) │
├────────────────────────────►│
│ │
│ task.status (streamed) │
│◄────────────────────────────┤
│ │
│ task.result │
│◄────────────────────────────┤
│ │ The A2A draft's task lifecycle as a sequence diagram. The interesting work is in the streaming status updates and the cancellation semantics, which the 0.4 draft has stabilized.
Capability manifest (OpenAgents-shaped)
┌──────────────────────────────────────────┐ │ agent_id: wf://example/research │ │ display_name: "Research Agent" │ │ version: 1.2.0 │ │ │ │ capabilities: │ │ - id: search.web │ │ cost: $0.01 per call │ │ sla: p95 < 3s │ │ auth: bearer │ │ │ │ - id: summarize.document │ │ cost: $0.10 per 1k tokens │ │ sla: p95 < 30s │ │ auth: oauth2 │ │ │ │ endpoints: │ │ rpc: https://... │ │ stream: wss://... │ │ │ │ signed_by: key:k1z... │ └──────────────────────────────────────────┘
A capability manifest in roughly the shape OpenAgents and A2A converge on. The interesting design choices are in the cost/SLA fields (operationally important, contractually unenforceable) and the signed_by field (which presumes a key infrastructure that does not yet broadly exist).
On ASCII as a publication tool
We use ASCII diagrams rather than rendered illustrations for three reasons. First, they are copyable — readers can paste them into their own docs, ADRs, and design conversations. Second, they are stable — they survive markdown migrations, RSS-reader rendering, and the eventual move to wherever the reading happens. Third, they constrain the diagrams toward the things that matter: boxes, arrows, labels, and the relationships between them. They are not a replacement for high-fidelity illustrations. They are the right medium for the kind of architectural conversation the Review tends to have.
Our drawing conventions are documented in the style guide.
Briefly: we use box-drawing characters (┌, ─, │,
and the rest), not ASCII-only pipes and dashes; we reserve the accent color for structural
boxes and inputs; we keep labels short and out of the boxes wherever the geometry allows.
If you would like to propose a diagram for inclusion in this library — perhaps because you have read a recent article and the diagram in it should be a reusable reference — write to the editors. We add diagrams that we expect to use again.