System Design Problem

Design a Multi-Agent Orchestration Platform (LangGraph / Supervisor-Worker)

Commonly Asked By:OpenAIAnthropicGoogleMicrosoftLangChain

Interview Setup

Interview Prompt

Design a multi-agent orchestration platform (LangGraph / supervisor-worker architecture) for 5K enterprise tenants, 10K concurrent graph runs, specialized agents (researcher, coder, reviewer), human-in-the-loop checkpoints, durable execution with checkpointing every N steps, and strict per-node cost and latency budgets, integrating with an LLM gateway, optional RAG, vector search, and cloud sandboxes.

Clarifying Questions (ask before designing)

QuestionWhy it matters
How is this different from an autonomous cloud coding agent?An autonomous cloud coding agent runs a single ReAct loop inside one isolated microVM. A multi-agent orchestration platform coordinates multiple specialized agents via an explicit state graph, shared state, and supervisor routing, reflecting LangGraph and AutoGen architectures.
Shared state store or message passing between agents?This is a core design fork. Shared state enables any agent to read full context, whereas message passing scales better but loses global view. Production hybrid designs pair an authoritative shared state store with an append-only event log.
Where does durable execution live?Graph runs span minutes to days due to human-in-the-loop waits. This requires Temporal workflows for timers, retries, and crash recovery rather than an in-memory asyncio loop.
What triggers human-in-the-loop?Regulated workflows need approval before external side effects. HitL is a graph node that blocks until Temporal receives an approve/reject signal.
How are cost and latency controlled per node?Multi-agent graphs consume tokens rapidly. Each node type receives strict budget caps enforced at the LLM gateway, and the supervisor must route to the END node when global budgets run low.

Scope

In scope

  • Supervisor-worker state graph execution (LangGraph-style)
  • Specialized agents: researcher, coder, reviewer with tool routing
  • Authoritative shared state store with append-only graph events
  • Graph checkpointing every N steps with resume on worker crash
  • Durable orchestration via Temporal workflows
  • Human-in-the-loop gates with approve/reject signals
  • Per-node and per-run token, USD, and latency budgets via the LLM gateway
  • SSE and WebSocket streaming of node transitions and state patches
  • Integration hooks: document RAG, vector search, and cloud sandboxes

Out of scope (state explicitly)

  • Training foundation models or fine-tuning agent policies
  • Building a general IDE copilot with local human-in-the-loop editing
  • Defining the LLM gateway itself, consuming it as an upstream dependency
  • Authoring UI for graph DSL (assume graphs pre-registered)

Functional Requirements

Start by distinguishing this design from an Autonomous Cloud Coding Agent. Clarify supervisor routing, human-in-the-loop gates, shared state vs message passing, and per-run token budgets before detailing worker agent roles.

  • State-graph execution: Tenants run immutable graph versions (nodes and edges) inside a LangGraph-style engine where the supervisor dynamically chooses the next node from shared state rather than traversing a static pipeline. Every run pins one graph version so retries and audit replay use the same topology and node policies.
  • Specialized worker agents: The tool router dispatches tasks to a researcher (web search and Document QA Platform (RAG)), a coder (drafting artifacts with an optional Autonomous Cloud Coding Agent sandbox), and a reviewer (policy validation and redlines), each constrained to role-scoped tools.
  • Shared state store: Authoritative JSON state (task description, artifacts, budgets, and open questions) merged through validated patches with a monotonic state version, backed by an append-only graph event log for replay as discussed in Event Sourcing and CQRS.
  • Human-in-the-loop checkpoints: The execution graph halts at designated gates until an operator approves or rejects through the UI, unlike the unsupervised loop in an Autonomous Cloud Coding Agent or the continuous inline suggestions of an AI Coding Assistant.
  • Durable execution: Multi-hour and multi-day runs survive worker crashes and approval pauses through Workflow Orchestration (Temporal) workflows paired with checkpointing every N steps.
  • Live observability: Stream node transitions, state patches, checkpoints, and approval prompts to client applications via Server-Sent Events and WebSockets.

Non-Functional Requirements

