Cord: AI Agents That Build Their Own Task Trees

AI agents excel at focused, individual tasks. Ask Claude to analyze a document or generate code, and it performs reliably. But real-world work rarely consists of single, isolated tasks. Instead, it forms intricate webs of dependencies, parallel processes, and context that must flow between components. Most current multi-agent frameworks fail to address this complexity, according to a new approach called Cord.

The multi-agent landscape has seen numerous frameworks emerge, each attempting to solve coordination in different ways. Yet June Kim, the creator of Cord, argues they're all solving the wrong problem. Existing approaches impose rigid structures that don't adapt to the actual needs of complex tasks.

LangGraph models coordination as a predefined state machine. Developers specify nodes and edges in Python, deciding upfront how agents hand off work. This approach works well for fixed workflows but creates static graphs that can't adapt when an agent mid-task realizes the work should be decomposed differently. Developers must anticipate every possible pattern in advance.

CrewAI takes a role-based approach, defining agents with personas like "researcher" or "analyst" and assigning them tasks. While intuitive, these roles are predetermined by developers rather than discovered by the agents themselves. A crew of three can't dynamically decide it actually needs five specialists or that "researcher" should split into two parallel tracks.

AutoGen puts agents in a group chat where coordination emerges from conversation. This provides flexibility but lacks structure—no dependency tracking, no authority scoping, no typed results. Coordination becomes unpredictable and difficult to inspect as it relies entirely on conversational dynamics.

OpenAI Swarm represents the most minimal approach, using lightweight handoffs between agents where Agent A transfers control to Agent B when appropriate. Simple and clean, but fundamentally linear—it doesn't support parallelism, tree structures, or the ability for an agent to spawn multiple subtasks and wait for all to complete.

Even Anthropic's own Claude tool-use patterns limit agents to single-threaded execution with context windows that constrain large tasks. While handling sequential complexity well, these patterns can't parallelize work or manage multiple threads of context.

The common limitation across all these frameworks is their requirement for developers to predefine coordination structures. You decide the workflow graph, agent roles, and handoff patterns. The agents simply execute within your predefined boundaries.

This approach made sense when AI models were unreliable and unpredictable. With GPT-3, you'd never let the model decide how to decompose a project. But current models have strong planning capabilities. They naturally break problems into subproblems, understand dependencies, and recognize when a task is too large for a single pass. So why are we still hardcoding decomposition patterns?

Cord proposes a different approach: let the agents build their own task trees dynamically. You provide a goal, and the agent determines the structure at runtime. For example, given the goal "Should we migrate our API from REST to GraphQL? Evaluate and recommend," Cord creates a tree like this:

● #1 [active] GOAL Should we migrate our API from REST to GraphQL? ● #2 [active] SPAWN Audit current REST API surface ● #3 [active] SPAWN Research GraphQL trade-offs for our stack ○ #4 [pending] ASK How many concurrent users do you serve? blocked-by: #2 ○ #5 [pending] FORK Comparative analysis blocked-by: #3, #4 ○ #6 [pending] SPAWN Write migration recommendation blocked-by: #5

No workflow was hardcoded. The agent decided this structure dynamically. It parallelized the API audit and GraphQL research, created a question node for human input when it realized the recommendation depends on scale, blocked the question on the audit for context, made the analysis a fork to inherit all prior knowledge, and sequenced the final recommendation appropriately.

The execution plays out in real-time, with tasks completing and dependencies resolving dynamically. Research runs in parallel, and when both finish and you answer the question, the analysis launches with all three results in context, producing a recommendation tailored to your specific API surface and scale rather than generic advice.

The core innovation in Cord is the distinction between "spawn" and "fork" as context-flow primitives. A spawned agent gets a clean slate—just its prompt and results of nodes it explicitly depends on, like hiring a contractor with a specific specification. A forked agent gets all completed sibling results injected into its context, like briefing a team member who knows everything the team has learned so far.

This distinction isn't about concurrency—both primitives can run in parallel or sequentially. It's about what the child agent knows. In the API migration example, the agent chose spawn for independent research tasks and fork for analysis that needs to synthesize all prior work.

Under the hood, Cord implements each agent as a Claude Code CLI process with MCP tools backed by a shared SQLite database. The five key primitives are:

1. spawn(goal, prompt, blocked_by) — create a child task with clean context
2. fork(goal, prompt, blocked_by) — create a context-inheriting child
3. ask(question, options) — ask the human a question
4. complete(result) — mark yourself done
5. read_tree() — see the full coordination tree

Crucially, agents don't know they're in a coordination tree. They only see tools and use them as needed. The protocol—dependency resolution, authority scoping, result injection—is enforced by the MCP server. When an ask node becomes ready, the engine pauses to prompt the human in the terminal, with the answer stored as a result that unblocks downstream nodes.

The human becomes a participant in the tree rather than an external observer, allowing for true human-agent collaboration.

The implementation is remarkably simple—around 500 lines of Python using SQLite and MCP. But the protocol itself is the key contribution, not this specific implementation. Cord could be implemented over Postgres for multi-machine coordination, directly over the Claude API without CLI overhead, with multiple LLM providers, or even with human workers for some nodes.

The author tested whether Claude would actually understand this coordination protocol before building the runtime. With just the five tools and no special prompting, Claude correctly decomposed tasks into 3-6 subtasks with proper dependencies, asked well-scoped questions when needed, and followed the authority model without attempting to circumvent it.

When asked why it chose spawn for some tasks and fork for others, Claude explained that fork is like "briefing a team member" while spawn is like "hiring a contractor"—the exact metaphor from the author's specification, despite never having seen it.

This suggests that current LLMs already have an intuitive understanding of coordination patterns. Cord simply provides the right tools to express that understanding.

The framework is available as an open-source project on GitHub, with instructions for cloning and running your own coordination trees. The author has also published an RFC and welcomes discussion on Hacker News.

While still early, Cord represents a significant shift in how we think about AI agent coordination. By letting agents build and manage their own task trees dynamically, it moves beyond the developer-centric approaches that have dominated the field. As AI models become more capable of planning and reasoning, frameworks like Cord may become essential for unlocking their full potential on complex, real-world problems.