Skip to main content

AI Harness

When one agent has to do everything, what breaks first — cost, security, or reliability?

An agent is deterministic software that harnesses the non-deterministic results of a model in pursuit of an objective. The harness is that deterministic wrapper: the loop, tools, rules, and context assembly. For design purposes, treat a harness as an agent and an agent as a harness. The useful question is not what to call it but how to structure it so it stays reliable as it grows.

This page teaches the architectural choice that decides that: inheritance vs composition — piling everything into one large agent, or composing many small domain-specific agents. It draws on Justin Schroeder's (StandardAgents) 2026 talk "The Future Is Domain-Specific Agents."

Why Teams Build Custom Agents​

The driver is integration, and integration is a data problem. Businesses expect outsized gains when their own data is wired into AI. General-purpose AI is everywhere, yet real estate agencies, insurance brokers, and large enterprises still try to build their own agents.

Generic AI does not know their data, their tools, or their rules. A custom agent is the first mechanism most teams reach for to close that gap. The real design question underneath "how do we build an agent?" is "how do we put the right slice of our data footprint in front of the model, and nothing more?"

Why agents are hard​

Most custom-agent attempts work as a demo and little more. The hard parts are structural, not cosmetic:

  • The agentic loop needs orchestration — turn taking, stop conditions, validations.
  • Provider abstractions multiply — each model vendor has its own shape (tooling like the Vercel AI SDK is easing this).
  • Durable execution — faults must resume cleanly, not restart from zero.
  • Telemetry and observability — knowing what is transmitted on each step lets you diagnose and tune. That is hard at scale.
  • Portability — a good agent works on my machine; environment variables, runtimes, and system requirements make it unlikely to run on yours.
  • Composability — a great chatbot built for one purpose rarely transfers to the next. You cannot easily share it.

There is, as of 2026, no single defined way to build an agent. Most teams invent their own. This is the real cost behind "we tried agents and backed off."

The retreat to MCP and skills — and why tools are not enough​

When custom agents get too hard, teams retreat to two intermediate patterns:

  • MCP (Model Context Protocol) — useful for putting corporate data and tools into a large general-purpose agent. In practice MCP has become a de facto tool-distribution mechanism: of its client capability matrix, only the tools column is filled out everywhere. Tools alone do not build a large project.
  • Skills — markdown files that act as documentation for complex tasks. Useful, but research shows that loading too many makes an agent substantially worse. Documentation helps; it is not the fundamental fix.

The stack is mostly context​

Build an agent up layer by layer and one fact dominates:

  • Model — every agent starts here (large or small).
  • System prompt — its role and objective in the universe.
  • Tools — the effects it can take.
  • Skills — layered on top.
  • MCP — layered on top of that.
  • Messages — the running conversation.

Almost all of this — system prompt, tools, skills, MCP — ends up as context. Most designs then solve integration by inflating context or upgrading the model. Those are the two knobs they touch.

Inheritance vs composition — the core insight​

Adding travel MCPs, Figma, Playwright, Gmail, Google Sheets, linters, and skills onto one agent is inheritance: take one object and bolt on attributes so it can do more. Inheritance works — that is why these stacks exist.

But an old rule holds: composition over inheritance. Five skills on one agent is fine; a hundred is not; a thousand is not. There is a point of diminishing returns from adding context, and everyone feels it implicitly.

Composition is the alternative. Instead of one bloated agent, build a small full agent per domain:

  • Its system prompt is written to be, say, a Figma expert — every API, every right click, every action.
  • It carries only the precise tools that domain needs, and nothing more.
  • It keeps its own short message history, scoped to that domain, and its own agentic loop.

Above these sits a coordinator. The small agents and coordinator communicate in English. "Check my mail for anything about a trip" → the Gmail agent returns "there's a trip to LA this weekend" → the coordinator hands the travel agent the booking.

This is biomimicry: it is how we got to the moon. Teams of experts, each with a narrow skill, a specific set of tools, and a mouth to pass messages up. One controller did not hold every tool — each specialist held a few and was excellent at them. We already know this structure works because human organisations run on it.

Why domain-specific agents win​

