Multi-Agent Collaboration in Practice: A Master Agent Orchestrating Codex and Claude Code

The AI product landscape is flourishing: some excel at coding, some have great UI aesthetics, and others are unmatched at research. These capabilities are scattered across different products—can a single master agent orchestrate them all? That's the problem multi-agent collaboration aims to solve. In the eleventh episode of Bilibili creator Xiaoshan's series "Building Your Own Agent from Scratch," he presents a complete solution in which a master agent (Ampere Agent) orchestrates Codex and Claude Code to complete complex tasks.

The Core Idea of Multi-Agent Collaboration: Reusing Capabilities, Not Bolting Them Together

The creator emphasizes that multi-agent collaboration is not about re-enabling capabilities inside a single AI product, but about orchestration between different AI products. Some might ask: if an agent lacks a capability, can't you just plug in a Skill or MCP? The creator's view is that external Skills can indeed fill gaps, but official native execution tends to perform better.

He cites Codex's deep-image capability as an example: similar Skills exist externally, of course, but they can't outperform official native Codex. So the more sensible approach is for the master agent to divide tasks among the most suitable agents, then collect and deliver the results in a unified way.

This "capability reuse" approach is clearer than cramming every capability into a single agent. The creator offers a vivid metaphor: it looks like it raises the AI's ceiling, but really it just smashes everything into one blob.