Interviewers will stress-test LLM throughput through the LLM Gateway. The concurrency model yields approximately 400K tokens per second, but the 500K runs per day requirement with 12 nodes and 8K tokens per node requires approximately 556K tokens per second on average. That mismatch must be resolved explicitly through higher node throughput, additional execution concurrency, or a lower token budget. Checkpoint frequency, Temporal workflow history growth during multi-day waits, and Idempotency and Exactly-Once Effects following approval represent the key staff-level topics.

  • Scale: 10K concurrent graph runs and 500K runs per day across 5K enterprise tenants.
  • Per-node budgets: Token, dollar, and latency caps per node type enforced at the LLM Gateway under a waterfall run budget.
  • Exactly-once side effects: External writes such as emails and API mutations require durable idempotency keys and effect records (covered in Idempotency and Exactly-Once Effects), especially upon resuming after operator approval. When the downstream system honors the idempotency key, retries converge on one external effect. Otherwise, the platform must use reconciliation and cannot promise exactly-once external effects.
  • Auditability: Full execution reconstruction from graph event logs and checkpoints, with optional fan-out to Message Queues for SIEM compliance. Replay must pin the immutable graph version and distinguish deterministic orchestration decisions from non-deterministic external tool results.
  • Tenant isolation: State, tools, and retrieval scopes are partitioned by tenant_id to prevent cross-tenant artifact access.
  • High availability: Crashed workers resume from the latest durable checkpoint. Activities may be retried, so completed external effects must be protected by idempotency rather than assuming the activity itself executes exactly once.

Capacity Estimations

LLM tokens passing through the LLM Gateway dominate capacity requirements, making tenant-fair queue sizing essential before database tuning. Checkpoint write throughput and shared state blob sizes dictate whether checkpoint intervals require per-tenant customization.

MetricCalculationValue
Enterprise tenantsGiven5K
Concurrent graph runs (peak)Given10K
Graph runs started / dayGiven500K
Avg graph nodes executed per runGiven12
Supervisor routing turns per runGiven8
LLM tokens per graph node (avg)Given8K
Concurrency-derived graph-node LLM rate10K runs x 0.3 node/min x 8K~400K tokens/s
Daily-volume graph-node LLM rate500K runs/day x 12 nodes x 8K ÷ 86,400s~556K tokens/s average
Supervisor routing token upper bound500K runs/day x 8 turns x 4K ÷ 86,400s~185K tokens/s average
Combined LLM capacity upper bound556K graph-node + 185K supervisor tokens/s~741K tokens/s average
Checkpoint writes / sec10K x 0.3 node/min ÷ 5 ÷ 60~10 writes/s
Shared state size (avg)Given64 KB JSON
Checkpoint data generated / day500K runs x 2.4 periodic ckpts x 64 KB~73 GiB/day, before extra on-HitL checkpoints
Checkpoint data / 30-day month73 GiB/day x 30~2.15 TiB/month before compression
Hot checkpoint working set10K active runs x 3 retained x 64 KB~1.83 GiB
HitL waits concurrently10% of peak runs~1K Temporal signals pending
Concurrency-derived message bus rate10K runs x 3 events/node x 12 nodes ÷ 60 min~6K events/min if peak runs average 1h
Daily-volume message bus rate500K runs/day x 3 events/node x 12 nodes ÷ 1,440 min~12.5K events/min average

LLM throughput is the primary bottleneck. The concurrency-derived model produces approximately 400K tokens per second, while the daily workload requires approximately 556K tokens per second on average, so production capacity must exceed the latter rather than treating 400K as a sustainable ceiling. Checkpoint write traffic is approximately 10 writes per second, while larger artifacts are offloaded to blob storage. Temporal manages roughly 10K long-lived workflows alongside 1K concurrent approval waits, where workflow history retention and large workflow payloads are important cost and reliability concerns for 24-hour gates. The message bus handles roughly 6K events per minute as an asynchronous observability pipeline rather than a synchronous routing dependency.

Architecture Diagram

Frame the system as a state graph rather than a linear pipeline. Unlike the single ReAct loop inside a microVM featured in Autonomous Cloud Coding Agent, a supervisor LLM inspects shared state and dynamically routes tasks to specialized workers (researcher, coder, and reviewer) until goals are met or budgets are exhausted.

The runtime persists authoritative shared state and records checkpoints every N steps, delegating durability to Workflow Orchestration (Temporal) so multi-day runs survive worker restarts and operator review pauses. All LLM inference routes through the LLM Gateway, while retrieval tools query the Document QA Platform (RAG) and Vector Database as needed.

The architecture divides into three tiers: the graph API and streaming gateway, the supervisor-worker executor with tool routing, and the checkpoint and event store. Human-in-the-loop gates act as first-class graph nodes, pausing regulated workflows until operators approve external side effects.

Loading...

In the room

