Building Heterogeneous AI Agent Pipelines: A Hands-On Guide to Cross-Account, Multi-Platform Automation with Claude Code, ChatGPT, Gemini and Grok

Audience: software engineers, systems architects, AI DevTools developers, technical geeks

Topics: collaboration patterns for heterogeneous AI agents, decoupling state across accounts, a context handover protocol, a local relay service (broker), and building the automated pipeline itself

Every Claude Code flag in this article was checked against claude --help and the official docs for Claude Code 2.1.278. The orchestrator, broker and poll worker in section 4 were actually run: using a mock claude executable, we exercised five scenarios (pass first time, tests fail then pass, review rejects then approves, no progress, three rejections in a row) and every state transition came out as expected. These CLIs move fast — when you read this, trust your own --help output over this article.

---

1. Background and Design Principles

1.1 The limits of a single agent

As software projects grow more complex, relying on a single LLM or a single AI agent terminal runs into predictable bottlenecks:

• Context pollution and forgetting: after a long conversation, the agent gradually loses the architectural constraints it was given early on, drifting semantically and eventually hallucinating. Constraints that must hold for the life of the project belong in instruction files that are re-read at every start (CLAUDE.md, AGENTS.md), not in chat history.
• Quota and billing boundaries: long stretches of heavy code generation hit a single platform's usage limits quickly. Spreading different kinds of work across different platforms is a form of load splitting in its own right — but that is not the same as "open several accounts on the same service and rotate them", which section 1.3 deals with separately.
• Single-model blind spots: models differ in reasoning, refactoring, bulk log analysis and real-time research. No single model covers all of it well.
• Self-audit risk: an agent that both writes the code and audits it for security will reliably miss its own blind spots.

1.2 A decoupled, cross-account, cross-platform architecture

The core idea behind a cross-account, multi-platform agent pipeline is to turn implicit conversational memory into explicit state artifacts:

With a state bus and a handover protocol in place, agents on different accounts and platforms can relay work asynchronously without ever sharing login credentials or API keys. In practice there are two buses: code and commit history travel through Git, and pipeline state travels through the .pipeline/ directory (remember to add it to .gitignore).

1.3 What "cross-account" actually buys you

A common pattern is to run the reviewer under a "second account" in the hope of getting an independent perspective. Two separate things are tangled together there:

