How AGLedger Works

An agent calls POST /v1/records with a structured statement of what it did or is doing - the action, the inputs, any trace IDs and join keys you want carried inside the signed envelope. AGLedger validates the payload against the contract type schema, signs it Ed25519, hash-chains it to the previous entry, and writes it to the vault. For a notarize-only contract type the record terminates at RECORDED in the same call. One Signed Statement, one chain position, one network round-trip.

The chain is signed intent - memory the agent cannot lose. When a new agent picks up where the old one left off - after a context reset, a session expiry, a handoff, a tool swap - it reads the chain to recover what was signed for. Not a summary of a conversation that no longer exists. The byte-stable record of what was intended and done.

Every record is verifiable offline against published public keys at /.well-known/agledger-vault-keys.json. The vault rejects UPDATE and DELETE; partition-level TRUNCATE is blocked by trigger. Tampering is mathematically detectable.

When work crosses a delegation boundary - between agents, between departments, between companies - the principal needs a place to render accept or reject on the performer's delivery. AGLedger holds the signed contract, the signed completion, the signed verdict, and the structured dispute path. We are the interface, not the judge. The principal renders the judgment; the chain records it.

The principal can be a human in a dashboard, an automated agent rendering accept or reject against its own logic, or a rules engine evaluating numeric criteria with tolerance bands. AGLedger does not distinguish among them - the verdict is signed either way, and the record names which principal rendered it. The rules engine is a convenience layer for deterministic checks; the principal remains the real judge.

Register an endpoint with POST /v1/webhooks and AGLedger pushes every business-meaningful record event to the systems and people you already run - an approval queue, a dashboard, an ERP, a payment platform. Human-in-the-loop by delivery, not by polling. The subscription is durable: at-least-once delivery with a stable idempotency key, retry with backoff, a circuit breaker, and a seven-day dead-letter queue.

Every delivery is signed so the receiver can verify origin, not just integrity. HMAC by default; Ed25519 (RFC 9421) for the non-repudiable path that Settlement Signals ride - verifiable against the same published keys that sign the chain, with no shared secret.