Soon F. Hoo

Research / AI agents

How Grokbot can pass a coding job to another agent

For GrokChief (Grok-based) handing work to gptdev (GPT/Codex) or a Claude-based agent — on a small self-hosted team with Gitea and an AWS deploy. The short answer is not a protocol. It’s a file, a branch, and an Issue.

Nov 11, 2026Gitea + AWS host + private boardNo native Grok → GPT/Claude handoff existsSources linked for every confirmed claim

Bottom line

There is no out-of-the-box Grok → GPT/Claude handoff. Every workable route is either (a) a shared artefact both agents can read/write — repo, branch, task file, Issue — or (b) a wrapper/framework you build around both agents. Start with (a). Do not start with A2A.

Do now — Option 1

Git + Issue + handoff file

Branch + tasks/active/*.md + Gitea Issue/PR + AGENTS.md. Works today, no new services, no vendor lock-in.

Do next — Option 2

Shared Gitea MCP server

Same handoff, but machine-readable: both agents create Issues, branches and PRs through the same MCP tools.

Later — Option 3

A2A or one orchestrator SDK

Future-proof, highest effort. Requires wrapping Grok — xAI has no confirmed native A2A support.

The distinction that prevents wasted work

Three protocols, three different jobs

Confusing these is the most common dead end. Only one of them is actually agent → agent.

ProtocolDirectionWhat it doesDirect GrokChief → gptdev?
MCP — Model Context ProtocolAgent → tools / dataGives an agent tools (e.g. create Issue, create PR). No notion of another agent, no task lifecycle between agents.No — shared tools only
A2A — Agent2AgentAgent → agent (peer)Discovery via Agent Card, message/send over HTTPS, Task lifecycle, Artifacts back. The real peer standard.In principle — wrap both sides
ACP — Agent Client ProtocolEditor / host → agentA host (Zed, JetBrains, a script) drives Grok Build, Codex and Claude Code side-by-side. Agents don’t talk to each other through it.No — host mediates
OpenAI Agents SDK handoffsAgent → agent, in-processtransfer_to_<name> tool switches the active Agent inside one Python/TS program run by one Runner.No for existing CLIs
Subagents (Grok / Claude / Codex)Parent → child, same vendorChild session with its own context returns a summary to its parent. Same process, same vendor.No — same-vendor only

Sources: A2A spec v1.0.0 — a2a-protocol.org/latest/specification · MCP spec 2026-07-28 — modelcontextprotocol.io/specification/2026-07-28 · ACP overview — agentclientprotocol.com/protocol/v2/overview (updated 2026-11-09) · OpenAI Agents SDK handoffs — openai.github.io/openai-agents-python/handoffs

1 — xAI / Grok

What Grok actually offers — and what it doesn’t

Confirmed from official xAI docs read live on 2026-11-11, unless marked secondary. The pattern: plenty of hooks to build a handoff on, no handoff itself.

MechanismConfirmed?What it isHands off to another vendor?
Grok API function callingYes — officialModel returns a tool-call request; your code executes it. Built-in tools (Web Search, X Search, Code Interpreter, Image Generation, Collections Search) run server-side on xAI.No — hook only. A function like hand_off_to_gptdev(task_json) is code you write; the API doesn’t deliver or track it.
Grok API Remote MCP ToolsYes — via secondary summaryAdd {"type":"mcp","server_url":…} to a Responses request; xAI connects server-side. Streamable HTTP / SSE only, no stdio; server must be publicly reachable.No — gives Grok tools, not a peer agent.
Grok Build subagentsYes — verified liveIndependent child sessions, own context, return a summary. Types: general-purpose, explore (read-only), plan (no shell/edits). Custom types in .grok/agents/.No — Grok children of a Grok parent, same process/repo.
Grok Build headless grok -pYes — verified livegrok -p "…" and --output-format streaming-json. Docs: “ideal for scripts, automations, or integration into other apps.”Indirect — enables script-driven handoff (see Plan).
Grok Build MCP serversYes — verified liveLocal stdio + remote HTTP. grok mcp add / list / doctor; project scope writes .grok/config.toml. Also loads ~/.claude.json, .cursor/mcp.json, .mcp.json.Indirect — shared tools only.
Grok Build ACP — grok agent stdioYes — verified live (overview)Editor/host drives Grok Build over JSON-RPC on stdio.No — host → agent.
AGENTS.md supportYesGrok Build reads repo instruction files — same convention Codex uses. This is the shared-instruction layer for the practical method.—
A2A supportNot confirmedNo official xAI page found announcing A2A server/client support, an agent card, or a handoff API. Tracker lists xAI as MCP: Supported, A2A: Not Confirmed.Only via third-party wrapper (e.g. Mastra).
Native cross-vendor handoff APINo evidence found——
Don’t quote these as official yet: grok-code-fast-1 (256K context, $0.20/M in / $1.50/M out / $0.02/M cached, ~190 tok/s) and grok-build-0.1 ($1.00/M in / $2.00/M out, 256K) come from aggregators/secondary write-ups only — not verified live on xAI’s models/pricing pages in this run. Re-check docs.x.ai before budgeting. Same caution for the subagent concurrency cap: launch coverage says up to 8, a later source-code analysis claims 32, and the official subagents page states no numeric cap. Arena Mode was described in May 2026 coverage but later reports say the term no longer appears in docs.x.ai — treat as unverified / likely removed.

Sources: Tools overview — docs.x.ai/developers/tools/overview (official, updated 2026-10-10) · Grok Build overview — docs.x.ai/build/overview (verified live) · Subagents — docs.x.ai/build/features/subagents (verified live, updated 2026-07-21) · MCP servers — docs.x.ai/build/features/mcp-servers (verified live, updated 2026-07-02) · Remote MCP summary — ai-x.chat/docs/remote-mcp-tools (reviewed 2026-11-07) · Protocol tracker — agenticplug.ai/current-state-of-agentic-commerce (verified Nov 2026) · Grok A2A via Mastra (third-party, not xAI-native) — skalablog.com/p/grok-a2a-connect-grok-to-your-own-agents

Install & headless commands (verified live) 
curl -fsSL https://x.ai/cli/install.sh | bash
cd your-project; grok            # first launch: browser auth, or XAI_API_KEY
grok -p "Explain this codebase"
grok -p "..." --output-format streaming-json
grok inspect                     # config, instructions, skills, MCP servers
grok mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /path/to/dir
grok mcp add --transport http linear https://mcp.linear.app/mcp

Grok Build source was published 2026-07-15 at github.com/xai-org/grok-build under Apache 2.0, with issues/PRs disabled and external contributions not accepted (secondary source) — treat as source-available, not community-governed. Docs examples now use Grok 4.7.

2 — Standards in detail

How each protocol would work, mechanically

A2A — the actual agent → agent standard

  1. Discovery: remote agent publishes an Agent Card (JSON) at /.well-known/agent-card.json — identity, skills, endpoint, auth. v1.0 adds signed cards (JWS).
  2. Send: JSON-RPC 2.0 message/send over HTTPS (v1.0 also binds gRPC and HTTP+JSON/REST), auth per the card (OAuth 2.0, bearer, API key, mTLS).
  3. Work: remote opens a Task — submitted → working → input-required / completed / failed / cancelled / rejected — and runs opaquely; the caller sees nothing of its internals.
  4. Return: poll tasks/get, stream via SSE, or webhook push; completion returns Artifacts (files, structured data, text).

Both sides must: be (or be wrapped as) an A2A server/client — HTTPS endpoint, agent card, JSON-RPC methods, task lifecycle, advertised auth. In practice: an SDK/framework (Google ADK, LangGraph, CrewAI, Semantic Kernel, Mastra, or the a2aproject/A2A SDKs). Maturity: announced by Google 2025-04-09 with 50+ partners; donated to the Linux Foundation June 2025; v1.0.0 is the latest released version on the spec site (secondary sources date it 2026-03-12 and April 2026 — version is settled, exact date is not); native in Azure AI Foundry, Copilot Studio, Bedrock AgentCore, Google Cloud — but most use outside those platforms is still PoC-level per analysts.

MCP — agent → tools

Host (Grok Build / Claude Code / Codex) → Client (one connection per server) → Server exposing tools (model-controlled), resources (app-controlled context) and prompts (user-controlled templates). JSON-RPC 2.0 over stdio (local) or Streamable HTTP (remote); the 2026-07-28 revision made the core stateless. Mature, de-facto standard. Security note from the spec: treat tool descriptions / server instructions as untrusted unless the server is trusted; require consent for write actions — relevant for a write-capable Gitea MCP server.

ACP — host → agent

Created by Zed Industries (Aug 2025), co-developed with JetBrains from Oct 2025; registry launched Jan 2026. Flow: initialize → authenticate → session/new → session/prompt ↔ session/update. Stable wire protocol is v1; v2 is draft. Local transport is stdio only — remote HTTP/WebSocket is an RFD / work in progress, not normative. Grok Build is native (grok agent stdio); Claude Code and Codex connect via adapters (codex-acp for Codex). Useful as an orchestration surface for a human or script — not an agent → agent channel.

OpenAI Agents SDK handoffs & same-vendor subagents

SDK: handoffs=[billing_agent, refund_agent] (or handoff() with on_handoff, input_type, input_filter) injects a transfer_to_<name> tool; the Runner switches the active agent and by default passes full history. Agent.as_tool() is the manager-pattern alternative where control returns to the caller. Handoffs stay within a single run; both agents must be Agent objects in the same program. Claude Code subagents (Agent tool, formerly Task; .claude/agents/ Markdown + YAML; built-ins Explore / Plan / general-purpose; one level deep by default) and Codex subagents (roles default / worker / explorer; TOML in .codex/agents/; codex exec for scripted runs) are likewise same-session only. Unverified: the Responses API multi-agent beta (multi_agent.enabled, spawn_agent etc., default 3 concurrent) is secondary-only in this run.

Sources: Claude Code subagents — code.claude.com/docs/en/sub-Agents · Codex subagents (secondary summary) — docs.arantic.com/codex/subagents · ACP remote transport RFD — agentclientprotocol.com/rfds/streamable-http-websocket-transport

3 — What works between any two agents

The practical method: the handoff is a file, not a chat message

Chat history does not transfer between vendors. A Markdown file in the repo does. Git is the one interface every coding agent already has — the diff is the context.

1 · BranchGrokChief works on agent/grokchief-<slug>, never on main. Pushes.
2 · Task fileWrites tasks/active/<date>-<slug>.md with the full payload below.
3 · IssueOpens a Gitea Issue: owner = receiver, label ready-for-gptdev, links branch + file.
4 · AnnouncePosts on the board: Issue #, branch. Chat announces — the repo holds the truth.
5 · Work & PRReceiver checks out the branch, works, validates, sets ready-for-review, opens PR.
6 · Human mergesReview in Gitea; merge to main; deploy to AWS only from main.

Shared board = Gitea Issues

One Issue per task. Labels: handoff, ready-for-gptdev / ready-for-claude, in-progress, needs-review, blocked. Assignee = agent name. Comments = running log. Receiver polls open Issues with its label (git / Gitea API, or MCP in Option 2) and claims by commenting / moving the label.

Limitation: Gitea has no “assign to an AI and wake it.” The receiver must be running — a cron/headless loop or an operator starting it — and polling. Labels are convention, not enforcement.

AGENTS.md — the shared contract

A short root AGENTS.md every agent reads on entry: project overview, exact install/test/lint/build commands, conventions, boundaries (never edit .env, never deploy to prod), git/PR workflow, and the handoff protocol. Grok Build, Codex, Cursor, Gemini CLI, Aider and OpenCode read AGENTS.md; Claude Code reads CLAUDE.md — add one line, @AGENTS.md, as a pointer. Keep it short; route to detail files.

Status strings (use literally, so grep/scripts can find work): Planner → Coder creates the task file; Coder → Reviewer sets status: ready-for-review; Reviewer → Planner sets approved or needs-revision with specific feedback.

Minimum information — enforce this checklist

  • ✓Goal — one sentence, the outcome. Without it the receiver optimises for the wrong thing.
  • ✓Context / why — decisions, Issue/PR links, what was already tried or ruled out.
  • ✓Scope — files/functions in play and out of scope.
  • ✓Starting point — branch name + base commit SHA. “Latest main” is ambiguous.
  • ✓Match example — a file that already does it right; the cheapest quality lever.
  • ✓Constraints — stack, versions, style, boundaries (no secrets, no prod, no .env).
  • ✓Tests / validation — exact commands and how to run them.
  • ✓Acceptance criteria — testable “done when”, not “make it better”.
  • ✓Evidence expected back — files changed, commands + results, checks not run + reason, assumptions, risks.
  • ✓Owner + status + next action (+ deadline/priority if any).

Handoff template — commit as tasks/TEMPLATE.md

# Handoff: <title>
Goal: [one sentence, the outcome — not the method]
Scope: [exact files / functions / endpoints in play]
Out of scope: [what NOT to touch]
Approach: [pattern, limits, logging, conventions to follow]
Match: [path/to/a/file that does it right]
Context: [why this exists, links to Issue/PR, relevant decisions]
Branch: [branch name, base commit SHA]
Done when / Acceptance criteria: [tests passing, commands to run, human reviews diff]
Evidence on completion: [files changed, validation commands + results,
  checks NOT run + reason, assumptions, risks, follow-up]
Status: [todo | in-progress | ready-for-review | approved | needs-revision]
Owner: [agent name, e.g. gptdev]  |  Previous owner: [e.g. GrokChief]

Copy template

Template sources (community practice, no single official standard): sublimecoding.com/blog/coding-agent-rollout-engineering-team · thepromptshelf.dev/blog/writing-effective-agentsmd-guide · codeharness.kuckit.dev/agents-md-template · Gitea workflow: voodoo.business/blog/2026/11/05/using-your-self-hosted-gitea-server

Rule for the board/chat: chat is the notification layer only — announce, clarify, report completion. It is ephemeral and unversioned; a fresh agent session can’t read it as state. Never put the only copy of a task in chat. Chat announces, the repo holds the truth.

4 — Recommendation for this team

Ranked plan: practicality first

A handoff that depends on a protocol neither agent natively speaks will not happen. A handoff that is a file + a branch will.

Option 1 · Recommended first

Git + Gitea Issue/PR + file handoff

tasks/ + AGENTS.md. Highest practicality — works today, no new services, no new protocol, no lock-in.

01
  1. Add a root AGENTS.md (project, exact test/build/deploy commands, boundaries, “work on a branch, human merges”, handoff protocol + tasks/ convention). Add one-line CLAUDE.md (@AGENTS.md).
  2. Add tasks/active/ and tasks/done/; commit the template as tasks/TEMPLATE.md.
  3. Fix conventions in AGENTS.md: branch agent/<agent>-<slug> (e.g. grokchief/add-login); labels handoff, ready-for-gptdev / ready-for-claude, in-progress, ready-for-review, blocked; status strings todo / in-progress / ready-for-review / approved / needs-revision.
  4. GrokChief handoff procedure (in AGENTS.md): finish on its branch → push → write tasks/active/<date>-<slug>.md → open/update Issue (owner = receiver, label ready-for-<agent>, link branch + file) → announce on the board with Issue # + branch.
  5. Receiver intake (in AGENTS.md): read AGENTS.md → list open Issues labelled ready-for-<name> → read task file → git fetch && git checkout <branch> (or branch off it) → work → run validation → update task file (evidence + ready-for-review) → push → open/update PR → comment on Issue → announce.
  6. Run unattended legs headless: Grok Build grok -p "<prompt>" (verified live); Codex codex exec "<prompt>" (secondary source) — or an operator starts each agent with the Issue/task-file path as its prompt. Human merges to main; deploy to AWS only from main, existing path unchanged.

Limitations: async only (no wake-up without a poller or human); no live progress streaming; relies on agents following the written convention — keep the template + AGENTS.md short and checkable; merge conflicts if two agents touch the same files (mitigate: worktrees / one branch per task); no context transfer beyond what’s written in the file — by design, and also its strength.

Option 2 · Next

Shared MCP server for Gitea (+ board)

Medium-high practicality. Builds on Option 1; makes the handoff machine-readable so agents act on Gitea without leaving their CLI. Do after Option 1 works.

02
  1. Run a self-hosted Gitea MCP server on the Gitea host/network (stdio locally, or Streamable HTTP on your private network behind auth). Either write a small Python/TS server against the Gitea REST API (tools: list_issues, create_issue, create_branch, create_pull_request, get_pull_request, merge_pull_request, dispatch_workflow), or evaluate a third-party integration — e.g. Composio’s Gitea MCP for Codex (Create Branch / PR, Get PR, Merge PR, Dispatch Workflow, Get Commit; third-party, not official Gitea — check auth/pricing first).
  2. Give both agents the same server. Grok Build: grok mcp add --transport http gitea https://<internal-host>/mcp --header "Authorization: Bearer ${GITEA_TOKEN}", or project-scoped in .grok/config.toml. Claude/Codex: same server in their MCP config — one project .mcp.json can serve several agents (Grok Build reads it too). Start read-only; add write tools behind an allowlist once trusted.
  3. Keep Option 1’s file + Issue as the source of truth. MCP is the action layer, not a replacement for the written handoff.
  4. Add a Gitea Actions workflow (.gitea/workflows/) running tests on every PR, so incoming work is checked automatically before human merge.

Limitations: you host, secure and maintain the server (auth, token scoping, allowlist — a write-capable MCP server is powerful; a compromised/prompt-injected agent could create/merge PRs). No official Gitea MCP server was verified in this run — integrations are third-party or DIY, so budget maintenance. Remote MCP from the xAI API needs a publicly reachable Streamable HTTP/SSE endpoint (no stdio); the Grok Build CLI can use local stdio. MCP still doesn’t notify the receiver — keep Option 1’s announcement/polling.

Source: composio.dev/toolkits/gitea/framework/codex (third-party)

Option 3 · Later / experimental

A2A — or rebuild both agents in one orchestrator SDK

Lowest practicality today for a small self-hosted team; highest long-term interoperability. Do not start here.

03

A2A route:

  1. Wrap each agent as an A2A server: a small Python/TS service (A2A SDKs from a2aproject/A2A, or Google ADK / LangGraph / Mastra) exposing /.well-known/agent-card.json (skills e.g. implement-task), message/send, tasks/get, SSE streaming, returning Artifacts. The wrapper translates A2A task → prompt + branch + task file for grok -p / codex exec / claude -p, runs it, and translates the diff/PR back into an Artifact.
  2. Host both wrappers on your private network / AWS host behind HTTPS + auth (OAuth 2.0 / API key / mTLS per the card). Each wrapper also acts as A2A client to the other.
  3. Keep Option 1 underneath: the A2A payload is the §3 checklist handoff; the Artifact is the branch/PR reference + evidence. A2A is the envelope, git is still the payload.

Alternative orchestrator route: rebuild both agents as Agent objects in one OpenAI Agents SDK (or LangGraph/CrewAI) program with native handoffs=[...] — in-process handoffs with tracing/guardrails, but you lose the Grok Build / Codex / Claude Code CLIs and re-implement their tool loops.

Limitations: no native Grok A2A (§1) — you build and maintain both wrappers; A2A adoption outside enterprise platforms is still PoC-level; auth, lifecycle, retries, timeouts and hours-long coding tasks are all your problem; debugging spans two services + two CLIs + git. Worth it only when handoffs are frequent, multi-hop, or need machine-readable discovery/routing a board + labels can’t express.

What not to do: don’t try to make Grok Build, Claude Code or Codex subagents hand off to each other (same-vendor, same-process only). Don’t treat ACP as agent → agent (it’s host → agent). Don’t treat MCP as a handoff (it’s a shared tool layer).

Honest gaps

Could not verify / open questions

  1. Model pricing/context for grok-code-fast-1 / grok-build-0.1 — secondary only; re-check xAI’s official pages before budgeting.
  2. Subagent cap — 8 (launch) vs 32 (source analysis); docs state no cap. Version-dependent.
  3. Arena Mode — described May 2026; later reports say it no longer appears in docs.x.ai. Unverified / likely removed.
  4. No native xAI A2A is absence of evidence, not proof of absence — three secondary sources say “not confirmed / not used in xAI’s own products,” and no official page was found. Re-check docs.x.ai before building wrappers; native support would make Option 3 much cheaper.
  5. Responses API multi-agent beta — secondary only, not verified against official OpenAI docs.
  6. Headless flags — grok -p verified live; codex exec is secondary; the exact Claude Code non-interactive flag was not verified — check claude --help at implementation time.
  7. No official Gitea MCP server verified — available integrations are third-party (e.g. Composio) or DIY. Verify auth model, token scope and maintenance before adopting.
  8. A2A v1.0 date — spec site lists 1.0.0 as latest released; secondary sources variously say 2026-03-12 and April 2026. Version settled, date not material.
  9. Grok Build pricing / plan access — not verified; secondary sources conflict. Check x.ai/grok and docs.x.ai before provisioning.
  10. Your actual setup was not inspected — Gitea version, whether Gitea Actions is enabled, the AWS deploy path, and how GrokChief/gptdev are currently launched (CLI vs API vs chat) were beyond the mission summary. Recommendations assume CLI/headless agents on a host that can reach Gitea; if GrokChief is only a grok.com chat with no shell, Option 1 still works (a human/operator runs the git steps) but Option 2’s local MCP and headless loops don’t apply directly.

Sources

Full source list

Verified live = read in the research browser on 2026-11-11. Index = via search/fetch on 2026-11-11. Every URL below is carried from the research report.

Research read 2026-11-11 (America/Chicago). Built solely from the finished research report for this request — confirmed values are marked as such, secondary-only values carry their hedge, and unverified items are listed under Open questions rather than presented as fact.

← All research