Day 17/20 of AI Agent Systems Series ARC 4: Production Systems - Human in the Loop as Architecture an agent that deletes the wrong S3 bucket, commits a breaking change to main, or triggers a large unexpected API bill does not pause and ask. it just acts. fully autonomous agents are useful in controlled environments. in production, most teams find they need deliberate points where a human reviews, approves, or edits what the agent is about to do. this is not a lack of trust in the model. it is a recognition that some actions carry consequences that are hard or impossible to reverse, and the cost of being wrong once outweighs the cost of adding a gate. the way most teams first implement this: a simple prompt. "should i proceed? y/n" the way it needs to work in production is architecturally different from that. HITL is not a pause button. it is an async state management problem. here is why.

the core architecture: serialize, wait, resume. when an agent hits an interrupt, it should not hold an open connection waiting for a human. humans take minutes, hours, sometimes days. the correct pattern: > agent reaches interrupt condition > serializes full graph state to a checkpoint store > returns control to the caller > caller routes the interrupt to whatever surface the human will see (UI, Slack, email) > human responds > system loads the checkpoint by thread_id > execution resumes from the exact node that interrupted > no re-running from the top LangGraph gives you two interrupt mechanisms to reach that checkpoint: static breakpoints: declared at compile time. always interrupts at a specific node, regardless of what the agent has done or decided. useful for mandatory review gates. dynamic interrupts: raised from inside a node at runtime, based on the current state. the node inspects what it is about to do and decides whether this specific action warrants a pause. more flexible, more powerful. once interrupted, a human has four options: > approve the action as-is > edit the action before it runs > reject it with feedback the agent can use > respond directly to an "ask user" style query the thread_id is what makes resumption work. it is a persistent cursor, the primary key for the conversation state. every checkpoint is stored against it. the system loads that checkpoint, the human's decision gets written into state, and Command resumes execution. LangGraph also allows "time travel": invoking the graph with a specific checkpoint_id to fork execution from a prior state, useful for exploring what would have happened if a human had approved differently.

Day 16/20 of AI Agent Systems Series ARC 4: Production Systems - Permission and Security Architecture an AI agent with full filesystem access, shell access, and network access is not a feature. it is a liability waiting for the wrong prompt. Claude Code's permission system is one of the more thought-through examples of how to handle this at the architecture level. a recent source-level analysis (arXiv, 2026) found the permission system follows four design principles: > deny-first with human escalation > a graduated trust spectrum > defense in depth through layered mechanisms > reversibility-weighted risk assessment every tool call passes through this system before execution. the default behavior is to deny or ask, never to allow silently. here is how that actually plays out in practice.

by default, Claude Code runs with strict read-only permissions. reading files, grep, git status, basic navigation, these run without a prompt. the moment an action could modify something, write a file, run a command that changes state, make a network call, the permission system steps in and asks before proceeding. as of mid-2026, the official docs describe the evaluation order as deny, then ask, then allow. deny rules are checked first and cannot be overridden by anything downstream, including hooks. this is the graduated trust spectrum in practice. not every action gets the same scrutiny read operations are cheap to allow. write and execute operations get a prompt. operations that are hard to reverse, deleting files, pushing to git, running destructive database commands, get the strongest scrutiny regardless of what mode the session is running in. there are several permission modes available,each trading oversight for speed differently. default mode keeps every action visible. acceptEdits assumes file edits are low risk once you know the codebase, but still prompts for bash commands and anything touching the system outside the editor. then there is bypassPermissions, sometimes called "YOLO mode." it disables permission checks entirely. the documentation is honest about this: it exists for automated pipelines with no human in the loop, and using it on a main developmentmachine is generally discouraged. permissions are one layer. sandboxing is the other. permissions control which tools and files an agent can touch. sandboxing enforces that at the OS level, restricting what a bash command and its child processes can actually reach on disk and over the network. the two layers are complementary, not redundant. permissions can be reasoned about and configured. sandboxing holds even if the permission layer is somehow bypassed.

Day 15/20 of AI Agent Systems Series ARC 3: Multi-Agent Orchestration - Handoff Object Design Recent industry analyses suggest orchestration design is a major source of production failures. not the models. not the tools. not the prompts. how agents coordinated with each other. the handoff boundary is one of the highest-leverage failure points in multi-agent systems. agent A completes its work and passes to agent B. what exactly gets passed, in what format, with what context, is usually left vague. that vagueness is the failure mode. the handoff object is a design artifact. it needs to be treated like one. what goes in, what stays out, and what gets transformed at the boundary determines whether the next agent starts informed or starts confused.