MCP (Model Context Protocol) is a standardized protocol proposed and open-sourced by Anthropic, designed to let AI applications connect to external tools, data sources, and services in a unified way. It's like a "USB-C port" for the AI world: developers only need to implement an MCP Server once, and any agent that supports the protocol (such as Claude Code, Codex, etc.) can call it, with no need to adapt separately for each product. MCP solves the problem of fragmented tool integration and enables agents to dynamically extend their capability boundaries. However, as the creator points out, MCP or external Skills provide general-purpose capability interfaces whose execution is limited by the protocol's abstraction layer, and they often fall short of the deeply optimized native capabilities of a product (such as Codex's deep image). Therefore, multi-agent collaboration does not negate the value of MCP; rather, for critical tasks it prioritizes dedicated agents with stronger native capabilities, achieving complementary strengths through orchestration.

The Positioning of the Two Execution Agents: Codex and Claude Code

In the creator's project, two external agents are integrated, with clear division of labor:

Codex: Deep Images, Research, and Code Modification

What the creator values most about Codex is its deep-image capability. Illustrations, background images, and interface assets needed for the project can all be generated with it; even before developing an app, you can use the deep-image skill to generate reference images for each page, first determining the UI effect and then connecting it to subsequent coding.

Beyond deep images, Codex also handles online research tasks—retrieving materials, comparing information for authenticity, and verifying sources. On the control side, it can also modify code, run tests, and troubleshoot actual errors.

Claude Code: Coding and UI Implementation

Claude Code's positioning is more focused: core coding and UI implementation. The creator calls it the "ceiling of coding, the overlord of UI aesthetics." Since Opus 5.5, handing the core coding and interface implementation of a task to it has been basically problem-free.

Task Dispatch Mechanism: How the Master Agent Assigns Work

Before dispatching tasks, the master agent needs to understand the status of each execution agent—model, capabilities, and whether information is genuine. Then, combining task requirements and the user's choice requirements, it decides whom to dispatch to.

When dispatching, the tool needs to explain to the target agent: what the task is, what counts as completion, where the workspace is, and whether a model choice has been explicitly specified. After filling this information into the tool, it formally dispatches through the delegation service.

The Adapter Pattern is a software design pattern used to convert the interface of a class into another interface that clients expect, enabling classes that otherwise couldn't collaborate due to incompatible interfaces to work together. In a multi-agent system, the adapter layer acts as an interpreter between the master agent and the execution agents: it masks differences in communication protocols, session management, and event formats across agents, and exposes a unified calling interface externally. For example, in this article the master agent starts Codex's App Server through an adapter, wrapping its local control entry point as standard operations; for Claude Code, it adapts through the SDK. The adapter is also responsible for normalizing the diverse outputs produced by execution agents (text, tool status, files) into unified events for the master agent to consume. This design means that when adding a new execution agent, you only need to write the corresponding adapter without modifying the master agent's core orchestration logic, greatly improving the system's scalability and maintainability.

The Agent SDK (Software Development Kit) is a set of programming interfaces officially provided by AI products, allowing developers to integrate the agent's full capabilities into their own applications. Take the Claude Agent SDK as an example: it encapsulates the underlying details of interacting with Claude Code, including session creation, message passing, tool invocation, file operations, and more. Developers only need to call high-level APIs to drive Claude Code to perform coding tasks. SDKs usually also provide mechanisms for identity authentication, error handling, and streaming responses, reducing integration complexity. Unlike the adapter pattern, an SDK is the officially prescribed integration path, with stronger guarantees of stability and feature completeness; adapters, on the other hand, are used to wrap agents that don't provide a standard SDK or require special control methods (such as Codex, controlled through a local App Server). Combined, the two allow the master agent to orchestrate heterogeneous execution bodies in flexible and diverse ways.

Execution and Callback: Designing Two Channels

After tasks are dispatched, the two agents receive them differently:

• Codex: The master agent starts the local Codex App Server through an adapter, understanding it as the localized control entry point provided by Codex. The master agent uses it to create or resume sessions and begin a round of work.
• Claude Code: The master agent invokes the locally installed Claude Code through the Claude Agent SDK, passing in the working directory and model selection.

Once the task is passed in, subsequent execution continues within each agent's session. How are execution results and progress fed back to the main process? The creator designed two return paths:

1. Process progress: Public text, tool status, tool activity, and state produced by external agents are organized by the adapter into unified events, letting the master agent update task records and the session interface so users can follow progress.
2. Completion notification: When a task ends, the service collects the results and sends a completion notification. After the main process retrieves the results, it decides whether to supplement requirements and resume the original session, or deliver directly to the user.

Progress lets users see "what is being done," while the completion notification brings back the final result, and the main process decides the next step.

The Complete Orchestration Flow and Test Results

A complete orchestration flow looks like this:

1. The user dispatches a task to the main process
2. The main process clarifies the goal and final deliverable, and breaks it into work packages (task input, output, constraints)
3. Based on capabilities, it selects the most suitable executor, prepares the task, and dispatches it
4. The executor (Codex or Claude Code) completes execution and returns text or file results
5. The main process checks whether the results meet standards; if not, it returns to step 3, supplementing requirements and resuming the original task
6. If the check passes, it delivers the results and the task ends

The creator actually demonstrated a task: have Ampere Agent use Codex to research a video of a Tesla ramp jump car and extract key process images, then use Claude Code to build a demonstration video recreating the Tesla 3D flying car, requiring realistic modeling and animations matching the original video.

Ampere Agent first summarized a reproduction plan document: Phase A has Codex research, Phase B has Claude Code build the reproduction. After approval and execution, Codex successfully started and returned research information. After verification, the main process concluded the research quality was high and even corrected an original error, then launched Claude Code for modeling.

The task ran for several hours and was later streamlined. How did the final cut turn out? In the video, the creator showed preview images and the final cut: hovering, reversing, flip actions, opening the door for display, jumping over a truck, and jet animations were all present. The creator commented that it was "almost exactly the same as the effect in the video," and the vehicle modeling and video action reproduction were "100% reproduced," with a very stunning effect.

There were flaws, of course—the flip action was a bit stiff, the jet effect was somewhat lackluster, and one action was done wrong. But overall, generating a product of this quality from a simple prompt demonstrates the value of multi-agent collaboration.

Next Episode: Group-Chat-Style Autonomous Orchestration

The creator teases that the next episode will continue to unlock multi-agent collaboration capabilities on this foundation—letting multiple agents converse and give feedback continuously in a group like a group chat, achieving autonomous orchestration, presented in a form similar to GrooveBot.

For developers who want to build it themselves, the value of this project lies in the fact that it provides a deployable architecture: adapter layer, delegation service, dual-channel callbacks, and a closed loop of check-resend-resume. This approach doesn't depend on any specific product and can be migrated to other combinations of agents.