Skip to main content
A scope is a named set of sessions that acts as a visibility boundary. Recall performed through a scope sees only what happened in that scope’s sessions, while the peer keeps its single unified representation of everything it has ever participated in. Use scopes when one peer’s history spans contexts that must not leak into each other — a therapy app where the clinical sessions must not inform the billing assistant, a support product where a reseller’s agent may only answer from its own tickets, a multi-tenant deployment where one human works across tenants.

Projection, Not Partition

The peer keeps one representation. A scope is a projection of it: a view built only from evidence in the member sessions.
  • Sessions can belong to more than one scope. Membership is many-to-many.
  • Sessions can belong to no scope. onboarding-1 above is reachable by an unscoped request and by nothing else.
  • An unscoped request still sees everything. A scope constrains the requests that name it; it does not hide the sessions from requests that don’t.
Scopes are a recall boundary, not an authorization boundary. Who may call the API is still governed by workspace, session, and peer keys.

The Two Arms

There are two ways to confine recall, and they behave differently. Picking the wrong one is the most common mistake with this feature.

Named scope: depth

Passing a single scope name swaps the observer. Recall runs against the scope’s own view of the target peer, which the deriver and dreamer have been building from the scope’s member sessions all along. That view contains higher-order inferences — but only ones reasoned from evidence inside the scope.
This is the arm you want for a durable, meaningful boundary.

Allowlist: breadth

Passing a list of scopes, or a bare list of session IDs, keeps the peer as the observer and restricts recall to the union of those sessions. Because a dream-derived conclusion is synthesized across sessions, it cannot be attributed to any one of them — so this arm recalls explicit conclusions only, and answers from directly-stated facts rather than inference.
Reach for this when the set of sessions is decided per-request, or when you want a quick boundary without provisioning a scope. See Scoping Recall to Sessions for the full allowlist rules.
A list of scopes is the allowlist arm, not “several named scopes at once”. It gives you the union of their sessions, at explicit-only depth — it does not give you the union of their reasoned views. If you need depth, query one scope.

Creating a Scope and Managing Membership

Scope IDs are unprefixed, must match ^[a-zA-Z0-9_-]+$, and are at most 506 characters. Get-or-create is idempotent: if the scope already exists, the same call returns it, and any metadata you pass is written onto it.
Every scopes route — and every read that passes scope — requires a workspace-level or admin key. A scope’s membership can exceed any single peer’s own session membership, so peer- and session-scoped keys are rejected with 401.

Membership Changes Copy, They Don’t Re-Derive

A session added to a scope while empty needs nothing special: messages sent after the change flow into the scope through the normal deriver fan-out. A session that already has messages is handled retroactively by a background job rather than by re-running the LLM over its history: adding it copies the session’s existing explicit conclusions into the scope, and removing it retracts that session’s contributions — including conclusions derived from them. Copying rather than re-deriving is why membership changes are cheap and deterministic — and why they are also asynchronous. It also means a freshly backfilled scope starts at explicit depth and accrues deeper reasoning through subsequent dreams. Poll status() to tell “the scope hasn’t caught up yet” apart from “the scope has caught up and there is genuinely nothing to recall”:
state is pending, completed, or failed; docs_copied appears once a backfill completes. Only sessions that have had a backfill enqueued appear, so an empty result means none have — not that the scope is empty.

Reading Through a Scope

scope is accepted on these surfaces:

Rules

scope is mutually exclusive with filters, sessions, and session / session_id — and on session context, with peer_perspective (where it also requires peer_target). Like the session allowlist, it fails closed: a contradiction is rejected with a 422 rather than silently widened, a scope with no member sessions recalls nothing, and an empty list (scope=[]) is rejected rather than treated as “no boundary”. Per-surface caps and error shapes are in the API reference.

Provenance, Not Topic

A scope is defined by where a fact was said, not what it is about. If a user mentions a therapy detail in a billing session, that conclusion is formed from the billing session and lands in the billing scope. Querying scope="therapy" will not find it, and querying scope="billing" will.
Scopes give you provenance-based privacy, not topic-based privacy. If you need “no clinical content in the billing assistant’s answers” regardless of where it was said, that is content classification and has to be enforced above Honcho — by controlling what reaches which session in the first place, or by filtering the answer.
Design accordingly: keep the session boundary aligned with the confidentiality boundary you actually care about, since that session boundary is the one scopes can enforce.

Guardrails

A few behaviors follow from how scopes are built:
  • The scope. prefix is reserved. Creating a peer, or adding a peer to a session, with a scope.-prefixed name is rejected.
  • List scopes through the scopes surface. honcho.scopes() / POST /scopes/list returns unprefixed ids. Peer listings hide scopes by default; kind="scope" on POST /peers/list returns the backing peers named scope.<id>, and kind="all" includes both regular peers and those backing peers.
  • A scope can’t be observed. No representation is formed of a scope, so a scope is rejected in any target / observed position, including as a dream target.
  • Membership is managed only through the scopes surface. The session add-peers, set-peers, and remove-peers routes reject scope names and point you at /scopes/{scope_id}/sessions or the scopes field on session create.
If you want the exact mechanics for scopes, read: src/routers/scopes.py, src/crud/scope.py, and src/deriver/scope_backfill.py.

Limits

Full request and response shapes are in the API reference.