Agent platform

Target state

In short: Own the control loop around each agent, run it on a bought runtime, and give every run explicit limits and crash survival.

The harnessHarness. The engineering shell around the model: what goes into its working memory, which tools it can call, when it must stop, how much it may spend, and how it recovers when something fails. is the engineering shell around the model: it decides what the model sees, what it may call, and when it stops. The enterprise owns and understands the harness. It runs on a managed runtimeAgent platform. The software that runs agents: the runtime, the harness, the list of approved agents, and the rules for how they start, stop, and change. that the enterprise does not own. Termination and budget conditions are explicit and rest on more than one condition, never on "until the model stops". State lives outside the context windowContext window. The model's working memory for one task. It is limited in size, so what goes in and what gets left out is a design decision. (the model's limited working memory) in artifacts a person can inspect. Verification runs as a separate agent or process from generation. An agent registryAgent registry. The official list of agents: what each is for, who owns it, what it may touch, and which version is live. promotesPromotion and demotion. Promotion moves a proven improvement into production. Demotion pulls it back out when it stops passing. agents through evaluationEval (evaluation suite). A set of test tasks with known right answers, written by people who know the work, used to check an agent before and after any change. gates, demotes them automatically when they go stale, and exposes only promoted agents to discovery. Routing leans on a deterministicDeterministic. Always gives the same answer for the same input by following fixed rules. The opposite of probabilistic, where the answer can vary. first tier (fixed rules that give the same answer every time) rather than on router sophistication. Anything that must survive a process dying runs on durable executionDurable execution. Running long jobs so they survive a crash or restart and pick up where they left off.. The layer's standing pattern: buy the runtime, build the harness.

layer · architecture

Buy the runtime, build the harness

The harness owns context assembly, explicit multi-condition termination, artifacts-as-state, separate verification, and budgets; the managed runtime owns isolation and durability.

1. 01Agent

   Agent

   Harness

   Context assembly and reset, iteration and wall-clock caps, per-run budgets

2. 02Control

   Control

   Verification path

   Separate agent or process; self-assessment distrusted

3. 03Evidence

   Evidence

   Artifacts-as-state

   Inspectable state outside the context window

4. 04System

   System

   Managed runtime

   Isolation, durable execution, hibernate-and-wake

5. 05Control

   Control

   Registry

   Eval-gated promotion; staleness demotes; search returns PUBLISHED only

6. 06System

   System

   Routing tiers

   Deterministic pre-router, light models, frontier synthesis

Approval rules are held in the harness and enforced at the gateway.

Diagram description: Agent platform architecture separating the enterprise-owned harness (context, termination, verification, budgets, artifacts-as-state) from the managed runtime (isolation, durable sessions), with the registry gating promotion. The map contains Harness: Context assembly and reset, iteration and wall-clock caps, per-run budgets; Verification path: Separate agent or process; self-assessment distrusted; Artifacts-as-state: Inspectable state outside the context window; Managed runtime: Isolation, durable execution, hibernate-and-wake; Registry: Eval-gated promotion; staleness demotes; search returns PUBLISHED only; Routing tiers: Deterministic pre-router, light models, frontier synthesis. Its connections are harness to runtime for runs on; harness to verify; harness to artifacts; registry to harness for gates promotion; harness to router for model calls. Important boundary: Approval rules are held in the harness and enforced at the gateway.

Reviewed 2026-08-20·Sources:r07-agent-platform findings

Mechanisms

The harness is the product

In short: The loop around the model, not the model, is what separates a working production agent from a demo.

Everything that separates a production agent from a demo lives here. That means how context is assembled and reset, how termination is decided, how state survives a crash, how verification happens, and how a runaway loop is stopped. Production practice has converged on four things. State lives outside the context window in inspectable artifacts. Termination is explicit and rests on more than one condition. Verification is a separate agent or process, because models confidently praise their own mediocre work. Recovery is a first-class path rather than an exception handler. Meta's production harness, known as REA, is the strongest named harness with published outcomes. REA-driven iterations doubled average model accuracy over baseline across six production models. Staffing moved from two engineers per model to three engineers across eight models [vendor]. Nor is the layer neutral plumbing. With task, environment, and model held constant, harness choices often leave the final outcome unchanged while changing the beliefs that drive later decisions (Yi and Song, arXiv 2607.04528, July 2026). On 116 LongMemEval questions run through four harnesses, a plain text search (grep) generally beat vector retrievalRetrieval. Finding the few relevant pieces of company information for a task and placing them in front of the model. (search by similarity of meaning). The variation was strongly harness-dependent and independent of the underlying data (Sen et al., arXiv 2605.15184, May 2026). Two consequences follow. Harness choice can outweigh the choice of retrieval architecture. And benchmarkBenchmark. A public test used to compare models or agents. Useful for orientation; scores can be gamed, so they are claims rather than measurements. comparisons across harnesses are confounded: you cannot tell whether the harness or the method made the difference.

