Kanban boards vs an execution ledger for coding agents

Put coding agents on shared work and the first tool most teams reach for is a board, because the board is what everyone already knows: columns for status, cards for intent, a drag for progress. This page compares that instinct against its stricter alternative — an execution ledger, where task state is a repository artifact with dependency, evidence, and concurrency semantics the workers themselves can read and enforce. The named instance on the ledger side is YYLO Ledger, the Git-native task manager published on PyPI that carries YYLO's task-truth layer; the board side is the category, judged by what every board tool shares by construction rather than by any one vendor's feature list. Every ledger behavior below was executed live against the released CLI and the README committed with it, on 2026-08-29, and the claim-source panel beneath the matrix names where each fact came from. Six verdicts fall out: one for the board, one tie, four for the ledger — a split that says keep the board where people plan, and put execution truth where agents work.

One honesty note before the matrix. No observed keyword evidence stands behind this decision: none of the competitor keyword exports feeding this site's other comparisons contains a phrase mapping to the board-versus-ledger choice, so this route claims no demand figure, cites no search estimate, and lists no corpus among its claim sources. Its justification is the approved content strategy plus released product truth, nothing else, and nothing here forecasts what anyone will search for.

What each side actually is

A Kanban board, structurally, is a visual state machine living in the vendor's database. The card holds the intent; the column is the status; the drag is the transition; the product keeps the records, renders the view, and logs the activity. Those properties are the board's strength and its ceiling in the same stroke: the view is unmatched for humans, and the state is reachable only through the product that owns it — its app, its permissions, its API for whoever builds the integration. None of that is a defect for standups and sprint planning. It becomes a ceiling the moment the workers are agents, because an agent does not glance at lanes and cannot drag a card until someone writes glue against that database first.

An execution ledger inverts where the state lives. YYLO Ledger keeps each task as a plain, validated record under .juno_task/tasks/ inside the repository itself — status a field, blockers a field, the recorded answer a field, the landing commit a field — and one command-line surface that people and programs can both run owns its reads and writes. The current release installs from PyPI as the yylo-ledger package, with the full command surface documented in its README. The longer introduction to these semantics — why dependency-aware, response-carrying, commit-bound state is the right memory for agent work — has its own guide; this page keeps to the decision between the two models.

The surface the board wins, and the vocabulary both keep

The first verdict belongs to the board, and not as a consolation prize. A board is a genuine planning instrument: columns make work-in-progress visible at a glance, card order makes priority arguable in a meeting, and re-planning is a physical act that takes seconds and leaves the judgment with humans. The ledger side has no board at all. Its surface is a terminal answer — list and ready reporting in text — and nothing in the shipped interface draws columns for you. If the question is what the whole plan looks like while a team argues about it, the board answers better than any text listing will, and the matrix says so plainly.

The second verdict is a tie because the ledger did not invent a new vocabulary — it kept the board's. Statuses in YYLO Ledger are first-class fields under configurable workflows, and the README's own bullet reads "Configurable status workflows (backlog → todo → done)": the lanes a team already argues about arrive as validated states rather than as a diagram. What changes is enforcement. A board moves a card because a wrist decided it; a ledger moves a status through a command that records the actor's answer and refuses transitions the declared state does not allow. Teams that keep both surfaces lose nothing by the tie — the vocabulary round-trips, which is exactly why the verdict reads both.

Dependencies: drawn versus declared

On most boards a dependency is a picture: an arrow between cards, a link field, or a convention everyone promises to honor. Pictures are fine for people and useless to automation — no dispatcher can consume arrows, and where a board tool does compute blocking, it computes inside its own database behind its own integration. The ledger makes the same relationship declared data. A task is created with --blocked-by naming the blockers that must finish before it; the README's quick start marks the intent in a comment — "Find tasks ready to work on (all blockers resolved)" — and the ready command answers it from the data, never from the diagram.

The drill behind this page ran that shape live on a fresh board. Three chained tasks — add a login endpoint, then rate-limit it, then document it — and the first ready call named exactly one task, the only one with no blockers. order --scores answered with the full chain ranked by downstream unblocking, scoring the head of the chain two, its middle one, its tail zero. Then the refusal: completing the documentation task while the rate-limit task was still open was rejected before any write, with the error naming the unmet blocker — Error marking task: cannot complete task 7QoQlD; unmet blockers: QII2eQ. The README compresses the scheduling half into one bullet — "order command returns topological sort for safe scheduling" — and the point for this comparison is that no board makes that computation part of the shared state: the ledger's admission answer comes from the task records themselves, not from a derived view behind someone's API.

Evidence: the card versus the record

A card that reaches Done is an assertion. It says somebody believes the work finished; it carries no memory of what was answered along the way and no pointer to the code that landed. Boards lean on their activity log and their link fields to approximate that record, and for human teams the approximation usually holds. Agent work makes it expensive: the worker deciding "done" is a process that ran unattended, and the reviewer's first question is not where the card sits but what it did and where the change is.

The ledger answers both questions inside the record. Each transition must carry a response — the drill's move to in_progress recorded "Wiring the endpoint and its tests", and the next query of the board answered with that response attached to the task — and completion takes a commit hash, checked on the spot, then files it in the same record; the README names the feature "Commit hash linking for git integration". The finished task from the drill reads status: done and a commit_hash beginning e1e17cb in one file, which is the whole argument: the evidence lives where the intent lived, and a later get hands both to whoever asks. The deeper anatomy of what breaks when shared state cannot carry this — lost updates, unowned claims, uncomputed readiness — is its own diagnosis, reproduced deterministically there.

Where the state lives, and who can reach it

Concurrency is an access question wearing a disguise. When task state sits in the board product's database, concurrent agents are concurrent API clients: someone provisions credentials, someone writes the integration, and every worker inherits the network, the auth, and the vendor's concurrency model as prerequisites for touching the plan at all. When task state is per-task records inside the repository, the agents already hold the client — the shell. YYLO Ledger splits its records per task, so two writers working separate tasks never touch the same record, serializes and revision-guards writes on a single task, and builds the output for machines as much as people; the README's bullet is "jq-compatible output for automation". A dispatcher with no board integration at all can still ask for the ready set and act on the answer.

The same placement settles custody of history. Board history is an activity log inside the vendor's product — readable, exportable, but not verifiable against anything you own. Ledger history is appended events, hash-chained, kept in the very repository that holds the code they describe; a task's past diffs like any other file, quiet edits show up as changes, and finished work can retire into sealed archive packs without losing readability. For a team auditing what an unattended agent actually did to its plan, that difference carries the decision: one history you take on faith from a vendor, one history your own Git can prove.

How the six verdicts read

• The glance and the drag: Kanban boards, outright — the ledger ships no board, and pretending a text listing replaces lanes for human planning would be dishonest.
• The backlog-to-done vocabulary: both — the ledger's statuses are the board's lanes, kept as validated fields under configurable workflows.
• What may start now: the ledger — blockers are declared data, ready and order compute admission, and completing behind an open blocker is refused before any write.
• What the work answered and where it landed: the ledger — required responses plus a validated commit hash, filed in the record itself.
• Concurrent access without an integration: the ledger — repository files and a shell beat a vendor database and credentials for workers that live in terminals.
• History you can prove: the ledger — hash-chained appends in your own Git against an activity log in someone else's product.

Choose by who plans and who executes. If your agents are few and human planning is the bottleneck, the board you already run may be all the task surface this comparison needs to leave alone. The moment unattended workers must decide what starts next, record what they answered, and land commits against a shared plan, execution truth wants to live beside the code — and YYLO Ledger is the layer that puts it there.