One Interface, Many Agents: A Cross-Agent Workflow with Claude, Codex, Antigravity, and Grok

TL;DR: Operating multiple agents from one interface first solves the friction of switching tools and carrying context between them. At a deeper level, it lets the user choose the right agent for the task scenario, then have Claude, Codex, Antigravity, and Grok complete the work together. The model page narrows down the choices; the unified interface handles dispatch and handoff; the human retains control over permissions, evidence, and final judgment.

My current working environment has already achieved operating multiple agents from a single interface. The experience is uncanny — like Guo Jing in The Legend of the Condor Heroes, somehow gathering into one person the Eighteen Dragon-Subduing Palms, the Seventy-Two Ways of Void-Illuminating Fist, the Technique of Left-Right Mutual Strike, the Sinew-Altering and Bone-Forging Chapter, the Nine Yin Manual’s Core Principles and Healing Chapter, Ascending Ladder to Heaven, Snake-Style Raccoon Roll, Flying Cotton Force, Tendon-Gathering and Bone-Shrinking Technique, Soul-Shifting Method, Great Demon-Subduing Fist, Playing the Five Strings by Hand, Fortress-Crushing Divine Claw, White Python Whip Technique, Complete Perfection Internal Energy, Golden Wild Goose Skill, Big Dipper Formation, Nanshan Boxing, Mountain-Opening Palm, Tendon-Severing and Bone-Dislocating Hand, Empty-Empty Fist, Yue Nu Sword Technique, Demon-Subduing Staff Technique, Golden Dragon Whip Technique, Nanshan Blade Technique, Huyan Spear Technique, Golden Bell Shield and Iron Shirt, Jebe’s Divine Archery, Mongolian Wrestling, Carefree Wandering, Qimen Dunjia, and the Wumu Testament — all in a single body of mastery.

Claude can operate Codex, and Codex can operate Claude. Extending this working method further, Antigravity and Grok can also be brought into it.

On the surface, this looks like a few extra tool options. In practice, it changes the basic way we use AI.

In the past, using multiple AI tools meant handling the friction in between yourself:

Figure 1 | How switching between multiple tools breaks up your work

flowchart LR
    A[想到一個問題] --> B[打開第一個工具]
    B --> C[複製內容]
    C --> D[切換到第二個工具]
    D --> E[重新說明背景]
    E --> F[再切換其他工具]
    F --> G[整理多份輸出]
    G --> H[回到原本的工作]

Each tool might be powerful on its own, but the user still has to carry content back and forth, maintain context, remember where the work stands, and judge which output should go to the next tool.

What’s changing now is that these agents can be brought into a single control surface.

Figure 2 | A single interface brings multiple agents into the same working context

flowchart TB
    U[使用者]
    I[統一操作介面]
    C[Claude]
    X[Codex]
    A[Antigravity]
    G[Grok]
    U --> I
    I --> C
    I --> X
    I --> A
    I --> G

Having fewer windows open is only the surface result.

It’s shifting the user from “using a single AI” toward “dispatching a set of agents that can collaborate with each other.”

Real convenience means work stops getting chopped up

Having multiple AI tools at once is, in principle, a kind of freedom of choice — but it can also turn into an operational burden.

Each additional tool can bring its own interface, its own way of being operated, its own context, and its own output format. The worker appears to gain more capability, but in practice ends up spending more time managing the tools themselves.

There are at least four kinds of friction here.

The first is interface friction.

Users constantly open, close, and switch between different windows. These actions themselves produce no value, but they interrupt thinking.

The second is context friction.

When the same task is handed to different agents, the user often has to re-explain the background, the goal, the constraints, and the current progress. If even one piece of that information doesn’t get passed along, the next agent may start working from a wrong premise.

The third is process friction.

The user has to remember, on their own, what each agent has already finished, who should take the next step, which outputs have been confirmed, and which are still just suggestions.

The fourth is accountability friction.

When results are scattered across different tools, it becomes hard for the user to trace back: which agent made which decision? Which part is raw data? Which part is inference? Which result has actually been verified by a human?

So the value of operating multiple agents from one interface starts with reducing tool friction — keeping the user’s work from being chopped into pieces by the tools themselves.

From “one AI answering” to “a working network”

The traditional way of using AI looks roughly like this:

Figure 3 | The traditional question-and-answer way of using AI

flowchart LR
    H[人提出問題] --> M[一個 AI 產生答案]
    M --> J[人判斷是否採用]

A cross-agent workflow looks closer to this structure:

Figure 4 | The basic structure of a cross-agent working network

flowchart TB
    H[人提出任務] --> I[統一介面接收任務]
    I --> P[任務拆解與角色分配]
    P --> E[不同 Agent 分別執行]
    E --> T[Agent 之間交接結果]
    T --> R[統一介面整合進度]
    R --> J[人類驗收與決策]