Contrast with Autonomous Cloud Coding Agent early: multi-agent architectures introduce supervisor routing overhead but enable composable domain expertise and selective approval gates. If asked about shared state vs messaging, advocate for authoritative JSON state complemented by append-only event logs as detailed in Event Sourcing and CQRS.

Component Deep Dives

1. Supervisor-Worker State Graph ⭐

Next we explore each architectural component. Supervisor routing and durable execution form the operational core, while role-scoped tool allowlists prevent privilege escalation by underlying models.

The graph operates as a state machine rather than a DAG batch pipeline. After each worker completes, control returns to the supervisor node, which evaluates the updated shared state and determines the next hop, including cycles between coder and reviewer or routing to the terminal END state.

Loading...
System: You are the supervisor router for a multi-agent workflow.
You read the shared graph state and decide which specialized worker runs next.

Shared state (authoritative):
  task: string
  artifacts: {type, content_ref, producer_agent}[]
  open_questions: string[]
  budget: {tokens_remaining, usd_remaining, wall_clock_deadline}
  hitl_pending: boolean

Available next nodes:
  - researcher: web search, document RAG, summarize sources
  - coder: draft and edit documents, optional cloud sandbox execution
  - reviewer: policy check, redline, compliance flags
  - human_gate: pause until operator approves (required before external send)
  - END: task complete, emit final artifact

Rules:
  - Never route to coder until researcher has at least one cited source (unless task is code-only).
  - Route to human_gate before any action with external side effects (email, PR merge, API write).
  - If budget.tokens_remaining < 10%: prefer reviewer summary + END over more research.
  - Output JSON only: {"next_node": "...", "reason": "...", "state_patch": {...}}

2. Shared State vs Message Passing

Shared state serves as the architectural default: a single structured JSON document exists per run and is patched after each node execution. Both the supervisor and worker agents inspect the same artifacts and budget meters, comfortably scaling to roughly 256 KB of structured metadata per run.

  • Pros: Presents a clean mental model (matching LangGraph StateGraph), provides the supervisor with a global view of task progress, and simplifies human-in-the-loop preview generation.
  • Cons: Creates a hot database row requiring frequent transactional updates, necessitating that large artifacts are stored as blob references rather than embedded inline.
  • Message passing complement: Appends events to Message Queues for analytics and downstream ingestion, ensuring worker execution never depends on broker availability for correctness.
  • Replay recovery: Reconstructs state from the event log via Event Sourcing and CQRS in the event of checkpoint corruption.

3. Tool Router and Specialized Agents

Role-scoped tool allowlists enforce strict least privilege across workers, preventing sensitive data exfiltration or unintended resource allocation.

  • Researcher: Restricted to web_search, rag_query (via Document QA Platform backed by Vector Database), and summarize, with no mutation rights on external systems.
  • Coder: Authorized for write_artifact and edit_section, with optional access to spawn_sandbox delegating to an Autonomous Cloud Coding Agent environment for code validation.
  • Reviewer: Permitted to run policy_check, redline, and append review comments into shared state, with network and sandbox tools completely blocked.
  • Supervisor: Limited exclusively to routing decisions without direct tool invocation capabilities. Worker credentials and the tool router remain the enforcement boundary, so the supervisor model cannot grant itself a privileged tool.

4. Durable Execution via Temporal and Checkpointing ⭐

Each graph run maps directly to a dedicated Workflow Orchestration (Temporal) workflow. Node executions run as discrete activities equipped with timeouts, heartbeats, and retry policies. Checkpointing every N steps materializes shared state to ensure rapid worker recovery.

Per-node cost/latency budgets (enforced before dispatch):

Node            Max tokens   Max latency   Model tier (via LLM Gateway)
────────────────────────────────────────────────────────────────────────
supervisor      4K           3s p95        fast router (Haiku / GPT-4o-mini)
researcher      32K          60s p95       Sonnet + tool calls
coder           48K          120s p95      Sonnet, cloud sandbox billed separately
reviewer        16K          30s p95       Sonnet or dedicated compliance model
human_gate      0            24h SLA       no LLM, Temporal timer

Global run budget is waterfall: child nodes cannot exceed run.tokens_remaining.
On breach: supervisor forced-routes to END with partial artifact + budget_exhausted flag.

