MCP Sprint Command Center

The Problem

AI coding agents had become individually capable — any one of them could complete tasks, write tests, refactor code. But they couldn't coordinate. Two agents would edit the same file. One would build on a dependency another hadn't finished. There was no way for agents to understand sprint structure, respect task ordering, or avoid stepping on each other's work.

Existing project management tools didn't speak MCP. The gap between "managing work" and "executing work with AI" had no bridge.

What I Built

Cortex — a sprint command center where AI coding agents check in, claim tasks in dependency order, execute work in isolated worktrees, and report results through 49 MCP tools organized across 17 categories. The system enforces dependency DAGs, prevents file conflicts, and coordinates parallel agent execution.

The key insight: the coordination problem isn't about the agents. It's about the information flow. Agents need to know what other agents are doing in real time. The moment you give them that visibility through a standards-based protocol, they self-coordinate.

Architecture

Why MCP over custom RPC: Standards-based protocol means any MCP-compatible agent connects without integration work. Custom RPC would have locked us into a single agent framework. MCP gives us extensibility — adding a new tool category is a function definition, not a protocol change.

Why FastAPI + asyncpg over Django + SQLAlchemy: Agent workloads are bursty — 3 builder agents simultaneously claiming tasks, committing code, and updating sprint state. Async-first FastAPI with raw asyncpg connection pools handles 200+ concurrent agent operations without connection exhaustion. Django's synchronous ORM would require thread pool hacks for the same throughput.

Why PostgreSQL relations over Neo4j: The knowledge graph (315+ nodes, 597+ edges) fits comfortably in PostgreSQL with a simple relations table. Neo4j would add operational complexity (separate database, separate backup, separate monitoring) for a graph that doesn't need Cypher's traversal power at this scale. PostgreSQL recursive CTEs handle our traversal patterns efficiently.

The 49 MCP tools, organized by category:
- Task Management (8): CRUD, claim, complete, ready tasks, blocked tasks
- Sprint Operations (5): Plan (bulk create with dependency DAG), get, update, list, create
- Knowledge Graph (3): add_relation, enrich_graph, get_graph
- Content Calendar (5): Add, list, schedule, generate, optimize
- Social Media (5): Post tweet, read tweets, trends, stats, read user
- Research (3): Add, get, search
- Sessions (4): Create, get, messages, send
- System (5): Health, heartbeat, checkin, checkout, notify
- And 8 more categories covering notes, revenue, apps, worktrees, and agent sessions

Key Decisions

Dependency enforcement at the tool level, not the UI level — agents ignore warnings. When an agent calls claim_task, the tool checks all dependencies. If any blocker isn't done, the claim is refused. Zero dependency violations across 60+ sprints.

Worktree isolation for parallel execution — each builder agent gets a separate git worktree, eliminating file conflicts entirely. Agents can't step on each other because they're physically working in different directories.

Auto-enrichment on entity creation — when any task, session, or sprint is created with a project link, a graph relation is automatically inserted. No manual enrichment step, no missing edges.

Impact

• 49 MCP tools across 17 categories — the most comprehensive agent coordination surface I've seen
• Coordinated 60+ sprints with dependency-enforced task execution
• Three parallel builder agents executing in isolated worktrees with zero merge conflicts
• Knowledge graph grew to 315+ nodes and 597+ edges through auto-enrichment alone
• Full SDLC pipeline: plan, execute, review, deploy, QA — all agent-driven

Trade-offs

49 tools was the right number for comprehensive coverage, but discoverability suffers — agents need category-based filtering to find the right tool. The tool registry (searchable, categorized) was added later to address this. Worktree isolation trades disk space for correctness — each worktree is a full checkout.