Harness limits, enumerated

In short: Every production loop needs several independent ways to stop, and the harness is not where security is enforced.

The limits are: iteration caps, wall-clock limits (caps on elapsed time), cancellation checks between rounds, and stop hooks. They also include approval gates with standing rules, per-run tokenToken. The unit AI usage is measured and billed in, roughly three-quarters of a word. and cost budgetsBudget envelope. A spending allowance for an agent with hard per-run caps and alarms, owned by its business sponsor., and a kill switchKill switch. A guaranteed way to stop an agent immediately, built at more than one point so that one failure cannot disable it.. These are published concretely. The VS Code Copilot harness (May 2026) states its termination conditions as a tool-callTool. A function an agent can call to do something real: look up a record, send an email, run a query. Tools are where agents touch your systems. limit, a cancellation check between rounds, and stop hooks. The Microsoft Agent Framework Harness (July 2026) is the most complete published inventory of what a harness contains. The placement rule: tool approval is decided in the harness, because it is the only component that sees the whole loop. It is enforced at the gatewayGateway. The single door every agent request passes through on its way to a tool or model. Because everything goes through it, it is where rules are enforced and activity is recorded. (the single door every tool request passes through, covered under the integration fabric, R03), because the harness is not a security boundary.

Artifacts as state

In short: Long-running work keeps its memory in files a person can read, not inside the model's limited working memory.

The published pattern for long-running work keeps state in three artifacts [vendor]. The first is a feature list stored as a JSON file (JavaScript Object Notation, a structured text format) with 200 or more end-to-end descriptions, all marked failing at the start. The second is a progress log. The third is git history (the version-control record). Work runs one feature per session, with a fixed checklist at the start of each session. Context is treated as "a finite resource with diminishing marginal returns" [vendor]. Three practices follow. Prefer resetting the context over compacting it (summarising it to save space). Have sub-agents return summaries of 1,000 to 2,000 tokens rather than full transcripts. Clear stale tool results first, as the easiest saving. Progressive disclosure (loading detail only when it is needed) extends the same economics to the skill library. Each capability costs roughly 100 tokens of always-loaded metadata. Its body, under 5,000 tokens, loads only when triggered. Bundled files cost nothing until read. Scripts execute through the shell (bash), so code never enters the context [vendor].

Durable execution

In short: Saving a run's data is not the same as making the run survive a crash, and day-long approval waits need the second.

Two layers are commonly conflated. A checkpoint preserves data, not execution. A checkpointed run lives in a single process, and if that process dies the run dies with it. That framing comes from a durable-execution vendor characterising a competing framework's checkpoints, and it is carried as such [vendor]. Durable execution makes the run itself survive. Human-in-the-loop (HITL) pauses consume no resources and survive worker restarts, which is what makes day-long approval waits affordable. Genuinely long jobs hibernate and wake (the Meta REA pattern). Named companies on the leading durable-execution engine include OpenAI, Cursor, Lovable, Block, Abridge, and Hebbia [vendor customer list]. Artifacts-as-state is the architectural fork that avoids the engine entirely: reset the context and carry state in the artifacts described above.

The lifecycle state machine

In short: Agents move through named stages with test thresholds at each gate, and one that stops passing drops out of circulation automatically.

The only fully specified published agent lifecycle (Kang and Wang, arXiv 2607.00345, July 2026) runs through five states: DRAFT, APPROVED, PUBLISHED, DEPRECATED, and RETIRED. Each promotion gate has a named threshold. Faithfulness must be at least 0.80, correctness at least 0.90, and tool accuracy at least 0.90. Helpfulness must be at least 0.70, latencyLatency. How long a request takes to come back. at most 15 seconds, and harm at most 5 percent. Versioning is by lineage, so a failing new version never reaches production. A 7-day staleness policy re-evaluates each agent automatically and demotes it on failure. Measured evaluation overhead is $2.10 per month at 10,000 interactions, about 2.5 percent of model cost. The architecturally interesting move is governance through discoverability. Search through MCP (Model Context Protocol)MCP (Model Context Protocol). An open standard for connecting agents to tools and data, like a universal plug. An MCP gateway is the governed version of that plug., the standard plug that connects agents to tools, returns only PUBLISHED agents. So a drop in quality reduces how reachable an agent is automatically, instead of waiting for a policy engine to step in. One caveat: this is a six-agent proof of concept by a cloud consultancy, not observed enterprise operation. Governance practice adds a complementary rule: an agent's autonomy levelAutonomy level (A0 to A5). How much an agent may do without a person in the loop, from manual (A0) to governed lights-out operation (A5). Set per task, not per agent. (how much it may do without a person in the loop) is itself a versioned, review-gated property. PromptPrompt. The instructions and information given to the model for a task. A prompt is advice to the model, not a control on it. refinements take a light path. Model updates and autonomy adjustments take a full review. One pharmaceutical programme, with five published levels of agency, requires a runtime policy enforcement layer at the AI gateway before higher levels are enabled.

