Ask your agentsfrom your terminal.
Connect the agent running in your pane to Scout, and keep each task tied to its actual session.
Scout reads Herdr workspaces and can focus a pane (macOS app and web). Scout does not type into or dispatch work to panes.
Use supported agents you have installed, authenticated and connected.
herdr · project panesIllustration$ bun test ✗ retry preserves the reference 1 test failed
Explain this test failure without editing files.
Use the agent’s configured Scout interface.
The retry creates a new request. Keep the original reference when checking the result.
Follow the returned handle in Scout. A pane name is not an agent address.
Scout runs Herdr
No
Herdr is not a Scout harness
Replies reach your open session
No
Scout does not type into or dispatch work to panes
Start here
- 01 · Connect
Get one route working
Check the prerequisites and access gates, then get one documented route working before asking for work.
Follow the setup → - 02 · Try
Your first useful task
Select a short test failure in your pane, then ask for an explanation through the configured agent’s Scout interface. Keep the agent’s actual routing identity.
Name the project and keep the request small. Asking for no edits describes the task; it does not restrict the agent’s permissions.
- 03 · Read
Wait for the answer
Keep the returned reference. Check the work’s status and read the completed response; a queued receipt is not the answer.
Check what success looks like →
Before your next ask
Where will the reply appear?
Read the result through the Scout interface configured in the agent running in your pane. A pane label is not a routing address.
What if the answer hasn’t arrived?
Inspect the existing task before submitting another one. A wait timeout does not establish that work failed. If it needs access or input, resolve that condition before continuing.
How do I follow up?
Continue using the returned reference or exact session handle supported by this integration. Keep it with the findings so your next question follows the same work.
Can Scout run this integration, or only receive asks from it?
These are separate capabilities. Check the supported directions on this page. Connection alone does not establish that Scout can launch the integration or reach an existing session.
Set it up
Fastest
Give this to your agent
Connect yourself to Scout for me. Read openscout.app/herdr/agents.md and follow it step by step: check the prerequisites first, ask me before any step that needs a token or other credential, and finish with its verification step. Tell me what you verified.
- reads agents.md
- checks prerequisites
- asks before any credential
- runs the verification
You need
- Herdr installed with a supported coding agent running in a pane.
- Scout installed and healthy on the same machine for local coordination.
- The selected pane’s actual harness and session identity; a pane label alone is not a Scout routing address.
Connect the agent in your pane
Start here- 01
Set up the terminal host
Follow Herdr’s current installation documentation and choose the real coding agent you want to run inside each pane. Install Herdr’s own lifecycle hooks for that agent so pane state (idle, working, blocked) stays authoritative, independent of Scout.
herdr integration install codex herdr integration status - 02
Connect the agent inside the pane
Use the Scout guide for that host: Codex, Claude Code, pi, or another compatible agent. The same shared CLI, MCP configuration, and skill apply according to the agent’s capabilities.
scout doctor - 03
Route by project and actual harness
Herdr owns the terminal pane, not the execution runtime. Use the actual harness when asking for new work; do not use --harness herdr.
scout ask --project /absolute/path/to/project --harness codex --notify "Review the latest changes; do not edit files." - 04
Preserve session identity
For existing work, continue by the returned Scout handle or a verified harness session ID. Do not infer a routing address from the pane’s display name. Idle terminal output alone does not prove completion.
What Scout sees
- 01
What Scout sees
The Scout app (macOS and web) lists your Herdr workspaces and panes and can jump focus to one. Agents connected to local Scout MCP can read the same ranked workspace digest through the herdr_workspaces tool. It is read-only: there is no tool that sends text to a pane.
Done when
- Confirm the expected identity and project context, request one small authorized review, and retain its handle.
- Observe the terminal result before reporting success.
If it breaks
- Scout is not found or cannot connect
- Check scout on PATH and run scout doctor in the same environment as the client. A desktop app may have a different PATH from your terminal.
- Requested runtime is unavailable
- Inspect scout runtimes --json and finish that runtime’s setup. Do not silently choose a different harness or model.
Where it stops
- Herdr is a terminal and agent-state surface, not a Scout execution harness.
- Host visibility does not grant new permissions or guarantee that an arbitrary pane can receive a Scout invocation.
- Deeper control (sending prompts to a pane, waiting on pane state) is a proposal (docs/proposals/herdr-terminal-host-integration.md), not shipped.
- herdr_workspaces is verified on local stdio MCP; availability under the hosted mcp:core scope is not claimed.
- High-trust local developer pilots. Connection traffic may contain project paths, instructions, messages, and agent results. Data and privacy.