Checkpoint every N=5 steps (configurable):
  - Persist full shared state to graph_checkpoints at the checkpoint boundary
  - Append GraphCheckpointCreated to graph_events (append-only log)
  - Await the durable checkpoint before dispatching the next node so the recovery point is committed
  - Low N causes write amplification, while high N increases replay cost on failure
  • Workflow lifecycle: Coordinates the supervisor loop, activity dispatch, checkpoint persistence, and graph-version pinning across process restarts. Long runs use continue-as-new before workflow history approaches configured limits.
  • Idempotent activities: Uses idempotency keys (as detailed in Idempotency and Exactly-Once Effects) on tool executions to avoid duplicate side effects upon retry.
  • Signals: Handles external events such as approval, rejection, run cancellation, or runtime operator steering hints merged into the state patch.

5. Human-in-the-Loop Gates

Human-in-the-loop nodes suspend workflow execution until an external signal arrives. Unlike the continuous inline suggestions of an AI Coding Assistant or the fully autonomous execution of an Autonomous Cloud Coding Agent, here operator review represents a first-class graph node reserved for sensitive or regulated actions.

  • Triggers: Activated prior to outbound email dispatch, pull request merges, or high-risk tool operations.
  • Reviewer UI: Presents artifact previews referenced directly from shared state, where approve or reject button clicks invoke the signaling endpoint.
  • Timeouts: Applies a configurable 24-hour SLA to either escalate to an alternate reviewer or gracefully fail the run according to tenant policy.

6. Streaming and Observability

Operators watch multi-agent graphs execute in real time. Stale telemetry degrades trust in approval previews, requiring node transitions to stream with sub-second latency.

  • Event stream: Emits granular events including node_started, state_patch, checkpoint, hitl_required, node_completed, and completed.
  • Reconnection handling: Uses the Last-Event-ID header backed by a Redis stream buffer with a one-hour time-to-live to ensure gapless replay upon client reconnection.
  • Cost attribution: Appends consumed tokens, computed dollar cost, and elapsed execution latency to every node_completed event for real-time tenant quota tracking.

API Design

Create Graph Run

Graph run initialization pins an immutable graph version and includes budget ceilings and checkpoint intervals, with the orchestrator enforcing waterfall spending limits across the supervisor and worker nodes. Human-in-the-loop approval and rejection endpoints enforce idempotency keys (as explored in Idempotency and Exactly-Once Effects) to ensure repeated clicks cannot cause duplicate external actions.

HTTP
POST /api/v1/graph-runs
Authorization: Bearer <token>
Content-Type: application/json
Idempotency-Key: run-create-7f3a

{
  "graph_id": "memo-with-legal-review-v2",
  "input": {
    "task": "Research ACME Q3 earnings and draft an investor memo",
    "constraints": ["cite all figures", "no forward-looking statements without disclaimer"]
  },
  "budget": {
    "max_tokens": 200000,
    "max_usd": 12.00,
    "max_wall_clock_minutes": 90
  },
  "checkpoint_policy": {
    "every_n_steps": 5,
    "on_hitl": true
  },
  "options": {
    "enable_rag": true,
    "enable_sandbox": false
  }
}

Response: 201 Created
{
  "run_id": "grun_9x2k4m",
  "status": "RUNNING",
  "stream_url": "https://orchestrator.example.com/api/v1/graph-runs/grun_9x2k4m/stream"
}

Stream Run Events (SSE)

HTTP
GET /api/v1/graph-runs/grun_9x2k4m/stream
Authorization: Bearer <token>
Accept: text/event-stream

HTTP/1.1 200 OK
Content-Type: text/event-stream

event: node_started
data: {"step": 3, "node": "researcher", "budget": {"tokens_used": 18400}}

event: state_patch
data: {"artifacts_added": [{"type": "research_brief", "ref": "blob://art_3f2"}], "open_questions": []}

event: checkpoint
data: {"checkpoint_id": "ckpt_5", "step": 5, "state_hash": "sha256:..."}

event: hitl_required
data: {"gate": "legal_review", "preview_ref": "blob://memo_draft_v2", "expires_at": "..."}

event: node_completed
data: {"step": 7, "node": "reviewer", "latency_ms": 4200, "tokens": 6200}

event: completed
data: {"status": "COMPLETED", "final_artifact_ref": "blob://memo_final", "cost_usd": 4.82}

HitL Approve / Reject

HTTP
POST /api/v1/graph-runs/grun_9x2k4m/hitl/legal_review/approve
Authorization: Bearer <token>
Idempotency-Key: hitl-approve-7f3a

{
  "comment": "Disclaimer added and approved for distribution"
}

