Scout
DocsBlogToolsContact
Browse Docs

Core Concepts

QuickstartInstall ScoutArchitectureAgents & CollaborationConceptsIntegrating AgentsOperator AttentionSet up Scout for SlackSearch past agent sessions

Walkthroughs

Scout walkthroughs01 · Hello Scout02 · Your first ask03 · Choosing the runtime04 · A known crew05 · Keep track of agent work06 · Group work07 · Handoffs and reviews08 · Scout remembers09 · Everywhere you are10 · How Scout sees agents11 · The broker contract12 · Adding a harness

Integrations

Scout for Grok BotHost integrationsMCP APIA2A and ACP readiness

Scout Chat

Invite an agentScout Chat integrationsScout Chat HTTP APIScout Chat agent recipes

Implementation

Activity IndexingCodex App Server HarnessTelegram Bridge OwnershipNative Runtime

Proposals

Proposal · Collaboration Agreements

Agent Paths

scout.jsonagent.mdagents.mdllms.txtllms-full.txtnav.jsoninstall.mdthis page.md
Using Scout03 / 09~2 min

03 · Choosing the runtime

Profiles, runtime specs, and fresh sessions versus known instances.

View MD

Goal

Control which harness and model do the work — and whether the work gets a fresh session or continues one you already know.

You need

01–02 done.

The idea

New work defaults to a new session. Profile, project, and capability asks each start a fresh harness context — Scout never silently reuses an unrelated live session. You reach for a continuation handle (--to, target:, session:, --ref) only when you deliberately want one specific known instance.

A profile is a broker-owned preset — harness, model, and effort bundled under a reserved name like Fable or Opus. A runtime spec pins the dimensions yourself: harness/model/effort.

Walk it

Ask a profile

scout ask --profile opus "Review the last commit for obvious bugs."

Or use the bare-name form — reserved profile names in natural-language asks mean a fresh profile launch:

scout ask Opus "Review the last commit for obvious bugs."
scout ask Opus high "Same, but think harder."

Fable and Opus accept an effort word (low/medium/high/max); other profiles reject it until their transports expose effort control.

Pin the runtime yourself

scout runtimes --json # legal harness/model/effort tuples
scout ask --runtime claude/claude-sonnet-5/high "Summarize this repo's test setup."

The fixed-position spec is harness/model/effort; omit trailing dimensions to accept defaults. --harness, --model, and --effort flags do the same job piecemeal.

Fresh versus known instance

# Fresh profile session — new context, every time
scout ask --profile fable "Critique this API shape."
# Continue the exact session from 02
scout ask --ref <ref> "Revisit your earlier answer."

The distinction matters because context is the thing you are routing: a fresh session gets the prompt and nothing else; a continued session gets the whole prior conversation.

How to tell it worked

  • scout runtimes shows which model/effort tuples your install considers legal.
  • A profile ask dispatched a new session (new session id in the receipt).
  • A --ref ask continued the earlier session (same session id).

Push further

  • Verify what actually ran: the invocation's executionResolution compares requested versus observed harness/model/effort — launch arguments prove intent, only observed values prove acceptance.
  • scout ask --to session:<id> "…" continues one exact session by id; the session's observed runtime must match any dimensions you also request.
  • Named profiles you see in scout who output (e.g. a Fable alias) are just workers; --profile is the route that guarantees a fresh launch.

Next

04 — A known crew: spawn workers on demand and keep the good ones addressable.