Skip to main content

The Agentic OS: what you buy and what you build

What an Agentic OS is, the runtime you buy, the harness you build, and the work no Agentic OS does for you.

By Murali SidLinkedInPublished Updated

Vendors now sell an "Agentic OS" as the thing that makes AI agents work at company scale. A buyer needs to know what that buys, and what work stays with them. In this guide, an Agentic OS is the runtime plus the harness. Buy the runtime: the sandboxes, sessions, identity, scheduling and metering. Build the harness: the loop around the model that decides what it sees, when it stops and how it recovers. No Agentic OS prepares your own information, keeps your rules outside the model, or tests your changes. That work stays with you.

What the term means today

The phrase means three different things, depending on who says it.

So two products with the same label can share almost nothing. A GPU scheduling paper and a nine-file scripting pattern have only the name in common. Before you compare offers, ask which meaning the vendor uses.

The runtime and the harness both sit in the agent platform layer (R07). The runtime is one of the seven capabilities on what an agent platform provides.

One turn of an agent loop runs in seven steps. The first three are context assembly, the model call, and tool routing through the gateway. Next come a policy check outside the model, the result, and evidence written where the agent cannot write. Last come termination and budget checks. They repeat or stop the loop. Each step is tagged with the part that owns it. A side panel lists five parts. You buy the runtime. You build the harness, the context, the enforcement and the order of the intelligence ladder. An eval suite you own binds all five.
One agent loop, five partsBuy the runtime. Build the other four parts, and test each one against a simple baseline on your own queries.Open image at full size ↗

Read the figure as one turn of an agent loop. The harness assembles the context. The model answers or asks for a tool. The call goes through the gateway, and a separate system checks the policy. The tool runs in the runtime's sandbox. The trace goes where the agent cannot write. The harness then checks the budget and decides to repeat or stop.

What you buy: the runtime

The runtime gives each agent a sandbox, a session store, an identity, scheduling and metering. It also collects traces. This is real engineering, and it is now a commodity. The managed runtimes accept almost any agent framework. AWS AgentCore accepts LangChain, the OpenAI Agents SDK, the Claude Agent SDK, Strands, or your own code. Google's platform accepts its own Agent Development Kit, LangGraph, LangChain, AG2 and LlamaIndex. A team that builds this plumbing itself spends budget on work that gives it no edge.

One caution on budgets. Some providers give a model a token allowance for a task. The model is told how much remains. It uses that to pace itself. That helps, but it is advice to the model. It is not a spending cap. A hard limit must be enforced by something the model does not control.

What you build: the harness

The harness is the loop around the model. It decides what context the model sees and when to reset it. It decides when the work is finished. It saves state. A crash then does not lose the work. It checks results and stops a runaway loop. Iteration caps, time limits, stop hooks and approval gates all live here. The harness is the only part that sees the whole loop.

The harness is not neutral plumbing. Two studies in 2026 found that harness choices change how an agent behaves later in a task. In retrieval-heavy work, the harness mattered more than the retrieval design. So benchmark results from different harnesses are hard to compare.

The harness is also where lock-in sits. Managed runtimes now accept any framework. That makes the runtime easy to move. Harnesses stayed custom. Prompts, tool definitions, model choice and skills move between platforms. Control flow, state formats, human interrupts and approval models do not. Put your portability effort into a harness you can lift out, not into the framework choice.

Start with one agent. Several agents working together cost many times more than one. They buy breadth, and they keep each agent's context separate. They do not make each step smarter. Add agents only when one agent cannot reach the accuracy you need. The published cost figures are in the research block below.

What an Agentic OS does not solve

Four kinds of work stay with you, whatever you buy.

Preparing your own information

No version of the term covers how your information is prepared for the agent. The vendor stacks include memory. Memory stores context and history. They do not cover data quality, how documents are split and indexed, or whether search works. Curate data for the purpose before it reaches the agent. Adding more documents can make answers worse until that is done.

In our own experiments, we changed only how documents were split and indexed. That one change moved search quality more than anything else we tested. Keyword search mattered too. Dropping it failed quietly on queries that name an exact identifier. Any component you adopt, bought or built, must beat a simple baseline on your own queries. We tested one of our own designs this way. The simple design won on real prose, and we published that.

Someone must own each body of documents. People can do the curation, or automation with sampled checks, or both. Match the effort to the risk. Accountability cannot be automated away. In Moffatt v. Air Canada (14 February 2024), the airline was liable for what its chatbot told a customer. The data-to-memory pipeline and the context patterns set out the method. How to test a context design shows how to run the comparison.

Keeping rules outside the model

Some designs put a rules file in the agent's context and call it governance. A model reads instructions and content as the same kind of text. It cannot reliably keep them apart. A rule the model only reads is advice. To make it a control, a separate system must check it. Models may take permission away, never grant it. In the four deterministic zones, a model may not approve at all.

The same goes for records. An agent's report on its own work is not proof. The audit trail is written where the agent cannot touch it. Enforcement outside the model sets out where each check sits.

Choosing what to change

When an agent falls short, you can change its context, distil a smaller model, or fine-tune. Distilling trains a smaller model to copy a larger one. These are not camps to pick between. They are an order to try, and the intelligence ladder sets it out. Improve context and prompts against a fixed test set first. Distil when speed or unit cost forces it. Fine-tune only when a grader exists that the model cannot game. Fine-tuning will not fix format, tone or style. Those are prompt problems.

Testing every change

Every choice above is a comparison. Does the new index beat plain chunks? Does a second agent earn its cost? Does a distilled model hold quality? Each needs a fixed set of test cases that you own, called an eval suite. Build it from real failures, before the agent goes live. Have domain experts own it. Without one, choices fall back on what vendors say. The learning flywheel shows how a change passes its tests before release.

