What guides the work
Most failures I’ve seen start when proposal, permission and proof are treated as the same thing. I keep them separate.
- Proposal
- What the agent wants to do.
- Permission
- What it is authorised to do.
- Proof
- What shows what actually happened.
These are working patterns, not claims of certification. They describe how I design, what I test, and where I expect the limits to be.
Most of what I build is client or product work and stays private. What is here is the method.
Make approval specific
An approval should still make sense years later to someone who wasn’t there. “Approved” isn’t enough.
It should identify the action, resource, scope and evidence the reviewer actually agreed to. If the proposal changes, the approval doesn’t travel with it.
- Action
- The change that is being proposed.
- Resource
- What that action will affect.
- Scope
- The limits within which it is permitted.
- Evidence
- What the reviewer was looking at.
The control is structural: change what was approved and the original approval no longer fits.
But the technology is only half of it. A person who cannot understand the evidence will eventually approve by habit. Good controls have to support good judgment, not simply record a click.
Knowledge isn’t authority
An agent knowing something does not give it permission to act on it.
I keep knowledge and control separate. Agents can retrieve the record, but they cannot quietly rewrite it or widen their own authority. The boundary exists in the permission model, not simply in an instruction telling the agent to behave.
That separation provides containment, not truth. A well-governed record can still be wrong. The system still needs people and processes capable of challenging what it knows.
Handoff without assumptions
Work moves between agents and sessions. Authority and proof should not move silently with it.
A handoff states what is done, what remains unresolved, where the evidence lives and what happens next. The receiving agent checks the evidence and establishes its own permission to continue rather than inheriting either from the sender.
The principle is simple: a summary can point to proof; it cannot become proof.
A good handoff reduces assumptions. It cannot manufacture honesty, so unresolved work stays visible.
Advice isn’t authority
A model can be asked for an opinion. It cannot be handed the decision.
When an agent consults a model, the answer should come back typed and bounded: an answer to the question that was asked, in the form that was declared, or an explicit refusal to answer it. A confident number is not a permission. Authorisation, execution and fallback stay with the caller, and none of them moves because the advice looked sure of itself.
The design rule is that silence and failure must look different from agreement. A model that cannot fit the question declines rather than answering a smaller one, an answer that arrives too late is thrown away rather than accepted, and an opinion no second source corroborated is reported as exactly that.
The limit: a typed answer is bounded, not correct. A probability is a claim until someone has qualified it, and the record has to say which it is.
The references
I publish the approval, memory and handoff patterns, and the checkpoint contract they rely on, as references an engineer can inspect and adapt:
- agentic-approval-gates — specific approval, bounded authority and auditability.
- ai-memory-reference — separation of knowledge and control.
- agent-checkpoint-contract — what a session is allowed to resume from.
- agent-handoff-pattern — passing work between agents without turning summaries into evidence.
- Agent proposesA bounded set of actions
- Evidence gatheredSource lines stay attached
- InterlockHeld until it is signedA named person signs
- Permitted actionExplicitly grantedNot grantable
- Trace retainedAnswerable afterwards