Hand your backlog to a coding agent — and get it back updated

You run Claude Code or Cursor as your main builder, but the plan lives somewhere else — Jira, Linear, a doc. So every task is a manual round-trip: you copy a ticket into the agent's prompt, wait, and copy the result back onto the board. The agent never knows what's next, what's blocked, or what "done" means — and by end of day the board has quietly drifted from what actually shipped.

The fix is to stop copying and let the agent read and write the same plan you do. My Architect keeps the project as one source-of-truth hierarchy and exposes it to agents over an MCP server. The agent doesn't get CRUD over your board — it gets a work loop.

The loop, not a bag of buttons

The agent works three verbs against your project, in order:

get_next_task — asks "what's next" and gets one task back in a single round-trip: title, full path, description, and release. The server picks it, not the agent — by release order, leaf-first, and assignee-aware — so the model never guesses based on recency or file order. (The task's requirements sit one call away, via get_requirements or get_node, so the agent pulls them when it needs the detail.)
start_task — claims the task and moves it into progress. From that moment it stops being a candidate for other agents, and its parent (feature, epic) advances automatically. That's the status cascade: a child moving forward is enough to move the tree.
complete_task — records the result, rolls status and progress up the hierarchy, and pre-fetches the next task in the same response. The agent closes one node and immediately knows what to do next, without a separate call.

No prompt-stuffing, no "don't forget to update the epic." The parents update themselves as a consequence of the loop — because in practice the "don't forgets" don't survive contact with a real session.

What "done" actually means

The loop refuses to lie at the point that matters: closing a node. Requirements can carry an Open Question, and nodes can declare a blocks dependency on other nodes. A blocker gate treats both as blockers — complete_task won't let the agent mark a node done while a draft Open Question hangs under it or an unfinished blocks-dependency is still open; the write is rejected with the unresolved blockers named. If a new dependency surfaces mid-work, the agent calls block_task — an honest blocked instead of a fake done. Your board stays truthful because "done" is hard-unavailable until the work really is.

The board updates itself while it works

You don't have to reconcile anything after the fact. The backend is agent-native: MCP tools plus live WebSocket sync. As the agent claims and closes tasks, the canvas updates on your screen in real time — the same model, one version of the truth for you and the agent alike. You watch an epic tick from 3/8 to 5/8 done without touching the board and without telling the agent what to do next. The plan stops being a thing you maintain and becomes a thing that maintains itself.

For the full reasoning behind the loop — why three verbs instead of an API, how the status cascade and progress rollup are wired, and where the blocker gate sits — see the engineering write-up on how the agent goes through the work cycle step by step.

How to try it

Create a project and let it scaffold a hierarchy — start with getting started.
Generate an API key and wire up your agent in one step — follow connecting an AI agent.
Tell the agent to pull the next task. Then watch the canvas, not the prompt.

The board was the thing you kept in sync by hand. Hand it to the agent instead — and get it back updated.