Agent Orchestration MCP

Role Product Manager, AI and Sales Experience · Freedom Forever Stack Model Context Protocol · Anthropic Claude SDK · Internal agent framework · Lightspeed ERP Scope Internal infrastructure powering multi-agent AI across the org

Context

Freedom Forever's AI ran on top of its proprietary ERP, Lightspeed, exposed to Claude through a layer of MCP servers for scheduling, calendar, and work prioritization. I was a significant contributor to that ERP MCP layer. This case study focuses on the piece I created: the agent orchestration MCP that sat on top of the agent framework.

Problem

As AI features multiplied, one agent could not, and should not, hold every specialized skill, tool, and piece of context. You want a general agent to hand specialized work to specialists, a data analyst agent or a code agent, without bloating its own context or carrying skills it has no business carrying. But the moment agents start spawning agents recursively, you lose the thread: which agent started this chain, which one spawned this exact session, and what did each of them see. Delegation is easy. Delegation you can trace is not.

What I built

An MCP that plugs into the agent framework and lets any agent spawn new traces and sessions recursively. The key design decision was linking the IDs at the point of creation. Every spawned record carries two references: a root session ID (the session that originally started the chain) and a direct parent ID (the session that spawned it directly). That produces a full parent-child tree, so any session can be traced back to both its immediate parent and the original agent that began the recursion.

In practice it runs as delegation down a chain. A general orchestration agent calls a data analyst agent, which carries the specialized analytics skills the general agent should not. The analyst agent in turn calls a code agent that reads the GitHub repositories and explains why a table is structured the way it is, or how a particular record gets created, then passes that understanding back up the chain.

A second MCP tool let the orchestration agent look up any session or trace through those parent-child relationships, returning either the structured output or the full trace for inspection as needed.

Where it ran

The orchestration MCP became the backbone of Project Swarm: recursive agents that walked the project pipeline, evaluated each project's realization probability (the likelihood it would actually close and install), and wrote a score back to the database. Each agent ran in its own session and could spawn subagents, and the lineage held across the entire swarm. The longer-term vision was a flywheel, where agents resumed cached sessions over time and graduated from "evaluate and score" to "evaluate, then take action."

Why it matters

Recursion is easy to start and hard to observe. Linking lineage at creation time, instead of reconstructing it after the fact, is what makes the whole tree traceable and debuggable. Specialists run in isolated sessions so each agent's context stays lean, while the root-and-parent lineage preserves an end-to-end record of what every agent saw and decided.

What I learned

The interesting problem in multi-agent systems is not getting agents to call each other, it is keeping the result observable. Once any session traces back to both its parent and its origin, recursive delegation stops being a black box and becomes something you can debug, cost-control, and trust.