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.

Person pointing at code displayed on a tablet next to a keyboard

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.

ComparisonQuestion to test
StateCan interrupted work resume without duplicating actions?
AuthorityWhich operations are blocked or require approval?
EvidenceCan a reviewer recover the inputs and tool results?
CostWhat 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
          
Anatomy of an agent harness: the runtime around the model

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 documentationDocumented focusReview question
OpenAI Agents SDK documentationAgents, handoffs and execution tracingDoes the trace cover the operations you need to review?
Google ADK workflow documentationSequential, parallel and loop workflowsWhich steps should remain deterministic?
Claude Agent SDKClaude Code agent loop and toolsCan permissions constrain the intended workflow?
Microsoft’s October 1, 2025 announcementAgent and workflow frameworkDoes the selected implementation support your integration?
CrewAIAgents, crews and flowsHow are role boundaries and shared state defined?
LangGraphStateful graph orchestrationWhich transitions are deterministic?
AgnoAgent runtime and service interfacesHow are execution, storage and permissions configured?
MastraTypeScript agents and workflowsDoes the workflow fit the application’s existing runtime?
Pydantic AITyped agent inputs and outputsWhat 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 measureKeep separate from
Accepted changeGenerated lines or suggested edits
Verified resultA successful-looking model response
Human interventionTotal time using an assistant
Deployment permissionPermission 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
Illustrative supervision choices. Environment names alone do not determine safe authority.

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
          
Three multi-agent patterns: solid arrows send work, dashed arrows return results

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
Illustrative interfaces: MCP for tools, A2A for agent services, AG-UI for frontends

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.

ControlEvidence to retain
ScopeAllowed tools and resources
ApprovalDecision and authorized operation
RecoveryTimeout, cancellation and retry behavior
EvaluationRepresentative 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.

← Articles