here is how major frameworks approach the handoff object differently. OPENAI AGENTS SDK made a breaking change to handoff behavior. prior versions passed the raw message history between agents. v0.6.0 collapsed that history into a single context message with the header: "For context, here is the conversation so far between the user and the previous agent." why: raw history passed between agents created context pollution at scale. agent B received everything agent A saw, regardless of relevance. the compression trades fidelity for focus. GOOGLE ADK takes a more explicit approach with two modes: agents as tools: the callee sees only a focused prompt and the necessary artifacts. no history. clean context. call it, get a result. agent transfer: the sub-agent inherits a view over the full session. the include_contents knob on the callee controls exactly how much flows through. the architectural choice is explicit: teams decide per handoff how much context the receiving agent gets. no implicit defaults. this design forces a useful question before every handoff is wired up: does this sub-agent genuinely need the full history, or just the relevant slice? Manus reported roughly a 10x cost difference between cached and uncached tokens in parts of its production system. passing too much context at handoffs is not just an accuracy risk. it is a unit economics problem.

Day 14/20 of AI Agent Systems Series ARC 3: Multi-Agent Orchestration - Agent as Tool most multi-agent systems are wired through message passing. agent A finishes, sends a message to agent B, agent B reads it, runs, sends to agent C. it works. it also means every agent in the system is tightly coupled to the message format of every other agent. change how agent A formats its output and agent B breaks. test agent B in isolation and you need to simulate agent A's messages exactly. LangGraph's subgraph pattern takes a different approach. wrap each agent as a node. give it a typed input, an isolated state, and a declared typed output. the parent graph sees it as a function call,not a conversation participant. that one architectural decision changes what you can do with the agent later. here is why it matters in practice.

a subgraph in LangGraph is a complete StateGraph used as a node inside another graph. it has its own TypedDict state, its own nodes, its own edges, its own internal reasoning loop. none of that is visible to the parent graph. the parent graph only sees: > what goes in (the typed input) > what comes out (the declared output keys) two modes depending on your architecture: SHARED STATE SCHEMA parent and subgraph share the same state keys. the subgraph reads directly from parent state and writes back to it. simpler to wire, tighter coupling between parent and subgraph. DIFFERENT STATE SCHEMAS parent and subgraph have different state structures. a transformation node sits between them, converts parent state into subgraph input before entry, converts subgraph output back into parent state on exit. more code upfront, but the subgraph becomes fully independent of the parent's state shape. the second mode is what enables real composability. when a subgraph does not depend on the parent's state structure, it can be: > tested completely in isolation, no parent graph needed > versioned and updated without touching the parent > deployed as a separate service on LangGraph Platform > swapped for a different implementation without changing a single line of parent graph code LangGraph Platform (GA May 2025) supports deploying subgraphs as independent services. the parent graph calls them over the network the same way it would call a local node.the interface contract is the same either way.

Day 13/20 of AI Agent Systems Series ARC 3: Multi-Agent Orchestration - The Swarm Pattern the Supervisor Pattern introduces a central coordination point: the supervisor. if the supervisor makes a bad routing decision,every downstream agent acts on it . if it becomes a bottleneck at scale, every worker waits behind it. the Swarm Pattern removes the supervisor entirely.agents hand off to each other based on context,with no central coordinator deciding who goes next. OpenAI popularized this pattern through the Swarm framework in October 2024. Swarm was later superseded by the OpenAI Agents SDK, which kept the same core handoff model while adding production features. same conceptual model, adds guardrails, tracing, and TypeScript support on top. the pattern survived the deprecation. the primitives are in production at scale. but most people have a fundamental misconception about how it works.

the misconception first: Swarm is not parallel. this catches most people. in the Swarm pattern, only one agent is active at any given time. it is sequential control transfer, not concurrent execution. agent A runs, decides it needs to hand off, passes control to agent B, agent B runs. one active agent throughout. fan-out parallelism multiple agents running simultaneously on independent sub-tasks requires a coordinator. Swarm explicitly removes the coordinator, so it does not give you parallelism. it gives you decentralized sequential routing. here is how the pattern actually works. two primitives only: AGENTS an agent is a system prompt plus a list of functions. that is it. the functions define what the agent can do and who it can hand off to. HANDOFFS a handoff is a function that returns a different agent object. when the current agent calls that function,the framework switches the active agent and continues. the entire API surface of the original Swarm: > define agents with instructions and tools > define handoff functions that return other agents > call run() with a message > the framework routes through agents until done the framework is stateless no persistent state between calls. every handoff must carry all the context the next agent needs in the conversation history. no hidden state. no memory between runs. OpenAI Agents SDK (March 2025) added what original Swarm deliberately left out: > guardrails (input/output validation) > built-in tracing per handoff > persistent state management > TypeScript support the pattern is identical. the production runtime is the Agents SDK, not the original Swarm repo.