The model is no longer the system
The four previous chapters added, one at a time: generation, the loop, knowledge, hands. Each was progress. Put end to end, they produce something nobody designed in one go.
Growth
The first system The same system, in production
- Agents
- 3 20
- Callable capabilities
- 8 74
- Data sources
- 4 11
- Human approvals
- 2 2
None of these additions was a mistake. It is their sum that changed in kind.
Flip the switch. Nothing that appears is unreasonable taken on its own.
Text version
The first system has 3 agents, 8 callable capabilities, 4 data sources and 2 human approvals. Eighteen months later: 20 agents, 74 capabilities, 11 sources — and still 2 human approvals.
Look at the last row. Everything multiplied except the number of places where someone decides. That is not negligence: nobody ever decided not to add any. There was simply never a moment when the question came up.
Six questions with no addressee
Freeze the picture on one call, at random, inside that system.
The frozen call
Call in flight adjust_alert_threshold(line="L3", threshold=82.5)
- Who requested this? Who can answer Nobody. The request goes out with the service's identity, not a person's.
- What exactly is being attempted? Who can answer The target system’s log will record it afterwards.
- Why this tool rather than another? Who can answer Nobody. The reasoning that selected it was kept nowhere.
- On what data does the decision rest? Who can answer Nobody. The context was assembled and then discarded.
- Who authorised this call? Who can answer Nobody. No authorisation was asked for — so none was refused.
- What actually happened next? Who can answer A timestamp line and a 200. Nothing about the effect.
Exactly one of these six has an answer, and it is the least useful one on the day something goes wrong.
Six ordinary questions. The right-hand column says who, in this system, can answer them today.
Text version
Six questions about a call in flight: who requested it, what is attempted, why this tool, on what data, who authorised it, what actually happened. Only one has an answer — what is attempted, which the target system will record. The other five have no addressee.
These six are not regulatory requirements. They are the questions anyone asks the day after an incident, and on their own they define what a control layer has to produce.
A layer between the decision and the effect
A control plane replaces neither the model nor the tools. It sits between them, at exactly the spot the previous chapter left empty: where a proposal becomes a call.
The control plane
Upstream
Agent
Control plane
- Identity Who is asking, and on whose behalf. The person’s identity survives to the far end of the chain.
- Policy What is permitted, to whom, within what limits — written outside the prompt, and true even when the prompt changes.
- Permissions The regime of each tool: forbidden, subject to approval, or automatic.
- Human approval The point where a person decides, with enough context for it to be a real decision.
- Trace The sequence of decisions, not only the sequence of calls.
- Evidence What remains afterwards, and lets you reconstruct without trusting the story.
Downstream
- Tools
- Systems
- Equipment
Each of these functions answers one of the six questions from the previous scene. That is not a coincidence: it is the specification.
Not a box added beside the system. A place the request has to pass through.
Text version
A control plane sits between the agent and the tools. It carries six functions: identity, policy, permissions, human approval, trace and evidence — each answering one of the six questions left without an addressee.
An action meets a policy
Here is what that looks like on a concrete case. A supervision agent proposes a change on a production line.
Policy gate
Proposed action adjust_fermentation_temperature(vessel="F-12", delta="+3°C") Requester supervision-agent-03, for marie.l@example.com
Evaluation
- Agent identity supervision-agent-03, acting for an identified user.
- Site and scope Vessel F-12 is within this agent’s declared scope.
- Allowed range Site policy caps automatic adjustment at +1.5 °C. The request is for +3 °C.
- Human approval Beyond the range, the action becomes subject to approval. An authorised person is asked.
The action is suspended. It will not run by itself, and it will not cancel itself either.
Action executed. The decision is attributed to a person, not to the system.
What gets recorded
- run_id : r-8f3a20e1
- requester : marie.l@example.com (via supervision-agent-03)
- action : adjust_fermentation_temperature(F-12, +3°C)
- policy : fermentation-range v7 — exceeds +1.5 °C
- human decision : approved by thomas.b@example.com
- reason : "compensating cooling stop, batch 2411, production signed off"
- execution : 14:07:52 — equipment acknowledged
- observed effect : 14:19:03 — setpoint reached, +2.9 °C
Action not executed. A refusal is a decision: it leaves as much of a record as an approval.
What gets recorded
- run_id : r-8f3a20e1
- requester : marie.l@example.com (via supervision-agent-03)
- action : adjust_fermentation_temperature(F-12, +3°C)
- policy : fermentation-range v7 — exceeds +1.5 °C
- human decision : refused by thomas.b@example.com
- reason : "batch under quality watch, no changes"
- execution : none
- notification : agent informed, task closed with no effect
Three checks pass, one fails, a fourth escalates. You decide — and watch what gets recorded in each case.
Text version
An agent proposes raising a vessel’s temperature by 3 °C. Identity and scope pass; the allowed range fails, site policy capping automatic adjustment at +1.5 °C; the action becomes subject to human approval. Approved or refused, the record holds the same core — run id, requester, action, policy applied, human decision and reason — and differs only in what followed.
Two things are worth noticing. The policy did not say no: it said not on your own. And the refusal produces a record as complete as the approval, because a system that only records what it did can never explain what it did not do.
A log is not an explanation
“We have logs” is the commonest answer to everything above. Put it to a real question.
Log and trace
The question, the next day Why was vessel F-12’s temperature changed yesterday afternoon?
What the log holds
- 14:07:41 POST /v1/chat 200 1243ms
- 14:07:49 POST /mcp/tools/call 200 180ms
- 14:07:52 POST /equip/setpoint 200 94ms
- 14:07:53 POST /v1/chat 200 870ms
- 14:19:03 GET /equip/state 200 31ms
None of these lines says who, or why, or who agreed. You know something happened and did not fail.
What the trace holds
- Goal received: recover the thermal drift on batch 2411 requested by marie.l@example.com
- Context assembled: 3 sensor readings, batch setpoint, site policy references kept, not copies
- Action proposed: +3 °C on F-12 supervision-agent-03
- Policy evaluated: exceeds the automatic range fermentation-range v7
- Approval requested, then granted thomas.b@example.com — reason recorded
- Execution, then observed effect on the equipment +2.9 °C at 14:19:03
Every link has an author, a reason and a timestamp. The next day's question finds its answer without anyone having to be taken at their word.
One limit, stated plainly: a trace records observable decisions — inputs, outputs, calls, policies applied, human choices, effects seen. It does not reconstruct what happened inside the model. Nobody knows how to do that, and a product promising it is lying to you.
The same run, recorded two ways. Both are accurate.
Text version
The log holds five lines of HTTP requests with status codes and durations: you know something happened without failing. The trace holds the goal and who asked for it, the context assembled, the action proposed, the policy evaluated, the approval granted with its reason, then the execution and the observed effect.
What a run leaves behind
A useful trace is not one more file. It is a record built during execution, because it cannot be built afterwards.
Evidence package
Recorded during the run
- run_id
- r-8f3a20e1
- identity
- marie.l@example.com via supervision-agent-03
- model and version
- local · gguf q4 · weight fingerprint
- context reference
- 3 readings + policy v7 (references, not copies)
- requested call
- adjust_fermentation_temperature(F-12, +3°C)
- policy decision
- outside automatic range → approval required
- human decision
- approved · thomas.b@example.com · reason
- call result
- equipment acknowledged, setpoint accepted
- timestamps
- proposal, decision, execution, observed effect
- chaining
- digest of the previous entry
What that makes tractable
- Incident Reconstruct the exact sequence without depending on what people remember.
- Root cause Separate a badly tuned policy from an agent that chose badly, and from equipment that responded badly.
- Audit Show that the rule in force that day was applied, and who owned the exception.
- Improvement See where approvals pile up, and decide what can legitimately be automated.
The journal is tamper-evident: each entry is chained to the previous one, so that a later modification shows. Detectable, not impossible — that distinction is the only honest statement, and it is already what lets a disagreement be about facts rather than recollections.
On the left what is recorded, on the right the questions that makes tractable.
Text version
The package records during the run: an identifier, the requester’s identity, model and version, context references, the requested call, the policy decision, the human decision with its reason, the result, timestamps and the chaining of entries. That makes four things tractable: incident analysis, root cause, audit, and improving the rules.
A human everywhere would be a human nowhere
The symmetrical mistake to having no control is having uniform control. An organisation that must approve every sensor reading stops approving anything within a week: people click, and validation becomes an empty ritual.
The dial from chapter 02 returns, but it is no longer about the system’s autonomy. It is about the risk of the action.
Regime by risk level
- Read
- Prepare
- Adjust
- Commit
- Stop
Change an alert threshold, move a reversible parameter within a known range.
Appropriate regime
- Automatic inside the declared range
- Approval as soon as it is exceeded
- An alert when the frequency leaves the ordinary
Move the dial. What changes is not the system's competence, it is what the action can break.
Text version
Five risk levels, from no-effect to irreversible. Read and prepare are automatic but recorded. Adjust is automatic within a declared range and subject to approval beyond it. Commit requires approval every time and a separation between requester and approver. Stop requires explicit human approval, never delegated.
A well-placed control is barely noticed. It is precisely because it is rare that it stays a decision.
What can go wrong
What a control plane does not do
It does not make the model right. An agent that gets things wrong will still get things wrong; it will do so in front of a witness, within limits, and reconstructably. That is a great deal, and it is not the same thing.
It does not explain the model. The trace records what is observable: inputs, outputs, calls, policies, decisions, effects. The inside of the model stays out of reach, and no tool will change that.
A badly written policy is faithfully applied. Control moves the question — from “what did the agent do” to “what did we authorise”. That is a better place to ask it; it is not an answer.
A control people route around protects nothing. If it slows things down indiscriminately, teams will find the path that avoids it, and that path will become the real system. Calibrating regimes is not comfort: it decides whether the whole arrangement holds.
Where we work
You have just walked through five layers. The model generates. The agent acts. Context informs. The protocol grants access. And the last layer decides what is permitted, has a person decide when it must, and keeps enough to answer for it afterwards.
That is the one we build. SwarmForge is an agent orchestrator that installs on your infrastructure, runs its models locally, governs tool calls through a policy held outside the prompt, routes sensitive actions through an identified person, and writes a tamper-evident journal of what was requested, decided and done.
Two things we will not say. We hold no certification, and the compliance documentation we produce — GDPR, AI Act, professional secrecy — is documented, not certified: it equips your process, it does not stand in for it. And none of this will make an agent infallible; the aim is that a mistake stays within limits, in front of a witness, and reconstructable.
If you are building agentic AI that touches real operations, the conversation we care about starts exactly here.
You are here
You have reached the control layer. What follows is not read, it is designed.