Response: 200 OK
{
  "run_id": "grun_9x2k4m",
  "status": "RUNNING",
  "resumed_at": "2026-07-01T14:22:01Z"
}

Common API Errors

400 Bad Request: invalid input, missing required fields, or malformed JSON payload
401 Unauthorized: missing or invalid authentication token or API key
403 Forbidden: authenticated caller lacks required permissions for this resource
404 Not Found: requested resource ID does not exist
409 Conflict: duplicate write or version conflict, retry with a unique idempotency key
422 Unprocessable Entity: syntactically valid request failed semantic business validation
429 Too Many Requests: rate limit quota exceeded, client should honor Retry-After header
500 Internal Error: unexpected server failure, retry safely with an idempotency key
503 Service Unavailable: downstream dependency is unavailable or overloaded, retry with exponential backoff
440 Login Timeout: WebSocket connection session expired, client reconnect is required
202 Accepted: asynchronous job queued successfully, poll GET /jobs/{id} for completion status
408 Request Timeout: background job is still executing, continue polling status endpoint
402 Payment Required: requested run budget exceeds the tenant allowance, so increase the permitted budget or abort. Running workflows terminate with budget_exhausted when their runtime budget is exhausted.
412 Precondition Failed: requested run mutation conflicts with a WAITING_HITL state, so use the HitL approval or rejection endpoint

Data Model

Graph runs persist authoritative shared state snapshots inside graph_checkpoints, while graph_events records an append-only audit log adhering to Event Sourcing and CQRS principles. Approval records maintain durable state transitions linked directly to Temporal workflow signal histories.

SQL
-- Shared graph state and durable checkpoints (event log and workflow history)

