Web, chat and CLI. One project history.
Updated Read as Markdown ↗
One project history. Web, chat and CLI give you different ways to use it.
The local Factory executes and verifies. The cloud publishes observations and accepts bounded owner intent. The cockpit and hosted MCP read the same project-scoped control plane.
The endpoint is available to configured private clients with bearer authentication. Public self-service setup, ChatGPT / Claude OAuth installation and a complete owner conversation still need acceptance evidence. The chat examples on this site are labelled illustrations.
What the private MCP surface exposes
Every tool requires an explicit project key. A read includes observation time and freshness; an absent projection is unknown, not a successful result.
| Purpose | Current tools | Boundary |
|---|---|---|
| Understand the Factory | status, current_work, recent_activity | Liveness and durable progress are separate. |
| Follow work and requests | requests, backlog, owner_gates, roadmap | Received in cloud does not mean consumed locally. |
| Inspect evidence | capabilities, metrics, learning, decision_trace | Only projected, recorded facts; missing measurements remain unknown. |
| Submit intent | create_intake, change_priority, record_owner_decision | Local pull validates and materializes the request. It does not bypass execution authority. |
Owner-decision mutations currently apply to real Advisor subjects. They cannot resolve every execution gate, authorize a release or declare a cure. Intake uses stable request IDs so retries do not create a second request.
The cockpit observes. Your machine does the work.
The private owner cockpit is deployed with Status, Now, Requests, Needs you, Progress, What’s left and Blockers & Recoveries. Local execution remains on the machine with the repository, agents and tools. Vercel serves the interface; the cloud read model is not another execution engine.
Read snapshot freshness and last durable progress independently. A green heartbeat does not prove productive work. Unknown blocker scope stays unknown. A resolved blocker is not marked as resumed unless later evidence supports it.
Owner outcome metrics are domain-defined and optional. If no metric is configured, there is no invented readiness percentage. Public views use a smaller, explicitly sanitized projection that excludes owner requests, private work titles, credentials and raw evidence. Content has a public read-only observation; ARVO’s public view is Coming online.
Open public Live Factories or inspect the local CLI reference.
Conversation expresses intent; the Factory remains the authority
A request can wait for the Mac to consume it, converge into existing work or become newly eligible work. Receipt in cloud proves only the first step. The chat never writes directly to the local ledger or certifies completion.
Explore the owner / system view of a request.
Worker tools are a different use of MCP
Your coding agent can also use its own MCP servers to read an issue tracker, database or documentation. Those tools belong to the worker’s configured host and permissions. Installing one does not connect a Factory automatically.
- Configure the tools and credentials in your coding host.
- Use the private onboarding path to declare project sources, evidence rules and allowed actions.
- Keep investigation, execution and independent verification attached to canonical work.
A domain pack defines the project’s bounded commands and structured evidence. Orchestro is not a universal database connector, and the cloud does not gain unrestricted access to your repository.
Coming from the original Orchestro MCP package?
The legacy mcp-orchestro package remains a separate installation. It is not the new Factory control plane. Existing data and settings are not migrated automatically.
Documentation for agents
/llms.txt and each page’s Markdown export are generated from the same visible documentation. commands.json is the dated CLI catalog, not the hosted MCP tool inventory above.
Check availability and remaining acceptance work.