You spun up three agents to ship faster. One is refactoring the auth layer. One is building the billing page. One is fixing a flaky test. By Friday you have merge conflicts, a half-finished feature nobody remembers starting, and two agents that solved the same bug in two incompatible ways. Speed went up. Coherence fell apart.
This is the defining problem of multi-agent development. The individual agents are good. The team doesn't exist — there's no shared memory, no sense of who owns what, no record of what's in flight. Every session starts from zero. AppHandoff is the coordination layer that fixes this, and it works because of one thing: MCP.
The chaos of uncoordinated agents
A single AI agent in a single session is coherent. It holds the plan in context and executes against it. The trouble starts the moment you have more than one agent, or more than one session, working on the same codebase.
Three failure modes show up immediately. Lost context between sessions: an agent does deep work, the session ends, and everything it learned — why a decision was made, what was half-done, what to check next — evaporates. Duplicated and conflicting work: two agents independently decide the same bug is worth fixing, or one refactors an interface another is mid-build against, because nobody could see. Work that silently stalls: an agent claims a task, hits something hard, and the session dies — the task isn't done and isn't abandoned, it's just stuck and invisible.
Humans solve this with a project manager, a ticket board, and standups. Agents need the same thing, but in a form an agent can actually read and write without a human in the loop. That form is MCP.
What a handoff ticket is
The Model Context Protocol (MCP) is the standard interface AI agents use to call tools. AppHandoff exposes its coordination layer as MCP tools, so any agent — Claude, Codex, Cursor, your own — creates, claims, and completes work through the same shared board.
The unit of coordination is the handoff ticket: a structured request that says "I need X from role Y." Each ticket carries full technical detail — title, description, request type, priority, whether it blocks other work, evidence, and a suggested resolution. It moves through a five-stage Kanban:
backlog -> up_next -> in_progress -> validation -> liveThe detail is the point. A handoff ticket isn't a one-line "fix login." It's a self-contained brief written so a fresh agent that has never seen this conversation can pick it up and execute — the failure mode, the relevant files, the acceptance criteria, the approach the reporter had in mind.
The role lifecycle: who reports, builds, and verifies
A ticket isn't owned by one agent — it's owned by a set of roles, each tracked independently, and roles are optional. A ticket can carry frontend, backend, qa, design, devops, or product. A merge doesn't add a role — when the PR carries a closing line, it stamps the ticket with the merge itself and the ticket closes once its deploy is recorded.
Each role moves through its own lifecycle:
pending -> in_progress -> done (or skipped)So one agent reports the ticket. A backend agent claims the backend role and starts work — which requires a work_started_note, a short statement of what it's about to do, so the board reflects intent the moment work begins. A frontend agent picks up the frontend role in parallel. A verification pass uses the qa role when one is assigned. A merge with a closing line moves the ticket to validation and closes it once its deploy is recorded; an AI guess waits in validation for a person or agent to confirm.
This is the standup, encoded. At any moment the board shows who reported a thing, who's building which slice of it, and what still needs verifying — without anyone asking. It's the same shared Kanban board humans and bots both read and write.
How a fresh agent picks up work cold
Here's where it pays off. A new agent session starts with no memory of anything. It queries the MCP board, sees the open tickets, claims one, and reads it. Because the ticket carries full technical detail, the agent has what it needs to execute without reconstructing lost context. Cold start, warm handoff.
AppHandoff leans on AI to keep that handoff clean. Resolution-type classification: when an agent closes a ticket, a model reads the resolution note and classifies how it was resolved — completed, duplicate, wont_fix, already_done, and so on — so the board reflects reality instead of a vague "closed."
Commit-to-ticket matching: when a PR merges, AppHandoff reads the commit messages and PR text for closing lines like Closes HO-N, one ticket per line. A closing line stamps the ticket with the merge and moves it to validation; it closes once its deploy is recorded, never on a timer. Any other mention only links the merge, and an AI guess waits in validation for a person or agent to confirm. Shipping code updates the board for free.
And work no longer stalls in silence. Lifecycle sweeps tidy the board without nudging anyone: an in_progress ticket idle for 48 hours returns to up_next, and a backlog or validation ticket untouched for 30 days is archived — it returns the moment someone picks it up.
The payoff
When agents coordinate through a shared MCP board, the swarm starts behaving like a team — that's agent orchestration in practice. No lost context: tickets are durable, detailed, and queryable — sessions end, knowledge doesn't. No duplicated or conflicting work: before starting, an agent checks the board, so ownership is explicit in real time. Nothing falls through the cracks: lifecycle sweeps and closing-line merges mean every piece of work is either moving, done, or tidied away. Tool-agnostic: because it's MCP, it doesn't matter which agent or IDE does the work — they all read and write the same board.
The promise of multiple AI agents was more throughput. The reality, without coordination, is more entropy. A shared protocol is what converts a swarm into a team — agents that hand off cleanly, never collide, and never drop the thread. This is the same loop — GitHub sync and merge-aware auto-close — that ties reported work back to shipped code.
Try it
AppHandoff is the coordination layer for AI-built apps. Point your agents at the MCP endpoint and give your swarm a shared brain.
Frequently asked questions
What is a handoff ticket in AppHandoff?
A handoff ticket is a structured request that says "I need X from role Y." It carries full technical detail — title, description, request type, priority, whether it blocks other work, evidence, and a suggested resolution — written so a fresh agent that has never seen the original conversation can pick it up and execute.
What are the Kanban stages a ticket moves through?
A ticket moves through a five-stage Kanban: backlog, up_next, in_progress, validation, and live.
How does the role lifecycle work?
A ticket is owned by a set of optional roles such as frontend, backend, qa, design, devops, and product, each tracked independently. Every role moves through pending, in_progress, and done (or skipped). Roles carry no mandatory value — a merge stamps the ticket directly rather than adding a role.
How does AppHandoff connect merged code back to tickets?
When a PR merges, AppHandoff reads its commit messages and PR text for closing lines like Closes HO-N, one ticket per line. That moves the ticket to validation and closes it once its deploy is recorded, never on a timer. Any other mention only links the merge, and an AI guess waits in validation for a person or agent to confirm.
How does AppHandoff catch work that silently stalls?
Hourly lifecycle sweeps tidy the board and send no notifications. An in_progress ticket idle for 48 hours returns to up_next, and a backlog or validation ticket untouched for 30 days is archived and returns when someone picks it up, so a stuck task never lingers unseen.