Scout + Herdr● Herdr asks an agent

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
Focused pane · shell
$ bun test
✗ retry preserves the reference

1 test failed
Agent pane · Codex

Explain this test failure without editing files.

Use the agent’s configured Scout interface.

Read the completed response

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.

Herdr calls Scout

Available

CLI

Connect the agent in your pane ↓

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

Scout sees Herdr

Available

workspaces, topology, focus

What Scout sees ↓
01

Start here

  1. 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 →
  2. 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.

  3. 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.

02

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.

  1. reads agents.md
  2. checks prerequisites
  3. asks before any credential
  4. 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.
calls Scout

Connect the agent in your pane

Start here
  1. 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
  2. 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
  3. 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."
  4. 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.

Scout sees it

What Scout sees

03

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.
04

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.
05

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.