Worklode: a work tracker for running several coding agents at once

The bottleneck

The supply of ready work

Worklode started as a lock. Two agents kept reaching for the same task, so work had to be handed out one item at a time and nothing could run unattended. Making pickup atomic removed that limit and revealed the next one. An agent finishes a well-specified task in about twenty minutes and then needs another one that touches different files, waits on nothing unmerged, and carries enough context to be finished without supervision. Producing work in that shape is the current constraint, and most of what follows is built around it.

01
Specify

Specifications and plans live as records in the tracker. A plan is reviewed like anything else, and accepting it creates one task per item it describes, with dependencies wired and context attached.
02
Execute

claim --next ranks the ready set and takes a lease in one transaction, server-side. The lease is bound to a git worktree, so it survives restarts, cleared context, and a person taking over from an agent halfway through.
03
Reconcile

Execution reports back. Submitting or accepting a document mints the review or planning task its lifecycle calls for, and revising an accepted document publishes a fix as a new version.

Design documents

The artifacts people actually review

Design documents are first-class objects in Worklode, with kinds, a lifecycle, review policies that differ by kind, stable identifiers, and commands for amending and retiring them. They're also the part of the system where human attention is the point: agents draft, execute and report, and people decide what the design should say.

Specifications and ADRs

Durable statements that stay true after the work is finished. Submitting one for review mints a review task automatically, and accepting it is a deliberate act reserved to the document's owner.

Plans

Executable and disposable. A plan is reviewed as a whole, and regenerates whenever the design underneath it changes.

Stable identifiers

An accepted document has a URI, and each of its sections keeps a fragment for good. A reference can therefore name one section of one document, which is what makes amendment, supersession and coverage queries expressible at all.

One global view of drafts

A design document usually describes work still ahead of any repository. Worklode keeps one global view of drafts, findable across every project, which is what stable identifiers need.

Documents keep evolving

lode doc revise opens a candidate revision of an accepted document, and landing it, reserved to the owner like acceptance itself, publishes the edit as a new version.

Follow-up work mints itself

Submitting a document mints its review task automatically, and accepting a spec mints a task to write its plan, unless one is already open. Either way, a resubmission or a second draft joins the follow-up already queued.

The model

Three layers on one graph

Intent is declared by people. Execution and runtime are derived automatically from what the repositories and clusters actually did: commits, pull requests, CI runs, artifacts, deployments. Deliverable is the vertical join, where a declared definition of done meets what is running in production.

Isometric illustration of the three layers. On the top tier, two people review a stack of document sheets. On the middle tier, robots at separate workbenches each hold a token linked to a slot on a central blue crystal, and conveyors carry blocks through a gate. On the bottom tier, an arm stacks containers into cabinets. Lines run from every tier into the crystal, and one runs from a robot back up to the review desk. — People declare intent at the top. Agents take exclusive claims from the centre and turn them into commits. Deployments settle at the bottom, and every tier reports back to the same store, including the line that runs from an executing agent back up to review.

Execution facts flow up into the graph as a projection; design facts flow back down as references. The work graph lives on one branch, with project as an ordinary property of the work.

More than one worker

Deterministic coordination

The features below exist because more than one worker is in the repository at the same time. Atomic pickup matters when two agents start together. Leases matter when a person takes over work an agent left unfinished. Session visibility matters once you can no longer see everyone who is working.

Atomic pickup

claim --next ranks and takes the next ready task in a single transaction, server-side. Two agents starting in the same second cannot land on the same task, and no model has to reason about which one to pick.

Worktree-bound leases

A lease is bound to a git worktree. It survives restarts and cleared context, renews from a compiled pre-commit hook, and expires on its own when work is genuinely abandoned.

Session visibility

The backbone records which coding-agent session holds which lease, across Claude Code, Codex, Copilot, Amp and others, so “what is running right now” is answerable.

Work routed by tier

Mechanical tasks go to cheap models and design work to stronger ones. A concern dimension and a per-project focus steer what comes next.

Skills delivered on demand

Org-wide agent skills live in the backbone. The server matches the relevant ones to a task with embeddings and explicit pins, then delivers them as files the agent reads, so a skill only costs context once it's actually chosen.

Cost attributed to work

Each session is priced from the agent's own transcript against effective-dated rate rows, so spend lands on a task, a session and a project as it happens.

Coordination is pushed into deterministic machinery: compiled hooks, a CLI with --json, and server-side selection. Model tokens are spent on judgement.

agent picking up work

// claim the next ready task, create its worktree, bind the lease
/lode:next
// re-acquire the task already bound to this worktree
/lode:resume
// a real blocker outside this task's scope: record it, release the lease
/lode:block --on WL-118
// verify the deliverable, push, open the PR, submit for review
/lode:done

Roadmap

When the plan turns out to be wrong

Plans are written by the strongest model available so that cheaper models can execute them mechanically. That only works if the executor has somewhere to go when it hits a case the plan missed, since fixing the plan is a call for whoever wrote it. This escalation ladder is fully specified and is the next major piece of the execution backbone. The first rung ships today: lode task escalate files the gap and hands the task back. The automatic fixer above it is still being built.

Gaps get recorded

An executor that meets a gap the plan does not cover records it and stops. The discovery becomes an event in the backbone, readable by everyone working the project.

A stronger model fixes it

A subagent running at the tier the fix requires will amend the plan, or the specification above it, and hand control back to the executor, keeping the delay bounded.

Substantive changes go back for review

A patch that adds a dependency, changes an interface, touches the ontology or alters a definition of done will count as substantive by rule, and the server will apply that rule automatically.

Judgement gets requested explicitly

When a fix needs a person's judgement, lode task escalate creates a design task assigned to whoever wrote the plan, and blocks the original work until it's resolved.

The general rule: a subagent will handle work where the only missing ingredient is a stronger model, and a queued task will handle work that needs a person. Both beat a session sitting idle.

Reconciliation

Every relationship is recorded twice

Each architectural relationship exists as an edge someone declared alongside a design document, and as an edge derived from code, pull requests and deployments. The difference between the two sets is drift, and finding it is one query.

observed − declared − acknowledged = drift

Deviations that are intentional are recorded as accepted: a node names the tolerated edge, cites the ADR that sanctions it, and can be given an expiry date. It is reviewed and provenanced like any other declaration.

Architectural drift

A component depends on something the design never said it could.

Documentation gaps

Code that exists in the observed layer with no design document behind it.

Unimplemented specifications

Intent that was written down, accepted, and then never showed up in a repository.

Ready frontier

What is genuinely unblocked right now, computed live from the graph.

Get started

Up in a few commands

Docker Compose brings up Postgres, applies migrations and starts the server. Then install the CLI and claim something.

shell

# start the stack
export LODE_BOOTSTRAP_TOKEN=wl_$(openssl rand -hex 20)
docker compose up -d

# install the CLI
go install ./cmd/lode

# create a project, map a repo, add work, claim it
lode project add sunstone-web --name "Sunstone Web"
lode project repo add sunstone-web sunstoneinstitute/sunstone-web
lode task add --project sunstone-web --title "Fix the footer link"
lode task claim --next

Read the docs on GitHub

A work tracker for running several coding agents at once