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. A ticket can carry frontend, backend, test, design, devops, qa, and more. Every ticket also auto-receives a merged role for CI/CD tracking and a test role for QA.
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 owns the test role. The ticket only auto-closes when every role is done or skipped.
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 matches it back to the right ticket — by Closes HO-N keywords, or, when those are absent, by classifying the changed files and commit messages against open tickets. The merged role flips to done and the ticket advances to validation automatically. Shipping code updates the board for free.
And work no longer stalls in silence. Stale-detection crons watch the board: a ticket stuck in_progress with no role activity for 48 hours emits a stale_in_progress notification; one sitting in validation with no PR linked for 24 hours emits stale_validation. The stuck task surfaces itself.
The payoff
When agents coordinate through a shared MCP board, the swarm starts behaving like a team. 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: stale detection and merge auto-close mean every piece of work is either moving, done, or flagged. 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 closed loop 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.