The key to this change is whether work can flow between different agents.

One agent can be responsible for understanding the problem, another for execution, a third for finding errors, and a fourth for providing an independent perspective. In the end, the user or a designated integrating agent converges the results.

In this kind of architecture, AI is no longer just a tool that answers questions — it becomes different nodes in a working network.

I previously wrote a piece called Three Claudes, One Loop: How I Connected Design Exploration to Production, which was about how different Claude interfaces could be wired into a loop through mocks, specs, and screenshots. The cross-agent workflow discussed here takes that a step further: what’s being handed off is no longer just different interfaces of the same product, but possibly agents in different systems, different models, and different permission environments.

Model choice should follow the scenario, not the brand

Every week I update my live model frontier dashboard twice. That page isn’t a fixed model leaderboard — it’s a selection map: it organizes which models are currently worth considering, and at what cost, across writing, research, programming, and everyday tasks.

This matters a lot for cross-agent workflows. Models get updated, prices change, and the same model can perform differently on different tasks. A model that suits a given role today may already have a better alternative by the next update.

So an article shouldn’t permanently cast Claude as the planner and Codex as the executor, nor lock Antigravity or Grok into some fixed personality. The more accurate approach is: look at the task first, then look at the current model data, and only then decide which agent takes which role in this particular round of work.

The reading order the model page currently follows can be carried directly over into a cross-agent selection process: first check whether the capability gap exceeds the margin of error; if the scores are close, compare cost next; then confirm whether the benchmark actually corresponds to your own task; and finally factor data sovereignty and safety risk into the decision.

Figure 5 | Choosing this round’s agent based on the task scenario

flowchart TB
    A[輸入任務場景] --> B[查看模型選擇地圖]
    B --> C{主要限制是什麼？}
    C --> D[能力與任務適配]
    C --> E[成本與使用頻率]
    C --> F[泛化能力與陌生問題]
    C --> G[安全與提示注入風險]
    D --> H[選擇本輪 Agent]
    E --> H
    F --> H
    G --> H
    H --> I[設定角色與權限]
    I --> J[執行、交接與驗收]

This map isn’t meant to make the final decision for the user. Its job is to narrow the range of choices first, so the user can then test it against their own task. In particular, results from long-horizon agentic coding shouldn’t be treated as an overall ranking for everyday conversation, writing, or research; cost also needs to be checked against a consistent basis — API usage cost and a chat subscription fee are not the same thing.

This also means a model’s role is a matter of work configuration, not brand essence.

Different agents can divide labor within the same piece of work

The premise of cross-agent collaboration is not treating every agent as the same kind of tool.

Within a single task, agents can take on different roles:

The same agent may also play different roles across different tasks.

For example, a single task might follow this flow:

Figure 6 | Different agents dividing labor within the same piece of work

flowchart LR
    H[使用者提出任務] --> C[Claude：理解與規劃]
    C --> X[Codex：執行或修改]
    X --> G[Grok：提出獨立觀點]
    G --> A[Antigravity：協助檢查或延伸]
    A --> C2[Claude：整合結果]
    C2 --> H2[使用者：確認是否採用]

This diagram illustrates roles; the actual flow still needs to be decided by the content of the task, and it doesn’t have to follow the same path every time.

The real question here is: “Which agent is right for this particular step?”

Once work is broken into stages, an agent’s value is no longer determined solely by the quality of a single response — it also includes whether it can correctly receive a task, deliver a result, and let the next agent continue the work.

The two-way relationship between Claude and Codex

We can already see a relationship that’s closer to real collaboration: Claude can offer suggestions and also hand work off to Codex; Codex can execute independently and hand the results back to Claude.

The flow can be represented as:

Figure 7 | The forward handoff flow between Claude and Codex

sequenceDiagram
    participant U as 使用者
    participant C as Claude
    participant X as Codex
    participant I as 統一介面

    U->>I: 提出工作目標
    I->>C: 交給 Claude 分析
    C->>I: 回報任務拆解
    C->>X: 交接具體工作
    X->>I: 回報執行結果與證據
    I->>C: 提供結果供整合
    C->>U: 提出下一步或待確認事項

The reverse flow looks like this:

Figure 8 | The reverse feedback flow, from execution back to analysis

flowchart LR
    X[Codex 執行中] --> Q[發現需要重新分析的問題]
    Q --> C[交給 Claude 重新整理]
    C --> D[Claude 提出判斷或替代方案]
    D --> X2[Codex 繼續執行]
    X2 --> U[使用者驗收]

What matters here is whether the task can flow smoothly.

