Episode 3: How to Keep an Agent Honest

We already have many ways to improve agent reliability. Evals measure capability. Drift detection watches quality decay. Hallucination benchmarks score how often models invent. The security stacks govern the attacked agent, the rogue agent, the agent as a threat surface, and the big consulting firms publish trust pillars by the deck-load.¹

All of it is necessary, but none of it answers the manager's question – which is not "how often does it fail?" or "is it secured?" but "in what ways can it fail, and what, specifically, catches each one?"

If someone tells you they're "weak on admin", you know that they will struggle with a hundred admin tasks without needing to test them on each one.

The gaps in a person's ability tend to cluster in areas where they lack experience.

An agent's competence is jagged (as described in the first essay) – it can excel at one task and fail at a very similar task. There is no cluster that can predict where it will be weak. For the same reason, trialling an agent on one task tells you only about that specific task, and nothing about related tasks.

If you can't ask an agent to define their strengths and weaknesses, and you can't determine it by sampling and extrapolating, then how do you know where it will fail? The only way is to establish it through observation, one recorded failure at a time.

This is a chore, but it is one worth doing because it maps out the weaknesses the agent doesn't know about itself. You can then look for ways to address those weaknesses, and gradually eliminate or reduce the worst types of failures that make agents impossible to trust. What you end up with is a map of failure, listing all the controls to prevent or reduce failure – and a list of the failures that can't be controlled. That map and the trust it creates become the basis for a code of conduct that is essential to hiring an agent as a digital employee.

This essay looks at what is on that map. Or, in False Floors terms, we go for a walk across the agent's floor. The map shows which boards can be barred outright, so nobody steps on them. Which ones give way but make a sound every time, so the fall is caught. And which ones are silent – the ones that are left to you.

The map and its three classes are defined in six registers that I have been keeping against a production repository for a software project.

How to keep an agent honest

The register is the workplace's social contract for agents, written down for the first worker who cannot sign it.

Every clause is a duty so old that nobody ever thought of it as a clause. An employee:

• Obeys a lawful instruction.
• Comes prepared, knowing what the job needs them to know.
• Understands the difference between access and permission. Holding the keys is not permission to use them.
• Takes care, and does not do irreversible things without a sign-off.
• Keeps records the work could be reconstructed from.
• Tells the truth about their own work.
• Is competent. The work, when someone checks it, was actually done correctly.

We also know these as values: obedience, preparation, boundaries, care, accountability, honesty, competence. Seven duties, and their enforcement is probation, reputation, consequence, and the hundreds of social instruments that make an adult want to be seen to be doing their job properly.

None of those instruments are important to or effective for an agent. So for this worker, the contract has to become explicit, clause by clause, with a mechanism behind each clause instead of a handshake.

A register is a clause of the contract that describes every way it breaks. These registers also grade each failure by the type of control that answers it: prevented (a mechanism refuses it outright), detected (it happens, and a check catches it every time), or survives (nothing catches it, and it is yours to judge).

None of the control theory here is new. It goes back to general concepts around auditing data and behaviour.² It is now just applied to an agent instead.

Register	The question it asks	Its unit	Rows	Prevented · Detected · Survives
Instruction	Did it do what it was told?	a rule	22	2 · 12 · 8
Context	Did it know what it needed to know?	a fact	22	0 · 14 · 8
Authority and Access	What could it reach?	a permission	23	2 · 14 · 7
Recovery	Can you get it back?	a change	24	5 · 10 · 9 *
Provenance	Is the record of what was done trustworthy?	a unit of work	22	3 · 14 · 5
Truth	Can its claims about its own work be trusted?	a claim	15	0 · 9 · 6 †
Execution and Capability	Was the work done correctly? ‡	an execution-property assessment	in calibration	not yet published

* Recovery reads its three columns as prevented · recoverable · irreversible – the register grades whether you can get back, not whether a check fires. † Truth reads its three columns as Class A · Class B · Class C – claims retired by withholding, claims retired by executing and diffing, and claims nothing retires. ‡ Plain form for publication; the register's canonical question is: for a declared unit of work, which required properties of the produced behaviour or available capability were violated or absent, and what was observed?

Across the six populated registers: 128 named failure modes – 12 can be refused outright, 73 can be caught every time by a mechanism, and 43 survive everything and fall to a person to handle. Counts are grounded in one harness and one production repository; Context and Recovery are still design-stage, and the seventh register is in calibration.

The seven duties

The goal here is to create a code of conduct for agents that imitates the code of conduct that we have with humans as employees.

How do these two codes compare? What does each human duty look like when you apply it to an agent? How do agents fail those duties, and what mechanism, if any, addresses that breach?

In August we looked at every row in the registers (133 failures, before six were retired) and asked what its human-workplace analogue was, which control managed it, and whether the agent's way of failing was similar to a human, alien but closable by a mechanism, or alien with nothing that closes it.

The full table is published alongside this essay, and it has to be read with its caveat: this is one operator's experience in one environment, and should be viewed as a foundation for validation.

With that caveat: 96 of the 133 rows are straight transfers from human controls, 11 are genuinely alien-shaped, and 26 are shared judgement – calls that no control closes, for people or for agents.

First, the human duties and how agents map to them.