One example: a vegetation inspection agent

An electricity distributor wants an agent that reviews imagery of power lines near trees. It buys a managed runtime for sandboxes, sessions, identity and metering. It builds the harness: which imagery to load, when to stop, and how to resume after a pause. It prepares the imagery index and the asset records itself. It keeps the work-order permission in the gateway and the policy decision point. It builds a test set from last season's missed spans. A new model must pass that set before release. This is a proposed design, not a measured deployment.

Evidence and limits

Three things have settled. The Model Context Protocol (MCP) is now the shared way to connect tools. The large cloud vendors landed on one split: a runtime you buy and a harness you build. Most multi-agent failures come from design, not from the model. A study of traces across seven frameworks found fourteen failure modes in three groups.

One claim rests on thin evidence. The agent-to-agent protocol (A2A) has more than 150 member organisations and a stable 1.0 release. Its release claims production use but names no enterprise user. Treat such claims as unproven until someone names a deployment.

Surveys on the category are not encouraging. A July 2026 survey of more than 100 enterprise leaders named orchestration the biggest gap. It found no vendor product that works reliably at production scale. A survey of 495 enterprises found only 16 percent of deployments were true agents. The rest were fixed workflows around one model call.

The retrieval results are the author's own experiments, not independent production results. Vendor figures are flagged. The split into a runtime you buy and parts you build is an author position.

Mixed evidence

Next step: see tested ways to give an agent the right context on context patterns.

Explore this topic

Definitions

Harness

  • arXiv 2607.04528 (July 2026): holding task, environment and model constant, harness choices changed the beliefs that drive later decisions, even where final success looked the same.
  • arXiv 2605.15184 (May 2026): in retrieval-heavy work, harness choice outweighed the retrieval architecture.
  • Full treatment on the agent platform layer.

Multi-agent cost

  • arXiv 2603.22651 (March 2026), 10,000 SEC filings, 25 field types, five models, four patterns. A supervisor-worker pattern reached 0.921 F1 at 1.4 times the cost. A self-correcting pattern reached 0.943 at 2.3 times. A hybrid kept 89 percent of the accuracy gain at 1.15 times. The paper puts the threshold for multi-agent at about 0.92 F1. F1 is a score that balances missed items against wrong ones.
  • One vendor reports single agents at about four times chat token use, and multi-agent systems at about fifteen times. Its own solo-agent against planner-generator-evaluator comparison on one task reported about twenty times the cost and eighteen times the wall-clock time [vendor].

Retrieval experiments (author's own)

Corpus, encoder and scoring were held fixed. Only the document representation changed. Scores are nDCG@10, a standard measure of how well the top ten results are ranked.

One vector, one topic per document

0.815

The usual starting point, on documents about a single thing.

Same index, ten topics per document

0.294

The same representation on realistic documents. Nothing else changed.

Several vectors per document

0.803

Recovered by representation alone, with fewer embeddings than the matched control.

Keyword search on exact-name queries

0.997

Against 0.314 for the dense index on the same queries.

  • On real prose, a purpose-shaped representation scored 0.635 against plain chunking's 0.667.
  • Methods and limits: aspect dilution, real prose, what changed after testing.
  • arXiv 2606.11350: adding documents drove accuracy below 40 percent until domain-scoped curation fixed it.
  • Context engineering was named by Lutke and Karpathy in June 2025 and set out by Anthropic in September 2025 [vendor]. Gartner Innovation Insight (2025) forecasts it in 80 percent of AI tools by 2028.
  • Moffatt v. Air Canada, British Columbia Civil Resolution Tribunal, 14 February 2024.

Rules outside the model

  • Bhattarai and Vu, February 2026, on why a model cannot keep instructions and content apart. Cited on the deterministic zones.

Choosing what to change

  • GEPA (arXiv 2507.19457, ICLR 2026): prompt optimisation beat a reinforcement-learning baseline by six points on average and up to twenty, with up to 35 times fewer rollouts.
  • ACE (arXiv 2510.04618, ICLR 2026): treating context as an evolving playbook improved agent benchmarks by 10.6 points and finance tasks by 8.6, with no weight updates.
  • On-policy distillation (October 2025): comparable quality at 9 to 30 times lower training compute than more supervised fine-tuning. It also repairs instruction-following that domain fine-tuning degrades.
  • Reinforcement fine-tuning customer results (May 2025) [vendor]: 39 percent better tax analysis, 12 points over physician baselines, 20 percent on citation-extraction F1. One head-to-head: a fine-tuned 7B model beat a prompted frontier model on classification, 88 percent against 31 percent, at about a fifteenth of the inference cost.
  • Cautions: LoRA adapters do not prevent forgetting. When validation reward exceeds the human ceiling, the model has gamed the rubric.
  • The verdict is recorded in the decision catalog and set out on intelligence and learning.

A promotion gate based on run counts

Some designs let a task run unattended after twenty runs at a 95 percent verified pass rate. Exact binomial calculations with Clopper-Pearson one-sided bounds show the sample is too small. Nineteen passes in twenty is consistent with a true pass rate as low as 78.4 percent. A task that is truly 90 percent reliable clears the gate 39.2 percent of the time. A truly 95 percent reliable task fails at least once in twenty runs 64.2 percent of the time. Separating 95 percent from 90 percent with 80 percent power needs about two hundred runs. The autonomy contract gates on the controls in place instead.

Cite this page

Written by Murali Sid, Founder and AI Systems Architect, last updated 15 October 2026. Licensed CC BY-SA 4.0, so quote it freely with attribution.

Murali Sid (2026). The Agentic OS: what you buy and what you build. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/agentic-os

Machine-readable version of this page: /agentic-os.md

On this page