The companion paper to this one, "The case for a trust layer," made the market argument: AI can do the work, and the missing piece is proof the work got done right. This paper makes the mechanism argument. It defines the smallest set of primitives that turns agent activity into verifiable work, shows how the primitives compose across multi-step jobs, names the failure that appears when any one of them is missing, and proposes how a business measures whether the mechanism is actually holding.
The mechanism is deliberately small. Three primitives. One composition rule. One unit of account.
1. Three gaps, precisely
Field research on deployed agents keeps finding the same three holes.
The evaluation gap. Half of enterprises have shipped an agent that passed internal evaluations and then failed a customer; only one in twenty fully trusts automated evaluation (VentureBeat, 2026). Scores predict deployment readiness poorly because the test distribution is not the world.
The evidence gap. Eighty-seven percent of organizations encourage agent use while fewer than half have matching governance; among governance activities, evidence, meaning documentation, audit trails, and proof of what happened, ranks last at 28% (OneTrust via Kiteworks, 2026). When a customer or regulator asks "prove it did the job right," the record does not exist.
The approval gap. Nearly half of organizations report an incident where an agent did something nobody approved. Approval, where it exists, usually arrives as a review of screenshots after the action, which is narration, not control.
Any serious trust mechanism has to close all three. Closing one or two leaves the failure mode that remains.
2. The three primitives
Boundary. A boundary is the set of constraints stated before a job starts: what the work may touch, what it may spend, what it may decide on its own, and the conditions under which it must stop and ask a person. A boundary is a control only if the runtime enforces it, meaning it can halt the work mid-flight. A boundary that is merely written down is documentation. The distinction matters and we will return to it.
Formally, treat a boundary as a predicate over actions: for each proposed action, allowed, denied, or escalate. The predicate is evaluated by the runtime before the action executes, never by the agent proposing it.
Trail. A trail is the contemporaneous record of the work: what was done, when, under which boundary, with whose approval, citing the inputs it acted on. Two properties make a trail evidence rather than memoir. It is written by the runtime as the action executes, not composed by the agent afterward. And it is append-only: later steps may correct earlier ones, but they cannot rewrite them.
Check. A check is a verification of an outcome against ground truth outside the agent's own report. The invoice amount against the payment ledger. The booking against the calendar. The refund against the processor's record. A check that reads the agent's summary proves nothing except that the agent can summarize. Ground truth is the entire point.
The three laws of the Armalo Layer are exactly these primitives stated as rules: every job has a boundary, every action leaves a trail, every outcome gets checked.
3. Composition: from actions to jobs
Real work is multi-step. A lead follow-up reads an inquiry, matches a service area, drafts a reply, sends it, watches for an answer, and books a slot. The mechanism composes.
Boundaries nest. The job boundary (answer this lead, book inside these windows) contains action boundaries (this send may cite only published pricing). An escalate at any level halts the job at that point and routes to a person with the trail so far attached.
Trails chain. Each action's record references the job and the prior step, so the job's history is a single ordered chain a reviewer can walk forward or backward. The chain is what makes "walk it back" possible: every step names its inputs and its approval, so undoing step n does not require guessing what steps 1 through n-1 did.
Checks compose into outcome predicates. A job is done when its outcome predicate holds in the world: the inspection is on the calendar and the confirmation reached the customer. Partial completion is representable and common: the reply sent and checked, the booking still open. The ledger reports the predicate state, not the agent's confidence.
4. The failure taxonomy: what breaks when one primitive is missing
Each missing primitive produces a characteristic, recognizable failure.
Boundary without check: policy theater. The limits exist, the runtime even enforces them, but nobody verifies outcomes. The system can prove it stayed inside the lines and cannot prove the work mattered. This is the most respectable failure and the most common one in mature organizations.
Trail without boundary: surveillance. Everything is logged, nothing is constrained. Incidents are beautifully documented after the customer is hurt. The approval gap lives here: with no predicate evaluated before actions, approval degrades into post-hoc review of a record nobody can change.
Check without trail: unaccountable sampling. Outcomes get verified, sometimes, but with no chained record there is no way to know which actions were checked, which were skipped, or what to fix when a check fails. Verification becomes a spot-check lottery.
Score instead of all three: the evaluation gap. A pre-deployment score is a boundary substitute (it constrains which agents ship) with no trail and no check at runtime. The field data says what that buys: passing scores, hurt customers.
The taxonomy is the practical test of any trust-layer claim. Ask which primitives are real, meaning runtime-enforced, runtime-written, and world-checked, and which are described in a slide.
5. The receipt: the unit a business runs on
Composing the three primitives over one job produces a single artifact: the boundary the job ran under, the chained trail of its actions, and the result of its outcome check, including any escalation and its resolution. Call it a receipt.
The receipt is the unit of account for agent work. A morning ledger is receipts, aggregated: what ran overnight, inside which boundaries, with which outcomes verified, and which items wait on a person. Approvals act on receipts. Disputes resolve against receipts. Rollback follows receipts. Pricing, eventually, can follow receipts too: verified outcomes are a meterable quantity in a way that tokens and seats are not.
Note what the receipt is not. It is not the agent's self-report, though it may quote it. It is not a log file, though logs feed it. It is a claim about the world with its evidence attached, produced by the normal execution path rather than prepared for an audience.
6. Measuring whether the mechanism holds
A mechanism that cannot be measured cannot be trusted either. Four quantities, all computable from receipts:
- 1.Proof coverage. The share of completed jobs whose outcome check read ground truth. Below full coverage, the uncovered share is activity, not outcomes, and the ledger should say so.
- 2.Boundary-stop rate. How often boundaries halt work, split by denied and escalated. Zero stops over a long window is not reassurance; it suggests boundaries are decorative or never tested.
- 3.Check latency. Time from action to verified outcome. Long latency means the business runs on unverified work for that whole window.
- 4.Approval latency and override rate. How long escalations wait on people, and how often people reverse the agent after the fact. Rising overrides with flat boundaries means the boundaries are wrong, not the people.
These are proposals, stated so they can be argued with. The claim underneath them is not.
7. Limitations and falsification
Three honest limits. First, ground truth is not always available: some outcomes, like the quality of a piece of writing, have no ledger to read. Checks degrade to structured human review there, and the receipt should label them as such rather than pretend otherwise. Second, boundaries cost design effort; a boundary written carelessly either strangles the work or constrains nothing, and both failures look fine in a demo. Third, the mechanism adds runtime overhead to every action. The bet is that verification is cheapest when built into the work, and the bet is falsifiable: if boundaries, trails, and checks slow agent work to human speed, the economics fail and the category with them.
The larger claim falsifies cleanly too. If evaluations start predicting real-world outcomes reliably, the receipt matters less. If customers and regulators accept vendor self-attestation, the demand for proof never materializes. We do not expect either. The gaps are widening, and "prove it" is getting louder.
8. Summary
Every job has a boundary. Every action leaves a trail. Every outcome gets checked. Compose the three and a business gets receipts: the unit it can approve, dispute, price, and stand behind. That mechanism, running underneath a company that builds and runs itself, is the Armalo Layer and the Armalo Stack. The market currently verifies the input and the identity. The receipt verifies the work.
Sources
- VentureBeat, "The agent evaluation gap" (2026): 157 enterprises; 50% shipped an eval-passing agent that failed a customer; 5% fully trust automated evaluation.
- Kiteworks / OneTrust (2026): 87% encourage agent use, 47% have matching governance; evidence ranks last among governance activities (28%); 48% report unapproved agent actions.
- VentureBeat, RSAC 2026: every vendor verified agent identity; none tracked what the agent did.
- Armalo Labs, "The case for a trust layer" (2026): the market argument and category definition this paper operationalizes.