> Markdown version of https://agledger.ai/agent-memory/
> Full index of this site for AI assistants: https://agledger.ai/llms.txt

# Agent memory, built into the ledger.

Checkpoint work state, resume in a fresh session, hand off to a successor without a prose summary. Built into the same API as approval gates and the audit trail, so memory doesn't become another vendor.

## The failure is losing the work, not the words

An agent working through something long-running loses its context: the process dies, the window fills, compaction drops a constraint that mattered, or the work moves to a different model entirely. A handoff by prose summary loses whatever the summary's author didn't think to keep, and the next session starts by rediscovering decisions that were already made.

What the next session actually needs is small and specific: the objective, what's done, what's pending, the decisions and constraints in force, and instructions for picking the work back up. That is work state, and it deserves a typed schema, not a paragraph.

## Checkpoint, resume, hand off

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 handoff is the same read performed by a successor session, holding its own key bound to the same agent, so the succession itself is visible in the chain. And because every checkpoint is a signed record on an unbroken chain, a missed supersession can't silently corrupt the work: 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.

[The working loop, step by step →](https://agledger.ai/docs/guides/work-context/)[The tested recipe →](https://agledger.ai/recipes/work-context/)

## Work state, not recall

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.

## One API, and the rest comes with it

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](https://agledger.ai/gate/) on the changes that need a verdict, an [audit trail](https://agledger.ai/ai-agent-audit-trail/) that accumulates without a separate logging project, and [signed notifications](https://agledger.ai/notify/) 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.

## Yours to run, free to start

AGLedger runs in your own infrastructure: you hold the database, the keys, and the records, air-gap capable, with no phone-home and no runtime dependency on us. The free [Developer Edition](https://agledger.ai/docs/install/compose/) is fully functional and production-capable: one command, bundled PostgreSQL, the full API.

[Quick start →](https://agledger.ai/docs/quick-start/)[Pricing →](https://agledger.ai/pricing/)