Status & Scope

This page is the plain-language maturity, trust, and scope statement for OpenScout. It should keep product claims, docs, and package metadata honest while the system is still moving quickly.

Short Version

OpenScout is pilot-worthy for high-trust local developer environments. It is not enterprise-ready, compliance-ready, or sponsor-review-ready yet.

The useful promise today is narrow and concrete: run a local broker, make agents addressable, keep Scout-owned coordination records durable, and let humans and agents communicate through the same state model across CLI, desktop, mobile, and mesh-aware peers.

Who It Is For Right Now

OpenScout is currently for:

• solo developers coordinating multiple local agents or harnesses
• small, trusted teams experimenting with agent-to-agent workflows
• coding agents that need a durable route to other agents or to the human operator
• platform reviewers evaluating whether the control-plane model is worth piloting

OpenScout is not currently for:

• untrusted multi-tenant execution
• regulated enterprise rollout
• security-sensitive production automation without a human trust boundary
• hosted, managed, or SLA-backed coordination

Trust Boundary

The default trust model is local-first and high-trust:

• The broker and Scout-owned state run on the user's machine.
• Scout does not require a hosted control plane for the ordinary local path.
• Pairing and mesh forwarding are explicit actions, not implicit cloud sync.
• Local agents and harnesses often run with meaningful machine access. Treat them as trusted local automation unless a stricter permission profile is explicitly configured.

This is not yet a hardened security perimeter:

• no enterprise SSO/RBAC policy layer
• no tenant isolation model
• no formal audit/compliance story
• no guarantee that every harness permission prompt is broker-owned yet
• no universal sandbox contract across Codex, Claude, and future harnesses

For the data boundary, read data-ownership.md. For operator approvals and permission prompts, read operator-attention-and-unblock.md.

Mesh Means Reachability

In OpenScout docs, "mesh" means machines and agents can discover, address, message, wake, and inspect each other through broker-owned routes.

It does not currently mean a distributed-systems guarantee layer. Do not read "mesh" as a promise of exactly-once delivery, at-most-once delivery, global consensus, CRDT-style convergence, or replicated external transcript storage.

The design center is: "I can talk to that agent over there, ask it to do work, check back later, and see the broker-owned records of that coordination."

Data Ownership

Scout owns coordination records it creates or routes:

• conversations and messages
• invocations and flights
• deliveries and delivery attempts
• bindings and agent registrations
• work items and questions when created through Scout

Scout observes external harness material without making it first-party conversation state:

• Claude Code transcript JSONL
• Codex session JSONL
• harness logs and tail streams
• process and filesystem signals

Observed harness material can be tailed, linked, summarized, or lightly indexed. It should not be bulk-imported into Scout's database as if Scout authored it.

Install Footprint

A realistic local install can involve:

• Bun for the CLI/runtime toolchain
• a Scout broker service
• macOS launch agent setup
• support files under ~/Library/Application Support/OpenScout
• optional Caddy for the local web edge
• optional Tailscale or manually configured mesh seeds for multi-machine discovery
• optional desktop and iOS apps for human surfaces

That footprint is appropriate for a developer pilot. It is too much to treat as a silent, enterprise-managed install without more packaging, policy, and admin work.

License And Package Signals

Do not infer public reuse rights from the product name or package availability alone. As of this document, the package manifests use UNLICENSED and the repo does not carry a top-level open-source license file.

Before broader external distribution, the project should make the license posture explicit and consistent across:

• repo root
• npm package manifests
• landing page agent files
• generated llms.txt / agents.md
• README and docs

Maturity Markers

Reasonable to say today:

• local-first control-plane prototype/product codebase
• active v0.x development
• useful for trusted pilots and internal dogfooding
• clear direction around broker-owned records, agent identity, and collaboration workflows

Do not say yet:

• enterprise-ready
• compliance-ready
• secure multi-tenant runtime
• guaranteed distributed delivery layer
• stable public API contract for all integrations
• complete permission/approval capture across all hosts

What Would Make It Sponsor-Ready

The next maturity bar is not just more features. It is clarity and evidence:

• one clean buyer/user story for the pilot
• consistent license and package trust signals
• explicit install and uninstall footprint
• documented security/trust posture
• stable agent integration contract
• broader host-level permission/approval capture over broker-owned unblock requests
• clear failure, retry, and notification semantics
• a small compatibility test suite for agent/tool integrations