What’s truly important is that a task doesn’t have to end inside a single tool. It can move from planning into execution, then back from execution into analysis, and finally arrive at a result that a human can verify and accept.

This way of working also builds on my earlier experience of having Codex review Claude. That piece, I Let Codex Pick Apart Claude’s Mistakes, But I Don’t Just Take Its Word For It, was about preserving the independence of a second opinion. This article goes a step further, addressing how handoffs and permissions need to be designed once a second agent isn’t just reviewing, but can be folded into the same workflow.

Separately, Getting Claude Code to Borrow Codex CLI for Image Generation is already a concrete example of cross-agent work: an agent within one working environment borrowing another agent’s capability to complete a task that no single tool could handle on its own. What this article covers is broader — extending from borrowing a single capability to dispatching multiple agents within one interface.

A single interface serves as the work’s control surface

The important role of a unified interface is letting the user see the state of the entire piece of work — not just putting different brands’ buttons next to each other.

An ideal control surface should, at minimum, let people see:

Figure 9 | The work status a unified interface needs to display

flowchart TB
    T[目前任務] --> R[目前負責的 Agent]
    R --> P[目前進度]
    P --> D[已完成的工作]
    D --> N[下一步接手者]
    N --> H[需要人工確認的地方]

So a unified interface can be understood as a work control surface:

Figure 10 | A unified interface as the control surface for cross-agent work

flowchart TB
    U[使用者]
    I[統一工作控制面]
    T[任務規劃]
    S[Agent 選擇]
    P[權限管理]
    V[進度追蹤]
    R[結果整合]
    H[人工驗收]
    U --> I
    I --> T
    I --> S
    I --> P
    I --> V
    I --> R
    I --> H

This control surface puts different agents’ capabilities into the same working context.

The user can first state what they need to accomplish, and only then decide which agent should be responsible for it, without first having to think “which tool should I open right now?”

That’s a significant difference.

A tool-oriented way of working is people adapting to tools.

A task-oriented way of working is tools adapting to the task.

The full flow of a single cross-agent task

A fairly complete cross-agent workflow can be broken into nine steps:

Figure 11 | The nine-step flow of a single cross-agent task

flowchart TB
    A[1. 輸入需求] --> B[2. 拆解任務]
    B --> C[3. 選擇適合的 Agent]
    C --> D[4. 設定上下文與權限]
    D --> E[5. Agent 執行]
    E --> F[6. 交接輸出與證據]
    F --> G[7. 另一個 Agent 審查或延伸]
    G --> H[8. 統一介面整合]
    H --> I[9. 人類驗收、繼續或停止]

Each step has its own responsibility.

“Enter requirements” handles the goal.

“Break down the task” handles the work sequence.

“Choose an agent” handles the division of roles.

“Set context and permissions” handles the boundaries.

“Hand off output and evidence” handles traceability.

“Human acceptance” handles final responsibility.

If you just put multiple agents together without these processes, the end result may just be several answers sitting side by side. Only when the task, the data, and the responsibility can all actually be passed along does it truly become a workflow.

Agent handoffs can’t rely on copying and pasting chat logs

The most common problem in cross-agent work is handing an entire chat transcript straight over to the next agent.

That may look like it preserves full context, but it doesn’t necessarily help. The next agent still has to figure out on its own:

• Which line is the task
• Which line is background
• Which line is just a thought raised in discussion
• Which content has already been confirmed
• Which content is only a tentative assumption
• Which things must not be executed

So an agent handoff should be organized into a simple work contract:

任務目標：
目前進度：
已知上下文：
可使用的資料：
不可使用或不可外傳的資料：
允許的操作：
禁止的操作：
期待輸出：
驗收條件：
停止條件：
下一步接手者：

The value of this handoff package is that it keeps the next agent from having to re-guess the boundaries of the work.

A more complete handoff flow looks like this:

Figure 12 | The flow of handoff information from Agent A to Agent B

flowchart LR
    A[Agent A]
    B[整理任務目標]
    C[整理已知上下文]
    D[標示證據與待確認事項]
    E[標示權限與限制]
    F[交給 Agent B]
    G[Agent B 產出結果與依據]
    H[回到統一介面]
    I[人工或其他 Agent 驗收]
    A --> B --> C --> D --> E --> F --> G --> H --> I

A good handoff conveys the information the next step actually needs, rather than moving an entire chat transcript over wholesale.

The more convenient it gets, the more permission boundaries matter

Being able to operate multiple agents from one interface drastically lowers the barrier to use. But that convenience also brings new problems.

If an agent can operate other agents, who decides what it’s allowed to do?

If one agent can start up another agent, will that permission keep expanding along the way?

If multiple agents can all see the same piece of data, which content can be shared, and which content must stay within its original scope of work?

