Scout
DocsBlogToolsContact
Scout + pi● pi asks an agent○ an agent hands pi work

Small agent.Shared coordination.

pi gets Scout as native tools, and Scout can start pi on any project.

pi → Scout: available (pi-scout) · Scout → new pi session: available (pi_rpc) · Scout → your open pi session: live notices only, no inbox

Use supported agents you have installed, authenticated and connected.

Set it upLet your agent do itpi reads the setup for you
pi — ~/dev/app

pi · ~/dev/app · scout tools loaded

> Use scout to ask hudson which tests are failing on main.

● scout_ask(to: "hudson")

└working…accepted · ref 3f1a

● notice · hudson replied on ref 3f1a

  1. 2 failing on main: wait.test.ts (timeout), reply.test.ts (old receipt shape).
>

pi calls Scout

Available

Extension

Give pi Scout tools ↓

Scout runs pi

Available

pi_rpc

Launch pi through Scout ↓

Replies reach your open session

Partly

Live notices while pi-scout is engaged

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

    From pi, ask another coding agent to explain a failing test before asking it to make changes.

    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?

Live notices while pi-scout is engaged; no durable inbox, unread state, or threaded reply. Keep the returned reference to check completion explicitly.

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 pi

Connect yourself to Scout for me. Read openscout.app/pi/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

  • Earendil pi coding agent installed, with Node.js 20 or newer.
  • Scout installed, initialized, and healthy on the same machine.
  • An authorized project directory and supported destination runtime.
calls Scout

Give pi Scout tools

Start here
  1. 01

    Install the extension

    This command skips the package’s optional install-time configuration of other local hosts. Omit the environment variable only if you also want the installer to configure compatible Codex/Claude MCP hosts.

    PI_SCOUT_SKIP_HOST_MCP_SETUP=1 pi install git:github.com/arach/pi-scout
  2. 02

    Confirm local readiness

    Start or reload pi after installation. Confirm Scout is healthy and that the extension exposes scout_ask and the session tools.

    scout doctor
  3. 03

    Use pi’s native Scout tools

    For new work use scout_ask with projectPath and an optional supported harness. Inspect the installed schema. Use scout_send only for one-way updates.

  4. 04

    Inspect sessions or follow a result

    Use the pi session picker to select known context. For an existing request, preserve the returned handle and observe it rather than asking again.

    /scout sessions
# In a shell, follow a returned Scout ref:
scout wait <returned-ref>
Scout runs it

Launch pi through Scout

03

Done when

  • pi lists the scout tools after install.
  • A small scout_ask returns a ref, and the reply arrives as a pi notice.
  • scout wait <ref> in a shell shows the same completed reply.
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

  • While pi-scout is engaged, your open pi session shows live message.posted and flight.updated notices. It has no durable inbox, no unread state, and no threaded reply, and the broker cannot run an invocation inside that session. Messages sent while pi is closed are not delivered to it later. For broker-owned pi work, launch a fresh session with --harness pi.
  • The native extension exposes scout_ask, not the unprefixed MCP ask tool.
  • High-trust local developer pilots. Connection traffic may contain project paths, instructions, messages, and agent results. Data and privacy.
06

For agents

agents.mdThe setup contract your agent follows. Same content as this page.integration.jsonDirections, gates and steps as data.