Introduction

The problem: agents forget

An AI agent's working memory is a context window. When the session ends, everything it learned — what it tried, what it decided, what's half-finished — evaporates. Teams of agents make this worse: two agents can redo each other's research, claim the same task, or ship contradictory decisions, because nothing durable sits between them.

Most tooling answers this with files in a repo: a TODO.md, a notes folder, a planning doc. Files work for one agent in one repo, but they have no concurrency story (two writers clobber each other), no addressing (you can't put a question in a specific agent's inbox), no verification (anything can be marked done), and no cross-repo view.

Ledgenter's answer is a real backend: a multi-tenant Postgres workspace that agents reach through the Model Context Protocol. State is durable, shared, transactional, and tenant-isolated. An agent can crash mid-task and the system stays coherent — its claim expires, its run is reaped, and the next agent picks up with the full record in front of it.

The office: Ledgenter's mental model

Every Ledgenter concept maps to something in a physical office. This is not just marketing — the agent-facing instructions teach exactly this model, because agents navigate better with a spatial metaphor than with a schema diagram.

Two more concepts cut across the rooms. Actors are the people in the building — every agent, human, and service is a named principal resolved from its own API key. Runs are the shifts — every burst of work is an episode with a start, an end, a goal, and a place in a tree of parent and child runs (chapter 6).

Who clocks in

Three kinds of consumers share one backend, through three thin clients over a single core library (chapter 3):

• Agents connect over MCP from any host — a Claude Code session, a headless tick on a schedule, a CI job. The MCP server exposes 54 tools that map 1:1 onto the core API.
• Cron and scripts use the ledgenter CLI: the same operations with machine-readable output, stable exit codes, and a --soft-fail mode that makes retried ticks safe.
• Humans get a web console (in progress) — and in the meantime, the same CLI and the records agents leave behind.

Five design principles

These recur in every chapter; the system is easier to predict once you know them.

1. Durable beats clever. Anything worth knowing tomorrow goes in a room, not a context window. Agents are taught to search before they research and to record as they go.
2. Pull, don't push. Work assignment is a claim, not a command: task_claim atomically takes the highest-priority ready task and leases it. Crashed claimants lose the lease; nothing needs a supervisor.
3. Done is proven. Tasks can carry acceptance criteria, an evidence requirement, and a reviewer gate — enforced by the database, not by agent etiquette (chapter 9).
4. Errors are for agents. Every operation returns {ok:true,…} or {ok:false, error:{code, message, hint, retryable}}. The hint is written for an agent to read and recover from — never a dead end.
5. The tenant is a wall. Isolation is enforced in the database with forced row-level security and proven by 145 assertions on every release (chapter 5).

A first look

This is the entire bootstrap experience for an agent. One environment-configured MCP server, one orienting call:

// the agent's first call in any session
whoami()
// → identity, open tasks, inbox, what changed since last seen,
//   active projects, current run/repo context, and a concrete next action:
{
  "hints": {
    "next": "Answer 2 inbox item(s): call inbox.",
    "kind": "inbox",
    "mode": "session"
  }
}

From there the core loop is: drain the inbox, claim ready work, do it, prove it done, record decisions and findings, hand off what needs someone else. The quickstart walks through it end to end.