So a cross-agent workflow needs to address not just “can it be done,” but also “how far is it allowed to go.”

Permissions can be split into a few levels:

Figure 13 | Permission moving step by step from viewing information toward external action

flowchart TB
    A[查看資訊] --> B[分析資訊]
    B --> C[提出建議]
    C --> D[修改工作內容]
    D --> E[執行外部操作]
    E --> F[代表使用者對外行動]
    F --> H[人工確認]

The closer to the outside world, the more it needs human confirmation.

For example, the following actions should never be completed automatically just because the workflow is running smoothly:

• Logging into an account
• Using private data
• Reading or transmitting confidential information
• Using an API key
• Sending an outbound message
• Executing a payment
• Publishing content
• Deploying a website
• Performing an irreversible deletion or modification

A unified interface can centralize these operations, but centralizing them doesn’t mean letting them run unchecked.

It should let the user see more clearly: which agent is working right now, what permissions it’s using, and whether the next action needs confirmation from the person themselves.

More agents doesn’t necessarily mean more reliable judgment

Multiple agents can help surface different angles, but the number of agents alone doesn’t automatically produce a correct answer.

They may share the same flawed premise, or arrive at similarly wrong conclusions together simply because they share the same context.

So cross-agent collaboration needs to distinguish between three different things:

Figure 14 | The layers of raw data, agent analysis, and human judgment

flowchart TB
    A[原始資料] --> B[Agent 的分析]
    B --> C[使用者或其他 Agent 的判斷]
    A -. 必須保留來源 .-> C

These three should not be blended together.

At handoff time, it’s best to clearly mark:

• Which content has already been confirmed
• Which content comes from raw data
• Which content is an agent’s inference
• Which content is still pending verification
• Which content is only a tentative direction

This is also why I never treat “multiple agents agreeing” as proof by itself.

Consensus can raise confidence, but it cannot substitute for evidence.

A unified interface also needs a fallback for when things fail

A workflow that only has a success path isn’t complete.

Cross-agent collaboration can break down at different points: an agent may become unavailable, permissions may be insufficient, context may be incomplete, output may not match the expected format, an external service may not respond, or different agents may reach conflicting judgments on the same question.

So the process should build in a fallback in advance:

Figure 15 | Correction, handoff, and human takeover when an agent fails

flowchart TB
    A[Agent 執行] --> B{結果符合驗收條件嗎？}
    B -->|是| C[交給下一步]
    B -->|否| D{問題是否可修正？}
    D -->|是| E[回到原 Agent 修正]
    D -->|否| F[交給另一個 Agent 審查]
    F --> G{是否需要人工判斷？}
    G -->|否| C
    G -->|是| H[停止並交回使用者]

There’s an important implication in this design: when an agent fails, the system should clearly show that failure — it shouldn’t quietly shift the task’s goal or lower the acceptance bar just to make the process look like it’s going smoothly.

For the user, “I need to make a judgment call right now” is itself a valid outcome.

From using multiple models to a cross-agent working system

The existence of Claude, Codex, Antigravity, and Grok lets us assign different agents to different tasks.

What’s more worth noting is what kind of system these tools have been placed into.

A mature cross-agent working system should have:

Figure 16 | The core components of a mature cross-agent working system

flowchart TB
    A[統一介面] --> B[清楚的任務拆解]
    B --> C[明確的角色分工]
    C --> D[可追蹤的 Agent 交接]
    D --> E[受控的權限邊界]
    E --> F[可驗收的輸出]
    F --> G[保留人工決策]

The center of this system is still the human.

A person doesn’t have to personally complete every step, but they need to know what happened at every step, and they need to retain the ability to stop and correct things at the critical points.

For me, the most valuable change is being able to, within one interface, let different agents enter the same piece of work, letting the task flow from planning into execution, and then into checking and integration.

People are starting to design their own agent working environments

In the past, the question we asked was:

Which AI is the best fit for me?

Now the more worthwhile question is:

Can I, within a single interface, let different agents each complete the work suited to them?

The answer to this question depends on how model capability, interface design, task handoff, permission management, and human judgment are all brought together.

When Claude can operate Codex, Codex can hand things back to Claude, and the work can extend further to Antigravity and Grok, using AI is no longer just “open a chat window and wait for an answer.”

Those of us in similar circles have already begun building a working environment where humans set the direction and multiple agents collaborate to complete the work.

・One interface solves the problem of switching tools. ・Cross-agent handoff solves the problem of work flowing forward.

And permissions plus human acceptance are what determine whether this system is worth trusting. What matters is whether we can get multiple agents to take over from each other on the same piece of work within clear boundaries. Every worker in the post-AI era needs to design and refine the system that best fits their own way of working.