• An independent context does not need a second account. Every claude -p invocation is a brand-new session with no view of the implementer's conversation. Claude Code's built-in subagents (.claude/agents/*.md, with tools restricted through tools:) also get their own context window.
• A second account does not give you a second perspective. The same model under a different login has exactly the same trained preferences and blind spots. For a genuine cross-audit, the review stage should use a model from another vendor (see the alternative at the end of Step 4 in section 5).

So is there any point to separate config directories (CLAUDE_CONFIG_DIR) and separate accounts? Yes — for isolation, not for capacity: keeping a work organization apart from a personal account, giving the pipeline its own separately billed API key with a spend limit, containing the blast radius if any one role's credentials leak, and keeping audit logs attributable per role.

There is one more boundary worth stating plainly. Anthropic's Claude Code legal and compliance page says the advertised usage limits for Pro and Max plans assume ordinary, individual usage, and that developers building products or services should use API key authentication through the Claude Console. Pooling several subscription accounts and rotating them through an unattended 24/7 pipeline both breaks that assumption and builds your pipeline on something that can stop working at any moment. For unattended automation, use an API key and set a spend limit in the Console. The other vendors have their own terms, and they are worth reading one by one before you go live.

---

2. The Heterogeneous Agent Matrix and Division of Labor

To get the most out of each model, assign pipeline roles according to what each one does natively:

Two further notes:

• This article does not hard-code model versions. o1/o3, GPT-4o and grok-3, all common in tutorials like this one, are no longer any vendor's current mainstay in 2026 — grok-3 was actually retired in May 2026, with requests redirected to a newer model. Model names belong in pipeline configuration as parameters, not in the architecture diagram.
• Long context is no longer a Gemini-only selling point. Mainstream flagship models now routinely offer context windows of several hundred thousand to a million tokens. The more practical reasons to hand long documents to Gemini are its multimodal parsing, its separate quota, and the different perspective you get simply by having another model read the material.

---

3. The Context Handover Standard

Seamless handover between agents requires a standard handover-file protocol, one that is both human-readable and machine-parseable.

First, separate two kinds of context:

• Static constraints (coding conventions, directory boundaries, things never to do) go in AGENTS.md at the project root. Codex, Cursor, Jules and others read it natively. Gemini CLI reads GEMINI.md by default, but you can set "context": {"fileName": "AGENTS.md"} in .gemini/settings.json. For Claude Code, one line — @AGENTS.md — in CLAUDE.md imports it. One file, shared by every agent.
• Dynamic handover (how far this task has got, and what comes next) goes in .pipeline/HANDOVER.md, updated at the end of every stage.

3.1 A structured HANDOVER.md

Every agent writes (or updates) .pipeline/HANDOVER.md when it finishes its stage:

Several design choices in this template deserve a closer look, because each one guards against a common handover mistake:

• Scope and instructions must agree. If In-Scope does not include src/services/ but the next actions ask for a new file there, the agent either oversteps or gets stuck.
• Don't let a handover file carry a wrong design decision. A common line is "for multi-instance deployments, TOTP secrets must be stored in Redis". But a TOTP secret is a long-lived credential, like a password, and belongs encrypted in the database. Redis is a cache — keys can be evicted, and persistence may not be enabled — so what it should hold is replay-guard records and rate-limit counters. A wrong constraint in a handover file is faithfully executed downstream as a settled decision.
• "JWT-based 2FA" is a muddled phrase. JWT handles the session and TOTP provides the second factor; they are orthogonal. The goal should read "add TOTP to the JWT login flow".
• Acceptance criteria and open questions are not optional. Without acceptance criteria, "done" is whatever the agent declares. Without a list of open questions, the agent makes those decisions for you.
• Timestamps use ISO 8601, and the Base Commit is recorded for the diff in section 3.3.

3.2 A machine-readable state machine: pipeline_state.json

Alongside the Markdown, a JSON file records atomic state changes so the orchestration scripts (watcher or broker) can decide what happens next:

status moves along AWAITING_EXECUTION → IN_PROGRESS → (then the next stage's AWAITING_EXECUTION, COMPLETED, or HUMAN_INTERVENTION_REQUIRED). There is deliberately no next_agent_target field: which agent runs which stage is orchestrator configuration, and writing it into the state file as well only creates two sources of truth that can disagree.

More important is who is allowed to write this file. Upstream (a human, or the broker's poll worker in section 4) only ever sets it to AWAITING_EXECUTION. Every transition after that is made by the orchestrator — agents never write the state file. An LLM can emit invalid JSON, skip a stage, or announce "done" while the tests are failing. The state machine should advance on exit codes and test results, not on an agent's self-report.

3.3 Git as the semantic handover channel

For stages that change code, the change itself is the strongest context there is. Taking the specification stage as an example, it ends with a commit:

A few details:

• Name the paths to commit explicitly instead of git add ., which sweeps in .env, build output and .pipeline/ along with everything else.
• Write Pipeline-ID as a Git trailer (in the last paragraph of the message). git log --grep="Pipeline-ID: pipe_feat_auth_v2_88f9a" then finds every commit in one pipeline run.
• Downstream uses git diff <base_commit>...HEAD, not git diff HEAD~1. The implementation stage can easily produce several commits — especially after a reject-and-reimplement round — and HEAD~1 only shows the last one. The three-dot form diffs everything from the merge base to HEAD.

The diff tells the next stage what changed; the commit message and HANDOVER.md tell it why. You need both. And a diff does not include the callers that weren't touched, so the reviewer still has to read surrounding files — which is why the review configuration in section 4 keeps Read and Grep.

---

4. The Inter-Agent Communication Bus

For independent agents to trigger one another you need an automated communication bus. First, one premise to get straight: the web versions of ChatGPT, Gemini and Grok can't be invoked from a script, and they can't write results into your repository. To bring them into an automated pipeline you switch to each vendor's CLI or API — OpenAI's Codex CLI (codex exec), Google's Gemini CLI (gemini -p), and xAI's Grok Build CLI (grok -p, currently in beta) or the xAI API. Keeping a stage that can't be fully automated as a semi-automated "a human drops the output into the repo" step is perfectly reasonable.

Option A: A shared filesystem and a lightweight watchdog listener

This is the best fit for a single machine with several terminals: a Python script watches .pipeline/pipeline_state.json and launches the next agent when it changes.

The orchestration script, agent_orchestrator.py

The minimal examples you usually find online are a few dozen lines: read the JSON in an on_modified callback, flip the status, then subprocess.run an agent with --dangerously-skip-permissions. The idea is right, but copied as-is it walks into the following traps, each of which the implementation above handles:

• File events are messier than they look. We tested watchdog 6.0.0 on Linux: merely reading the file fires FileOpenedEvent and FileClosedNoWriteEvent; saving via "write a temp file, then rename" gives the target a single FileMovedEvent and on_modified never fires at all; and one ordinary write can fire on_modified several times. Hence the handler subscribes only to write events, and a threading.Event coalesces a burst of events into one pass.
• Dispatch must not block the event thread. Running an agent that may take half an hour inside a watchdog callback stalls event delivery entirely. Here the callback only "wakes" the main loop, which does the actual work.
• State has to move forward, not just in. The naive version sets IN_PROGRESS, then neither checks the exit code nor advances the state, relying entirely on the agent to edit the JSON. The moment an agent skips that step, the pipeline hangs forever without a single error.
• The reviewer needs no write access at all. The diff goes in on stdin, the report comes back on stdout, and the orchestrator writes audit_report.md. Demanding a read-only reviewer while launching it with --dangerously-skip-permissions is a contradiction these examples commit all the time.
• --output-format json returns fields such as session_id, num_turns and total_cost_usd. The orchestrator records them in history, so you can trace afterwards what each round cost and how many turns it took.

Each config directory needs one interactive login first: run CLAUDE_CONFIG_DIR="$HOME/.claude_profiles/acc_a" claude, then /login. According to the official docs, once CLAUDE_CONFIG_DIR is set, the credentials file (and on macOS, the Keychain entry) is keyed to that directory. For fully unattended runs, claude setup-token generates a one-year OAuth token that you pass in as CLAUDE_CODE_OAUTH_TOKEN; or use ANTHROPIC_API_KEY and pay API rates. Watch the precedence: in -p mode, an ANTHROPIC_API_KEY in the environment is always used when present, ahead of the OAuth token and the subscription login — which is why the code above filters it out of the child's environment.

---

Option B: A lightweight Python HTTP broker (a relay across machines)

If your agents live on different physical machines or in CI, you can run a FastAPI broker:

On the machine that runs Claude Code, a poll worker turns each task it claims into an Option A state file and leaves the rest to the orchestrator:

The broker is short, but four things in it are deliberate:

• Authentication and bind address. Many examples listen on 0.0.0.0 with no authentication at all, while the tasks the broker delivers end up with an agent that can run commands — effectively exposing a machine's shell to the whole subnet.
• A queue has to actually be a queue. A "queue" implemented as message_queue[receiver] = payload lets the second task silently overwrite the first. Here each receiver gets a FIFO queue.
• Don't send local paths across machines. A local path such as docs/spec.md in the payload means nothing on another machine. The payload carries git_commit instead, and the artifacts themselves travel through the Git remote.
• Know your delivery semantics. poll deletes as it hands out, which is at-most-once: if the worker crashes after claiming a task, that task is gone. In production, switch to a queue with acknowledgements, such as a Redis Streams consumer group (XREADGROUP + XACK) or SQS with its visibility timeout.

How the agents use it: the "ChatGPT / Gemini node" is really a script you write. It calls Codex CLI, Gemini CLI or a vendor API to do the work, pushes the result to the Git remote, and then sends a POST to /api/v1/handover. The ChatGPT web app has no way to reach a broker inside your network.

---

Option C: Redirecting CLI standard input and output (stdio / pipes)

At the shell level, a Unix pipe can hand one platform's output straight to another agent:

Two details that are easy to get wrong: the official Google CLI's executable is gemini, not gemini-cli (that's the repository name), and files are pulled in with @path inside the prompt. set -euo pipefail stops the whole pipeline the moment step 1 fails, instead of passing an empty summary downstream.

Step 2 deliberately does not use --dangerously-skip-permissions; it auto-accepts edits and allows only the test command. The reason goes beyond the size of the permission set: a pipe turns the upstream model's output, verbatim, into the downstream agent's instructions. Gemini is reading a PDF, and any passage in that PDF can travel down this pipe and become a command on your machine. That is exactly the problem section 6.2 takes up.

---

5. Walkthrough: An End-to-End Cross-Platform Agent Pipeline

Here is a semi-automated workflow for a real scenario: a human triggers and signs off the first two stages, and the section 4 orchestrator runs the last two.

Scenario: refactoring an enterprise Redis cache layer, with an independent security review

Step 1: Research (Grok)

• Prompt: "Research client choices and reconnection strategies for Node.js against Redis Cluster. Give a source link for every conclusion, and note each client library's current maintenance status."
• Output: docs/research/redis_client.md

The prompt deliberately isn't "find the best ioredis reconnection strategy" — that presupposes the answer. Ask about the choice first, and the research comes back with a key fact: the ioredis README says its maintenance is done on a best-effort basis and that node-redis is the recommended client for new projects. Skip research and let the coding agent work from memory, and it will most likely pick whichever library shows up most in its training data.

Requiring a source for every conclusion isn't box-ticking either: search-backed models invent API changes too, and a conclusion without a link shouldn't make it into the next stage.

Step 2: Specification and test design (ChatGPT / Codex)

• Input: docs/research/redis_client.md
• Prompt: "As lead architect, define the TypeScript interface for CacheManager based on the research report. The interface must not expose any client library's types. Output a unit-test checklist and .pipeline/HANDOVER.md."
• Output:
  • src/cache/ICacheManager.ts
  • tests/specs/cache_spec.md
  • .pipeline/HANDOVER.md

"No client library types in the interface" turns node-redis versus ioredis into an implementation detail you can defer and reverse. This is also the single best place in the pipeline for a human sign-off: get the architecture decision wrong and every later stage will execute the mistake very diligently. After sign-off, commit, write that commit's SHA into the state file as base_commit, and set the status to AWAITING_EXECUTION — the orchestrator takes it from there.

Step 3: Core implementation (Claude Code, profile acc_a)

The orchestrator runs the equivalent of:

Note that this uses $HOME, not CLAUDE_CONFIG_DIR="~/.claude_acc_a": a ~ inside double quotes is not expanded by the shell, so the program receives the literal string ~/.claude_acc_a. Whether that works depends on every program that reads the variable handling ~ itself — rather than bet on it, just write $HOME. And the permission flags are not optional: in -p mode nobody is there to click "allow", so without pre-approval every file edit and test run is denied and the agent can't actually change anything.

What happens:

1. The agent reads the scope and constraints in HANDOVER.md.
2. It writes src/cache/CacheManager.ts and its unit tests, running npm test itself and iterating until they pass.
3. Once the agent exits, the orchestrator runs npm test again on its own — and that result is the one that counts.
4. On a pass, the orchestrator commits the change (with a Pipeline-ID trailer) and advances the state to REVIEW.

Why not let the agent run git add . && git commit and edit pipeline_state.json itself? Because one missing sentence in the prompt is all it takes for the pipeline to stop right there, with no error; and git add . sweeps in files that should never be committed.

Step 4: Cross security review (Claude Code, profile acc_b)

• Output: .pipeline/audit_report.md. If the last line is APPROVE, the pipeline finishes. If it's CHANGES_REQUESTED — or there's no verdict line at all — the report goes into feedback.md and the task returns to Step 3.

"Redis injection" is deliberately absent from the review focus. RESP transmits each command as an array of arguments, so there is no concatenation vulnerability in the SQL-injection sense. The real risks in Redis are Lua scripts assembled by string concatenation (EVAL) and keys without a namespace prefix. Cluster mode adds one more check on multi-key operations: if the keys don't hash to the same slot the command fails outright with CROSSSLOT, and you need a hash tag such as {user:42} to put them in one slot.

For genuine model diversity, swap this step for a model from another vendor — for example, Codex CLI reviewing in a read-only sandbox: codex exec --sandbox read-only "Review the changes in git diff $BASE_COMMIT...HEAD ...". The same model under another account only gets you a clean context, not a second perspective.

---

6. Engineering Safety, Sandboxing and Fault Tolerance

The more complex a multi-agent pipeline becomes, the more its fault tolerance and security controls matter.

6.1 Permissions and account isolation

1. Config directory isolation (profile sandboxing) Use environment variables to keep each role's authentication state separate, and never share credentials between roles:

   alias claude-dev='CLAUDE_CONFIG_DIR="$HOME/.claude_profiles/acc_a" claude' alias claude-audit='CLAUDE_CONFIG_DIR="$HOME/.claude_profiles/acc_b" claude'

   Defining the aliases in single quotes defers expanding the variable until each use.

2. Least privilege per role

   Role	Permission mode	Allowed	Denied
   Implementer	acceptEdits	File edits; Bash(npm test *), Bash(npx tsc *)	All other Bash commands (nobody approves them in -p mode, so they're denied)
   Reviewer	dontAsk	Read, Grep, Glob	Edit, Write, Bash, network tools

3. Permission rules are guardrails, not a security boundary Bash(npm test *) allows a command prefix, but what npm test actually runs is decided by scripts.test in package.json — a file the implementer is allowed to edit. Worse, the orchestrator's own test gate executes it too. So:

   • Run both the implementer and the test gate inside a container, Dev Container or VM that holds no production credentials and allows only the network egress it needs. Claude Code's built-in sandbox (the sandbox.enabled setting, which gives Bash filesystem and network isolation on macOS, Linux and WSL2) is a useful extra layer.
   • claude --help describes --dangerously-skip-permissions as "Recommended only for sandboxes with no internet access". Turning it on for every agent on the host machine is the most common — and most dangerous — move in multi-agent tutorials.
   • The reviewer's checklist must include changes to package.json scripts and CI configuration; the review prompt in section 4 already does.

6.2 Prompt injection across agents: every handover is a trust boundary

This is the link that articles like this one most often ignore, and it is the most dangerous. The upstream stages of the pipeline are precisely the agents whose job is to read untrusted content: Grok reads web pages and posts on X, Gemini reads PDFs and logs of unknown origin. Once their output flows verbatim into the "next actions" of HANDOVER.md — or, as in Option C, is piped straight in as a prompt — a sentence an attacker planted on a web page can become a command on the implementer's machine.

Simon Willison calls this combination the "lethal trifecta": access to private data, exposure to untrusted content, and the ability to communicate externally. With all three present, data exfiltration is one carefully crafted paragraph away. A multi-agent pipeline assembles all three almost without trying: the research agent does the reading, the implementer holds the repository and credentials, and the only thing between them is a Markdown file.

Practical mitigations:

• Research output is reference material, not instructions. It lives in docs/research/, and only after a human or the architecture stage distills it does anything reach HANDOVER.md. The implementer's prompt states explicitly that research material is data, not commands.
• Remove at least one leg of the trifecta. Keep production credentials out of the implementer's environment and put its network egress on an allowlist — then even a successful injection finds nothing to steal and nowhere to send it.
• Have the reviewer watch for abnormal behavior specifically: new network calls, new dependencies, modified build scripts.

6.3 Loop protection and token budgets

When the implementer and the reviewer fall into a "change → reject → change → reject" loop, tokens keep burning. Control it in three layers:

1. Per invocation: --max-turns caps the turns in one run, --max-budget-usd caps the spend of one run (it only works in -p mode), and subprocess.run adds a timeout.
2. Per pipeline: retry_count totals failed tests, rejected reviews and timeouts; at MAX_RETRIES the status becomes HUMAN_INTERVENTION_REQUIRED. That logic already lives in the section 4 orchestrator's fail(). The retry cap has to be wired into the state transitions themselves: defining a check_loop_limit() that nothing calls on each failure, with a retry_count that never increments, is no cap at all.
3. No-progress detection: compute the index's tree hash with git write-tree and stop immediately if it matches the previous round. This catches "the agent keeps submitting the same thing" much earlier than counting alone.

Every invocation's total_cost_usd is stored in history, so a pipeline's total cost is one command away:

Finally, replace the orchestrator's notify() with a real alert. Below is the Slack Incoming Webhook version; Feishu and DingTalk custom bots differ only in the JSON shape (Feishu: {"msg_type": "text", "content": {"text": ...}}; DingTalk: {"msgtype": "text", "text": {"content": ...}}):

---

7. Conclusion: Where the Agent Mesh Is Heading

Cross-account, cross-platform AI agent workflows mark the move in AI-assisted development from the era of the lone AI assistant to the era of multi-agent pipelines.

Combine Grok (real-time intelligence), Gemini (long-document and multimodal understanding), ChatGPT / Codex (reasoning and specification) and Claude Code (terminal execution and refactoring), add a standardized handover protocol (HANDOVER.md) and a lightweight dispatch bus, and you can build a high-throughput, well-isolated automated software line whose stages review one another. But the point this article keeps coming back to is that the line's reliability does not depend on how many models you plug in. It depends on who advances the state, who guards the gates, and where untrusted content stops.

As for the future, the interoperability standards are already concrete enough that there's no need to invent a private protocol over Unix domain sockets:

• MCP (Model Context Protocol) connects tools and context to agents. Claude Code can itself act as an MCP server via claude mcp serve, to be called as a tool by other agents.
• The A2A (Agent2Agent) protocol handles communication between agents. In August 2026 it joined the Agentic AI Foundation (AAIF) under the Linux Foundation, with the specification at version 1.0. Agents publish their capabilities as an Agent Card at /.well-known/agent-card.json.
• AGENTS.md, also stewarded by the AAIF, is becoming the de facto standard for sharing project constraints across tools.

Looking back, the hand-rolled pipeline_state.json state machine and broker in this article are essentially a manual version of A2A's task lifecycle and artifact passing — and HUMAN_INTERVENTION_REQUIRED corresponds directly to A2A's input-required state. Build the simplified version by hand first, then migrate to the standard protocol, and you'll know exactly why every field exists.

A checklist for going live:

• Add .pipeline/ to .gitignore, and log in interactively (/login) once in each config directory.
• Only the orchestrator moves state; gates look at exit codes and test results.
• The reviewer is read-only: the diff goes in on stdin, the report comes out on stdout.
• The implementer runs in a sandbox, with no production credentials and allowlisted network egress.
• Set --max-turns and --max-budget-usd on every invocation, and a retry cap on every pipeline.
• Schedule a human sign-off after the specification stage.
• Unattended pipelines use an API key, not a rotation of subscription accounts.