Agent-native project execution

A tracker that runs the agent loop.

Every other tracker is a list built for a human to read top-to-bottom. AgentLedger is a work queue an AI coder can run unattended: decompose a spec into tasks, claim them without collisions, batch by which files they touch, and rank by the dependency graph — all through one self-describing MCP.

Join the waitlist Read the technical deepdive → View source
27 MCP tools pgvector memory local-first · one docker compose up offline by default
agent → POST /api/mcp 
# an agent pulls a whole code-neighborhood in one call
next_cluster({ agent_id: "builder-1", max_items: 3 })

→ { claimed: 3, cluster: [
    { id: "AL-13", status: "in_progress", claimed_by: "builder-1", seed: true },
    { id: "AL-14", shared: ["backend/app/routers/*"] },
    { id: "AL-15", shared: ["backend/app/routers/*"] } ] }

The problem

Agents don't need a list. They need a graph they can run.

Point an agent at a normal tracker and it grabs the top card, loses track of what it already touched, collides with the next agent, and has no idea which work unblocks the rest. The primitives a human tracker optimizes for — a single ordering, drag-to-reorder, a status dropdown — are the wrong shape for an autonomous loop.

How it works

The loop

Six calls form a cycle an agent runs on its own. The spec is the source of truth at both ends; completing work emits the next batch.

prd_coverage
what's specced but unbuilt
→
decompose_prd
spec → tracked tasks
→
get_backlog
dependency-aware, code-local
→
claim_next
atomic, leased — no collisions
→
update_item done
auto-extracts lessons → memory
…then back to coverage. The loop closes on itself.

Why it works

Four things a normal tracker can't do

Safe claiming

Multiple agents, zero collisions

claim_next atomically assigns the best ready item with an optimistic guard — two agents never take the same task. Leases + heartbeats free a crashed agent's work automatically.

Code-locality

Pick up related work at once

Items declare the files they touch. next_cluster claims a whole code-neighborhood in one call, so an agent works one area instead of context-switching across the codebase.

Dependency-aware

Priority from the graph

Readiness comes from real dependency links, not a flag. The backlog ranks ready-first, then by what unblocks the most, request votes, effort, and staleness — never handing out blocked work.

Spec-driven

The spec drives the tracker

Items trace to a PRD section. decompose_prd turns a spec into tracked tasks; prd_coverage reports what's built, in progress, and still a gap — closing the loop with the doc.

The interface

Built for agents, not bolted on

REST for people, MCP for agents — both over the exact same service layer, so an agent's write shows up in the web tracker instantly. The 27-tool surface is self-describing: typed inputs and outputs, read-only / destructive annotations, idempotency keys so retries never duplicate, and pagination. Arguments are validated before dispatch, and every failure comes back with a machine code — not_found, validation, conflict, unauthorized — plus a hint naming the fix, so an agent knows whether a retry could ever help instead of guessing from prose.

Persistent agent memory

pgvector semantic recall. Finishing an item auto-extracts its lessons into memory — the loop doesn't repeat past mistakes.

Enforced isolation, on the record

One key = one agent, scoped to one workspace — and it's enforced: a key can't reach another project's data or out-rank the human who minted it. Every mutation lands in an audit ledger, attributed to the agent that made it.

Real integrations

GitHub issues route to the right project and link back; PRDs two-way sync with a markdown folder — conflict-flagged, never clobbered.

Yours to run

One docker compose up and it's live on your machine — Postgres, API, and UI. Fully offline; no keys, no accounts, no external calls required.

The mentality

Built like the agent is the user

When a coding agent operates the tool unattended, the environment around it is the product. A confusing error isn't a rough edge — it's the app failing at its one job. So the whole system is built to a single bar: a capable agent should be able to do a whole job and prove it, with a person supplying judgment, not acting as a relay.

One source of truth

Duplication is a build error

MCP and the web UI run the same service layer — one path to the database. Facts like statuses and the tool list have one owner; a CI ratchet fails the build the moment the docs and the code disagree.

Authority, enforced & audited

Capability ≠ permission

An agent acts freely in reversible space and is gated where it matters. Key scope and project membership are enforced at every boundary, and every mutation is recorded — who, what, when.

Errors that teach

Every result is context

Arguments are validated before dispatch; failures carry a typed code and a hint naming the fix. An agent branches on the code instead of parsing prose — and knows when a retry can't help.

Proof, not vibes

Tested on the real engine

Production is Postgres + pgvector, so CI runs the suite on both SQLite and Postgres every change — catching vector-search and migration bugs a single-engine suite waves through.

The engineering write-up lives in the technical deepdive.