§September 26, 2026OpenScout

Connecting Grok, Devin, and Claude Code in one multi-agent workflow

Run Grok CLI, Devin CLI, and Claude Code against the same project through one local broker, and hand work between them with tracked results.

Grok, Devin, and Claude Code each run as their own coding agent with their own CLI, login, and model. OpenScout connects them through one local broker on your machine. Any of them can receive a task, the broker records it, and you get a handle for reading the result and asking a follow-up. None of the agents needs to know how to talk to the others.

This guide covers the exact combinations people ask about:

Claude Code + Grok: Claude Code writes, Grok reviews (or the reverse).
Claude Code + Devin: Claude Code plans, Devin implements in a disposable checkout.
Grok + Devin: Devin implements, Grok reviews.
Grok, Devin, and Claude Code together: one implementer, two independent reviewers, one place to read the results.

Need a single connection first? Follow the Grok setup guide, the Devin setup guide, or the Claude Code setup guide. All three lead to the same local Scout broker.

Which Grok and which Devin

Both names cover more than one product, and the connection is different for each.

Name	What Scout connects to	How
Grok	The xAI Grok CLI on your machine	Scout launches it over ACP (`grok-acp`). Available.
Grok Bot	The hosted bot in Cursor's cloud	Grok Bot calls Scout through the hosted MCP gateway. Invite-only pilot; see /grokbot.
Devin	The Devin CLI on your machine	Scout launches it over ACP (`devin`). Available.
Devin cloud	Devin's hosted sessions	Devin calls Scout through hosted MCP. Not yet validated end to end; see /devin.
Claude Code	The `claude` CLI on your machine	Scout launches it (`claude`), or Claude Code calls Scout through its plugin.

This guide uses the three local CLIs. They run on the same machine, read the same checkout, and need no hosted bridge. scout ask --harness grok-acp launches the Grok CLI, not Grok Bot.

What you need

Scout installed, with a healthy broker. Start with the Scout quickstart.
The Grok CLI installed and signed in with xAI (grok --version).
The Devin CLI installed and signed in once, interactively (devin --version).
Claude Code installed and authenticated.
An absolute path to the checkout the agents will work in.

Each task runs in the selected harness and uses that provider's account. Scout keeps coordination records locally; each model provider receives the task data needed to do its part. See the data ownership model before choosing what to share. OpenScout is currently intended for high-trust local developer pilots.

Devin edits without asking. When Scout launches Devin, tool approvals are auto-accepted, so Devin can edit files and run commands in the project without confirmation. Point it only at a checkout you are willing to let it change, and say "do not edit files" in any review task.

1. Check that all three agents are ready

scout doctor

scout runtimes --json

Doctor should report a healthy broker. In the runtime listing, confirm that claude, grok-acp, and devin are all ready. If one is missing, finish its setup before continuing; don't substitute a similarly named runtime or guess a model name.

2. Claude Code + Grok

Make your changes in Claude Code, then ask Grok for an independent review:

scout ask --project /absolute/path/to/project --harness grok-acp --notify "Review the uncommitted diff. Report correctness issues with file and line references, or say no findings. Do not edit files or run tests."

--profile grok and --harness grok are accepted short forms of the same runtime. To pin a model, add one listed in scout runtimes --json, for example --model grok-4.6.

Scout returns a ref. Wait on it:

scout wait RETURNED_REF --timeout 120

If the wait times out, run it again. A timeout doesn't mean the task failed. To ask a follow-up in the same Grok conversation:

scout ask --ref RETURNED_REF "Explain the highest-priority finding. Do not edit files."

For the reverse direction, where Grok implements and Claude Code reviews, send the review with --harness claude.

3. Claude Code + Devin

Use Claude Code to plan, then hand the implementation to Devin in a checkout it is allowed to change:

scout ask --project /absolute/path/to/disposable-checkout --harness devin --model swe-2-high --notify "Implement the plan in PLAN.md. Keep the change small and report which files you changed."

scout wait RETURNED_REF --timeout 300

Review Devin's diff yourself, or send it back to Claude Code:

scout ask --project /absolute/path/to/disposable-checkout --harness claude --notify "Review the uncommitted diff against PLAN.md. Report correctness issues with file and line references, or say no findings. Do not edit files or run tests."

4. Grok + Devin

The pairing works the same way with no Claude Code in the loop. Devin implements, and Grok reviews the same checkout:

scout ask --project /absolute/path/to/disposable-checkout --harness devin --model swe-2-high --notify "Fix the failing test in tests/parser.test.ts. Report what you changed."

scout wait DEVIN_REF --timeout 300

scout ask --project /absolute/path/to/disposable-checkout --harness grok-acp --notify "Review the uncommitted diff. Report correctness issues with file and line references, or say no findings. Do not edit files or run tests."

scout wait GROK_REF --timeout 120

Wait for Devin to finish before you start the review, so Grok reads the finished diff and not a tree that is still changing.

5. Grok, Devin, and Claude Code in one workflow

With all three connected, a practical split is one implementer and two independent reviewers:

Devin implements in a disposable checkout (step 3).
Grok and Claude Code review the same diff in parallel. Send both asks back to back, then wait on each ref:

scout ask --project /absolute/path/to/disposable-checkout --harness claude --notify "Review the uncommitted diff. Report correctness issues with file and line references, or say no findings. Do not edit files or run tests."

scout wait GROK_REF --timeout 120

scout wait CLAUDE_REF --timeout 120

Send the combined findings back to Devin in its original conversation, so it keeps the context of what it built:

scout ask --ref DEVIN_REF "Two reviewers reported these findings: <paste>. Fix the ones that are correct and explain any you disagree with."

The two reviewers don't see each other's output, so their findings are independent. The broker keeps every request, reply, and ref, so you can come back to any of the three conversations later.

Let an agent start the handoff

The commands above run in a terminal, which is the easiest way to try the workflow. Once it works, you can let an agent start the handoff:

From Claude Code: install the Scout plugin (/plugin marketplace add oscout/claude-scout, then /plugin install scout@openscout) and use /scout:ask with the same flags. See /claude.
From the Grok CLI: register Scout as a local MCP server with grok mcp add scout -- scout mcp --context-root /absolute/path/to/project. See /grok.
From the Devin CLI: devin mcp add -s local scout -- scout mcp --context-root /absolute/path/to/project. This direction hasn't been verified end to end yet. See /devin.

Troubleshooting

Symptom	What to check
A harness is missing from `scout runtimes --json`	Confirm its CLI is on `PATH` and signed in. For Devin, sign in interactively once; Scout can't complete a browser login headless.
Grok Bot can't see your agents	That is the hosted connector, not the Grok CLI. It needs a provisioned bridge; see /grokbot.
Devin changed files you didn't expect	Scout runs Devin with approvals auto-accepted. Use a disposable checkout and say "do not edit files" in review tasks.
A review describes code you already changed	The tree moved while the reviewer was reading. Pause edits until each ref completes.
`scout wait` times out	Run it again. Check the destination harness for a login or permission prompt if nothing progresses.