Routing

In short: Clever routing between models barely matters; fixed first-tier rules, clear tier boundaries, and fallbacks are what matter.

The routing-plateau study (Rice and Amazon, arXiv 2606.07587, May 2026) is the decisive result. It compared 21 routing methods across 5 benchmarks. They converged to nearly identical performance, with the top 5 within 0.22 percentage points of each other. All of them trailed the oracle (a perfect router with hindsight) by 10 to 30 percentage points. Hard queries, 11 to 35 percent of the benchmarks, account for 70 to 91 percent of that gap. A simple k-nearest-neighbour (kNN) method, a basic similarity lookup, achieved lower loss than the trained methods on every benchmark. The best combined intervention closed only 14.6 percent of the gap. Routing-method sophistication is not the lever. Tier boundaries, fallbacks, and a deterministic pre-router are. Roughly 70 percent of instrumented organisations run three or more models [vendor telemetry]. So treat inference (running models to get answers) as a pipeline. Lightweight models handle extraction and tagging, and frontier models (the largest, most capable current models) handle synthesis. Both sit behind a modular routing mechanism whose first tier is deterministic rules.

The portability inversion

In short: The runtime has become the part you can move between vendors, and the harness has become the part that locks you in.

Managed runtimes converged on being framework-agnostic. One hyperscaler runtime (from one of the largest cloud providers) accepts LangChain, the OpenAI Agents software development kit (SDK), the Claude Agent SDK, Strands, or your own framework. Another accepts the Agent Development Kit (ADK), LangGraph, LangChain, AG2, LlamaIndex, the Agent-to-Agent protocol (A2A), and custom code. Harnesses stayed bespoke. The runtime is therefore becoming the portable substrate while the harness is the lock-in, the opposite of what most portability discussion assumes. What ports: prompts, tool definitions, model choice, and Agent Skills. What does not port: orchestrationOrchestration. Coordinating several agents or steps so they work together on one job. Useful for breadth; it does not make any single step smarter. and control flow, state and checkpoint schemas (LangGraph, Temporal, DBOS, and Restate are mutually incompatible), HITL interrupt semantics, and approval and permission models. Consequence: put portability investment into the harness abstraction, not into framework selection.

Design decisions

• Single agent with good tools vs multi-agent orchestration (CD-21): parallel breadth only, and the decisive variable is whether compute is held constant. This challenged defaultChallenged default. A technology choice most people treat as obvious, re-examined here against the simplest credible alternative on evidence and cost. asks whether one agent with good tools beats several agents coordinating. The headline orchestrator-worker result was roughly 90 percent better than a single agent on an internal research eval. It was bought with roughly 15 times chat-level token consumption (single agents run about 4 times). Token usage alone explains about 80 percent of the variance on a related benchmark [vendor]. The same vendor's comparison of a solo agent against a full harness on one task ran 20 minutes and $9 against 6 hours and $200. With reasoning tokens held constant, single agents consistently match or outperform multi-agentMulti-agent. Several agents splitting one job. It costs many times more than one agent and pays off only when the work is wide and the parts are independent. systems on multi-hop reasoning (questions that need several linked steps). That held across three model families (Tran and Kiela, arXiv 2604.02460, April 2026). Multi-agent buys parallel breadth and context isolation, not reasoning quality per token. The conditions for paying the multiplier must all hold at once. They are: independent read-heavy strands, total information beyond one context window, an accuracy requirement beyond a single pass, and task value that clears the multiplier. The only published crossover sits above an F1 score (a combined accuracy measure; higher is better) of roughly 0.92 on document extraction. There, a hierarchical supervisor-worker design held the cost-accuracy frontier at 0.921 F1 for 1.4 times the cost, and a hybrid captured most of the gain at 1.15 times (arXiv 2603.22651). Coordination cost is measured. Across 10 topologies (arrangements of agents), the average combined pass rate was 17.2 percent, with average information leakage of 217.9 percent per scenario (arXiv 2606.08878). In production, 59 percent of agentic requests make only a single service call, and only 18 percent make three or more [vendor telemetry]. The leading multi-agent advocate itself states the limits. The approach fits poorly where agents share context or have many dependencies.
• Build vs buy at the harness: no credible published dataset exists at this layer. The guide states the gap rather than citing weak numbers. What observed data supports: about 82 percent of instrumented organisations run agentic workloads with no recognised framework [vendor telemetry, dependency-inspected]. Practitioners call orchestration the most cited gap and the most improvised category. For whole AI solutions, the market swung toward buying at the same time (47 percent built in 2024, against 76 percent purchased in 2025). Framework churn is a real cost of buying in. The year's major framework consolidation reached general availability (GA) at version 1.0 in April 2026, then kept changing its surface for four further months. Verdict: buy the runtime, build the harness, and expect to own the maintenance burden. That burden exists because the managed layer is immature, not because primitives are cheaper.

