Systems I run

These are the controls underneath my day-to-day agent work: what an agent is allowed to do, what it has to prove, and who answers for it.

It runs on my own machines, on my own work, every day. It isn’t a proposal.


Why these controls exist

An agent that can act is a delegation problem before it is a technology problem. Once software can change something durable, I need the same three things a settlement system asks for. The actor being a model doesn’t make them any easier.

The decision must remain explainable
Authority
Identify who authorised the change.
Evidence
Keep the basis for that authorisation.
Reconstruction
Be able to show how the decision happened.

So the estate is built around a single rule, stated in its constitution:

No entity may silently take another entity’s authority.

Everything below follows from that one sentence.


Three planes

The control plane — method and authority

A portable, owner-governed working method that admits evidence, bounds execution and requires honest proof. It stays functional when the memory plane and every external provider are absent, because a control that depends on a service isn’t really a control.

It runs a two-phase law. First, admit the minimum sufficient evidence: objective, acceptance criteria, constraints, exact regions, dependencies, tests, unknowns, risk and authority. Then act and prove: execute within scope, verify the exact subject, checkpoint material transitions, clear obsolete output, and stop.

Owner gates are explicit and non-negotiable. Commits and pushes, deployment, production access, data and schema mutation, global configuration, service restarts, security exceptions and anything irreversible require the owner, not a confident agent.

The memory plane — read, but not quietly rewrite

Durable cross-project knowledge, retrieved on demand rather than loaded wholesale. The control plane may perform bounded, routed reads from it. It may not write to it.

That asymmetry is the whole design. An agent that can rewrite its own history can launder a mistake into a fact, and nobody reviewing the record afterwards would be able to tell. Retrieval is cheap; durable writes require an authority the agent doesn’t hold.

The continuity plane — handoff with receipts

Work crosses sessions, machines and agents. Requests, receipts, evidence and checksums carry the handoff, and all are read verbatim. A summary of a receipt is not a receipt.


Controls that refuse

The distinction I care about is between a guideline and a control. A guideline asks. A control refuses.

The project state each session resumes from is governed by a versioned contract with hard limits: a maximum line count, a maximum size, exactly one resume target. State that exceeds them is rejected, not warned about. While I was writing this page, that contract blocked my own checkpoint five separate times in one session until the state was condensed to something a stranger could actually read.

That is the point. A limit you can exceed when it suits you is a preference. The value of the contract is precisely that it is inconvenient at the moment you would rather it weren’t.

The same principle runs through the rest. Capabilities are pinned and removable rather than ambient. A missing dependency is a supported state that degrades honestly rather than a crash. Provider behaviour never becomes method authority.


What stays private

The instances stay private, and they will. The journals, the decision records, the failure logs, the machine topology and the configuration are mine, and none of it is interesting to anyone else in raw form. A learning ledger read cold by a stranger is an incident report published about yourself.

What is publishable is the part that transfers: the contracts, the schemas, the protocols and the reasoning. Nobody can reuse my instance. Anyone can reuse the specification, and the specification is the more valuable artefact anyway.


Read the references

The patterns are written up in full, as references rather than libraries: