Agent memory, built into the ledger.

An agent runs when something triggers it, does its part, and ends; the next trigger starts it with an empty context. That is the design: a fresh start costs less and reasons better than a context carrying every earlier step. Long-running work spans many runs, and resets happen inside a run too: the window fills, compaction runs, the work moves to a different model. A prose summary keeps only what its author thought to keep, and the next session starts by rediscovering decisions that were already made.

What the next session needs to catch up is small and specific: the objective, who asked and on whose authority, what's done, what's pending, the decisions and constraints in force, and what has been sent out to other agents. That is work state, and it deserves a typed schema, not a paragraph. The agent writes it before, during and after the work, and reads it back at the start of every run.

The agent checkpoints its work state as typed records under one root record that represents the piece of work. Each checkpoint names the checkpoint it supersedes; the engine resolves that link at create time and indexes it, so one query returns exactly the current head. A fresh session of the same agent reads the head, does the next pending item, and writes its own checkpoint. No prior conversation is needed, and any process that speaks HTTP can run the loop.

A successor session taking over performs the same read, holding its own key bound to the same agent, so the succession itself is visible in the chain. A missed supersession can't silently corrupt the work either. Because every checkpoint is a signed record on an unbroken chain, the fork shows up as two heads on the next read, immediately, instead of surfacing weeks later as an agent confidently resuming from stale state.

Long work often means waiting on another agent. The agent delegates and ends; a later run checks status (not done) and ends; another checks again and picks up the result when it lands. Because the delegation is recorded before the work is sent, each check starts from the record, not from memory, and a deadline on the delegation turns an endless “not done” into a failure the next run can act on.

In our measurement across three model vendors, an agent reset right after delegating caught up on the work it had sent out 21 times in 24 with the record, against 8 in 23 without it; most of the rest sent the same work out a second time.

A dedicated memory layer optimizes recall: retrieving the right facts into a context window. That is a real problem, and it is not this one. AGLedger holds the current picture of in-progress work, typed and schema-guarded, where the questions are different: is this the latest checkpoint, did anything fork, and is what I'm resuming from what was actually written. Run a recall layer beside it if your agents need one; the two don't compete for the same job.

Memory as a standalone product does one job, and approvals, audit, and delivery then live somewhere else. Here they share one API and one ledger. The same records that carry checkpoints carry approval gates on the changes that need a verdict, an audit trail that accumulates without a separate logging project, and signed notifications to the systems and people around the work. An agent that checkpoints its work is already producing the record the rest of the company will eventually ask for.