Change control for multi-agent systems

In most multi-agent stacks, work moves by queue or function call: one component invokes another, and the only trace is a log line written by whichever side happened to log. AGLedger makes the handoff itself the record. The intent and terms of the job go on the record first, the performing agent accepts on the record, and only then does work begin. The agreement is the before picture; the completion and verdict are the after.

That before-and-after structure is what a log cannot give you. A log tells you what happened, written during or after the fact by the party doing the work. A recorded agreement gives divergence something to diverge from: when what was delivered drifts from what was agreed, the drift is visible, attributable, and signed.

Acceptance is the rule, not a special mode. An agent accepts work that a person, a system, or another agent puts on the record. Where a deployment grants an agent authority to hand work onward to a defined set of others, that grant is itself recorded. So when work runs deeper, an agent acting for an agent that acts on a person's mandate, the chain is built to answer “on whose authority” at every step, back to the person, not just to the last agent that acted.

Agents lose context. They restart, hand off, compact their history, or get replaced mid-task. In a multi-agent system that failure compounds, because the agent that resumes is often not the agent that agreed. Because the agreement lives in the signed record rather than in any one context window, a performer can read back exactly what it agreed to, for whom, and what done looks like, byte for byte rather than reconstructed from a summary. Handoffs and restarts stop being data loss.

This is the same record the auditor reads later. The agent uses it to recover; the operator uses it to oversee; a third party verifies it offline against published keys. One object, three readers, and nothing to re-export or convert when the next reader shows up.

When delegated work comes back, someone must decide whether it is done right, and in a multi-agent system the wrong answer is “the agent that did it.” When work is gated for review, the verdict belongs to the principal named on the record: a person, your own system, or another agent. The separation is enforced by the Server, not by convention. A performer's attempt to render the verdict on its own delegated work is rejected, and an agent cannot appoint itself the judge of work another party put on the record.

For deterministic checks, the engine renders the verdict directly from the evidence: an amount against an authority ceiling, a score against a band. The decision comes from the evidence value, not from what the agent says about itself, which closes the classic laundering hole where an agent sets its own “review not required” flag. Either way the verdict is signed, held on the chain, and names who rendered it. The Gate covers the full lifecycle: create, accept, completion, verdict, and the dispute path behind it.

Nothing new is bolted on as the system grows. The record that covers a single agent's work is the record that scales:

• Notarize, the spine: one agent's intent and outcome, signed and hash-chained the moment each happens.
• Delegation: a second party appears. The record names a performer, the performer accepts, and the agreement, completion, and verdict are entries on the same chain.
• Federation: the parties sit in different organizations. Each runs its own Server, each Server signs its own portion with its own key, and the signed span extends across the boundary while criteria and evidence stay local. The chain crosses; the data does not.
• Federated gates: the verdict itself crosses organizations. A principal in one company renders the decision on work performed in another, and the outcome routes onward as a signed Settlement Signal to the systems that move value.

Cross-company coordination is its own page: Federation, multi-agent work across companies.