Attribution note: the following figures are from StandardAgents' internal work as presented in the talk — treat them as directional, not independently benchmarked.

  • Token efficiency. A domain agent does not need the whole conversation to act. The coordinator hands it only its system prompt, its tools, and the one incoming instruction. StandardAgents reports over 80% token efficiency on targeted tasks [source: StandardAgents talk] — the trade is that tasks must be defined a little more up front.
  • Small and non-language models become practical. Because a domain agent only does its narrow job with minimal context, a cheap small model can execute faithfully. The talk cites a per-task cost gap of roughly 137× between a small flash model and a frontier model [source: StandardAgents talk]. You can also slot in image-generation and diffusion models for the sub-tasks that suit them. (The caveat: a small model that fails repeatedly erases its own savings — the domain must be narrow enough that it succeeds reliably.)
  • Strict capability limits. A frontier coding agent can do anything, which is why teams bypass permissions "flying close to the sun." A domain agent can only do what is explicitly approved for it. You opt into a controlled ecosystem — the answer that puts the IT security owner at ease.
  • Excellent scaling. Each agent is its own small execution environment, so you can parallelise them, run thousands of instances across regions without co-location, and deploy them to the cloud without a heavy shared footprint.

The macro pressure making this urgent: the cost of intelligence stopped falling in 2026. Per the talk's tracking, tokens rose ~29% IQ-adjusted and ~76% unadjusted in the first half of 2026 [source: StandardAgents talk]. A frontier model only fits customers with massive lifetime value. Efficiency with efficacy is the requirement, and domain-specific agents are the route to it.

Domain-specific agents are a data-footprint strategy​

Read the pattern through the lens of data footprint. Everything an agent carries — system prompt, tools, skills, MCP, message history — is context. Context is data the model must ingest and reason over. Minimising an agent's context footprint is minimising its data footprint, and that move buys the four wins above:

  • Cost falls because the model reads less data per task — the data-value flow is scoped, not dumped.
  • Security improves because a narrow agent can only see its own slice of data. A frontier agent with the keys to everything is a data-exposure surface; a domain agent bounded to Gmail cannot touch Salesforce. The blast radius of a leak or a bad action shrinks to one domain.
  • Scale works because small, self-contained data contexts parallelise — there is no giant shared state to synchronise.
  • Portability exists because a scoped agent carries its own data contract; you can squeeze it up and hand it to someone else.

This is the same bounded-context discipline that hexagonal architecture applies to code: draw the boundary around one domain, let it own its data and its ports, and coordinate across boundaries through a thin interface (here, English). The agent boundary is a data boundary. Get the data-footprint strategy right and the architecture follows; get it wrong and you are back to one bloated agent inheriting everyone's data.

Anatomy of an ideal agent​

Break the harness into its real primitives:

  • Model — the reasoning core.
  • System prompt — role and objective.
  • Tools, of three kinds:
    • Functions — actual executable effects (e.g. write a file).
    • Prompts / sub-prompts — smaller prompts injected to call an LLM mid-task (e.g. a main agent invokes a cheaper image model to generate one asset).
    • Sub-agents — a complete other domain-specific agent exposed as a single tool.
  • Hooks — deterministic interventions that mutate state or fire side effects. Example: an LLM never knows the time, so a hook injects a synthetic message/tool-call ("what time is it?" → "6:45pm Pacific") into history. Hooks also fire external side effects.
  • Agent rules — the per-agent governance: max turns/steps, whether a tool call must be validated, and similar constraints.
  • Sandboxed file system — every agent needs a small sandbox to write and store artifacts. An effective chat interface needs a file system.
  • Sandboxed code execution — every agent needs a safe way to run its own files without touching the host OS or exfiltrating anything.

Treat the sandboxed file system and sandboxed execution as domain-agent primitives, not add-ons.

Recursion: agents all the way down​

The "sub-agent as a tool" primitive is recursive — agents call sub-agents that call sub-agents, keeping every context window minimal:

  • A coordinator at the top delegates to a Salesforce agent that knows the API and holds the credentials.
  • The Salesforce agent talks to a Google Workspace agent to build a spreadsheet of top sales people.
  • It also calls an asset-generation agent (its own image/SVG models plus self-QA) when work needs assets.
  • The coordinator routes checks through a legal agent, which itself owns a GDPR compliance agent for EU customers and an OSHA compliance agent — so no single agent carries 45MB of compliance context.

Each node stays small and specialised; the system as a whole is capable. That is the point of domain-specific agents.

Principles​

  • Composition over inheritance. Adding context to one agent works until it doesn't; splitting into narrow full agents scales past the wall.
  • Narrow the context, not the ambition. Minimal context per agent is what unlocks cheap models, security limits, and parallel scale.
  • English is the interface. Agents coordinating in natural language is a feature — it mirrors how expert teams already work.
  • Constrain to secure. An agent that can only do approved things is safer than a powerful one you must police with permission dialogs.
  • Sandbox by default. File system and code execution are primitives, not afterthoughts.
  • The agent boundary is a data boundary. Scope each agent's data footprint to exactly its domain — that is what converts into cost, security, and scale.

Inversion​

Conventional wisdom says: use the biggest model, give it every tool and skill, and let one powerful agent do everything. The inversion: many small, cheap, tightly-scoped agents beat one large one on cost, security, portability, and scale. Reliability comes from the constraint, not despite it.

The "cost of intelligence keeps falling, so wait" assumption also inverts. In 2026 token cost rose, making efficiency a present engineering problem, not a future convenience.

Predictions​

  • H2 2026 — a rapid, accelerating uptick in teams building domain-specific agents and frameworks around them (Vercel's Eve — "build a company brain, personal assistant, or domain-specific agent" — is an early signal).
  • 2027 — the year of multi-agent orchestration, entering the common vocabulary.
  • Signal to watch: whether cheap small-model-per-domain economics hold up against retry-failure rates in production.

How to apply​

Turn one bloated agent into a coordinated fleet:

  1. List the domains. Name each distinct data-and-tool territory the agent touches (email, CRM, docs, assets, compliance).
  2. Draw the data boundary. For each domain, write down the exact data and tools it needs — and nothing more. That list is the agent's data footprint.
  3. Build one domain agent. Give it a domain-expert system prompt, only its tools, its own short message history, and a sandboxed file system + code execution.
  4. Pick the cheapest model that succeeds. Start small; promote to a larger model only where the small one fails repeatedly.
  5. Add a coordinator. Let it delegate to domain agents in plain English and compose their results.
  6. Instrument every hop. Trace what each agent receives and returns so you can diagnose the tree.

Proof of done: a task that previously ran on one large agent now completes through the coordinator and its domain agents, with lower token cost per task and each agent scoped to only its own data.

Failure modes​

  • The domain is too broad. A small model fails repeatedly and retries erase the cost savings — split the domain or promote the model.
  • Context leaks across the boundary. The coordinator passes an agent more than its slice, and the data-footprint advantage evaporates.
  • Lossy English hops. Information silently drops between agents because the hand-off prompt is underspecified.
  • Rebuilding the monolith. Convenience pressure re-adds tools and skills to the coordinator until it is one bloated agent again.
  • No observability. Without per-hop tracing, a multi-agent failure is undiagnosable and trust collapses.

Changes my mind: if small models reliably matched frontier quality across broad, open-ended tasks at comparable cost, the single-large-agent design would win and composition would be premature optimisation.

Context​

  • instance-of Intelligent Hyperlinks — the harness is the third pipe (intent) made concrete: agents that discover, negotiate, and execute, coordinating in English
  • depends-on Data Footprint — the integration problem is a data problem; a domain agent's context footprint is its data footprint
  • depends-on Data-Value Flow — scoping what data moves into each agent is what makes the economics work
  • depends-on Agent Protocols — the MCP/A2A substrate that lets a coordinator and its domain agents talk
  • pairs-with MCP Toolkit — MCP as the de facto tool-distribution layer, and why tools alone are not enough
  • pairs-with Agentic Prompt Loops — the agentic loop each domain agent runs internally
  • pairs-with Context Graphs — the memory layer a fleet of agents queries before acting
  • instance-of Agentic AI Systems — where the harness sits in the broader agent operating model
  • contrasts-with Hexagonal Architecture — same bounded-context discipline, applied to agents instead of code
  • applies-to The AI Engineer's Stack — where harness design lands in a real build
  • up Software Architecture — the architecture hub this page belongs to

Questions​

Where does a fleet of domain-specific agents beat one well-provisioned agent: task count, context size, cost pressure, or risk boundary?

  • Which domains are narrow enough that a cheap small model succeeds reliably, and which still demand a frontier model?
  • How do you keep English-based agent-to-agent coordination from silently losing information across hops?
  • What observability do you need across a recursive agent tree to diagnose where a multi-agent task went off the rails?

Next question: what is the smallest reliable domain — the point below which splitting an agent costs more coordination than it saves?