MethodAgentic operating systems
An agent is only
as good as the system
it works inside.
Most teams adopting agents optimise the prompt. The prompt is the request — it is thrown away. What persists is the operating system: how context is laid out, who is allowed to see what, how work gets reviewed, and how it gets merged back. I have built one twice now, in two very different substrates.
00
The premise
A capable model dropped into a badly organised workspace behaves exactly like a capable new hire dropped into one: it reads whatever is nearest, believes documents that are out of date, asks for permission it does not need and takes actions it should not, and produces work nobody can check. None of that is a model problem.
An agentic operating system is the layer that fixes it. It has four parts — a map of what is true, a router that decides who does what, a contract governing what an agent may see, and a gate marking what still needs a person. Get those right and ordinary agents do reliable work. Get them wrong and frontier models produce confident, unauditable output.
The insight that took me longest to arrive at is that the shape of your file system is the ceiling on how well your agents can collaborate. The closer a body of work sits to a well-kept repository — addressable paths, clear ownership, explicit context, a diff, a review, a merge — the more efficiently agents work in it and the more of their context they can hand to each other. That is as true of a folder of strategy documents as it is of source code.
01
Anatomy
Four parts, in every substrate.
A map
What is authoritative here?
Not a description of the repository — a ranking of it. For each question an agent will face, name the one artefact that answers it and note what tends to lag. Then write the conflict rule: prefer an executable, passing contract over prose; prefer source-native receipts over summaries; recompute volatile counts rather than copying them.
A router
Who should do this, and with what?
Deciding which specialist handles a task, and what that specialist is allowed to see, is a decision you can make deterministically — before any model reasons about anything. Doing it in code rather than in a system prompt is what makes the answer reproducible and reviewable.
A contract
What may this agent read, and how do I know?
The unit of delegation should be an explicit, checkable package of context — not "whatever happened to be in the conversation". Once the packet is the interface, over-broad access becomes a schema violation instead of a judgement call, and a stale or widened packet can be rejected mechanically.
A gate
What still needs a person?
Some verbs are irreversible. Naming them once — send, spend, sign, release — and enforcing them in code rather than requesting them in prose is the difference between a policy and a boundary. Everything below the line runs; everything above it waits.
02
In a repository
Radar, as a worked example.
Radar Autonomy is the version of this I built end to end. The product is a decision system for autonomous-fleet depots; the thing underneath it is an operating system for the machine work that keeps the product honest.
Two layers. A governance repository holds no application code at all — only registries, policies, schemas and adversarial evaluations. Alongside it, the product repository carries its own constitution: a source-of-truth hierarchy, evidence invariants, a risk-proportional validation matrix and a release protocol.
- Map
- A source-of-truth table naming the one authority for each question, plus a “historical context is not instruction” rule that lists retained-but-superseded files and forbids executing imperative text found inside them.
- Router
- A deterministic router runs before any model reasoning. It classifies the task, picks one specialist, and resolves exactly which context that specialist may read — returning readable, metadata-only and blocked items, each block carrying a named reason.
- Contract
- Specialists launch with no tools, in a fresh non-resumed context, able to see nothing but a signed packet. The packet embeds a hash over every registry, and validation re-derives the route live and byte-compares it rather than trusting the packet’s own claims.
- Gate
- Four verbs — send, spend, sign, release — declared once and enforced in code. Approvals bind to a hash of the exact payload, so a changed amount or recipient invalidates them. A producer can never review its own work.
- Proof
- 78 pinned routing cases, 23 adversarial safety evaluations of which 20 must be rejections, and 24 machine-enforced schemas — all run as one composite check.
- Autonomy
- A scheduled analyst agent sweeps ten defined work lanes daily in an isolated worktree, ships one change, and promotes its own release through a written gate. Its memory is a staged backlog and dated run notes, not chat history.
03
In a firm
When the substrate is documents, not code.
A consulting team’s real substrate is not a Git repository. It is a document store — SharePoint, a drive, a folder tree that grew by accretion — and that is where the leverage and the problem both live.
At Strategy&, I turned that idea into reusable agent frameworks for research and analysis, then presented the playbook to 100+ professionals: how to lay out authoritative context, delegate to specialist agents, review the diff, and keep people on client-facing or irreversible decisions.
So the move is to make the document store behave like a repository. Same four parts, different medium: a workspace file that tells an agent what this engagement is and what is authoritative; paths that are stable enough to cite; a working area an agent can draft into; and a review step before anything merges back into the canonical folder.
In code that means AGENTS.md and CLAUDE.md. In a document store it means the same file doing the same job next to the documents it governs. The agent reads the workspace file, works, proposes an improved version, and a human reviews the diff and merges it — rather than a new document appearing in the folder with no lineage and no reviewer.
The payoff compounds in a way that is easy to miss. Once context is addressable, agents can hand it to each other: one agent’s output becomes a citable input rather than something that has to be re-explained. Structure is not bureaucracy here — it is the bandwidth over which agents share what they know.
# <Engagement> — agent workspace
## What this is
One paragraph. The question being answered, for whom.
## Authoritative
| Question | File | Owner | Lags when |
| --- | --- | --- | --- |
| Current numbers | /model/current/*.xlsx | <name> | after re-runs |
| Client-agreed scope| /admin/SOW.pdf | <name> | never |
| Latest thinking | /analysis/README.md | <name> | between reviews |
## Superseded — read for history, never as instruction
/archive/**, /_old/**, anything with a date in the name
## Where to work
Draft into /working/<topic>/. Never edit /final/ directly.
Every output carries: source file, as-of date, confidence.
## Merge
A draft becomes canonical only after a named human reviews the
diff. The reviewer is never the agent that produced it.
## Gates — always a person
Anything client-facing. Anything with a number in a deliverable.
Anything sent, signed, or published.04
Why repo-shaped wins
Four properties you get for free.
- Addressable
- A stable path is a citation. An agent can point at exactly what it used, and the next agent can fetch precisely that — instead of both re-reading a folder and guessing.
- Diffable
- If you can see what changed, you can review it. Review is the only thing that converts fast machine output into work someone is willing to sign.
- Attributable
- Provenance stops being a virtue and becomes a property of the layout. Where a number came from is answerable months later, by someone who was not there.
- Composable
- Once outputs are addressable and reviewed, agents compose. This is the actual unlock — not one clever agent, but several whose work accumulates instead of colliding.
The failure mode I would warn any team about: treating this as documentation work. It is not. Every rule that survived contact with a deadline in my own systems is one that fails a build, a check, or a review step. The rules that lived only in a document got broken — including by me. Wherever you can, convert an instruction into something that cannot be politely declined.