A lead agent and its workers: split a feature into tasks

2026-10-145 min read

One planner, several hands

A feature is rarely one task. The endpoint needs the migration first, and the UI needs the endpoint. If every agent plans for itself, you get three plans that disagree. Make one agent the lead, who plans, and let the others be workers that take whatever is ready.

They all work from the same project board in databasedmcp. If you haven't set one up yet, start with running several agents on one repo: it covers claiming, leases and land. This article is about the shape of the work.

Nothing in databasedmcp makes an agent a lead. The guide asks each agent to name itself <role>-<4 hex>, so the lead is lead-01c2 and a worker is worker-7f3a. The role is the job you give it.

The lead writes tasks, not code

The lead turns your feature into tasks of an hour or less. Each one says which paths it writes, its land, and which tasks it needs first:

INSERT INTO tasks (title, body, needs, land) VALUES (?, ?, '[3]', '["src/web/", "src/sql.ts"]')

needs is a JSON array of task ids. A task isn't ready until every task it needs is done. The lead can write the whole plan up front, and workers can start straight away. Only tasks with nothing ahead of them show up in ready_tasks. The order lives in that view, so the lead doesn't have to stay around handing out work in sequence.

Results flow down the chain

When a worker claims a task, the claim returns its inputs: the result of each task it needs, by id. The worker on the endpoint gets the migration worker's note about the column it renamed, without you or the lead passing it on.

That only helps if results are written for the next agent. The guide asks for what changed, which files, the commit, the tests and the gotchas. A result holds up to 2,000 characters, which is plenty for a handoff and too little for a diff.

Too big? Split it

A worker claims a task and finds it's really three. Instead of doing all three, it releases the task, with SET status = 'todo', owner = NULL, lease_until = NULL, updated_at = datetime('now') on the same conditions as finishing it, and adds sub-tasks under it:

INSERT INTO tasks (parent_id, title, land) VALUES (?, ?, ?), …

Both writes go in one transaction, so no other agent sees the task released with nothing under it and claims the whole thing. Each sub-task points at its parent with parent_id. While any of them is still open, the parent isn't ready. When they're all done or dropped, it returns to the board, and whoever claims it next does what's left: wiring the parts together, a last test run.

Review, blocked and stuck

Not every task ends as done. A worker can finish with status review when a person should look before anything builds on it, or blocked plus a question when it can't go on without an answer. Both show at the top of the briefing, with the owner and land:

SELECT * FROM briefing

Every claim counts an attempt. A task claimed 3 times without being finished drops out of ready_tasks, so a task that keeps crashing agents or keeps being handed back doesn't eat your afternoon. Once its status is back to todo, the briefing lists it as stuck. The board won't hand it out again. Read what the earlier attempts left, then have the lead rewrite it as new tasks or drop it.

The lead's job at the end of a phase

While they work, workers park what's off-task instead of doing it. The briefing shows a count of parked items. At the end of a phase, the lead goes through them. Each one becomes a task, a convention the others should follow, or a question for you. The lead then closes it with status = 'closed'.

Then the lead reports the open questions to you. That report is where you come in. The rest of the time, the board does the coordinating.

Copy this prompt to set it up

Paste this into the agent you want as lead, then describe the feature.

You're the lead for a feature on this repo. Use the databasedmcp project board for this repo, the one CLAUDE.md names, or <owner>-<repo> from git remote get-url origin (create it from the project template if list_databases doesn't show it). Read its guide with get_database and follow it from now on.

1. Name yourself lead-<4 hex>. Don't write code yourself.
2. Split the feature I describe next into tasks of an hour or less. Give each its land (the paths it writes) and its needs (the task ids that must be done first). Insert them.
3. Show me the plan: ids, titles, needs and land, and how many tasks are ready now, so I know how many workers to start.
4. When I say the phase is over: run the briefing, turn each parked row into a task, a convention or a question, close it, and list the open questions for me.

Start each worker with "Join the databasedmcp project board for this repo, name yourself worker-<4 hex>, and claim a ready task. When you finish one, claim the next. When nothing is ready, stop." Give each worker its own git worktree or checkout.

What it doesn't do

databasedmcp doesn't start workers, and it doesn't tell them when a task becomes ready. You open the terminals. A worker finds work by claiming, and stops when the claim returns no row. The database does enforce the order: needs, the wait for sub-tasks and the 3-attempt limit are all in the ready_tasks view, and overlapping land is rejected. Whether a worker splits a task that's too big, writes a useful result, or asks instead of guessing comes from the guide and the agent. And the lead is a role, not a permission: any agent on your account can insert tasks.

Create an account