Cross-cutting concerns

Evidence and limits

The failure record at this layerLayer (the fourteen layers). One of fourteen parts of the enterprise estate that agents touch, from infrastructure (R01) to agent data engineering (R14). is built from tracesTrace. The step-by-step log of one agent run: what it read, what it called, and what it decided. rather than from Common Vulnerabilities and Exposures (CVE) records. A taxonomy known as MAST (presented at the NeurIPS 2025 conference) was built from 150 traces and validated on more than 1,600 traces across seven frameworks. Inter-rater agreement (kappa) was 0.88. It identifies 14 failure modes in 3 categories. It concludes that multi-agent failures are design failures, not model failures. A benchmark competition across 2,196 execution traces and 149 teams found that token expenditure does not reliably predict task completion. Success correlated negatively with token usage, execution length, and tool entropy (how varied the tool choices were). Winning submissions improved guardrailsGuardrail. A filter that uses an AI model to catch bad inputs or outputs. Useful as an early warning, but not reliable enough to be the thing that grants or denies an action. rather than architectures (arXiv 2605.08518).

Several figures are vendor-published and carried as such. They are the multi-agent multiplier and variance figures, and the three-artifact pattern with its progressive-disclosure token costs. They also include the checkpoint-versus-durable framing (from a durable-execution vendor) and its customer list. The framework-adoption and single-service-call telemetry is vendor-sourced too, observed through dependency inspection (checking the software actually installed) rather than self-reported. The lifecycle state machine is a six-agent proof of concept. Survey context: in a December 2025 survey (sample size n=495), only 16 percent of enterprise deployments qualified as true agents under a strict test. In a July 2026 survey of more than 100 leaders, 43 percent limit agents to low-risk workflows, 33 percent require human-in-the-loop approval, and 20 percent permit broad autonomy. Skill-library caution: a study collected 775,790 skills from four marketplaces, 11,497 of them unique after deduplication (arXiv 2607.09065). Only 6.3 percent appear on more than one marketplace. Most are single-version and never updated. And 24 percent were rated a concern on instruction scope. The vendor's own documentation states that custom skills do not sync across its surfaces.

Authors' position, labelled as such: for passive and embedded agents, the qualification that matters is eval-gated behavior plus exception logging that feeds learning, rather than autonomy. Every published taxonomy surveyed uses autonomy or action scope as its defining axis. That classifies a bank's deliberately bounded advisory agent (task-level autonomy only, no self-initiation, no decision authority) out of "agentic" entirely. The consensus currently runs the other way.

Refusals. Circulating build-versus-buy figures for time to production, success rate, and maintenance share trace to vendor blogs without methodology, so this guide excludes them. A widely shared single-versus-multi-agent token comparison attributed to AssetOpsBench is a misreading of a domain fingerprint and a sample size. No such comparison exists in that paper. The claim that the leading single-agent essay predates the rival multi-agent post by months is contradicted by the pages themselves, which are dated one day apart. Also unverified and excluded: a compaction token-reduction percentage absent from the vendor's own documentation, and a cost-reduction claim for a popular open router. Likewise excluded: a skills-benchmark effect size, a maintenance-mode end date for the two merged frameworks, and a failure-share percentage attributed to MAST. No agents-per-supervisor ratio appears in this guide, because none has a defensible source. Re-verify quarterly: framework surface change after general availability, the lifecycle pattern beyond proof of concept, routing-plateau replication, and skills-marketplace hygiene.

The research behind this page

• Agent platform findings
• Research brief
• Vendor landscape
• Sources