> ## Documentation Index
> Fetch the complete documentation index at: https://docs.breakingtrailtech.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Scout

> A multi-tenant agent server: what it is, who these pages are for, and the rules every tool decision follows.

Scout is a web server that runs AI agents for one or more brands. A person chats
with an agent in the browser; the agent can hand work to **coworkers** that run
unattended; a **goals** engine reviews progress on a schedule. Agents reach the
outside world through **connectors** (Shopify, Google, DataForSEO, Firecrawl,
GitHub and others), each of which a brand connects with its own credentials.

Each session runs on the Claude Agent SDK by default. The tools a session
holds are assembled per session from three things: who started it, which model
route it runs on, and which connectors that brand has connected.

## Who these pages are for

<CardGroup cols={2}>
  <Card title="The operator" icon="server">
    You run your own deployment. You set the host environment switches, the
    budgets in `agent.config.json`, and which harnesses exist at all.
  </Card>

  <Card title="The owner" icon="user-shield">
    You want to know, before you rely on it, exactly what an agent can and
    cannot do with your store, your ad accounts and your money.
  </Card>
</CardGroup>

## The roles

| Role | Started by | Has a person watching? |
| - | - | - |
| Person chat | A person in the browser | Yes |
| Inbound email turn | An email to the brand's inbox | No |
| Coworker run | A person, or another agent, assigning a task | No |
| Specialist coworker run | Same, on a coworker holding a connector grant | No |
| Goal agent step | A person tapping a step on the Goals page | No |
| Goal reviewer | The goals tick | No |
| Read-only route | Any of the above, on a model or harness that is not certified for the standard tool set | Depends |

The full tool list for each is on [Tool permissions](/security/tool-permissions).

## Rules every tool decision follows

<AccordionGroup>
  <Accordion title="Absent beats refusing">
    A tool the operator did not enable is not registered at all. A tool that is
    described to the model but refuses when called is an invitation the model
    keeps accepting, so the code removes the tool instead. There are two
    deliberate exceptions, listed on the permissions page, where a tool stays
    registered and refuses.
  </Accordion>

  <Accordion title="Fail closed on money and secrets">
    A budget that is zero, negative, not a number, or unreadable is an error,
    never "unlimited". A spend ledger that cannot be read stops the session
    rather than reading as empty.
  </Accordion>

  <Accordion title="A person approves each write, one at a time">
    Writes to the outside world (a store change, a commit, an email, a sheet)
    and spends above a threshold wait for a person to approve that specific
    call. Silence denies. Unattended runs have no one to ask, so the writes
    that need asking are not available to them.
  </Accordion>

  <Accordion title="Budgets are caps, not targets">
    Every session has a dollar cap and a turn cap. Every coworker run has its
    own. The model spend for the month has a cap per brand, and each paid
    connector has its own monthly cap in its own currency.
  </Accordion>

  <Accordion title="Measured is not the same as reasoned">
    The code keeps two kinds of note: what was observed against the real
    service, with a date, and what is reasoned from documentation. These pages
    keep the same distinction. A passing test suite is evidence about the
    test fakes, not about the vendor.
  </Accordion>
</AccordionGroup>

<Note>
  These pages describe the code at the commit they were built from. Where a
  behaviour has never been exercised against the real service, the page says
  so.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.