Mar 1, 2026 · Lab notes · 7 min
The systems around an AI agent
An AI application that can act needs more than a model response. It needs a runtime to execute tools, retain state, enforce permissions and expose failures. A single model call remains appropriate for bounded tasks. This article examines the additional system needed when a workflow delegates several steps to an agent.
Comparing runtimes
Framework documentation provides evidence of implementation choices, not a reliable ranking of production adoption. The useful comparison is how each framework handles state, tool execution, interruption and review.
| Comparison | Question to test |
|---|---|
| State | Can interrupted work resume without duplicating actions? |
| Authority | Which operations are blocked or require approval? |
| Evidence | Can a reviewer recover the inputs and tool results? |
| Cost | What is the cost per accepted result, including review? |
We use “harness” to mean the application runtime around a model: the code that dispatches tool requests, manages execution state and decides what can proceed. Some frameworks supply these facilities; others expect the application to implement them. A model can propose the next action, while the surrounding system determines whether that action is permitted.
Anatomy of a harness
Several useful concepts recur, but they are not universal guarantees. An agent combines a model with instructions and tools. A handoff transfers work or control. A session retains conversation state. Guardrails validate selected inputs, outputs or operations. A trace records observable execution events. It does not reveal every internal model decision or establish that the model’s explanation is faithful.
graph TB
INPUT((Input)) --> G_IN
subgraph Harness["Agent Harness"]
G_IN["Input Guardrails"] --> AGENT["Agent · LLM"]
AGENT <--> TOOLS["Tools · MCP, APIs"]
AGENT <--> STATE["State · Memory"]
AGENT --> G_OUT["Output Guardrails"]
end
G_OUT --> OUTPUT((Output))
style Harness fill:none,stroke:#0a0a0a
style AGENT fill:#e8e8e8,color:#0a0a0a,stroke:#0a0a0a
OpenAI Agents SDK documentation describes agents, handoffs, guardrails, sessions and tracing. Google ADK workflow documentation describes sequential, parallel and loop workflow agents. Microsoft’s October 1, 2025 announcement describes the convergence of AutoGen and Semantic Kernel. Claude Agent SDK documentation describes programmatic access to Claude Code’s agent loop and tools.
Framework comparison
| Primary documentation | Documented focus | Review question |
|---|---|---|
| OpenAI Agents SDK documentation | Agents, handoffs and execution tracing | Does the trace cover the operations you need to review? |
| Google ADK workflow documentation | Sequential, parallel and loop workflows | Which steps should remain deterministic? |
| Claude Agent SDK | Claude Code agent loop and tools | Can permissions constrain the intended workflow? |
| Microsoft’s October 1, 2025 announcement | Agent and workflow framework | Does the selected implementation support your integration? |
| CrewAI | Agents, crews and flows | How are role boundaries and shared state defined? |
| LangGraph | Stateful graph orchestration | Which transitions are deterministic? |
| Agno | Agent runtime and service interfaces | How are execution, storage and permissions configured? |
| Mastra | TypeScript agents and workflows | Does the workflow fit the application’s existing runtime? |
| Pydantic AI | Typed agent inputs and outputs | What happens when output validation fails? |
From chatbots to autonomous systems
The operational distinction is the degree of control delegated to the model. A fixed workflow can call a model without allowing it to choose arbitrary actions. An agent loop may choose tools and revise its plan. Anthropic’s workflow and agent distinction is useful here: start with the simplest design that works and add autonomy when the task benefits from it.
A coding workflow can illustrate the boundary. The system reads selected files, proposes an edit, runs checks and returns a reviewable change. Access to a repository does not require access to production credentials. The review record should identify the changed files and test results, including failures.
| Coding task measure | Keep separate from |
|---|---|
| Accepted change | Generated lines or suggested edits |
| Verified result | A successful-looking model response |
| Human intervention | Total time using an assistant |
| Deployment permission | Permission to edit a local branch |
Apple’s February 3, 2026 announcement describes Xcode 26.3 support for Claude Agent and Codex, including documentation search, project changes, previews and build iteration. It also describes access through MCP. The announcement date was February 3, not February 26. These are product capabilities; they do not establish how much engineering work can safely be delegated without review.
The human-in-the-loop reality
Measure assistance and delegation separately. Time spent using an assistant, code suggested, code accepted and tasks completed without intervention answer different questions. A deployment review should record the task population, success criteria, human corrections and failures. Without those definitions, an adoption percentage cannot establish operational autonomy.
graph LR
subgraph "Supervision Spectrum"
direction LR
A["Full Human
Control"] --- B["Human Approves
All Actions"] --- C["Human Approves
High-Risk Only"] --- D["Human Notified
Post-Action"] --- E["Full Agent
Autonomy"]
end
STAGING["Isolated evaluation
with explicit limits"] -.->|"possible policy"| D
PROD["External mutations"] -.->|"example approval policy"| B
style C fill:#e8e8e8,color:#0a0a0a,stroke:#0a0a0a
The supervision boundary belongs in executable policy. Define which files, accounts and services the runtime may access; which operations require approval; and what happens after a timeout or uncertain result. Staging can still contain sensitive data or expensive resources. Use separate credentials and test approval behavior in each environment. Instructions to a model complement these controls but do not replace them.
Multi-agent design patterns
Three illustrative orchestration patterns are useful to compare. The diagrams describe design options, not measured market shares or mandatory framework behavior:
graph LR
subgraph "Sequential Pipeline"
direction LR
R["Researcher"] -->|findings| A["Analyst"] -->|conclusions| W["Writer"]
end
graph TB
subgraph "Hierarchical Delegation"
direction TB
LEAD["Lead Agent"] -->|assign| W1["Worker A"]
LEAD -->|assign| W2["Worker B"]
LEAD -->|assign| W3["Worker C"]
W1 -.->|result| LEAD
W2 -.->|result| LEAD
W3 -.->|result| LEAD
end
style LEAD fill:#e8e8e8,color:#0a0a0a,stroke:#0a0a0a
graph TB
subgraph "Competitive Evaluation"
direction TB
TASK["Task"] --> A1["Agent A"]
TASK --> A2["Agent B"]
TASK --> A3["Agent C"]
A1 -.-> JUDGE["Judge Agent"]
A2 -.-> JUDGE
A3 -.-> JUDGE
JUDGE --> BEST["Best Output"]
end
style JUDGE fill:#e8e8e8,color:#0a0a0a,stroke:#0a0a0a
Sequential pipelines chain specialists. A researcher agent feeds findings to an analyst agent, which feeds conclusions to a writer agent. Each agent has narrow expertise and clear input/output contracts. Hierarchical delegation uses a lead agent that decomposes complex tasks and assigns sub-tasks to specialized workers, monitoring progress and reassigning on failure. Competitive evaluation runs multiple agents on the same task in parallel and uses a judge agent to select or synthesize the best output.
Our recommendation is to make coordination explicit. Specify roles, input contracts, ownership of shared state and fallback behavior. A worker that cannot complete a task should return evidence of the failure rather than silently widening its authority. Test the simplest single-agent or deterministic workflow before adding workers: parallel activity alone does not establish better results.
The protocol integration
MCP, A2A and AG-UI address different interfaces. They can appear in the same application, but this is an optional architecture rather than a required three-layer stack. A system may use a direct API, an internal queue or a conventional web interface where that is simpler.
graph TB USER((User)) --> AGUI["AG-UI · Human Interface"] AGUI --> APP["Your Application"] APP --> HARNESS["Agent Harnesses
LangGraph, Claude SDK, CrewAI, ADK"] HARNESS --> A2A["A2A · Agent ↔ Agent"] HARNESS --> MCP2["MCP · Agent ↔ Tool"] MCP2 --> INFRA["Databases, APIs, File Systems"] style APP fill:#e8e8e8,color:#0a0a0a,stroke:#0a0a0a style HARNESS fill:#e8e8e8,color:#0a0a0a,stroke:#0a0a0a
MCP’s June 2025 architecture separates hosts, clients and servers for tools and data. A2A v0.3.0 defines messages, tasks and artifacts between agent services. AG-UI documentation describes an event-based agent/frontend interface; it is not restricted to SSE. These sources establish interface roles, not universal implementation support.
Shared interfaces can reduce adapter work. Compatibility still depends on versions, supported capabilities, authentication and the meaning of the data exchanged. An integration test should exercise errors, cancellation, duplicate requests and reconnects, not only the successful path. A protocol connection does not grant authority to perform an external action.
The governance gap
Consider three concrete failure modes in the illustrated system. A retrieved document can contain instructions that attempt to redirect the agent. An overprivileged tool can make a mistaken request destructive. A retried operation can duplicate a payment or mutation. Treat retrieved content as data, constrain credentials and design idempotent operations where possible. These are design recommendations to test against the workflow’s actual permissions and failure modes.
| Control | Evidence to retain |
|---|---|
| Scope | Allowed tools and resources |
| Approval | Decision and authorized operation |
| Recovery | Timeout, cancellation and retry behavior |
| Evaluation | Representative tasks and observed failures |
Anthropic’s June 13, 2025 research-system report says its multi-agent systems used about fifteen times the tokens of chats. That is an observation about its reported workload, not a universal cost multiplier. For a proposed deployment, measure completed-task cost including model calls, tools, retries and review time. Compare that cost with a simpler baseline at the same quality threshold.
Where this is going
Our thesis is that orchestration deserves evaluation alongside model quality. A system with a strong model can still fail through weak permissions, missing state or poor recovery. Conversely, adding an elaborate harness to a simple task can increase latency and maintenance without improving the outcome.
A useful analogy: a model supplies inference, context holds working information and the runtime coordinates actions. This is a design analogy, not a claim that language models and operating systems have equivalent guarantees. The practical test is whether the complete system is easier to inspect, constrain and recover.
Evaluate the finished workflow against representative tasks. Retain the inputs, tool results, permission decisions, checks and human corrections. Expand autonomy only when that evidence supports it. A reviewable outcome is more useful than a larger agent count.
Factual review: October 26, 2026. Original publication date retained. Primary sources are linked alongside the revised claims. Framework documentation describes the reviewed versions, not a reconstruction of every March 2026 feature.