Agent Calling Agent: A New Paradigm of Recursive Collaboration with Git as the Hub

From Single-Point Intelligence to Agent Networks

When we talk about AI Agents, we usually imagine an independent assistant completing a task. But an observation on Twitter points to a more radical trend: Agents will increasingly be called by other Agents. The reason isn't showing off—it's an engineering inevitability: orchestration is simpler, and it can be centralized around a system record that compounds: Git.

The value of this judgment is that it pulls the Agent collaboration problem from "model capability" back to the "software engineering" level. When an Agent runs in code-mode and its execution traces are managed under version control, a true recursive loop can be established—and the key metric for measuring this loop is "less human intervention."

Why Git?

Git becomes the natural hub for Agent collaboration because it provides three things: traceable state, reproducible changes, and parallelizable collaboration. When multiple Agents work around the same repository, every code generation, every tool call, and every repair attempt leaves a trace in the form of a commit. This effectively establishes an auditable "system record" for the Agent's decision-making process.

Compared with traditional API orchestration, Git's advantage as a record hub lies in its compounding effect: every successful Agent interaction settles into retrievable knowledge, and subsequent Agents can directly inherit the context of prior work without re-deriving it. This "one composite system" approach lets the overall efficiency of the Agent network grow with use, rather than remaining at the level of a single call.

Agent orchestration refers to coordinating the call order, data passing, and error handling among multiple Agents or between Agents and tools. The traditional approach is to build your own scheduler: use a message queue to pass tasks, a state database to record progress, and a custom protocol to define the communication format between Agents. The problem with such solutions is that the scheduling logic itself swells with system complexity, becoming yet another software project to maintain. Using Git as the orchestration layer is different: it reuses primitives that have been validated for decades in version control—branches isolate parallel tasks, merge integrates results, commit history serves as a communication log, and rebase adjusts execution order. The orchestration layer is thus compressed into a thin layer of conventions rather than a newly built middleware. The cost of this approach is that Agents must organize work at the granularity of repositories; the benefit is that state management, concurrency control, and historical auditing are all natively handled by Git.

The Key to the Recursive Loop: code-mode and Trace Versioning

The original tweet specifically emphasized two preconditions: the Agent runs in code-mode, and traces are version-controlled. Both are indispensable.

code-mode means the Agent interacts with the environment by writing and executing code, which naturally fits the Git workflow—code itself is a versionable object. Versioning traces goes a step further: it brings the Agent's reasoning traces, tool call sequences, and intermediate results under repository management. Only the combination of the two forms a "recursive loop": an upper-layer Agent can inspect the traces of a lower-layer Agent, make decisions based on historical records, and even roll back or fork a given execution path.

In this mode, the frequency of human intervention becomes the yardstick for measuring system maturity. When an Agent can read the traces left by a previous Agent and autonomously continue, humans step back from "confirming every step" to "reviewing only at key nodes"—precisely the sign that the recursive loop is becoming practical.

code-mode is an Agent operating paradigm as opposed to chat-mode. In chat-mode, the Agent interacts with tools through natural language, and each call requires the model to generate text that is then parsed into structured parameters; code-mode, by contrast, lets the Agent directly generate and execute code snippets to complete tasks, with tool calls expressed as function calls or scripts. The advantage of this approach is that the execution flow itself is readable, testable, and versionable program text, and errors can be located like debugging code rather than reverse-engineered from conversation history. For the Git workflow, code-mode is a natural fit, because the generated artifacts are files in the repository—diff is the change, commit is the decision node—with no need for an extra serialization layer to record Agent behavior.

traces refer to the complete record left during Agent execution, including reasoning steps, tool call sequences, intermediate outputs, and final results. Bringing traces under version control means managing the Agent's "thought process" as a code asset: you can diff two executions, roll back to an intermediate state, or try different strategies at a fork point. Its essential difference from ordinary logs lies in structure and reproducibility—logs are for post-hoc troubleshooting, whereas versioned traces are for proactive reuse and recursive continuation, which is precisely the prerequisite for an upper-layer Agent to understand the work of a lower-layer Agent.

What "Simpler Orchestration" Really Means

The phrase "orchestration is easier" is easily underestimated. In multi-Agent systems, the trickiest problems are often not the capability ceiling of a single Agent, but the communication cost, state synchronization, and error propagation between Agents. Centering on Git is equivalent to replacing custom orchestration logic with a mature version control protocol: branches as task isolation, merge as result integration, commit history as communication log.

The cost of this approach is that Agents must adapt to Git's working paradigm, but the benefit is that the orchestration layer can be made extremely thin. For teams building complex Agent systems, this means they can shift effort from "building a scheduler" to "designing the responsibility boundaries of Agents."

Implications for Developers

Although brief, this observation points to several actionable directions. First, when designing multi-Agent systems, prioritize using Git as the shared state layer rather than building another database or message queue. Second, value the readability and versionability of Agent traces, as this directly determines whether the recursive loop can close. Third, treat "number of human interventions" as one of the core metrics for system optimization—it reflects collaboration efficiency better than raw accuracy.

Agent calling Agent won't remain a concept demo. Once orchestration cost and state management are handled by mature tools like Git, the barrier to recursive collaboration will drop significantly. The real challenge will shift from "can it run" to "how to design Agent traces worth reusing."

One-line Summary

Behind the trend of Agents calling each other is the orchestration simplification and recursive collaboration enabled by Git as a state hub.

Paragraph Summary

Starting from an observation on Twitter, the article points out that AI Agents will increasingly be called by other Agents. The driver is not showing off model capability but an engineering inevitability: simpler orchestration, centralized around a compounding system record—Git. Git provides traceable state, reproducible changes, and parallelizable collaboration, allowing every generation and call by an Agent to settle as auditable, retrievable knowledge in the form of commits, creating a compounding effect. Establishing a recursive loop requires two preconditions: the Agent runs in code-mode, and traces are version-controlled. Combined, an upper-layer Agent can inspect, roll back, or fork the traces of a lower-layer Agent, and the frequency of human intervention declines accordingly, becoming the yardstick for system maturity. The article concludes with implications for developers: prioritize Git as the shared state layer, value trace versionability, and treat the number of human interventions as a core optimization metric.