CREATE TABLE graph_runs (
    run_id           UUID PRIMARY KEY,
    tenant_id        UUID NOT NULL,
    graph_id         TEXT NOT NULL,
    graph_version    TEXT NOT NULL,           -- immutable graph definition pinned for this run
    status           TEXT NOT NULL,          -- RUNNING, WAITING_HITL, COMPLETED, FAILED
    input            JSONB NOT NULL,
    budget           JSONB NOT NULL,
    state_version    BIGINT NOT NULL DEFAULT 0,
    created_at       TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE graph_checkpoints (
    run_id           UUID NOT NULL,
    checkpoint_id    BIGINT NOT NULL,        -- monotonic per run
    step             INT NOT NULL,
    state_version    BIGINT NOT NULL,
    node             TEXT,                   -- last completed node
    state_blob       JSONB NOT NULL,         -- full shared state snapshot
    state_hash       TEXT NOT NULL,
    created_at       TIMESTAMPTZ DEFAULT now(),
    PRIMARY KEY (run_id, checkpoint_id)
);

CREATE TABLE graph_events (
    run_id           UUID NOT NULL,
    event_id         BIGINT NOT NULL,
    event_type       TEXT NOT NULL,          -- NodeStarted, StatePatched, HitlSignaled, ...
    payload          JSONB NOT NULL,
    idempotency_key  TEXT,                   -- deduplicates effect attempts within a run
    created_at       TIMESTAMPTZ DEFAULT now(),
    PRIMARY KEY (run_id, event_id),
    UNIQUE (run_id, idempotency_key)
);

CREATE TABLE hitl_approvals (
    run_id           UUID NOT NULL,
    gate_id          TEXT NOT NULL,
    status           TEXT NOT NULL,          -- PENDING, APPROVED, REJECTED
    reviewer_id      UUID,
    decided_at       TIMESTAMPTZ,
    PRIMARY KEY (run_id, gate_id)
);

Fault Tolerance

Failure CaseSystem Solution Design
Graph executor worker crash mid-nodeTemporal retries a failed activity according to its retry policy, where a retry normally starts the activity again rather than resuming from an arbitrary acknowledgement point. Heartbeats can record resumable progress for long-running activities, while graph checkpoints restore completed nodes after a worker crash. Idempotent tools and a durable effect ledger suppress duplicate external side effects.
Supervisor routes to invalid nodeSchema validation rejects malformed node destinations, triggering a retry with the routing error feedback injected into prompt context and failing the run if three invalid routes occur consecutively.
Shared state patch conflictOptimistic checks on the monotonic state_version reject stale patches, prompting the supervisor to re-read the latest validated checkpoint. The state hash remains a content-integrity and deduplication aid rather than the concurrency version.
LLM rate limit (429) from model gatewayThe activity enters exponential backoff and emits a waiting status event to client streams. Provider backoff does not bypass the overall wall-clock run budget, and the activity timeout policy must leave enough margin for the configured retry schedule.
Human-in-the-loop signal delivery failureThe approval endpoint is idempotent, using unique idempotency keys and a durable approval record to deduplicate repeated signals while the client interface polls run state. The post-approval effect activity reuses a durable effect key so a workflow retry cannot submit the external mutation twice when the downstream system supports idempotency.
Checkpoint database unavailableThe runtime fails closed at checkpoint boundaries by pausing new node dispatches when the authoritative state store is unavailable. In-flight activities continue only when their results can be safely replayed or their side effects are protected by idempotency. Processing resumes after state-store recovery, with an alert if downtime exceeds 60 seconds.

Additional Considerations

Interview Walkthrough

  • 25-minute interview pacing:

    Skip internal scheduler algorithms unless targeting staff-level evaluation.

    • 5 minutes: Contrast with Autonomous Cloud Coding Agent, highlighting multi-agent supervisor coordination vs single-sandbox ReAct loops.
    • 6 minutes: State graph architecture covering supervisor routing, specialized agents (researcher, coder, reviewer), and human-in-the-loop gates.
    • 5 minutes: Shared state store paired with event logging (Event Sourcing), contrasting against chat transcript histories.
    • 5 minutes: Durable execution using Workflow Orchestration (Temporal) and checkpointing intervals.
    • 4 minutes: Per-node budget waterfall at the LLM Gateway and supervisor fallback strategies.
  • Frame architectural trade-offs vs an Autonomous Cloud Coding Agent: multi-agent graphs introduce supervisor routing overhead but enable composable specialist models and selective governance.
  • Illustrate the state graph: supervisor evaluates shared state, delegates to researcher, coder, or reviewer, and loops until completion, with approval gates acting as blocking nodes.
  • Authoritative shared state store backed by event logs (Event Sourcing), justifying why raw chat histories break down at scale.
  • Durable execution: explain how Workflow Orchestration (Temporal) manages multi-day wait timers, retries, and checkpoint restoration upon worker crashes.
  • Cost governance: enforce strict token and dollar ceilings at the LLM Gateway with automated supervisor termination on budget depletion.
  • Human-in-the-loop mechanics: leverage workflow signals and ensure Idempotency Guarantees on approval APIs.
  • Integration ecosystem: route retrieval to Document QA Platform (RAG) and Vector Database, and sandbox execution to Autonomous Cloud Coding Agent, maintaining role-based tool allowlists.
  • Scale to 10K runs: shard by tenant across workflow queues and isolate telemetry onto Message Queues off the critical path.
  • Contrast with local developer copilots: an AI Coding Assistant relies on continuous inline human approval, whereas orchestration platforms apply selective gates for high-stakes actions.

Engineering Trade-offs

Multi-Agent Graph vs Single Autonomous Agent

An Autonomous Cloud Coding Agent optimizes for deep autonomous coding within a single environment. In contrast, an orchestration platform optimizes for composable expertise and modular governance, allowing the researcher and reviewer to employ different models, prompts, and budget tiers. The trade-off is that supervisor routing adds latency and token overhead, meaning simpler tasks should remain on single-agent loops.

Shared State vs Pure Message Passing

Shared state simplifies supervisor routing decisions and approval preview generation, though it centralizes transactional database writes. Pure actor message passing scales horizontally for massive agent swarms but complicates global budget enforcement and deterministic audits. A hybrid design featuring authoritative relational state alongside an asynchronous event bus provides the optimal production architecture.

Checkpoint Frequency (N)

A low checkpoint interval improves recovery point objectives but amplifies database write throughput. A high interval reduces write overhead but forces the system to replay more costly LLM turns after a worker crash. Checkpointing every N=5 steps serves as a robust baseline. Large states should move to blob references and delta patches rather than forcing full JSON snapshots, with the threshold chosen from measured serialization and storage costs rather than a fixed universal cutoff.

Synchronous Approval vs Fully Autonomous Execution

Selective approval gates can introduce days of wall-clock latency while waiting for humans, yet they are essential for regulated and high-risk workflows. Fully autonomous execution suits internal exploratory drafts, whereas approval gates remain enabled by default for external communications. This behavior is configured per graph edge rather than through a global toggle.

💬Review

Help Us Improve

How helpful was this walkthrough?

Click a star to rate. We actively use this feedback to refine and update our system design content.

Placeholder
Optional but highly appreciated!

Discussion

Share your thoughts, ask questions, or help others.

Loading comments...