Every team I talk to has the same question: 'How do we actually manage AI agents alongside human developers?' They've tried letting agents loose on their codebase. The results were messy — duplicate work, unreviewed commits, agents 'fixing' things that weren't broken. The problem isn't the agents. It's the lack of a project management system that treats bots as real participants.
Why Traditional PM Tools Don't Work for Agents
Jira, Linear, Notion — they're all designed for humans. A human reads a ticket description, applies judgment, does the work, updates the status. An AI agent can do all of those things, but it needs structure that human PM tools don't provide: machine-readable acceptance criteria, scoped file permissions, automated review gates, and explicit handoff points between bot work and human review.
We tried using Linear for our own agent workflows early on. It lasted a week. The agents could read tickets, but they had no way to signal 'I'm done, please review' in a way that triggered a human workflow. They'd mark tickets as Done when the code was written — before review, before CI, before anyone looked at it. The status labels meant different things to bots and humans, and the result was chaos.
The 5-Lane Kanban
We built a kanban board with five lanes that both humans and agents understand. Each lane has explicit entry and exit criteria. An agent can't skip from 'In Progress' to 'Done' — it has to pass through 'Human Review' first. Here's the full pipeline:
# AppHandoff 5-Lane Kanban Pipeline
┌─────────┐ ┌─────────────┐ ┌──────────────┐ ┌──────────┐ ┌──────┐
│ Backlog │→ │ In Progress │→ │ Human Review │→ │ Approved │→ │ Done │
└─────────┘ └─────────────┘ └──────────────┘ └──────────┘ └──────┘
Backlog: Mismatch detected or ticket filed. Ready for pickup.
Entry: scan finds mismatch OR human creates ticket
Exit: agent or human claims the ticket
In Progress: Agent (or human) is actively working.
Entry: ticket is claimed
Exit: PR opened + CI passes
Human Review: Code is written. A human must review.
Entry: PR opened with passing CI
Exit: human approves or requests changes
Approved: PR approved. Ready to merge and deploy.
Entry: human approves PR
Exit: PR merged to main
Done: Shipped. Contract updated. Mismatch resolved.
Entry: PR merged + deploy confirmed
Exit: archived after 30 daysThe critical lane is Human Review. That's the gate that prevents agents from shipping unreviewed code. It's not optional — the system enforces it. An agent that opens a PR without passing CI gets its ticket bounced back to In Progress automatically.
Multi-Role Tickets
Each ticket has explicit roles: frontend, backend, design, QA. This matters because agents with narrow scope make fewer mistakes. A frontend agent assigned to fix a UI mismatch only sees frontend files. It can't accidentally refactor the API client layer or modify shared utilities. Role scoping is the simplest guardrail that produces the biggest improvement in agent output quality.
In our experience, role-scoped agents produce PRs that are 60% smaller and get approved 3x faster than unscoped agents. The reason is obvious once you see it: smaller scope means fewer files changed, which means faster review, which means faster merge. The shared Kanban board (/shared-kanban-humans-bots) shows role assignments per ticket so everyone — human and bot — knows who owns what.
How Agents Pick Up Work
Agents don't browse the kanban board like humans do. They call MCP tools. When an agent connects to the AppHandoff MCP server (/mcp-server), it can call get_handoff_requests to see available tickets filtered by role, priority, and project. It picks a ticket, generates an implementation plan, and waits for human approval on the plan before writing code.
// Agent workflow via MCP:
// 1. Get available tickets
await mcp.call('get_handoff_requests', {
project_id: 'proj_abc123',
status: 'backlog',
role: 'frontend'
});
// 2. Claim a ticket and generate a plan
await mcp.call('update_handoff_request', {
handoff_id: 'HO-142',
status: 'in_progress',
plan: 'Add route alias /tickets -> /issues handler...'
});
// 3. After human approves plan → write code → open PR
// 4. Ticket auto-moves to Human Review when PR passes CIThis plan-first approach catches bad ideas before they become bad code. We've seen agents propose plans that would have introduced breaking changes — renaming database columns, restructuring shared types, modifying auth middleware. The plan review step catches these before a single line of code is written. It's cheaper to reject a plan than to reject a 400-line PR.
Complementing Jira, Not Replacing It
AppHandoff's kanban board handles the machine-generated work: mismatches, contract drift, agent-built fixes. Your existing Jira or Linear board handles the human-driven work: feature planning, sprint goals, product decisions. The two systems complement each other.
In practice, teams use Jira for 'what to build' and AppHandoff for 'what's broken between frontend and backend.' A Jira ticket might say 'build user settings page.' The AppHandoff board surfaces the mismatches that arise when the Lovable prototype for that page doesn't match the backend — missing endpoints, wrong response shapes, auth gaps. The closed-loop pipeline (/closed-loop) connects the two: human intent in Jira, machine execution in AppHandoff.
Real Numbers from Our Team
We dogfood this system on AppHandoff itself. In the last 90 days, agents handled 340+ mismatch tickets through the 5-lane pipeline. Average time from Backlog to Done: 4.2 hours. Average PR size: 38 lines. Human review approval rate on first submission: 78%. The 22% that needed changes were caught at the plan review stage or the PR review stage — never in production.
The key metric is zero agent-caused production incidents in 90 days. Not because the agents are perfect — they're not. Because the pipeline catches their mistakes before merge. That's what project management for AI agents actually looks like: not trusting them less, but verifying them better.