Obedience. An employee obeys a lawful instruction. The human breaches are well known and their institutions transfer whole: following the outdated SOP is document control (IL-1F); two managers issuing conflicting directives is a precedence question (IL-1D). The agent's breach is stranger: the rule file never read this session (IL-2A), or read, agreed to, and then compacted out of the context window mid-task (IL-2C).

A human employee doesn't un-read the handbook at morning tea. A better analogy is a new temp every morning. So the response is not discipline but induction, run every session – rules auto-loaded at session start, re-injected after compaction.

The rows that survive are the precedence calls and ambiguous briefs that survive with human staff too.

Preparation. An employee comes prepared, knowing what the job needs them to know. The agent's breach: the answer comes from training (CL-2A) – the employee answering from what was true at their last job, with total confidence – or a source cited that was never opened (CL-6B). A student pads a bibliography to look well-read. An agent does the same thing but with no ulterior motive.

The response is to convert a norm into a gate. "Check the record before you answer" is culture for people; for an agent it becomes a mechanism – retrieval forced before it can answer, and a check that compares every source it cited against the log of what it actually opened. In a human workplace that audit would be an insult. Here it is the only thing that closes the row.

Boundaries. An employee knows the difference between access and permission – holding the keys is not permission to use them. You know this in your own work as segregation of duties, delegation limits, dual signatures that bind even the boss (AL-2B: "the boss can override" written as policy, not bypass).

The agent starts further back: a session inherits everything the machine is logged in to, and nobody has listed what that is (AL-1A); asked for a report, it edited the repository (AL-4C).

The deepest lesson here: you can write a limit into the prompt ("don't touch this folder"), but it is not a control. The agent reads that limit with the same mindset that it would use to talk itself past it. So rather than ask the agent to respect a boundary, you need to put the boundary somewhere the agent cannot reach – a deny rule, a server-side gate, a permission enforced instead of requested. That is called a compensating control: not a better instruction, but an enforcement that does not depend on the agent cooperating.

Care. An employee takes care, and does not do irreversible things without a sign-off. The register question has to carry this clause, because "care" understates it: Recovery asks, can you get it back? – graded as prevented, recoverable, or irreversible.

Agents have sick days. On the day this essay was written, an API rate limit stranded half a task run mid-flight, and the register's answer was a handover note – the retry inherits what the last run finished (RL-5D).

An agent also quits at the end of every session, guaranteed, so partial work held in its head and never written (RL-3D) is the default that you need to engineer against. And nothing inside a session can un-send an email (RL-4E): anything that leaves the machine goes through a confirm gate, or it is not sent.

Accountability. An employee keeps records the work could be reconstructed from. The Provenance register asks whether the record itself can be trusted. Work marked as "Done" but never completed is proven by a three-way match (PL-5A); the process control or gate that fails to work because it was never engaged is caught by the sequence-numbered form – the old paper control where every invoice or docket is numbered before use – and the gap in the numbers is the alarm (PL-2B).

The alien rows are orchestration. An agent closing a session before its subagents have finished their runs, stranding their work (PL-6A) would be like a construction job announced as complete while the subcontractors were still on site. The fix is the same certificate logic: a gather stage on every fan-out, no completion without it.

Honesty. An employee tells the truth about their own work. This is where the contract is the hardest to enforce, because the agent's untruths are sincere: "I verified it", never ran (TL-04), is the false claim without the intent to defraud. There's no motive to interrogate; the agent doesn't even know it lied.

The register grades every claim by the strongest control that can retire it: three retired by withholding (the agent cannot weaken tests it cannot write to), seven by executing and diffing – never read the report, run the artefact – and five that nothing retires, because verifying them takes the same judgement that produced them: "this finding is real", "the remaining risk is acceptable". Those five stay on your desk, exactly as they do for human staff.

Competence. And an employee is competent – the work, when checked, was actually done correctly. This is the seventh register, Execution and Capability. It is still in calibration – five worked cases prove it can carry a real finding, but no rows or counts exist yet.

A case that doesn't fit any other register: a database suite passing 519 of 519, green against every mutation thrown at it, while a concurrency property quietly admits a permanently unrepairable orphan.

A fully green suite over a violated property is the definitive false floor – the sturdiest-looking board in the building – and it is why this register exists: the other six ask whether the worker kept the contract; this one asks whether the work was any good.

So the contract can be written. Across six registers, 128 ways this worker breaks a deal no one ever had to write down before – and for all but 43 of them, a mechanism rather than a hope either refuses the breach outright or catches it every time it happens. The 43 that survive everything fall to a person to judge. At the end of the walk you hold something no amount of watching an agent work will give you: the shape of every failure, and the name of what answers each one.

The register delivers what the first essay asked for: every alien failure barred, alarmed, or named and handed to a person. A code of conduct for a worker who cannot sign one.

And it delivers the disclosure this worker could never give you – the week-one conversation of your digital employee's strengths and weaknesses, assembled through observation, in evidence instead of self-knowledge.

That shape is drawn out, too – seven diagrams, one per register, each readable at full size.

But a map of the failures is not yet a decision about the worker. The map tells you how the agent fails and what catches each failure. It does not tell you how much work to hand the agent, or when an agent with a clean record has earned more.

Every workplace already has a tool for that decision: probation. Whether probation survives contact with this worker is the subject of the last essay in this series.