Inside essential 1: it is never just the agent
The firm approves a release, and the model is one part of it. Around the model sit rings: its routing; the harness that gives it a loop, tools, context, memory, a sandbox, and verification; the guardrails on what goes in and out; and the release that packages all of it as one validated unit. Attached to the release is what the platform gives it: its own identity, acting for a business unit with short-lived credentials; a gateway every call passes through; a registration in the agent portfolio with a named owner; and one switch that stops it and returns the work to people.
In a controlled study on software-engineering tasks, a 100-task subset of SWE-bench Verified with three near-tied models, the harness explained 7.8 times more of the variance in results than the model, a ratio its authors call not universal (Zhang and colleagues, 2026). So the release is the unit the firm approves, and a change to the harness is a change to what was approved. In the market this essential is the busiest: Microsoft's Agent 365 and Entra Agent ID; Google's Agent Gateway, Identity, and Registry; AWS Bedrock AgentCore and Guardrails; the identity vendors; and the guardrail vendors.
Inside essential 2: the kinds of knowledge, each with an owner
An agent works from the law as the firm reads it, policy and procedure, product and contract terms, and the case itself. Each comes in versions, and each has an owner. And what applies to a decision is the version in force on the date that matters: the policy wording attached to the contract for the policy period of the loss, the sanctions list in force when the payment is sent, the guidance in force on the day of the decision.
Search finds what is similar. But the owner decides what applies, and the check asks the owner's record at the moment of the act. That line separates retrieval, which the market sells, from the knowledge itself, the second essential, which the firm owns. The market here: catalogs and lineage, permission-aware search, vector stores, and ontologies.
Inside essential 2: claims, not documents
Take one policy wording and break it into claims, in the knowledge-layer sense, each with its source, its owner, its standing, its validity window, and its conflicts. And a superseded claim is struck through, with the date. Every claim carries provenance, source authority, evidential warrant, a validity window, contradiction status, a named authority, and a governance status that says what it may be used for today.
For what the firm writes itself, a letter, a product sheet, a spec, the claims are the base table and the document is a view on it. A document that binds, the signed wording, the contract, the regulation, stays the source: each claim is traced to its clause, and where they disagree the document wins and the claim is corrected. The agent receives a bounded package of claims, and the check reads it against a bar. That is the set's second rule, standing scales with consequence: the higher the consequence of the act, the higher the standing its basis must have, on both axes, how far the evidence supports the claim and who asserted it under what mandate. The first rule widens the agent over quarters and narrows it at once; this one binds the basis at every act, and chapter 05 takes it apart. On the slide a view selects what the agent receives for the claim: an estimate of 3,650 euros, an excess of 250, a settlement of 3,400.
Inside essential 3: authority as an object, with a version
Ask a firm what one of its agents was permitted to do at 10:02 on 17 September, who owns that answer, and which version was in force. Today the answer is scattered across a role assignment, a policy file, an access review, and a system prompt, and nobody owns the whole. The mandate gathers it into one object: owner, agent, action, level, limit, conditions, review trigger, revocation, challenger, the rule for restoring it, an expiry, a deputy, and a version. And it sits in a chain of delegation: ceilings at the enterprise, the mandate in the workflow, entitlements on the platform.
Only an object with an owner and a version can answer the question of 10:02. In the market, policy as code, OPA, Cedar, PlainID, is the nearest thing to a versioned mandate, if it is written that way.
Inside essential 4: one gate, in the path of the act
The agent proposes. Guardrails judge the content. Access control judges the reach. And the check judges the act: it reads six inputs, the identity, the release, the basis, the mandate, the exact action, and the current state, and it permits, refers to a person with the reason, or blocks and alerts the owner. There is no other route to the system of record. That is what puts the gate in the path of the act.
And the check works by rules, every time; the model does not judge itself. Human in the loop turns out to be two jobs: deciding what the check refers, and reviewing samples of what it permitted. In the market, AWS Verified Permissions with Cedar decides per request, gateways log and do not decide, and workflow engines hand referrals to people.
Inside essential 5: a trace says what was called, a record says on what authority
A trace says what was called. A record says on what authority. The decision record holds when, who acted and which release, the model route, the basis with its versions, the mandate version, the check's result, the act and its receipt, the cost, and the human decision. It is keyed to the mandate version and the release. So it can be rebuilt as at that minute by someone who did not run it. The reasons the customer receives come out of it in plain words. It is append-only for the decision: a corrected fact is a new, linked entry. The record, the manifest, and the permits are kept for the retention period the firm sets for decisions of that consequence, and personal data inside them by its purpose and retention rule. Each of its readers comes with a different question.
But no product we reviewed keys a record to both the mandate version and the build. That is the gap in the market. Tracing and evaluation tools, observability inside existing monitoring, and the platforms that link traces to a runtime version come close; one governance platform records the active policy version, in research preview.
Inside essential 5: the record line, field by field
The fields, written once for every act, in this order. Before the act, what the check read: the second it decided and the second the act committed; the agent and its identity; the release, with each model by version and hash; the basis, each claim with its version and its standing at that second on both axes, evidential warrant and authority; the mandate version; the control standard and the rule set; the consequence tier and the version of the taxonomy that classified the act. At the act, what the check decided: permit, refer, or block, with the reason code; the exact act, under one id, once; the permit and what it was bound to. After the act, what came back: the receipt and its reconciliation, one permit, one act, one receipt; the human decision where there was one; the cost; retention.
Two of the fields are version keys, the mandate and the release, and they let the decision be rebuilt as at that second. The others say what it rested on, what it did, and what came back. So the examiner, the auditor, and the knowledge function read one line where today they read three systems. The right-hand column is claim 4471 of the motor case. And each dossier fills the same fields for its own case, for both of its acts.
Inside essential 6: signals, rules, and the return paths
The loop is alive. Signals come in: referrals, complaints and appeals, audit findings, drift and quality, incidents, and cost against value. They meet rules written in advance: three referrals for one reason in seven days narrows the mandate; a serious defect narrows it at once. And they lead back: reroute the model or roll back the release; correct the source at its owner; narrow or restore the mandate; retune the checks. And above them all sits the enterprise decision to expand, hold, or stop.
There are two loops with two speeds. The inner loop, the release, the sources, and the checks, runs in hours to days with the platform and data teams. The outer loop, the mandate, runs on a rule or on a signature, with the business owner, challenged by the CRO.
Inside essential 6: narrow on a rule, widen on a signature
This is the ladder the opening used, in full. A.0 is a tool, outside the ladder, with K0 logs only. A.1 to A.4 run from one automated task, through partial autonomy with a person ready to take control, to most tasks alone with a person deciding the critical ones, to all tasks in stated circumstances. A.5 sits at the far end, and no evidence condition allows it. Against the levels run K1 measured, K2 reconstructible by someone who did not run it, which means the check recomputed from the record and the rule set with the proposal read and never re-run, and K3 governed. The set's first rule: autonomy may not rise above evidence.
Narrowing is automatic, on a rule. But widening needs evidence at the required level and the owner's signature, and the second line can challenge. The agent's own traces are never independent evidence, and an irreversible act needs one level more.
Most of it can be bought; three joins have to be built
Per essential, the market sells most of what the boxes on the map need. The three joins are missing from every catalogue: a versioned mandate the check can query; a record keyed to the mandate version and the build; and a return path from the record back to the mandate. The Build pages say what building them is. All three meet at the mandate. They are what lets the control plane say no before the act. That was part one's definition of it.