AI AgentAI CodingArchitecture

Behind the Multi-Agent Hype: Product Genes and Core Beliefs of Modern AI Coding Harnesses

Open any mainstream AI coding tool today—whether it’s a command-line CLI in the terminal or an editor extension—and the release notes will almost certainly boast support for multi-agent collaboration. On the surface, it might seem like they all do roughly the same thing: wrapping LLMs in a lightweight function-calling loop where a main process spawns a few worker threads, invokes model APIs, and distributes tools for code searching or file editing.

However, once you put these harnesses to work in real-world production engineering—digging into their CLI source code, configuration files, and underlying IPC logs—a very different picture emerges. While they all market themselves under the “multi-agent” label, their underlying engineering paths, state synchronization mechanisms, and assumptions about the future of software engineering diverge completely. Behind each chosen architecture lies a distinct set of product genes and design philosophies.

Claude Code: Network Topologies and Dual-Track Arrays

Let’s start with Anthropic’s Claude Code. Although it operates inside the terminal, Anthropic has consistently explored inter-agent communication topologies.

Along the primary axis of tree-structured spawning, Anthropic has actively refined vertical depth controllability. In version v2.1.219, the default spawn depth for subagents was set to 3 levels (configurable up to 5 levels via CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH). To address the reasoning blind spots caused by deep recursion, it pairs this with the --forward-subagent-text CLI flag to propagate deep child reasoning context up the hierarchy, precisely attributing context back to the tool_use ID that spawned the agent. This design maintains context isolation across hierarchical decomposition while retaining end-to-end, globally traceable debugging capabilities.

Along the secondary axis of horizontal exploration, Claude Code introduced an experimental Agent Teams mechanism, activated by setting the environment variable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. This mechanism attempts to break away from traditional master-worker reporting structures in favor of peer-to-peer network topologies. To support peer collaboration, it introduces a shared ledger system centered around tasks.md. All task states, claim records, and output dependencies are persisted into this decentralized ledger file, enabling agents to dynamically claim tasks and hand off intermediate artifacts by parsing tasks.md.

Furthermore, Anthropic incorporates the concept of Dynamic Workflows into its topological framework. Rather than blindly spinning up an arbitrary number of agents, the system dynamically plans agent pool sizes and execution sequences based on the specific task dependency graph. Within Dynamic Workflows, official guidelines recommend capping concurrent collaborative agents at 15 by default—though developers can override this setting—striving to strike a balance between automated scaling and system resource overhead. These design choices reveal Anthropic’s deep product gene in network topologies, treating software engineering as a communication array that flexibly evolves between hierarchical trees and peer meshes.

OpenAI Codex: Heterogeneous Compute and Reasoning-Affinity Matching

Unlike Anthropic’s pursuit of topological elegance, OpenAI displays a pragmatic engineering approach in Codex CLI (since introducing the Multi-Agent V2 architecture in version 0.145.0).

In conventional multi-agent dispatch, child nodes typically inherit the parent’s model configuration (or at best allow coarse-grained model selection). In real-world development, however, running a simple static syntax check or locating a config file path hardly requires top-tier deep reasoning capabilities. Having dozens of subagents in a terminal session all calling the most expensive model or performing heavy reasoning not only slows down response times but also burns through token budgets at an alarming rate.

OpenAI’s core solution in Codex Multi-Agent V2 is tailored resource allocation: affinity matching between tasks and reasoning intensity. When scheduling subagents, the primary node retains fine-grained control. It can dynamically assign different base models based on subagent role templates and even tune reasoning effort levels—flexibly switching between low, medium, and high—while enforcing strict concurrency limits.

For instance, during a large-scale codebase refactoring, Codex dispatches a subagent with reasoning effort set to high to handle cross-module architectural design and type inference, while concurrently dispatching lightweight subagents set to low reasoning effort to batch-update import declarations and test cases across peripheral files. Additionally, it extends the /import CLI command to seamlessly pull external project conventions, historical decision context, and memory rules into a designated subagent’s execution environment. Looking at its Rust scheduling logic, this product gene is entirely driven by cost, throughput, and reasoning efficiency—combining economical compute allocations to achieve maximum ROI on code refactoring.

Cursor: Model-Agnostic Engine Seamlessly Fused with IDE State

If CLI tools fight their battles in the terminal, Cursor represents an entirely different direction: dissolving the agent directly into the IDE user experience.

Cursor’s agent collaboration relies on its Composer interface and Agent Mode. Composer is a multi-file editing interface and orchestration system embedded deep within the editor architecture, while Agent Mode equips it with autonomous capabilities to execute terminal commands and rewrite multiple files. This harness architecture is decoupled from any specific underlying model. In terms of product lineage, Cursor is a complete model agnostic: whether powered by Claude Opus 5, GPT-5.6, Gemini 3.6 Flash, or Grok 4.5, the upper-layer interaction experience and context awareness remain uniform.

Cursor’s defining characteristic lies in how tightly it binds Composer’s agent execution loop to the local VS Code IDE state. When triggering multi-file editing tasks in Multitask Mode, the agent isn’t running headless shell scripts in the background; it acts directly on editor buffers, unsaved background tab states, .cursor/rules rule repositories, and the local SQLite database state.vscdb.

To maintain sub-millisecond context retrieval during extensive file modifications, Cursor builds a repository index architecture powered by a Merkle Tree in the background. As multiple agent loops concurrently perform localized edits, code generation, and diff previews across different files in the background, developers experience zero UI blocking—they can continue typing in the foreground while reviewing agent-generated diffs at will. Cursor prioritizes seamlessness and fluidity, hiding complex agent orchestration details beneath familiar keyboard shortcuts and editor UI panels.

Antigravity: Governance-Native and Explicit Workflows with “Measure Twice, Cut Once” Philosophy

Finally, let’s look at Google DeepMind’s Antigravity. If Cursor strives for invisibility and seamlessness, Antigravity exhibits an engineering philosophy rooted in explicit governance: measure twice, cut once.

The true native low-level primitives of Antigravity are architected entirely around explicit workflows and security governance.

First is its Planning Mode. Once Planning Mode is active, the primary node will not prematurely edit a single line of code or run destructive commands. Instead, it must first generate a detailed, structured Plan and explicitly hit a Proceed Gate. Only after the developer reviews and clicks to approve in the interface does the agent enter the code modification phase.

Second is its native, first-class artifact engine. All plans, architectural analyses, and milestone deliverables are structurally persisted into the designated brain/<id> directory. Even more notable is its transparent traceability: the system logs preserve untruncated transcript.jsonl files, ensuring every reasoning step, tool call detail, and error message remains fully auditable.

For multi-agent isolation, Antigravity natively bakes Git Worktree-based isolation into its invoke_subagent primitive, especially under the share mode. When spawning multiple child nodes to explore or edit code in parallel, each node gets an independent working directory space while sharing the underlying Git repository storage. This eliminates redundant disk footprint while preventing file conflict issues caused by concurrent edits. When refactoring large-scale, mission-critical systems, the determinism and auditability delivered by plan-first execution, durable artifacts, and isolated worktrees make Antigravity irreplaceable.

Conclusion: Product Genes and Engineering Selection

Having dissected the underlying mechanics of these four harnesses, the conclusion is clear: multi-agent collaboration is far from a generic commodity feature. The design of each tool bears the distinct indelible mark of its team’s core engineering philosophy:

Software engineering has never had a silver bullet. By seeing past the multi-agent marketing buzz and understanding the underlying product genes and core beliefs of these AI coding harnesses, we can make informed engineering choices—selecting the precise tool that fits our codebase and engineering workflow.