A coordination fabric for agent fleets, steered by humans.
tuhdoo is a shared backlog, work queue, and activity ledger that lives on a git branch inside the repo it plans — synced through an ordinary git remote. No server, no vendor, no accounts.
npm i -D tuhdoo && npx tuhdoo initWhat it is
Point an agent fleet at a backlog and the hard part isn't the work — it's seeing the work. tuhdoo keeps every task, claim, question, and outcome on one shared ledger. Agents connect through a twelve-verb MCP surface: they claim a task (an exclusive, time-boxed lease that stops two agents from building the same thing), work it on ordinary git branches, escalate questions to a human when they hit a wall, and finish by reporting an honest outcome. Humans steer from a terminal UI and CLI: capture ideas, triage them, set priorities and dependencies, and answer escalations — on their own schedule, not the fleet's.
All it's really doing is letting me see and organize the work while slightly slowing agents down. The slowdown is the feature: everything moves through typed, visible transitions a human can steer.
How it works
One loop, enforced by leases and recorded on the ledger. Sessions end and contexts compact; the ledger is the only continuity between today's agent and tomorrow's.
1Claim
An agent calls claim_next and gets the highest-priority ready task, fully hydrated — description, acceptance criteria, prior runs and notes. The lease renews automatically while the session lives; if the agent dies, the task returns to the pool.
2Work
Ordinary git on ordinary branches — tuhdoo never touches your code workflow. Optional notes checkpoint anything a successor would need if the session ends mid-flight.
3Escalate
Hit a wall? The agent raises an escalation — a question routed to a human — and hands off instead of guessing. A blocking escalation keeps the task out of the pool until someone answers; then any agent picks up question and answer together.
4Finish
Every run ends with a refereed outcome — done means the acceptance criteria actually hold, and a confirmation gate settles ownership before anything merges. No outcome an agent didn't earn.
Why there's no server
The whole ledger is an orphan branch — a git branch with its own history, carrying coordination data instead of code — inside the repository it plans. Syncing is git syncing: push and pull over the remote you already have. That buys properties a coordination server has to work for:
Nothing to run
No service to deploy, no accounts to create, no vendor to trust. If you can clone the repo, you have the entire coordination state — history included.
Offline is normal
Everything works locally with no remote reachable; the first sync afterwards converges histories automatically. That's the normal operating mode, not a repair.
Leaves no trace
Joining is a clone and one init; leaving is a handful of ordinary git commands. No hooks, no writes to your worktree, no commits on your code branches.
Get started
Install the single static binary — via npm, a release archive, or go install — run tuhdoo init in the repo you want to plan, and connect your agent harness with one MCP snippet.
Docs: joining a repo, the agent protocol, workflow recipes →