Source: https://www.orchestro.org/ Updated: 2026-10-16 PERSISTENT AI-AGENT LOOPS · PRIVATE PREVIEW # Give your project a goal. Watch it ship. A Factory turns your goal into durable work. It runs your agents on your machine, verifies the results and remembers what happened. The cockpit shows the whole day as one river. [Apply for a free pilot](https://www.orchestro.org/early-access?track=build)[Read the river](https://www.orchestro.org/#giornata) 14 jobs shipped today12 online now · 3 waiting for you · 2 reopened later END OF DAY · 19:00 ◈**The Factory**You decide here: publish the loop series in English too? 07:00Sample data · one content-factory day replayed in 30 seconds · a green dot is a first publication19:00 THE DIFFERENCE ## A project that continues after the conversation. Claude Code, Codex and Grok do the work inside a Factory. The Factory keeps the goal, the work, the evidence and the history between sessions. | | AGENT SESSION | /GOAL · /LOOP | ORCHESTRO | | --- | --- | --- | --- | | Keeps working toward a goal | —No | while the session runs | ✓ across sessions | | Work survives the session | —No | —No | ✓ durable backlog | | “Done” is checked independently | —No | self-assessed | ✓ separate check | | Another worker takes over | —No | —No | ✓ with a receipt | | Finds new work when the backlog is empty | —No | —No | ✓ Advisor | You define the direction.Goal, constraints and evidence guide the next authorized work. You don’t draw every step. You keep execution with the project.The remote control plane adds visibility and intent; it does not need to become the machine that owns your repository. ALREADY DISPATCHING AGENTS FROM A BOARD? ## A board runs tickets. A Factory pursues a goal. Linear with OpenAI’s Symphony gives every open ticket a coding agent, a workspace and a run until review. Orchestro starts one step earlier, with the goal, and ends one step later, with the result. | | LINEAR + SYMPHONY | ORCHESTRO | | --- | --- | --- | | Work starts from | a ticket someone writes | a goal with a number | | “Done” means | a pull request ready for human review | an independent check, then the metric after release | | When the backlog is empty | agents wait for new tickets | the Advisor proposes work toward the goal | | Domain | code in a repository | content, product, sales: any domain with tools and permissions | | Memory | ticket state in the tracker | durable history and what was learned | Based on OpenAI’s public Symphony specification, released 27 April 2026 as a reference implementation. A tracker stays a good place for tickets; this compares what happens around them. HOW A FACTORY WORKS ## One goal. One Factory. Six steps, from the goal you write to the direction you keep giving. 01 · GIVE IT A GOAL ### Start with what you want to achieve. A publication. A product. A service you want to keep improving. Start with the outcome and the boundaries. You don’t need to begin with forty prompts or a hand-drawn workflow. Local terminalnorthstar ``` northstar init \ --dir packs/content-factory \ --slug content-factory \ --goal "Build an evidence-led content system for danielepelleri.com: publish useful work, improve discoverability and learn from results." ``` ✓ Goal saved in the domain manifest✓ Valid domain scaffold created→ Next: connect sources, permissions and verification 02 · BUILD THE WORK SYSTEM ### The goal becomes a roadmap. Onboarding connects the goal to capabilities, observable sources, evidence rules and the work to do first. Metrics need measurable sources. Permissions need authority. Missing capabilities stay visible. GOALA publication that keeps getting better.5 ready · 1 needs authority Evidence mining✓observable source✓permission✓verificationready Writing✓observable source✓permission✓verificationready SEO✓observable source✓permission✓verificationready Internal linking✓observable source✓permission✓verificationready Distribution✓observable sourcepermission missing✓verificationneeds authority Measurement✓observable source✓permission✓verificationready · GSC export arrived DURABLE WORKPRIORITY ArticleTurn a real engineering incident into a storyeligibleP1 SEOMake every published article discoverableeligibleP2 LinkingConnect the article to its topic clustereligibleP2 MeasureReview results when a GSC export arriveseligibleP2 New evidence can become the next authorized work. 03 · TURN ON THE LOOP ### Your agents do the work. The Factory keeps continuity. Work is selected, executed, independently checked and recorded. When a check fails the work goes back with the reason. When a worker stops, the next configured one takes over and the history stays. “Done” needs evidence. CONFIGURED EXECUTOR CHAIN **Claude Code**quota exhausted**Codex**last worker**Grok**standby DURABLE HISTORY · NEWEST FIRST 10:32Selecting the next eligible item 10:28History kept across the switch 10:24Receipt recorded 10:20Independent check passed. Later progress proves continuation 10:16Handoff receipt: switched to Codex 10:12Claude Code: provider quota exhausted Illustrative sequence. A running host, configured tools, permissions and provider quota are required. Execution pauses when the host is offline. 03 · WHEN THE BACKLOG RUNS OUT ### The Advisor keeps the loop moving toward the goal. When the planned work is done and the goal is still far, the Advisor follows its routine: read the results, compare them with the goal, find the gap, propose work. Proposals go through the same governed intake. What exceeds authority waits for you. GOAL · MARKETING FACTORYOrganic traffic +20% year over year +9%of +20% 11 points to go BACKLOG5 items Competitor analysis: what 5 similar blogs rank forAdvisor · goal gaprunning Keyword gaps from Search Console queriesAdvisor · goal gapeligible Funnel drop: article → newsletter signup at 0.8%Advisor · goal gapeligible CTA test on the 10 most-read articlesAdvisor · goal gapeligible Paid test: €200 LinkedIn promotionAdvisor · goal gapasks you ADVISOR ROUTINE 1. 1Read the results 2. 2Compare with the goal 3. 3Find the gap 4. 4Propose work 5. 5Send it through intake ◈ **Advisor**4 items accepted by intake. The paid test needs you: it spends budget. Illustrative sequence. The Advisor proposes; governed intake, permissions and the owner decide what becomes work. 04 · WATCH · GIORNATA ## One question first: what shipped today? Every job the Factory touched today flows left to right through four stations: opened, started, solution written, online. Read it in four steps. Step 1 · thicknessthe river at the end of the day Band thickness = number of jobs Stopped early. The reason is written beside it. 05 · LEARN · MEMORIA ## Every problem climbs from a guess to a verified fix. The Factory keeps what it learned between cycles. The river shows how far each problem got. The graph shows what it is connected to. The river of what it learnedWEEK 8 OF 8 A fix counts as verified only when an independent check passes on main. Fixes that fail drop back a step, in their own lane. Sample data, eight weeks replayed. The graph of connections VERIFIED BY A THIRD PARTYTitles cut off on GoogleSEO & search same causeSocial titles too long same causeSubject line truncated in Gmail followsseo/checklist.md citesowner-writing.md ◈ **The Factory**Same cause in three places: a length limit ignored for titles, social titles and the email subject. I fixed the rule, not the single page. Tap any dot to draw its connections, one at a time. Tap a link type to hide it. 06 · KEEP GIVING DIRECTION ### Your chat is the control surface. The Factory is the memory. Ask what is happening. Add a request. Find out why work is waiting, from the conversation where you already work. 1. ChatGPT / Claudeyou ask 2. Orchestro MCPcontrol plane 3. Cloud intentdirection travels 4. Local intakegoverned 5. Execution & evidenceon your machine 6. Cloud readbackstatus + receipts **You**What is the Content Factory working on? **Orchestro**Cluster linking sprint, on Codex. Last durable progress: 4 minutes ago. Two GSC tasks are waiting for a new export; independent work can continue.From the Factory’s last synced snapshot **You**Add a P2 task to build a downloadable content audit tool. **Orchestro**Request sent. The local Factory checks it through governed intake. **Receipt**backlog:example-audit-tool · P2After local acceptance Conversation expresses intent. The Factory remains the authority. Hosted MCP is implemented in private preview; ChatGPT / Claude require a configured client. ## Different goals. Separate project truth. Each Factory has its own domain, tools, permissions, metrics and backlog. The Orchestro core is shared. One cockpit, one river each. CContent Factory RunningBuild a useful, discoverable publication. Own goal · tools · permissions · history PProduct Reliability Waiting for evidenceKeep critical product journeys working. Own goal · tools · permissions · history SSales Factory Needs youDevelop a qualified pipeline within agreed limits. Own goal · tools · permissions · history CCustomer Support RunningTurn recurring questions into better service. Own goal · tools · permissions · history ORCHESTRO CORE · SHAREDCanonical intake · permissions · work selection · independent verification · durable history Illustrative workspace states. Content and Reliability are real pilots; Sales and Support are further domains to validate, not generally available products. REAL PROJECT · DANIELEPELLERI.COM ## A real Factory. Actual published work. 01 / Configure The original Content Factory was manually configured, before goal-based bootstrap landed. 02 / Produce Factory run branches produced articles and site changes, including broader article coverage in the site’s LLM index. 03 / Improve the system Framework work added stricter capability readiness and closeout rules for delivered work that remained open. 04 / Validate after release Each publication registers the metric it should move: Search Console clicks and impressions against its own baseline. The check runs after release; until the data arrives, the result stays open. [Pillar article01Building the Autonomous CompanyA long-form guide connecting real failures, operating loops and designed control.Publication commit f40812fMetric check at +28 days · open](https://www.danielepelleri.com/blog/building-the-autonomous-company)[Engineering story02Il retry che riceveva per sempre la riga mortaAn evidence-led article about an idempotency key that kept returning a failed job.Publication commit 3a9e1bfMetric check at +28 days · open](https://www.danielepelleri.com/blog/idempotenza-retry-riga-morta)[Product lesson03Quando le pagine di marketing promettono ciò che il prodotto non faA published account of finding and correcting unsupported product claims.Publication commit 51a52d8Metric check at +28 days · open](https://www.danielepelleri.com/blog/claim-marketing-non-provate-debito-affidabilita) Publications and Git history checked 4 October 2026. Output is proven here; audience growth, conversion lift and fully hands-off operation are not inferred. ## Autonomy has operating rules. ### Waits keep their context Waiting has a reason and a way back. It need not freeze unrelated work. ### Verification is independent The worker produces a result. A separate check decides whether the evidence is sufficient. ### Learning stays governed History can inform new work. Governor, Critic and bounded experiments keep decisions within authority. ## What you can use. What we’re building. Product snapshot · 4 October 2026 Real pilots today Local Factory loops, durable work, independent checks, CLI operation, Reliability and Content cases. Private access with project-specific setup. Private core Goal scaffold, Domain Builder / Compiler V1, capability reconciliation, cloud publishing, owner cockpit, hosted MCP and governed intent processing. Implementation is not a public self-service launch. In development Self-service chat onboarding, public installation and broader domain validation. No claim of a finished autonomous SaaS. ## Execution stays with the project. YOUR COMPUTERThe Factory does the work.Agents · repository · tools · evidence CLOUD CONTROL PLANEDirection travels. History stays.Intents in · status and receipts out YOUR PHONE & CHATYou stay in the loop.Cockpit + ChatGPT / Claude · in development ### And everything still has a command. CLI, MCP and web are designed around the same project identity and history. The web is a view into the Factory, not a second backlog. CLIyou run it from the terminal MCPyour chat asks and adds requests Webthe cockpit shows the river ↳ one project · one history [Explore the CLI reference →](https://www.orchestro.org/docs/tools) northstar · packs/content-factoryillustrative output $ northstar readiness --pack packs/content-factory ✓ 5 capabilities ready · 1 needs authority $ northstar checkpoint --pack packs/content-factory next: Linking P2 · eligible $ northstar run --pack packs/content-factory running on Codex · receipt recorded $ northstar watch --pack packs/content-factory watching · next cycle in 15 min $ northstar cloud status --pack packs/content-factory connected · last sync 12 s ago $ northstar stato --pack packs/content-factory 3 shipped today · 1 waiting for you ## Give one project a goal. Build its loop. You set the direction. The Factory keeps the project moving. [Get early access](https://www.orchestro.org/early-access?track=build)[Read the docs](https://www.orchestro.org/docs) Private preview · hands-on onboarding · your agents and tools --- Source: https://www.orchestro.org/how-it-works Updated: 2026-10-08 HOW ORCHESTRO WORKS # Simple on the surface. A system underneath. You ask a question. Set a goal. Give it direction. Follow what the Factory does with it. CHOOSE YOUR DEPTH 1. [01“Are there new product bugs?”](https://www.orchestro.org/how-it-works#signals) 2. [02“Build a Factory for this goal.”](https://www.orchestro.org/how-it-works#build) 3. [03“How is my backlog?”](https://www.orchestro.org/how-it-works#backlog) 4. [04“Why isn’t this moving?”](https://www.orchestro.org/how-it-works#waits) 5. [05“What is it doing now?”](https://www.orchestro.org/how-it-works#now) 6. [06“Fix this.”](https://www.orchestro.org/how-it-works#requests) 7. [07“Did this issue come back?”](https://www.orchestro.org/how-it-works#recurrence) [Open the system ↓](https://www.orchestro.org/how-it-works#signals) 01 /“Are there new product bugs?” ## What matters. What is noise. What needs you. Your domain decides which sources to read. Similar reports can share a work identity; similarity alone does not prove a shared cause. WHAT YOU SEEIllustrative grouping · no live counts Implemented · domain dependent [Technical reference ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/src/kernel/lifecycle.ts) 1. 01Declared sources 2. 02Normalize signals 3. 03Stable identities 4. 04Evidence & causal families 5. 05Material work 6. 06Owner answer Reliability adapters can interpret feedback and production evidence. Family membership needs canonical evidence; a distinct database failure must remain distinct. Raw inputs retain their provenance. No source is universally connected by default. 02 /“Build a Factory for this goal.” ## One goal. A work system built around it. Start with northstar init. It creates a scaffold; the Domain Builder and readiness gates determine what is ready to run. WHAT YOU SEE local terminal · scaffold $ northstar init \\ --dir packs/content-factory \\ --slug content-factory \\ --goal "Build an evidence-based content system" scaffold→Domain Builder→readiness gates→ready to run Implemented · governed bootstrap [Technical reference ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/src/commands.ts) 1. 01Goal 2. 02Domain manifest 3. 03Capabilities & sources 4. 04Tools & permissions 5. 05Evidence & verification 6. 06Initial work 7. 07Readiness The pack defines work types, measurable goals, source adapters, guardrails, autonomy and executor posture. Bootstrap reconciles capabilities against the canonical map before READY. Credentials and integrations still require configuration. The original Content Factory was manually configured. 03 /“How is my backlog?” ## Show me what matters now. Actionable work, current execution, evidence waits, owner decisions and outcomes each have a place. A large count is not a measure of progress. WHAT YOU SEEOwner categories · counts come from the selected project Live private preview · two connected projects [Technical reference ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/apps/cockpit/lib/model.ts) 1. 01Project identity 2. 02Latest snapshot 3. 03Work projection 4. 04Receipts + intents 5. 05Lifecycle reconciliation 6. 06Owner view Every cloud read is scoped to the selected project. The local publisher derives work state from canonical backlog and receipts. An accepted request is not execution. ARVO and Content never share a backlog merely because titles look alike. Unknown or stale state stays visible. 04 /“Why isn’t this moving?” ## Know the wait. Know the way forward. Autonomous does not mean never blocked. Know what is blocked, who can resolve it, and which evidence allows work to resume. WHAT YOU SEE ILLUSTRATIVE · EVIDENCE WAITWaiting for evidence Reproduction needed Affected work This investigation Needed A reproducible failure Wakes when New evidence is accepted Wider scope must be recorded. Independent work continues only when permitted. Implemented · historical gaps remain explicit [Technical reference ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/src/owner-interruptions.ts) 1. 01Canonical interruption 2. 02Category 3. 03Item / mission / Factory scope 4. 04Required action or evidence 5. 05Resolution receipt 6. 06Resumption evidence OWNER, EXTERNAL, PROVIDER, EVIDENCE and RUNTIME / INFRA are different causes. Scope is shown only when recorded. Older receipts may not establish mission scope or human involvement. A fallback receipt proves an executor handoff; later progress must prove that work continued. 05 /“What is it doing now?” ## One current task. A reason. Real progress. See the active executor and the last durable result separately. An alive process can still be making no measurable progress. WHAT YOU SEE ILLUSTRATIVE OWNER VIEWRunning NowInvestigate a startup failure Why Only a recorded selection reason Executor Observed local worker Progress Last durable receipt, not heartbeat Implemented · observed runtime in cockpit [Technical reference ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/src/checkpoint.ts) 1. 01Checkpoint 2. 02Actionable work 3. 03Selector 4. 04Authority check 5. 05Single execution seat 6. 06Executor 7. 07Durable receipts The watch wakes the Factory. The selector chooses eligible work within authority. The execution seat protects the local loop. Executor liveness, wake schedule and durable progress are separate signals. Selection rationale is shown only when published, never invented from a title. 06 /“Fix this.” ## Your request enters the system. It does not skip the system. Chat expresses intent. The local Factory accepts or rejects it, converges it with existing work where appropriate, then chooses when it is eligible. WHAT YOU SEEIllustrative conversation · configured MCP client Fix this before the release. **ORCHESTRO**Received in cloud.Awaiting local materialization. backlogAfter local acceptance → canonical work identity The conversation ends. The request remains. Private preview · client setup required [Technical reference ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/apps/cockpit/lib/cloud.ts) 1. 01Chat / MCP intent 2. 02Cloud receipt 3. 03Local pull 4. 04Canonical intake 5. 05Selection & execution 6. 06Independent verification 7. 07Cloud readback MCP can append project-scoped intake, roadmap priorities and supported Advisor decisions. Local pull materializes canonical work. Executors change the project; verifiers evaluate evidence; the ledger remembers. Execution-gate decisions still need the supported local resolution path. A connector installed in ChatGPT or Claude is a separate setup step. 07 /“Did this issue come back?” ## Keep the recurrence. Refine the response. A fix does not erase the problem’s history. New evidence can reopen work and motivate a refinement. WHAT YOU SEEILLUSTRATIVE LIFECYCLEThe previous fix stays in history. Implemented · governed learning [Technical reference ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/src/kernel/lifecycle.ts) 1. 01Fix 2. 02Independent check 3. 03New contradictory evidence 4. 04Recurrence / reopening 5. 05Durable lesson 6. 06Governed next work Canonical receipts preserve earlier fixes and new evidence. Strategic memory can carry lessons into future work. Framework retrospectives propose changes; they do not grant themselves authority to modify policy. A proposal, an adopted rule and a verified improvement are different facts. THE OWNER COCKPIT ## Five views. And a time machine. One screen per question an owner actually asks. The screens below use sample data; the interface is in Italian. [![Orchestro owner cockpit, Map view with sample data: What is the Factory doing right now?](/images/cockpit/map.webp)![](/images/cockpit/requests.webp)![](/images/cockpit/backlog.webp)![](/images/cockpit/product.webp)![](/images/cockpit/data.webp)![](/images/cockpit/time-machine.webp)](https://www.orchestro.org/images/cockpit/map.webp)Sample data [Play the simulation](https://www.orchestro.org/live/demo)[See real Factories ↗](https://www.orchestro.org/live) SAME KERNEL. DIFFERENT DOMAIN PACK. ## The project changes. The operating rules don’t. The pack teaches the kernel what sources, tools, evidence and outcomes mean here. REAL HISTORICAL DOMAIN ### Product / Reliability Reduce material product risk. * Feedback * Incidents * QA * Release evidence ARVO provided the original reliability experience. Its public cloud view is coming online; no live release-readiness number is implied. REAL PROJECT · CURRENT READ MODEL ### Marketing / Content Build a compounding content system. * Research * Writing * SEO * Publishing danielepelleri.com has published outputs. Observed execution and measured audience growth are separate facts. IMPLEMENTED PROOF · NOT A LIVE SALES PILOT ### Sales / Revenue Keep qualified opportunities moving. * Pipeline * Follow-ups * Qualification * Revenue outcomes The cross-domain sales proof exercises the shared kernel. Live CRM connections and commercial outcomes are not claimed. SHARED KERNELWork · evidence · independent checks · operating rules THE GOLDEN RULES ## Why the answer can be trusted. 01 Content≠ARVO ### One project identity Content work stays with Content. Switching to ARVO must change every read. UNDER THE HOODProject predicates + assertScope[Read the implementation ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/apps/cockpit/lib/model.ts) 02 Seat taken→2nd worker waits ### One execution seat A second worker cannot simply take the same local seat. UNDER THE HOODCanonical lease and authority checks[Read the implementation ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/src/checkpoint.ts) 03 Received in cloud≠Executed ### Intent is not execution “Received in cloud” still means the Mac may not have read it. UNDER THE HOODIntent receipt → subsequent work projection[Read the implementation ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/apps/cockpit/lib/model.ts) 04 Merged≠Reached users ### Merged is not deployed A merge receipt does not prove the release reached users. UNDER THE HOODSeparate merge, deploy and verification receipts[Read the implementation ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/src/kernel/lifecycle.ts) 05 “Finished”≠Verified ### The worker cannot certify done An executor’s “finished” is not an independent verdict. UNDER THE HOODVerifier boundary and evidence requirements[Read the implementation ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/docs/constitution.md) 06 Parked→Wakes on evidence ### Waiting is a real state Missing evidence keeps work parked with a wake condition. UNDER THE HOODEVIDENCE\_PENDING + evidence plan[Read the implementation ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/src/kernel/lifecycle.ts) 07 1 blocked+Others move ### A blocked item need not stop everything Independent work can continue when the authority and selector permit it. UNDER THE HOODCheckpoint scope, dependencies and eligibility[Read the implementation ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/src/checkpoint.ts) 08 Phone reads·Mac operates ### Cloud guides. Local executes. Your phone reads state; your machine operates the repository. UNDER THE HOODPublisher + intent pull + canonical intake[Read the implementation ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/apps/cockpit/lib/cloud.ts) 09 Configured≠Fresh ### Configured is not live A configured publisher is not proof of a fresh observation. UNDER THE HOODObservation timestamps and stale state[Read the implementation ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/apps/cockpit/lib/model.ts) 10 Delivered\=Closed locally ### Done must reconcile External delivery and local lifecycle must agree. UNDER THE HOODCanonical closeout and reconciliation[Read the implementation ↗](https://github.com/khaoss85/agentic-factory/blob/e403c410c9fd94a24eeb20de108f4e1f06fc9010/src/kernel/lifecycle.ts) THE COMPLETE LOOP ## Three flows. One project history. Cloud holds observations and intent. The project’s local Factory owns execution and durable evidence. No chat session becomes the source of truth. ### Observe 1. 1Sources 2. 2Domain adapters 3. 3Canonical evidence 4. 4Cloud read model 5. 5Web / MCP readback ### Direct 1. 1Chat client + MCP 2. 2Cloud intent 3. 3Local pull 4. 4Canonical intake / decision 5. 5Eligible work ### Execute 1. 1Backlog / roadmap 2. 2Selector + Governor 3. 3Local executor 4. 4Independent verifier 5. 5Ledger / governed learning ## Now see a real Factory. Current observations, with their age and limits made visible. [Open Live Factories →](https://www.orchestro.org/live)[Explore bounded experiments & deeper examples ↗](https://www.orchestro.org/docs/operating-examples) --- Source: https://www.orchestro.org/live Updated: 2026-10-04 LIVE FACTORIES # Real projects. Visible progress. See what Orchestro can publicly show about real Factories. Current observations come from the cloud read model, with their freshness made explicit. PRODUCT / RELIABILITY ## ARVO Turn user feedback and production evidence into verified work. Reduce material risk toward releases. CHECKING PUBLIC READ MODEL Now Loading a real observation. No sample data is shown. Last durable progress Not published Active blockers Not published Latest recorded outcome No public outcome available Public access is coming online. Availability is checked on page load. [Check public availability ↗](https://orchestro-cockpit.vercel.app/public/arvo) DANIELEPELLERI.COM ## Content Factory Research, write, publish and improve discoverability. Build a content system that remembers what it learns. CHECKING PUBLIC READ MODEL Now Loading a real observation. No sample data is shown. Last durable progress Not published Active blockers Not published Latest recorded outcome No public outcome available Public access is coming online. Availability is checked on page load. [Check public availability ↗](https://orchestro-cockpit.vercel.app/public/content) Public views are read only. Private work titles, owner requests, customer information and evidence stay private. “Running” means an executor was observed, not that a business outcome was achieved. Missing data is never replaced with simulated metrics. JavaScript is needed to refresh the cards. The public Factory links open server-rendered observations without JavaScript. SIMULATION · SAMPLE DATA ## Watch a software recovery. An agent claims done, an independent check rejects it, and interrupted work resumes from history. A 64-second simulation, separate from the real observations above. [Play the simulation](https://www.orchestro.org/live/demo) REAL HISTORICAL CASE · OCTOBER 2026 ## See the work it published. The Content Factory produced published articles on danielepelleri.com. These dated artifacts are historical proof, separate from the current status above. [Explore the Content Factory case →](https://www.orchestro.org/#real-case) ## Curious what happens underneath? Follow a signal, a request and a result through the same system. [How Orchestro works →](https://www.orchestro.org/how-it-works) --- Source: https://www.orchestro.org/live/demo Updated: 2026-10-07 ORCHESTRO / SOFTWARE RELIABILITY # “Done” is a verified state. Not an agent opinion. One failed release. A false completion. An interrupted session. See how Orchestro keeps the work, checks and next action connected. A 64-second interactive simulation, with sample data. No signup. INTERACTIVE DEMO · SAMPLE DATASoftware reliability / CHAT-17 01 / 08 ## A release is green. Chat is broken. The deployment completed, but a request to the released chat endpoint fails. Orchestro keeps the user problem open. YOUR CODING AGENT**Previous task: deployed**Executes the work ORCHESTRO**Investigate the failed outcome**OPEN INDEPENDENT EVIDENCE`Sample check: POST /chat → 500`Sample evidence, not a live receipt DURABLE HISTORYAttached the failed check to incident CHAT-17. Read the full walkthrough and its limits This is an illustrative scenario, not a product recording or proof of unattended production recovery. Recovery, checks and deployment depend on the project’s configured tools, authority, host and provider quota. The final sample check proves only the outcome shown; it does not establish a conversion or business improvement. 1. **A release is green. Chat is broken.** The deployment completed, but a request to the released chat endpoint fails. Orchestro keeps the user problem open. 2. **Two reports. One repair.** The log and support report point to the same missing dependency. Evidence links them to one job; a second agent does not start a duplicate fix. 3. **The agent says “done”.** The worker adds the missing package and reports success. That report triggers an independent check; it does not close the incident. 4. **The verifier finds what the agent missed.** A clean install still fails: the lockfile was not updated. The failed check becomes the next repair instruction, attached to the same history. 5. **The session ends. The work survives.** A configured recovery resumes from the durable checkpoint. The next worker sees the cause, rejected revision and remaining check instead of starting over. 6. **A fresh revision earns a fresh check.** The repaired lockfile passes a separate clean-install and chat check. Evidence belongs to revision B. Release still requires the project’s permission. 7. **Deployed. Still waiting for proof.** The authorized release is recorded. The incident stays open while the configured production check is pending; unrelated permitted work can continue. 8. **Now “done” has evidence.** The sample check passes on the released version. The incident closes for this defined outcome, and the dependency failure informs the next release check. Inspired by the failure modes that shaped Orchestro. [Read the real ARVO origin story](https://www.orchestro.org/story#the-night) or [inspect current public project observations](https://www.orchestro.org/live). Another domain: explore the Content Factory simulation Six sample signals, duplicate detection, separate inspection and owner decisions. Open to load the interactive example. FREE PREVIEW · HANDS-ON ONBOARDING ## One project. One problem you keep babysitting. Bring a recurring software issue and the coding agent you already use. We’ll review the fit, agree on the evidence and permissions, and help you set up a bounded private pilot. [Apply for a free pilot](https://www.orchestro.org/early-access?track=build)[Read the setup requirements](https://www.orchestro.org/docs/quickstart) Super private beta. Access is reviewed. You supply your agent subscriptions and infrastructure. 3 fields. No repo access or credentials needed. --- Source: https://www.orchestro.org/story Updated: 2026-10-04 OUR STORY · FROM ARVO TO ORCHESTRO # The project needed a memory. We started by asking agents to fix software. We ended up building the system that keeps the work moving after the conversation ends. [It started with a night of no progress](https://www.orchestro.org/story#the-night) 01 / THE RELIABILITY FACTORY ## The process was alive. Progress had stopped. On ARVO, our Reliability Factory investigated production problems, produced repairs, and checked the results. The hard part was keeping the whole operation moving. One night, a pull request waiting for an external review held the active slot. Each scheduled check found the same job. The process kept waking up. Useful work waited behind it. A heartbeat tells you a process is alive. Evidence tells you the project moved. ARVO · A night in the Reliability FactoryHISTORICAL ACCOUNT WAITING FOR REVIEWOne missing review. One occupied slot. 1. 1 · Work readyRepair submitted 2. 2 · External waitReview not yet available 3. 3 · Next checkThe same job still holds the slot Owner account, 2 October 2026. Retold for clarity; this is not live telemetry. THE RULE THAT CHANGED THE LOOP ## Keep its priority. Free its place. A critical job can still be the most important thing in the project when there is no permitted action to take. Keep its cause, evidence and return condition. Let independent, authorized work continue. That lesson became a product question: **what is blocked, who can unblock it, and what can still move?** A wait needs a scope. A recovery needs proof. Closing a blocker is not proof that execution resumed. [See Blockers & Recoveries in the loop →](https://www.orchestro.org/how-it-works#blockers) NEEDS YOUIllustrative owner view · scope must come from recorded evidence A product decision is pending. Blocks This mission Can continue Independent, authorized work Way back Record the decision, then check that work resumed ANOTHER LESSON FROM PRODUCTION ## “Deployed” was not the last word. A release on ARVO left out a dependency. Chat requests started failing. The release receipt existed; the user’s experience was broken. That is why merge, deployment and independent verification carry separate evidence. New production failures can change what matters next. A recurrence stays attached to its history when evidence proves the same cause. [How evidence changes the next cycle →](https://www.orchestro.org/how-it-works#learning) The loop continues after the worker says “done”. 02 / THE SECOND DOMAIN · 3 OCTOBER 2026 ## Same kernel. Different domain. We thought we were building a software factory. Then we used the same system to run the Content Factory for danielepelleri.com. Editorial and evidence work became durable backlog. The loop could select a job, use a coding agent, retain reviews and verify a published result. The work changed. The need for continuity did not. REAL PROJECT · REAL BACKLOG · REAL OUTPUT Reliability 1. Feedback→ 2. investigation→ 3. repair→ 4. verification Content 1. Evidence→ 2. thesis→ 3. article→ 4. review→ 5. publish→ 6. verify Work. Evidence. History.One ledger, lifecycle, selector and executor / verifier boundary. Each domain adds its own vocabulary, sources, tools and rules for done. WHAT STAYED THE SAME The Content Factory pilot was manually configured. It demonstrates reuse across two domains; it does not prove traffic growth, revenue lift, or effortless setup for every business. [Visit the real publication ↗](https://www.danielepelleri.com) The original pilot is a historical case. Today’s public observation is available separately, with its timestamp. [See the current Content Factory →](https://www.orchestro.org/live) 03 / THE PRODUCT TODAY · 4 OCTOBER 2026 ## Your agents are workers. The Factory keeps the history. Orchestro became the operating layer for persistent AI-agent loops around a goal. The Factory runs beside the project, on your Mac or server. The cloud holds observations and owner intent. The cockpit lets you see what happened without opening a terminal. Your machineExecute, verify and record durable evidence. Cloud + cockpitSee current work, freshness, requests and blockers. Chat + MCPExpress intent. Read back what the Factory actually did. evidence of what the Factory actually did comes back Conversation expresses intent. The Factory remains the authority. A request received in the cloud is not yet work consumed locally, and neither is a completed result. ### What you can see now The owner cockpit is deployed in private preview, including Blockers & Recoveries. Content has a public read-only projection. ARVO’s public cockpit is still **Coming online**. The private hosted MCP endpoint is deployed. A complete ChatGPT / Claude client setup and end-to-end owner conversation still need product acceptance. Goal scaffolding and Domain Builder / Compiler V1 are implemented; public self-service onboarding remains in development. An executor chain exists in code. Automatic provider failover and unattended Mac reboot recovery are not presented here as proven live stories. [Check the availability and evidence boundaries →](https://www.orchestro.org/docs/roadmap) AT A GLANCE * Owner cockpit, incl. Blockers & Recoveriesprivate preview * Content public read-only projectionlive * ARVO public cockpitcoming online * Hosted MCP endpointdeployed · private * ChatGPT / Claude end-to-end conversationneeds acceptance * Goal scaffolding · Domain Builder / Compiler V1implemented * Public self-service onboardingin development * Executor chainin code * Automatic failover · unattended reboot recoverynot claimed as proven WHAT WE CARRY FORWARD ## The lessons became operating rules. Historical lessons and design invariants. Each configured Factory still needs evidence that it meets them. 01 ### Running is not the same as progressing. A process can keep waking up without doing useful work. Measure durable progress and verified results separately from uptime and activity. 02 ### Important does not always mean ready. A critical repair waiting for traffic keeps its priority, cause and evidence. Selection also asks whether a permitted action is possible now. 03 ### Waiting work makes room. Save the reason and return condition, release execution capacity and select another actionable job. Waiting is not resolved; a review, new evidence or a due date can bring it back. 04 ### Every required gate has a way forward. A required external dependency must be controllable or parkable. An unavailable reviewer cannot hold the whole system. A separate reviewer checks the exact code revision; a changed revision needs a fresh check. 05 ### Yesterday’s answer has an expiry. The Critic revisits expected behavior, duplicates, declined fixes, previous cures and measurement gaps. New evidence can confirm the conclusion, require another check, reopen the same problem or leave an honest unknown. 06 ### Similar errors need proof of a shared cause. A matching failure signature, route and release context can suggest a family. Only evidence of the same mechanism justifies joining causes. Keep plausible groups, distinct causes, platform noise and unknowns separate. 07 ### A new production failure goes first. Watch after a release. A severe regression takes priority over ordinary work. Recovery or rollback still needs the project’s authority and its own verification. 08 ### Shipped is a milestone, not the finish. Merge, deployment, distribution and cure carry separate evidence. Check immediately, after an initial traffic window, later that day and at 24 hours where configured. A mobile build is not proof that users received a working release. 09 ### Every temporary test has an ending. Declare the question, baseline, start, due date, sample requirements, success/failure/inconclusive criteria, extension limit, cleanup and final decision authority. Adopt, reject or allow a bounded follow-up. At the limit, record insufficient evidence or ask for an explicit new investment decision. 10 ### More specialists. One shared history. Live sources feed the canonical ledger; selection and views derive from it. The Critic challenges conclusions, the Lab adds evidence and the reviewer adds a revision-bound receipt. None creates a competing scheduler, backlog or source of truth. 11 ### A restart must not erase the work. Reconstruct waiting and ready work from durable history. The current chat session is not the memory of the system. ARVO’s parking and restart tests informed this requirement; they are not proof of a fully adopted unattended production loop. 12 ### Health is more than a smaller task count. Ask what remains unexplained, urgent, stale, waiting without a limit, experimentally expired or released without timely verification. An explained open item can be legitimate. A quiet dashboard can still hide unresolved risk. ### ↳ What we mean by a healthy Factory Six design targets, not current live measurements: * Unexplained signals.0Know what each signal means, or the plan to find out.`UNEXPLAINED = 0` * Urgent work left ready.0Handle the critical work that can be acted on now.`ACTIONABLE_P0_P1 = 0` * Outdated conclusions.0Recheck decisions when their evidence gets old.`STALE_DECISIVE_JUDGMENTS = 0` * Waits without a limit.0Every wait has a reason and a way back.`UNBOUNDED_WAITS = 0` * Expired experiments.0End the test, make a decision and clean up.`EXPIRED_EXPERIMENTS = 0` * Overdue release checks.0Verify within the project’s agreed time limit.`UNVERIFIED_RELEASES_BEYOND_SLA = 0` THE EVIDENCE BOUNDARY ## A real origin. A dated account. This preserves what the incident taught us without turning a historical plan into today’s release claim. Current availability is documented separately. IMPLEMENTED AND TESTED · 2 OCTOBER 2026 The ARVO account was shared on **2 October 2026**. Parking, releasing the active slot and reconstructing work after restart had been implemented and tested there. * Parking * Releasing the active slot * Reconstructing after restart STILL INCOMPLETE AT THAT CHECKPOINT Full production adoption was still incomplete at that historical checkpoint: database migration, GitHub wake events, production release and parts of experiment and post-release monitoring remained. NEXT TEST, NOT A BENCHMARK The proposed 36–72-hour unattended run was a next test, not a completed autonomy benchmark. [What is available today →](https://www.orchestro.org/docs/roadmap) YOU SET THE DIRECTION. ## The Factory keeps the project moving. [See a real Factory](https://www.orchestro.org/live)[How Orchestro works](https://www.orchestro.org/how-it-works)[Bring your project](https://www.orchestro.org/early-access?track=build) --- Source: https://www.orchestro.org/early-access Updated: 2026-10-04 SUPER PRIVATE BETA · FREE PREVIEW # One project. One problem you keep babysitting. Already using coding agents heavily? Bring a recurring software issue. Let’s see whether Orchestro can make that loop more reliable, with hands-on setup and clear evidence. ## Apply for a free pilot Three fields. No credentials or repository access needed. Email Your coding agentChoose an agentCodexClaude CodeGrokOther What do you keep checking or fixing? Leave this empty You can contact me about this preview and my feedback. [How we handle this request.](https://www.orchestro.org/privacy) Please don’t include credentials, customer data or private source code. This form needs JavaScript. You can request access using the email link below. Prefer email? [Send your agent and the problem.](mailto:daniele.pelleri@gmail.com?subject=Orchestro%20%E2%80%94%20early%20access&body=Hey%20Daniele%2C%0A%0AI%27d%20like%20to%20try%20Orchestro.%0A%0AMy%20project%3A%20%0AMy%20coding%20agent%3A%20%0AWhat%20I%27d%20like%20to%20loop%3A%20) ## What the pilot includes * Private Orchestro access and hands-on setup for one agreed project. * A defined failure or workflow, the evidence to check it, and explicit operating limits. * Direct feedback on blockers and what still needs your intervention. Start by email; a call is optional. ## What you bring A software project you maintain, a supported coding agent, an available Mac or server, and a test, log or check we can use. Start in observation mode; agree on permissions before enabling repairs or releases. Current repair workers: Claude Code, Codex and Grok. Other agents can be discussed, but are not promised as supported. [Check compatibility.](https://www.orchestro.org/docs/agents) ## What happens after you apply 1. 01 **Fit:** Daniele reviews your project and replies by email with questions or a proposed scope. 2. 02 **Setup:** if the pilot is a fit, we agree on access, host, evidence and permissions. GitHub details come at this stage. 3. 03 **First loop:** inspect what ran, what was verified and what still needs a human. Use that evidence to decide the next step. The preview is free. You pay for your own agent subscriptions, usage and infrastructure. Access is reviewed, not instant. Orchestro has primarily been used on our own internal projects. --- Source: https://www.orchestro.org/privacy Updated: 2026-09-30 PRIVACY · DEVELOPER PREVIEW # Your developer-preview request. When you apply for Orchestro access, Daniele Pelleri, building Orchestro at Aetha, receives your email, selected coding agent and the project or problem you describe. We record the build or grow track from your entry point. Older forms may also include a GitHub username and optional problem or loop details. We also record the submission time and campaign source, when supplied. ## Why we collect it We use this information to review your request, arrange repository access and discuss your preview experience. Applying does not subscribe you to a marketing newsletter or automatically grant access. ## Where it goes The application is stored in private Vercel Blob storage in the Frankfurt region. It is accessible to the project’s authorized operators, not published on the website. Replies are handled by email; an approved invitation is handled through GitHub. We do not publish your feedback or project details without your agreement. So that a request is not left unread, a summary of new applications is sent to the operator by email. A copy of what you submitted therefore also passes through Google’s Gmail. The application itself stays in the private storage described above. ## Keeping or removing your request Contact [daniele.pelleri@gmail.com](mailto:daniele.pelleri@gmail.com) to update your request, withdraw it, ask for a copy or request deletion. We keep application information while reviewing access and supporting your participation; you can ask us to remove it at any time. Please submit only a description you can share. We do not need project credentials, customer records or private source code. [Back to the developer preview](https://www.orchestro.org/early-access) --- Source: https://www.orchestro.org/docs/operating-examples Updated: 2026-10-04 Documentation · illustrative operating examples # One kernel. Every domain keeps its proof. The kernel manages persistent work, evidence, authority and independent verification. Each domain supplies its own work model, tools and definition of done. [Watch a day in the loop](https://www.orchestro.org/?case=product#loop) [Try the interactive loop](https://www.orchestro.org/demo?case=product#loop-demo) [Explore the rules](https://www.orchestro.org/docs/operating-examples#loop-rules) Operating model and illustrative examples. [Check current availability.](https://www.orchestro.org/docs/operating-examples#availability) Explore the longer product and campaign stories Illustrative operating models Illustrative product operating model ## A healthier product. A review is pending. An old bug needs a fix. A new release is about to surprise you. Follow the work through one illustrative morning. [Explore the interactive events](https://www.orchestro.org/demo?case=product#loop-demo) 07:00 ### Waiting is a state. Work keeps moving. The search fix needs an independent review. Orchestro saves its context, priority and evidence, then frees the active slot. The next useful job can start immediately. Search fix: waiting for review. Checkout bug: now active. 07:01 ### 37 reports. One thing to fix. Different error messages point to the same checkout timeout. Orchestro proves which reports share the same mechanism, then coordinates one fix, independent review and release. Similarity alone is not enough. One underlying cause gets one investigation and one repair. 08:15 ### When production breaks, priorities change. After the release, monitoring spots a burst of server errors. A new regression takes priority over routine backlog work. Orchestro investigates the cause and prepares a repair within the project’s permissions. Urgent recovery moves first. The other work keeps its place. 09:00 ### The fix is live. Proof takes time. The regression fix is released, but needs 60 minutes of real traffic before it can be called resolved. Orchestro parks that verification and resumes the backlog. A release alone is never proof of recovery. Waiting for traffic frees the next job to run. 10:00 ### The moment it’s ready, it’s back. The search review arrives. Its saved work becomes actionable again: checks pass, then merge, release and verification. Separately, the regression’s traffic window can now be evaluated against its recovery criteria. An event wakes the right job. It never had to hold up the morning. 10:30 ### Even yesterday’s answers get checked. An old error was classified as expected behavior. Twelve new occurrences look different. The Critic challenges that conclusion, reopens the investigation and checks whether this is the same cause or something new. A past decision stays open to new evidence. 2–9 Oct ### Every experiment has an ending. A test has a baseline, at least 50 samples and a seven-day deadline. In this example, failure below 1% means adopt; above 3% means reject. The middle band or too little evidence means inconclusive, with at most one bounded follow-up. When the follow-up ends, decide or record insufficient evidence. Clean up temporary instrumentation. The result ### A healthier product. And the next useful job. The checkout works again. The urgent regression has passed its traffic checks. The reviewed search fix has its own release evidence. Open questions remain visible, and Orchestro selects the next actionable job. The goal is to keep your product healthy, continuously. Illustrative scenario. Scroll to follow the work. Illustrative campaign operating model ## A better campaign. A creative is waiting for approval. A landing page needs work. Results need time to mature. The same loop, with different tools, evidence and limits. Design-partner example. [Explore the interactive events](https://www.orchestro.org/demo?case=campaign#loop-demo) 09:00 ### Approval pending. Progress continues. A new creative needs your approval. Its context stays saved while the team investigates a landing-page problem within the already approved scope. Waiting for a human decision never grants permission to publish. 09:15 ### Many weak ads. One broken destination. Several ads show the same drop after a click. The evidence points to a broken mobile form on their shared landing page. One verified repair can address the shared cause. Investigate the common cause before rewriting every ad. 10:00 ### Protect the budget first. A broken campaign link appears while ads are spending. The loop prioritizes it, pausing the affected delivery only where that permission was granted. New spending still needs your decision. Act within agreed budget and publishing limits. 11:00 ### Let results mature. Keep working. The repaired form passes a separate functional check. Measuring conversion needs a mature cohort and the agreed attribution window. That measurement waits while another approved task moves forward. A working form and better conversion are separate conclusions. 14:00 ### Approved. Ready to move. Your creative approval arrives. The saved work resumes with a quality check, publication within the approved budget and a separate delivery check. The approval wakes that campaign, with its original limits intact. Next day ### A winner stays a question. Yesterday’s best creative starts attracting a different audience. The Critic checks cohort, spend, tracking and attribution before deciding whether the old conclusion still holds. Observed improvement is not automatically a causal lift. Day 7 ### Close the test. Keep the learning. The experiment reaches its declared deadline. Evaluate the target metric, sample requirement and guardrails. Adopt, reject or record inconclusive, with at most one bounded follow-up. More time never appears by default. No endless test, no silent spend increase, no invented winner. The result ### A campaign you can account for. The form works. The creative is approved and live. Budget decisions have an owner. Conversion remains a measured question until comparable, mature evidence supports a conclusion. Every action has a reason. Every result has evidence. Illustrative scenario. Scroll to follow the work. What if a release fails? A failed release stays failed, even when code is merged. Use a bounded retry, an authorized rollback or a technical repair. If a new release harms production, rollback is a first-class recovery option. Then select the next useful job. What if the sources disagree? If the work history, repository and production disagree, stop changes to that affected item. Record the authority conflict, repair the evidence and keep other independent work moving. What if a solved problem returns differently? Investigate whether the new failure shares the original cause. Reopen the same causal boundary when it does; create a new one when it does not. Similar symptoms alone are not proof of a shared cause. What if there is never enough evidence? An inconclusive test can have at most one bounded follow-up in these examples. At the limit, record not measurable or insufficient evidence, or request an explicit owner decision about further investment. Remove temporary instrumentation. Compare Reliability and Content Interactive simulation orchestro / mission controlInteractive simulation · sample data Same kernel. Same rules. Mission ### Keep checkout working. Checkout service · approved repair scope 1. 1Observe 2. 2Understand 3. 3Select 4. 4Strategize 5. 5Execute 6. 6Verify 7. 7Learn 8. 8Next work Durable work Context stays with the job Active**Repair checkout timeout**Kernel stage: Observe Waiting**Search fix · review pending**Saved context · wakes when evidence arrives Later in this cycle**Discover the next useful job**The mission continues beyond this task 1 / 8 · Observe #### The system finds work. Monitoring spots failed checkouts. The mission stays active even when nobody is writing a prompt. **Observed failure**Example * Checkout request → timeout * Customer cannot complete an order * Source: example application monitor Simulated receipt Signal saved with source and affected behavior. Test the boundaries Read both domain walkthroughs #### Software reliability: Keep checkout working. 1. **Observe: The system finds work.** Monitoring spots failed checkouts. The mission stays active even when nobody is writing a prompt. 2. **Understand: A symptom becomes a question.** The investigator reproduces the timeout and links it to an exhausted connection pool. Similar-looking reports still need evidence. 3. **Select: Pick what can actually move.** Checkout is actionable. The search fix keeps its priority and history while waiting for an independent review. 4. **Strategize: The agent chooses the method.** It plans a focused repair and a regression test. The kernel checks the affected service, allowed changes and run budget. 5. **Execute: Make the change. Keep the proof.** The worker prepares the fix. In this scenario, green review gates permit a release. Deployment is recorded; the job remains open. 6. **Verify: A separate check decides.** The verifier checks the released checkout against the original failure and the agreed observation window. The worker cannot certify itself. 7. **Learn: Keep the lesson, with its limits.** The repair history records the retry failure and its regression check. A project lesson is not automatically a universal kernel rule. 8. **Next work: One job ends. The mission continues.** A slow order confirmation becomes new work. The repaired checkout keeps its evidence; the search review still has its place. #### Content operations: Run an evidence-led publication. 1. **Observe: The system finds material.** Evidence mining finds a lesson in project notes. The mission is to run a publication, not just generate one article. 2. **Understand: Build a thesis you can defend.** The domain checks novelty, source quality and relevance. A promising idea becomes work with explicit editorial acceptance criteria. 3. **Select: Choose the next useful article.** This article has enough source material to proceed. A previous article waits for its measurement window without blocking new work. 4. **Strategize: Same rules. A different plan.** The agent chooses the outline, examples and internal links. The domain adds voice, factual and adversarial review requirements. 5. **Execute: Create, review, then publish.** The draft passes its editorial gates. The publishing adapter acts within existing authorization. A publication receipt is still not proof of a good outcome. 6. **Verify: Read what actually went live.** A separate check reads the published page and verifies the text, sources and links. Traffic and commercial impact remain a later question. 7. **Learn: Learn without inventing a winner.** Record the editorial lesson now. Evaluate audience response only when a defined measurement window supplies enough evidence. 8. **Next work: The article creates the next question.** An unanswered reader question becomes research work. The article keeps its sources, reviews and publication evidence in the same history. A guided model of the two domains, not a live dashboard. No code is deployed, no content is published. Switch domains at any stage to compare the same kernel. What is Orchestro? ## The mission changes. The machinery doesn’t. A runtime for autonomous operations: persistent work, evidence and memory let agents maintain a mission across tasks, sessions and releases. ### The kernel keeps the rules. Durable backlog and memory. Work lifecycle and selection. Evidence, execution and independent verification. Governor, authority boundaries and learning records. **Shared across domains** ### The domain defines the work. What a job is. What evidence matters. Which tools can act. The policy, verification rules and conditions that make a job complete. **Reliability: a verified repair. Content: a checked publication, with impact measured separately.** ### Cloud guides. Governor supervises. Factory executes. Evidence decides. The architectural direction separates a cloud control plane for domains, work, intent, health and receipts from execution on a local or cloud host. Private cloud capabilities exist; a complete hosted, self-service SaaS is still in development. [Cloud architecture and current limits](https://www.orchestro.org/docs/mcp#cloud-factory) The building blocks ## One core. Your kind of work. The core keeps the rules. A project pack brings your goals, tools and checks. The agents do the work. Each part adds a function. All share one history. Read every block and its examples + ### Core: the shared rules The core coordinates the loop: read evidence, choose permitted work, keep its history and require a check. The kernel is the central machinery inside that core. So each new project inherits the rules instead of inventing another scheduler. **Product:** Select a checkout repair only when the evidence and permissions allow it. **Marketing:** Apply the same work-and-evidence rules to a campaign, with the project’s own approvals. Shared private kernel, reused by Reliability and the manually configured Content Factory pilot. ### Project pack: your project’s rules A pack defines the project’s sources, goals, tools, checks, release surfaces and permissions. The core reads this configuration; it does not guess how your business works. So different projects can share a core without sharing credentials, budgets or authority. **Product:** Runtime errors, a repository, checkout tests and web or mobile release checks. **Marketing:** Campaign signals, approved creative, spending limits and a mature measurement window. Configured per domain. Content has a real pilot; the campaign example here and a ready-made pack marketplace are not shipped integrations. ### Agents & tools: do the work A supported agent receives a bounded task and the tools the project allows. Providers and subscriptions can change without becoming the owner of the work’s history. So the system can use your tools while keeping scope, cost and permissions explicit. **Product:** Investigate the reproduced failure and propose a focused repair. **Marketing:** Prepare an approved creative variant or repair the landing page within scope. Depends on configured adapters, an available host and your agent quota. ### Independent checks: prove the result The agent’s report is not the verdict. A separate review checks the exact revision; release verification checks what users actually receive. A required check must be controllable or allow the job to wait safely. So a finished task cannot quietly turn into an unproven success claim. **Product:** The original checkout failure passes on the released version, with enough real traffic. **Marketing:** The approved creative is delivered and its destination works. Conversion improvement needs separate evidence. Checks and review authorities must be configured. A demo receipt is not live proof. ### Shared history: remember what is true Sources and durable receipts record what happened. Ready work, waits and views are reconstructed from that canonical history, rather than the memory of one agent session. So another agent or a restarted process does not have to invent the state again. **Product:** Keep the same cause, review, release evidence and traffic wait together. **Marketing:** Keep the approval, delivery receipt and measurement window tied to the same campaign. Durable history is a foundation. ARVO’s demonstrated parking recovery informs Orchestro’s broader target. ### Specialists: question and improve The Governor handles operating limits and stalls. The Critic questions old conclusions. The Lab runs tests with an end date. Each adds a function to the same loop. So learning and supervision improve the system without creating shadow backlogs. **Product:** Reopen an old classification when new errors contradict it; end an inconclusive test. **Marketing:** Recheck yesterday’s winning creative against a changed audience; retire an expired experiment. Roles in the operating model. Complete continuous learning and unattended recovery remain roadmap. An explanation of the architecture, not an installation screen. [How project connections work](https://www.orchestro.org/docs/mcp) · [Current availability](https://www.orchestro.org/docs/roadmap) ## The path behind the progress. A waiting item leaves the active slot. An urgent regression changes the priority. The whole portfolio keeps moving. 1. 01 ### Notice Errors, feedback, QA and post-release monitoring supply the evidence. 2. 02 ### Understand Group reports by cause. Explain noise. Give unknowns a bounded evidence plan. 3. 03 ### Choose Select actionable work. A serious production regression takes priority. 4. 04 ### Investigate & repair Reproduce the failure and fix its cause within the project’s permissions. 5. 05 ### Review independently A real finding needs reproduction, a fix and another review. No self-certification. 6. 06 ### Release Record merge, deployment and distribution separately for each release channel. 7. 07 ### Watch Check the release immediately and over time. Recover or roll back within authority if it regresses. 8. 08 ### Verify Require released behavior and the agreed evidence window before declaring a cure. 9. 09 ### Choose again Resume the next useful job. Retain evidence and watch for recurrence. ### Park. Wake. Resume. Review unavailable, traffic still maturing or a decision pending: save the work and its wake condition. Return it to selection when it becomes actionable. ### Keep questioning the answer. The Critic can challenge a duplicate, an expected behavior classification or a claimed cure when new evidence contradicts it. Why these rules exist: [what running a Reliability Factory on ARVO taught us](https://www.orchestro.org/story). The technical lifecycle below uses the product example. ## Every signal has a next step. First decide what the evidence means. Only actionable work enters the repair path; the other routes keep their context and conditions. ### Expected or platform noise **Explain and observe** Keep the evidence. Do not invent a product fix. ### Duplicate or known cause **Join its history** Attach the signal to the canonical cause. If cured, check recurrence first. ### Unknown **Plan the evidence** Declare baseline, sample target, due date and success, failure or inconclusive criteria. Park until due. ### Product bug **Investigate and repair** An actionable cause can enter the repair loop within existing authority. ### Feature gap **Resolve the product decision** Get a direction decision where needed before starting implementation. ### Operations or cost **Check the operational gate** Respect spending, infrastructure and recovery limits. ### Owner or policy **Ask the right person** Record a real permission decision. Keep independent work moving. **200 events do not mean 200 fixes.** 150 occurrences of one timeout + 30 platform-noise events + 15 occurrences of another regression + 5 unknowns become two identified causes, explained noise and five open questions. Keep every event linked to its evidence. ## Release starts the watch. Use the observation windows configured for the project. A serious regression can interrupt ordinary work at any point; waiting for a sample frees the active slot. 1. **Immediately** Check release health 2. **Around 1 hour** Evaluate early traffic 3. **Several hours** Check sustained behavior 4. **24 hours** Reconfirm the outcome ## Verification chooses the way forward. Each outcome returns to selection. A cure stays open to future evidence; the Critic can challenge any conclusion. Cured Record independent proof, keep watching, select the next job. Same cause returns Reopen the original boundary and keep its repair history. New cause Open a distinct boundary; retain the evidence linking the symptoms. Failed Return to remediation, review and the relevant release path. Inconclusive Create a bounded follow-up within the extension limit; otherwise record insufficient evidence. Expected or not a product issue Change the diagnosis when evidence supports it. The Critic may challenge it later. [Try these events in the demo](https://www.orchestro.org/demo?case=product#loop-demo) [See the same model for a campaign](https://www.orchestro.org/factory?case=campaign#campaign-loop) ## From an active task to a verified result. Inspect a checkout repair in Web, Chat + MCP or CLI. Follow its evidence through a technical wait, release and independent verification. All data is illustrative. Example **Mobile checkout** One job. Explore it in three surfaces. Ready to investigate ### Two reports. One piece of work. QA and user feedback point to the same checkout failure. Keep the reports together and investigate the cause. QA finding Checkout cannot be tapped on mobile Safari. User feedback “I fill in my address, but I can’t pay.” **Governor No decision needed** Work is within the project’s approved scope. Investigation can start. Repair in progress ### Reproduce it. Then fix the cause. The keyboard covers the checkout button. The coding agent adjusts the layout and adds a regression test. Reproduction Fails with the keyboard open in mobile Safari. Change Keep the payment button inside the visible area. **Governor No decision needed** The coding agent has a bounded task, a reproducer and a success check. Waiting for CI ### Wait for CI. Keep other work moving. Checks fail before release. The Governor parks this item and lets other authorized work continue. This task Waiting for green checks. No merge or release. Other work The settings copy task can continue. **Governor Not escalated** Wait for green. Keep the release gate. Continue independent work. Released · check pending ### Live is a milestone. Check the result. CI passes. Within this example’s existing release permission, the reviewed change is merged and deployed. Checks Regression tests and code review passed. Delivery The version containing the fix is deployed. **Governor Within approved permissions** Release is already authorized for this example. New publishing authority would need you. Verified ### The original failure no longer happens. A separate check opens the released checkout on mobile Safari, brings up the keyboard and completes the payment flow. Independent check Original mobile Safari reproduction now passes. Result Required checks for this example are complete. **Governor Ready to review** This work is complete. Select the next authorized task and retain the history. Interactive product example. No live customer data. [Availability](https://www.orchestro.org/docs/roadmap) ## Try the difficult moments. Four product-recovery examples. Choose an event to see how the operating model handles it. These controls only change the demonstration. What if a release fails? A failed release stays failed, even when code is merged. Use a bounded retry, an authorized rollback or a technical repair. If a new release harms production, rollback is a first-class recovery option. Then select the next useful job. Code merged **Yes**Release succeeded **No**Recovery verified **No** The affected release stays failed. Independent work can continue. When the retry limit is exhausted, repair or escalate explicitly. A recovery action never certifies its own success. What if the sources disagree? If the work history, repository and production disagree, stop changes to that affected item. Record the authority conflict, repair the evidence and keep other independent work moving. Repository **Merged**Work history **Claims released**Production **Old version** Changes to this job are blocked until the sources agree. The rest of the portfolio remains available. This example corrects a false release claim; it does not invent a deployment. What if a solved problem returns differently? Investigate whether the new failure shares the original cause. Reopen the same causal boundary when it does; create a new one when it does not. Similar symptoms alone are not proof of a shared cause. The checkout was cured under P-B. A new packaging error now appears on the same route. A similar location alone does not identify its cause. Investigate first. Keep the previous cure and the new evidence visible. What if there is never enough evidence? An inconclusive test can have at most one bounded follow-up in these examples. At the limit, record not measurable or insufficient evidence, or request an explicit owner decision about further investment. Remove temporary instrumentation. Example reliability contract: baseline recorded on 2 October, at least 50 samples, decision by 9 October. Adopt below 1% failure; reject above 3%. The middle band stays inconclusive. Evidence at the deadline23 samples, no failures · too little evidence100 samples, no failures · below 1%100 samples, 2 failures · middle band100 samples, 4 failures · above 3% Choose the evidence and evaluate the contract. Elapsed time alone never proves success. Bounded follow-ups used: 0 / 1. Changing the sample does not reset this limit. ## Verification belongs to the result. The coding agent’s report is not the final authority. Check the released system against the original failure and agreed acceptance criteria. Web **Merged is not deployed.**Check the actual server, migration or edge-function release and the affected user path. Mobile **Built is not distributed.**Record the app version, distribution channel and device evidence. A store submission is not a verified user result. Value **Recovery is not business impact.**Measure conversion, cost or engagement with defined cohorts and mature data. Keep unproven outcomes explicit. orchestro / execution replaySimulation · anonymized examples DEMO-08 · Reliability ## Keep checkout working after retries. Same kernel. Different domain. 1. 1Observe 2. 2Investigate 3. 3Prepare 4. 4Review 5. 5Revise 6. 6Release 7. 7Verify 8. 8Next work Follow execution 1 / 8 · Observe ### A mission already has work waiting. The selector can move “Repair a connection left open after a retry”. Waiting work keeps its context. shop.example/checkoutPreview Error trace + regression reproducer #### What can we actually support? Checkout times out after a failed retry. The reproducer finds a connection left open. A successful retry must release the connection too. Recorded in this simulation No waiting job was discarded Try an exception Content examples draw on real editorial work and product-page audits, with names, artifacts and outcomes generalized. Playback compresses the sequence; it does not represent execution time. No command runs and nothing is published. Read every example without playback ### Founder publication: Explain why open work is not always ready work 1. **A mission already has work waiting.** The selector can move “Explain why open work is not always ready work”. Waiting work keeps its context. 2. **Read the evidence before writing.** The worker inspects the source and records what it supports. Missing proof is work to do, not permission to invent a claim. 3. **Produce a concrete draft.** The worker changes content/blog/ready-work.md. The scope stays attached to the work. 4. **The reviewer finds a real problem.** The draft says “our system” without naming the artifact that supports the claim. 5. **Revise the artifact, then check again.** Name the work ledger, link the source and keep the project-level limit. 6. **Publish the reviewed revision.** The configured adapter acts inside the existing authority. A release receipt records the change; the outcome still needs its own check. 7. **Check what actually reached the user.** Reviewed paragraph, source links and canonical match. 8. **A verified change creates the next job.** Audience measurement waits for the declared 90-day window. ### Product content: Correct an unsupported offline claim 1. **A mission already has work waiting.** The selector can move “Correct an unsupported offline claim”. Waiting work keeps its context. 2. **Read the evidence before writing.** The worker inspects the source and records what it supports. Missing proof is work to do, not permission to invent a claim. 3. **Produce a concrete draft.** The worker changes pages/mobile-companion.md. The scope stays attached to the work. 4. **The reviewer finds a real problem.** The proposed copy still promises offline behavior the inspected flow does not support. 5. **Revise the artifact, then check again.** State the connection requirement in the page and FAQ. Preserve its URL and title. 6. **Publish the reviewed revision.** The configured adapter acts inside the existing authority. A release receipt records the change; the outcome still needs its own check. 7. **Check what actually reached the user.** Body, visible FAQ and structured answer agree; protected pages unchanged. 8. **A verified change creates the next job.** Record the baseline; evaluate traffic and CTA impact in a comparable window. ### Software reliability: Repair a connection left open after a retry 1. **A mission already has work waiting.** The selector can move “Repair a connection left open after a retry”. Waiting work keeps its context. 2. **Read the evidence before writing.** The worker inspects the source and records what it supports. Missing proof is work to do, not permission to invent a claim. 3. **Prepare the patch and its test.** The worker changes src/checkout/retry.ts. The scope stays attached to the work. 4. **The reviewer finds a real problem.** The first patch handles success but leaves the failed retry path open. 5. **Revise the artifact, then check again.** Move cleanup to the shared exit path and add the failing retry to the regression test. 6. **Release the reviewed patch.** The configured adapter acts inside the existing authority. A release receipt records the change; the outcome still needs its own check. 7. **Check what actually reached the user.** The released retry passes the original reproduction and the declared recheck window. 8. **A verified change creates the next job.** Retain the technical verification; business impact remains unmeasured. ## What’s real. What’s next. Implementation and pilot snapshot · 4 October 2026. Private access, with configuration and permissions defined per domain. Proven in our systems The Orchestro kernel, autonomous Reliability Factory and Content Factory pilot. Durable state, evidence, independent verification and governed execution. Content uses the same kernel with a manually configured domain. Required to operate Readable sources, domain rules, bounded adapters, explicit authority, a running host and agent quota. Pilot availability does not mean unattended operation is guaranteed for every project. In development Public self-service onboarding, the phone cockpit, hosted MCP/chat access and further domains. Domain Manifest, Domain Builder / Compiler V1 and capability reconciliation are implemented in the private core. The cloud is not a finished hosted SaaS. [Read the availability reference](https://www.orchestro.org/docs/roadmap) Your goals. Your permissions. Your evidence. ## Start with a project you know. [Request early access](https://www.orchestro.org/early-access?track=build) --- Source: https://www.orchestro.org/docs Updated: 2026-10-04 # A shared kernel for different missions. Updated October 4, 2026[Read as Markdown ↗](https://www.orchestro.org/docs.md) Orchestro is the control plane for autonomous software agents. It maintains persistent AI-agent loops with durable state, work selection, recovery, independent verification, production feedback and learning. Your models supply intelligence and agent harnesses execute; Orchestro keeps the work and evidence connected. Super private beta, primarily used on our own internal projects. The preview is free with hands-on onboarding; users supply their own agents, subscriptions and infrastructure. Public self-service access and broader unattended autonomy remain in development. The same kernel runs a Reliability Factory and a manually configured Content Factory pilot. A domain adds its work vocabulary, evidence, policy, adapters and completion rules. The kernel keeps durable state and constrains effects while agents choose a method. ## Same kernel. Different domain. Workflow automation says “when X, do Y”. An agent completes a task. Orchestro maintains a mission over time: observe, understand, select, strategize, execute, verify, learn and create the next work. Goal-based scaffolding and Domain Builder V1 exist in the private core; public self-service onboarding is in development. [Read the two-domain proof](https://www.orchestro.org/story#content-factory) or [check live capabilities versus roadmap](https://www.orchestro.org/docs/roadmap). ## In Reliability: start with the user’s job “Sign up” is a product capability. The form, authentication service and verification email are the pieces behind it. Factory links them so a technical issue has a human context. User goalProduct capabilityCode + evidence ## Keep two questions separate * **Did the change work?** Check the actual released behavior, with verification separate from the agent that made the change. * **Did it help?** Look at a meaningful user or business outcome. An improvement in a metric alone does not prove what caused it. **Understand the loop. Then see a real Factory.** [How it works](https://www.orchestro.org/how-it-works) pairs the owner view with the machinery underneath. [Live Factories](https://www.orchestro.org/live) reads a dedicated public projection: Content is connected; ARVO is Coming online. Every observation has a timestamp. Missing or stale data is never replaced with sample activity. The older product and marketing walkthroughs remain in [illustrative operating examples](https://www.orchestro.org/docs/operating-examples). Their sample metrics explain the model; they are not live results. ## Get oriented [**Factory lifecycle**A report in the backlog is not a promised PR. Follow classification, shared problems, selection, root cause, verification, evidence waits and the distinction between Backlog Zero and Operational Zero.](https://www.orchestro.org/docs/factory/lifecycle)[**Quickstart**Set up Orchestro, check your coding CLI and connect a project in observation mode.](https://www.orchestro.org/docs/quickstart)[**How the loop works**How Orchestro connects product mapping, recommendations, owner decisions, agent work and verification.](https://www.orchestro.org/docs/how-it-works)[**Your loop**One kernel maintains different missions. See the historical Reliability and Content pilots, the current Content observation, and the private Domain Builder foundation for public self-service setup.](https://www.orchestro.org/docs/loops) **Early access, actively being built.** The private owner cockpit is deployed, and Content has a public read-only view. Product illustrations remain labelled separately. The [availability page](https://www.orchestro.org/docs/roadmap) distinguishes deployed preview capabilities, historical proof and remaining work. --- Source: https://www.orchestro.org/docs/factory/lifecycle Updated: 2026-10-02 # From a signal to a verified cure. Updated October 2, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/factory/lifecycle.md) Signals become evidence. Evidence establishes a cause. A bounded repair becomes a cure only when the required verification proves it. [Start with the visual Factory tour](https://www.orchestro.org/how-it-works), then use this page to connect the public language to the actual implementation. Orchestro is the current product name. 1. 1Send 2. 2Classify 3. 3One problem 4. 4Investigate & fix 5. 5Verify 6. 6Cure or park ## A report in the backlog is not a promised PR Intake classifies the signal and attaches it to a canonical identity — a new one, or an existing one. That is correct disposition. It is not a promise of investigation or a PR. The selector later chooses what may change. A report may remain in the queue, wait for evidence, attach to a problem already shipped, describe expected behavior, or, rarely, be a true duplicate. [Follow an 11-report weekend through intake](https://www.orchestro.org/how-it-works#signals), then F-17 from investigation onward — not back through the reports. **Implementation snapshot: 20 September 2026.** The core is implemented in the private framework. Sources, tests and release procedures require project configuration. Examples below are fictional. Built-in autonomous web/mobile journey execution and full Backlog Zero certification remain roadmap; they are not shipped product settings. ## A signal is not automatically a bug Users, support, production logs, monitoring, product analytics, automated tests, agents and human-created issues can all provide evidence. Each source must be connected through the project’s configured inputs; this is not a list of turnkey integrations. A report may reveal a real bug, capability gap, wrong result, false action claim or service availability issue. It may also describe expected behavior or lack enough evidence. These are explanatory categories, not a new implementation enum. The agent proposes a classification; validated intake and durable authority decide what may happen next. ## Public language → implementation ### Signal An observation from a person, system or test. It may describe expected behavior or incomplete evidence. **In the implementation:** Configured truth sources; signalIdentity; structured intake ### Canonical identity The durable address of one problem, with linked reports and repair history. Source-provided occurrences can grow without creating new problems; distinct-user totals require source data. **In the implementation:** signalIdentity; same\_cause relations; family grouping ### Classification An agent proposes what the evidence means; deterministic validation controls what is recorded. Public examples include bugs, capability gaps, wrong results, false action claims, availability, expected behavior and uncertainty. **In the implementation:** Intake: verify / fix / feature / experiment / decision. Investigation: product / measurement / both / ops / unknown ### Selector Chooses executable work under priority, current authority, dependencies, evidence and human decisions. A high-ranked item that cannot run should not occupy the mutating seat. **In the implementation:** factory.ts; checkpoint; current / evidence\_acquisition / backlog\_campaign; measurement dependencies ### Root cause boundary The specific causal mechanism the investigation proves. Similar symptoms do not grant authority to merge unrelated causes. **In the implementation:** causal\_confirmation; ROOT\_CAUSE\_CONFIRMED ### Remediation One bounded change and persistent PR for one cause. Review and regression evidence belong to that identity. **In the implementation:** remediation receipt; IN\_REMEDIATION ### Merge Code joined the main branch. This does not prove release or repair for users. **In the implementation:** merge receipt; mergedSha; release queue (not a separate MERGED lifecycle enum) ### Release The relevant version reached the declared delivery surface. A web release is not proof of native app distribution. **In the implementation:** deploy receipt; deployedSha; releaseChannels ### Verification A separate actor checks the declared evidence against the released version. Outcomes are passed, failed or inconclusive. **In the implementation:** WAITING\_VERIFICATION; verification receipt; verifier.command ### Recurrence A verified cause returns. Reuse its identity and history rather than making an unrelated ticket. **In the implementation:** RECURRENT; cure lineage; current observations ### Evidence plan A bounded next probe: what is missing, how to obtain it, and an evaluable return condition. **In the implementation:** evidence\_plan; missingEvidence; nextProbe; dueAt or targetSampleCount + planBaselineOccurrences ### Park / re-entry Keep the problem open and visible while unrelated work proceeds. When its supported condition becomes due, the probe becomes eligible for selection. **In the implementation:** EVIDENCE\_PENDING; EVIDENCE\_PLAN\_WAITING; WAITING\_VERIFICATION\_DEFERRED; verificationNotBefore ### Cured Required verification has passed. Where production reconfirmation is configured, it must also pass before cure. **In the implementation:** IN\_PRODUCTION\_UNCONFIRMED → cure\_reconfirmation → CURED (when configured) ### Backlog Zero Zero actionable deterministic debt in the declared scope. Evidence waits, external waits, observation, owner decisions and explicit deferrals remain visible. **In the implementation:** NO\_ACTIONABLE\_WORK / EVIDENCE\_WAIT\_ONLY + remainingGates. Full zero-proof certification remains roadmap ## Understand, group into one problem, then select Ten matching reports should strengthen one problem rather than produce ten unrelated tickets. Intake reuses an exact or high-confidence backlog match. Proposed relations and family grouping do not prove a common cause. Keep distinct causes separate, and retain the original evidence when a family needs to be split. The selector reconciles current signals, due evidence probes and the canonical backlog. Existing mutation authority, measurement dependencies, priority, human decisions and release/verification state constrain execution. Only one mutating causal boundary is allowed at a time. A parked item stays visible without holding that seat; re-entry makes it eligible, not automatically selected ahead of other authority. ## Worked example: a saved change that stays invisible This generic application example uses one identity, F-17, throughout. The observed symptom is “I saved a change, but the app still shows the old version.” 1. **Signals.** “I still see the old version.” “Saved. Nothing changed on screen.” Same person, same weekend. That is evidence, not yet a proven bug. 2. **Classify.** Compare the saved result with what people actually see. Is this a bug, a missing capability, expected behavior, or simply not enough evidence? Classification is not a PR. 3. **One problem.** Link the matching reports to F-17. Keep their evidence and history together. A similar-looking error with a different cause stays separate. 4. **Select.** F-17 is classified and attached. The Factory now chooses the next work that is allowed: priority, evidence and human decisions. Other identities stay in the queue or wait for samples. Only one cause is rewritten at a time. 5. **Investigate.** The saved record is correct. A reproducible check shows that the app keeps an old cached version after save. The problem is the refresh path. 6. **Fix.** The agent repairs the refresh path and adds a regression check. Review, merge and release evidence stay attached to F-17. A merged PR is only one step. 7. **Verify.** An independent check exercises the released save-and-refresh flow. Tests, release identity and the declared production evidence determine the verdict. 8. **Cure or park.** Pass the required checks and observation window: cured. Missing evidence: wait with a plan. A confirmed failure: reopen the same problem. Then select again. **Passing ending:** the regression check succeeds, the reviewed PR is merged, and the relevant release is recorded. An independent verifier checks the released save-and-refresh flow. If the project requires production reconfirmation, the item remains `IN_PRODUCTION_UNCONFIRMED` until that check also passes. Only then is F-17 `CURED`. **If it returns:** evidence tying a later failure to the same cause makes F-17 `RECURRENT`. The previous repair remains attached. A different cause gets its own boundary. A cured defect is not, by itself, proof that a business metric improved. ## Coded → merged → deployed → verified → cured These are separate claims. A PR, a merge receipt, a deployment receipt and an independent verification receipt answer different questions. A mobile fix requiring a new binary also needs the relevant client distribution; a web deployment is not a substitute. “Merged, awaiting release” is useful public language for the release queue. It is not a new lifecycle enum in this framework. Likewise “park” is an explanation of eligibility and gates, not a `PARKED` state. Use the actual receipt kinds and lifecycle vocabulary above. ## Worked example: no production sample yet The F-17 change is deployed and its regression test passed. The required production observation has not happened. The honest verdict is **INCONCLUSIVE**: neither a pass nor proof of recurrence. 1. **Declare the missing evidence:** a production save-and-refresh observation for the deployed version. 2. **Bound the next check:** a deployment-linked `verificationNotBefore` timestamp records when the observation window can first be evaluated. 3. **Park this wait:** the gate projects as `WAITING_VERIFICATION_DEFERRED` while the window is not executable. F-17 is still open. 4. **Reselect:** unrelated executable B, C and D may proceed. A has not been closed or declared fixed. 5. **Re-evaluate when due:** expiry makes verification executable again. Read fresh evidence. Missing samples remain inconclusive; elapsed time is never a cure. ### When the investigation itself lacks evidence An `EVIDENCE_PENDING` investigation uses an `evidence_plan` receipt. It must name `probeType`, `missingEvidence`, `nextProbe` and a machine-evaluable condition: an absolute `dueAt` timestamp or a positive `targetSampleCount` with a frozen `planBaselineOccurrences`. **Example: 5 new occurrences, not 5 total.** At baseline 12, a target of 5 becomes due at 17 source-reported occurrences, or at the declared due time if that arrives first. Unknown counts do not satisfy the target. The next packet runs the recorded probe; it does not authorize an invented pass or unrestricted code changes. The latest active plan applies. Re-entry only promotes an identity still in the plan’s eligible lifecycle. A prose instruction such as “when traffic returns” is insufficient on its own. General external-event wakeups and automatic backoff for unchanged probes remain roadmap. These limits matter: structured waiting is not an excuse to silently forget an item or promise a wakeup the engine cannot evaluate. ## Autonomous web/mobile testing is part of the cycle The intended system includes autonomous journeys in the same loop: **test the product → collect signals → investigate and fix → verify the relevant release → feed new evidence back**. Web and native mobile are surfaces of that system, not a separate add-on backlog. **Implemented:** project contracts configure truth commands, periodic checks and an independent `verifier.command`. A project can supply its own browser or mobile test tooling through those commands. That is an integration mechanism, not evidence of a built-in runner for every platform. **Roadmap / demo:** a built-in autonomous web/mobile journey runner and the simple on/off switches in the visual tour. They illustrate control of test generation inside the Factory; they do not change an actual project’s configuration. Disabling autonomous test generation does not remove required verification. An unexecuted test is not a pass. Synthetic checks and natural production observations answer different questions; the project must specify which evidence its verification requires. ## From Backlog Zero to Operational Zero The broader health goal is not an empty list. Explained waits can remain open while the system addresses unexplained signals, actionable urgent work, stale conclusions, unbounded waits, expired experiments and overdue release verification. [The ARVO experience behind these six targets](https://www.orchestro.org/story) explains the shift. These are operating goals, not a new implemented certification command. The historical Backlog Zero contract below remains a narrower technical target. ## Backlog Zero means zero actionable deterministic debt It does not mean deleting every row. Within a declared scope, all executable work has been handled. Some identities may lawfully remain awaiting evidence, external events, cure observation, human decisions or explicit deferral. Their reasons and return conditions must stay visible. The tour’s **0 actionable / 4 waiting / 7 observing** is a fictional explanation of that definition. Current checkpoints distinguish `NO_ACTIONABLE_WORK` and `EVIDENCE_WAIT_ONLY` and expose `remainingGates`. Complete zero-proof reconciliation is still roadmap. An empty source response, missing visibility or a green aggregate counter cannot certify every product problem cured. ## Why receipts outlive the conversation An agent session can end, lose context or be replaced. Its recollection cannot authorize a mutation, establish which version is live or prove a cure. The Factory persists identity-linked receipts, decisions and state so the next session can reconstruct what happened from authoritative records. The append-only lifecycle records the cause, remediation, PR, merge, deployment, verification actor and evidence, outcome and any evidence plan. A new agent reads current repository and release truth alongside that history. A confident message in chat is never a replacement for those records. [Explore the detailed signal register and evidence-plan examples](https://www.orchestro.org/docs/work-lifecycle), [read the real CLI reference](https://www.orchestro.org/docs/tools), or [return to the visual tour](https://www.orchestro.org/how-it-works). --- Source: https://www.orchestro.org/docs/quickstart Updated: 2026-10-04 # Start with one real project. Updated October 4, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/quickstart.md) Connect a small project you know well. Start by observing it, then decide how much work to hand over. **What it takes:** steps 1–4 below get you to a first capability map and an opening checkpoint. On a repository you already know, the main work is choosing which outcome matters, which signals are readable and what actions are permitted. Setup time depends on the domain and its integrations. Steps 5–6, the permissions and the scheduled watcher, are a separate decision you can make later. **You’ll need repository access.** Factory is currently private. [Request early access](https://www.orchestro.org/early-access) before running the checkout commands below. There is no public Factory npm installer. ## 1\. Check the basics You need Node.js 22.16.0 or newer, an installed and signed-in coding CLI, and the GitHub CLI authenticated for your project. Your project also needs at least one signal a machine can read: a test, a log check or a product metric. check your machine ``` node --version gh auth status ``` ## 2\. Open the Factory checkout After access is granted, clone Factory and install its dependencies. The current internal package and CLI use the name `northstar`. repository setup ``` git clone https://github.com/khaoss85/agentic-factory.git cd agentic-factory npm ci npm run northstar -- preflight --agent codex ``` Use `--agent claude` or `--agent grok` if that is your configured CLI. Preflight checks that the executable exists; it cannot independently confirm every provider’s login. Sign in through your CLI before starting work. ## 3\. Give the project a goal In the private checkout, scaffold a new pack with the real CLI: create a goal scaffold ``` npm run northstar -- init --dir packs/my-app --slug my-app --goal "Reduce material product failures with independent evidence." ``` Init creates a domain manifest. It does not discover credentials, connect sources, grant permissions or start a worker. For an existing pack, continue with its actual path instead of creating another one. Then ask your coding agent to guide the configuration: prompt for your coding agent ``` Connect Factory to my project at /absolute/path/to/my-app. Use the goal scaffold at packs/my-app. Read .agents/skills/onboard-project/SKILL.md and follow it. Start in observation mode. Explain remaining readiness gaps before running work. ``` Domain Builder / Compiler V1 validates the proposed operating model against available capabilities. The project still needs real sources, tools, evidence rules, verification and permissions. Keep credentials in the project’s existing secret storage. ## 4\. Inspect the project and open the board Use the actual pack path produced during onboarding in place of `packs/my-app`. inspect and explore ``` npm run northstar -- readiness --pack packs/my-app npm run northstar -- checkpoint --pack packs/my-app npm run northstar -- serve --packs packs ``` Open the local URL printed by the server. Look at the mapped capabilities, open problems and missing evidence before enabling automated work. ## 5\. Choose your operating boundaries Observation, implementation, merge and release are different permissions. Configure the project’s autonomy contract before running an agent. The onboarding guide walks you through that choice. For an already configured project where you have authorized execution: run configured work ``` npm run northstar -- run --pack packs/my-app ``` ## 6\. Keep checking on a schedule After the pack’s schedule, run command and permissions are configured, start the periodic watcher: scheduled operation ``` npm run northstar -- watch --pack packs/my-app ``` Keep that process running on an awake host. The watcher measures at the configured times and launches the run command when the checkpoint finds work. It also records observations when there is nothing to repair. This is how operation can continue across days. Each worker run still has time and invocation limits. Authentication, subscription quotas, human decisions and missing evidence can stop work. The project’s recorded history survives an individual agent session; multi-day operation does not mean one unlimited model call. ## Observe from the cloud when connected The private cockpit reads a project-scoped cloud projection; it does not host the execution loop. Configure publishing through the private onboarding process, then inspect synchronization locally: check the cloud connection ``` npm run northstar -- cloud status --pack packs/my-app ``` A connected binding alone is not proof of a fresh observation. Read snapshot age and last durable progress separately. See the [cloud and MCP boundaries](https://www.orchestro.org/docs/mcp#cloud-factory). To inspect the full command reference in your installed checkout: terminal ``` npm run northstar -- --help ``` --- Source: https://www.orchestro.org/docs/how-it-works Updated: 2026-09-26 # Map, fix, verify, watch for a return. Updated September 26, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/how-it-works.md) This page is the same loop: map, fix, verify. An app needs new users to finish onboarding, AI tools to complete their tasks and reports to load reliably. Factory maps those capabilities, follows their history and gives each one a measurable next target. Want the execution details? [Inspect all 12 example signals](https://www.orchestro.org/docs/work-lifecycle#twelve-signals), then [follow one investigation from checkpoint to verification](https://www.orchestro.org/docs/work-lifecycle#execution-flow). ## The product map A map links business capabilities to journeys, screens, agents, services, data pipelines and external dependencies. Repository history helps reconstruct what happened before. Connected runtime evidence tells you what is happening now. Code existing in a repository does not mean it is released, enabled or being used. Missing evidence remains visible rather than becoming a reassuring green status. ## Two kinds of useful work ### Make it reliable Existing capability → reported problem → underlying cause → change → release → verification. ### Make it more useful User need → opportunity → hypothesis → experiment or feature → release → outcome measurement. The second path is part of the wider product loop under development. A new opportunity should not have to masquerade as a bug to be worth doing. ## One problem, with its context A failed sign-up might appear in feedback, a runtime error and a GitHub issue. Those can be evidence about the same problem. Grouping them avoids three agents independently trying to fix one cause. ## The owner’s decision matters The Advisor makes recommendations from available facts. Decisions are recorded durably. Accepting a recommendation and authorizing execution are separate steps; the project’s permission settings still govern what may happen. The current decision-to-work bridge promotes an accepted canonical-problem decision through explicit checks. Capability-level recommendations do not automatically become executable work. [Inspect owner-decision tools](https://www.orchestro.org/docs/tools#tool-owner-decision) for promotion and work status, or [follow the execution gates](https://www.orchestro.org/docs/work-lifecycle#execution-flow). ## Verification is a separate job A merged pull request is evidence that code changed. A release shows it was deployed. A behavioral check shows whether the fix works. A product measurement helps assess whether it was useful. Factory keeps these distinctions. ## One main metric, up to two supporting measures For sign-up, that might be completed registrations. For a conversation agent, helpful answers. Each measurement needs a definition, population, time window and enough fresh data to support the conclusion. A small set of guardrails can protect other outcomes. “We cannot measure this yet” is a valid result. In the public board, select a metric to change its chart, target and Advisor suggestion. Chat quality is a reply score out of 100; Cost per reply includes all model calls and retries; Tool success measures whether required actions finish correctly. Fewer tools or turns is not itself a better outcome. Automations follows a reminder through email or in-app delivery to a completed user action. Paywall & upgrades follows the same visitor from first view to a confirmed payment, with a full conversion window. Delivery is not completion; a checkout event is not a confirmed paid subscription. Definitions, populations and missing evidence stay in the metric details. The date range filters charts and recent activity. It never rewinds current work or hides an outstanding decision. Problem histories retain their own dates. P1, P2 and P3 describe urgency; “Needs you” is reserved for a decision or authorization that requires the owner. ## Follow the same capability over a week An illustrative issue, F-17, shows the same idea. Funnel events, server logs and a reproducer show that session refresh loses the workspace ID. This blocks onboarding and AI tool calls that depend on the same context. | When | What changes | What Factory retains | | --- | --- | --- | | Day 1 | The onboarding capability is mapped. Activation is 62%. | User goal, dependencies and initial measurement | | Day 2 | The cause is reproduced; an approved patch is released. | One issue, confirmed cause, scope, patch and release | | Day 3 | An independent check passes on the release. | A verified repair cycle; a separate product measurement | | Day 6 | A retry route reproduces the same missing-context cause. | F-17 reopens; the previous fix remains in its history | | Day 7 | The retry repair is independently verified. | One issue, two verified repair cycles, one recurrence | A similar complaint alone does not establish recurrence. The new evidence must connect it to the confirmed cause. A different cause should be tracked separately. The example’s 62%, 63.4%, 62.7% and 64% onboarding conversion rates are illustrative, not customer results. Each cohort contains 1,000 eligible new accounts with a full 24-hour observation window. Activation means creating a first project; tests and bots are excluded. The guardrail is project creation p95 below 2 seconds. Before/after movement does not establish causation. ## Past, present and the next target Each capability keeps its metric definition, denominator, sample window, baseline and target. Four public examples: * **Onboarding:** 62% to 64% activation within 24 hours. This is +2 percentage points, not a 2% relative increase. * **AI assistant:** 91% to 95% successful tool calls with validated results, using the same tool mix. This measures tool reliability; answer usefulness needs its own evaluation. * **Server reliability:** 99.5% to 99.9% of requests without a 5xx, with latency as a guardrail. Logs help locate the cause. * **Analytics:** report load p95 from 1.8 seconds to below 1 second, while data stays less than 15 minutes old. Targets are proposals for the next 30 days. The owner reviews the scope and hypothesis before work begins. The [coding-agent tools](https://www.orchestro.org/docs/tools#capability-example) show how to read measurements, record an expectation and compare the outcome. ## Memory carries the work forward Keep causes, decisions, attempted changes and observed outcomes with the project. Turning those lessons into automatically promoted operating rules is a later roadmap step. ### How a lesson would earn the right to become a rule Planned, not shipped. The four steps below are the review gate a candidate rule has to pass before it can guide later work. 1. **Repeated evidence.** The same session failure caused two repair cycles. Both reproductions and both fixes stay attached to F-17. One successful patch is not a universal lesson. 2. **Candidate lesson.** “Verify workspace context survives onboarding, tool calls and background retries.” A proposal, not a permanent instruction. 3. **Shadow check.** Run it without expanding agent permissions. Record missed cases and false alarms before trusting it. 4. **Reviewed rule.** Promote only after reading the evidence. Keep its version so it can be corrected or retired. [Check implementation status](https://www.orchestro.org/docs/roadmap) --- Source: https://www.orchestro.org/docs/loops Updated: 2026-10-04 # Define the loop. Orchestro runs it. Updated October 4, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/loops.md) A loop is work plus checks plus limits, running on a schedule until you change it. Every Orchestro loop answers the same five questions: what is the goal and how is it measured, what work moves it, what checks prove the result, what the loop may never do without you, and when it runs next. The Factory does the work, the Governor keeps it moving, and the answers above are what keep it safe to leave running. ## The anatomy of a loop | Part | What you declare | Example: repair loop | | --- | --- | --- | | Goal + measure | One primary metric, population, window, target | Onboarding activation, 64% within 24 hours | | Work | What the agents do each round | Reproduce, fix the cause, release | | Checks | Independent proof, separate from the worker | Behavioral check on the release | | Limits | Permissions, budget, approvals, guardrails | No merge without green checks; you approve publishing | | Schedule | When the loop wakes up | Configured watcher on an awake host | ## What runs today Reliability runs from observation to independently verified release. The Content Factory pilot runs from evidence and thesis to reviewed articles, publishing, post-publish checks and learning work. Both use the same kernel; their domain configuration is currently manual. [Start with the quickstart](https://www.orchestro.org/docs/quickstart), or [watch the loop run](https://www.orchestro.org/how-it-works). ## Custom loops are the direction Domain Manifest V1, Domain Builder / Compiler V1 and agent-guided bootstrap are implemented in the private core. The builder checks discovered capabilities, validates the proposed domain and materializes initial work. Missing access or capabilities produce NOT\_READY. The public self-service experience is still in development. **Two doors, one model.** Reliability and the Content pilot are the first proof points. General campaign operations and further domains still need validation. [See the growth loop](https://www.orchestro.org/docs/grow). --- Source: https://www.orchestro.org/docs/work-lifecycle Updated: 2026-09-15 # What is ready, what waits, and why. Updated September 15, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/work-lifecycle.md) Factory keeps the record of what happened, derives the problem's current lifecycle and checks what can move next. An open backlog item can already have an investigation, a pending probe or a released fix. ## 12 signals do not mean 12 fixes. This fictional app has 12 signal identities at one point in time. Each appears once in the register below. Repeated occurrences of one signal are a different count. S01–S12 are reading labels, not Factory IDs. | Signals | What happens next | | --- | --- | | **5 · Ready to investigate** | Three session-related signals form one investigation; two others stand alone. Five signals, three work packets. | | **4 · Waiting for evidence** | Each has a recorded probe and a measurable return condition. The worker can move on while the plan waits. | | **2 · Waiting for verification** | The changes are released. The configured independent verifier has the next turn; neither issue is cured yet. | | **1 · Needs an owner decision** | A product choice is outside the project's authority. That item waits while unrelated authorized work can continue. | **5 + 4 + 2 + 1 = 12 signal identities.** The five eligible signals form three investigation packets: one family of three, plus two individual signals. Neither grouping nor eligibility proves a root cause. These are teaching categories, not a new Factory status enum or an export from a customer board. A missing direct receipt also does not prove an item is untouched: related history may exist elsewhere. [Try the numerical example on the homepage](https://www.orchestro.org/#work-readiness). ### 5 signals · Ready to investigate `S01` #### Email sign-in returns to an empty workspace Onboarding / investigation packet A What we know A support report and callback trace show the workspace context disappearing after sign-in. Next step Packet A: trace session restoration alongside S02 and S03. `S02` #### A tool call gets a 403 after session refresh AI assistant / investigation packet A What we know The tool trace contains the same missing workspace context seen in S01. Next step Packet A: compare the tool request with the sign-in callback. A shared cause still needs proof. `S03` #### The API rejects requests without workspace context Server reliability / investigation packet A What we know Request logs point to the same session-restoration path as S01 and S02. Next step Packet A: reproduce all three paths before deciding whether one repair covers them. `S04` #### A 90-day report times out Analytics / investigation packet B What we know A reproducible report request has a slow query trace and a known dataset size. Next step Packet B: inspect the query and reproduce the timeout independently of the session family. `S05` #### A webhook retry processes an event twice Server reliability / investigation packet C What we know Two deliveries with the same event ID produce two writes in a reproducible test. Next step Packet C: investigate idempotency at the write boundary. ### 4 signals · Waiting for evidence `S06` #### A project request fails with no captured payload Project creation What we know One occurrence is known. The request payload and workspace context needed to reproduce it are missing. Next step Capture two new matching occurrences, or recheck on September 21 at 08:00 UTC. Then run the recorded probe. Example identity: `verify:project-payload`. [Inspect its evidence-plan receipt.](https://www.orchestro.org/docs/work-lifecycle#evidence-plan) `S07` #### A chart is blank in one mobile session Analytics What we know A screenshot exists, but there is no browser trace to distinguish rendering from missing data. Next step Check for the trace on September 18 at 08:00 UTC. If inconclusive, allow one bounded follow-up. At its deadline, record insufficient evidence and clean up temporary instrumentation. `S08` #### A tool occasionally returns an empty result AI assistant What we know Two occurrences are known; the tool inputs needed to compare the failures are incomplete. Next step The plan freezes a baseline of 2 and requests 3 new occurrences, or a September 20, 08:00 UTC recheck. Inspect the captured inputs when due. `S09` #### A notification arrives late Server reliability What we know The app timestamp is available; the provider delivery log is missing. Next step The plan schedules a cross-source probe for September 19 at 08:00 UTC to compare app and provider timestamps. ### 2 signals · Waiting for verification `S10` #### The invite-expiry message has been repaired Onboarding What we know The repair and deployed commit are recorded. Its independent behavioral check has not returned a verdict. Next step The configured verifier checks expired and valid invites against that release. Keep the boundary open until the required evidence supports closure. `S11` #### The report cache now invalidates after an import Analytics What we know Deployment is recorded; the post-release freshness check is pending. This is separate from S04's query timeout. Next step The configured verifier imports a sample dataset and checks that the report reflects the new data. ### 1 signals · Needs an owner decision `S12` #### Should the company-size step be optional? Onboarding What we know The step has measurable drop-off, but changing required information is a product choice outside the worker's authority. Next step Ask the owner to decide the intended behavior. A recorded answer must still pass scope and execution-authority checks. ### How five eligible signals become three packets `S01 + S02 + S03`Packet A**Investigate lost session context** `S04`Packet B**Investigate the report query** `S05`Packet C**Investigate duplicate event writes** The selector can group a related family into one investigation. It preserves the member signals. This snapshot assumes no active repair needs to resume first; A, B and C name the packets, not a guaranteed execution order. ## Three layers, three different questions. 1. **Backlog status: is the request still open?** Factory's pack backlog uses `open`, `done` and `dismissed`. 2. **Problem lifecycle: what does the evidence establish?** Examples include `ACTIONABLE`, `EVIDENCE_PENDING` and `WAITING_VERIFICATION`. 3. **Receipts: what actually happened?** Investigation, evidence plan, remediation, merge, deploy and verification are recorded facts. An `evidence_plan` is a receipt, not another lifecycle state. The append-only ledger preserves the history. Projections reconstruct the current state from those records. The checkpoint and selector determine whether to resume active work, select a packet, wait, or request human input. ## S06: one occurrence. Two more. Then run the probe. S06 is the project-creation request from the register. It failed once, but the discriminating payload is missing. An inconclusive investigation leaves the identity in `EVIDENCE_PENDING`. Its evidence plan records the missing evidence and a specific way back. Illustrative evidence-plan receipt ``` { "receiptKey": "plan:project-payload:1", "receiptKind": "evidence_plan", "signalIdentity": "verify:project-payload", "signalSource": "verify", "probeType": "wait_for_occurrences", "planBaselineOccurrences": 1, "targetSampleCount": 2, "dueAt": "2026-09-21T08:00:00Z", "missingEvidence": "Request payload and workspace context for the failing path", "nextProbe": "Inspect matching request events and reproduce the workspace-context failure", "createdAt": "2026-09-15T08:00:00Z" } ``` **`targetSampleCount = 2` means two new occurrences beyond `planBaselineOccurrences = 1`.** At two total occurrences, one new sample is still missing. At three total occurrences, the plan is due. Reaching the absolute `dueAt` timestamp also makes it due, even if the extra samples never arrive. The next job is `run-probe`. It is eligible for selection, not a promise to run immediately ahead of an active repair or higher-priority current work. If evidence is still insufficient, investigate the result and record a new effective plan. Do not treat the calendar reaching a date as proof of a cause. Factory refuses a new evidence plan without a machine-evaluable return condition. An occurrence target requires its frozen baseline; `wait_for_occurrences` requires a target. A free-text `externalCondition` alone is insufficient. If the source does not provide a usable occurrence count, the count threshold is not considered met. ## Follow packet A through one turn of the loop This walkthrough starts from the snapshot above and explores what could happen next. The receipts described here are hypothetical continuation events, not evidence that the 12 listed signals have already been fixed. 1. ### Checkpoint: reconstruct the work already in progress Read current project evidence, the backlog and recorded receipts. S06–S09 have evidence waits; S10–S11 have released changes awaiting the configured independent verifier; S12 needs a product decision. **Gate:** resume an active repair when required. A new turn does not discard its branch, release boundary or unresolved decision. [Inspect the checkpoint command](https://www.orchestro.org/docs/tools#tool-checkpoint) 2. ### Selection: choose a packet that can move Evaluate active evidence plans against their frozen occurrence baselines and dates. The five eligible signals form packets A, B and C. For this walkthrough, assume A is selected and the pack allows investigation. **Output:** a focused work packet for the session-context family, carrying the member evidence. Due probes compete within the selection rules; they do not automatically interrupt active work. 3. ### Investigation: test the suspected connection Trace S01's sign-in callback, S02's tool request and S03's API rejection. Reproduce the missing workspace context and check whether the same code path explains all three. **Record:** an investigation receipt. Confirmed shared causality can be recorded as a `same_cause` relation. If the evidence disagrees, keep separate causes or reclassify the family. **If evidence is missing:** record an effective evidence plan, as in [S06](https://www.orchestro.org/docs/work-lifecycle#evidence-plan). If a product or cost choice is needed, record that boundary and continue unrelated authorized work. [Inspect relation tools](https://www.orchestro.org/docs/tools#tool-relations) 4. ### Remediation: repair the proven boundary Within the pack's permissions, prepare an isolated code change and check all three affected paths. Test the original failure and a valid session so the repair does not block legitimate users. **Record:** remediation evidence tied to the signal and repair boundary. Passing local tests supports review; it does not establish a production cure. [Inspect the repair command sequence](https://www.orchestro.org/docs/tools#repair-sequence) 5. ### Merge and release: establish what actually shipped Follow the project's review and release authority. Record the merge separately from deployment, with evidence identifying the released commit. **Gate:** a draft-PR boundary can end the worker's turn. If release is authorized and recorded, the boundary proceeds to verification. A merged PR alone cannot prove that users have the fix. [Inspect receipt recording](https://www.orchestro.org/docs/tools#tool-record) 6. ### Independent verification: check the released behavior The designated verifier exercises sign-in, refreshed AI tool calls and API requests against the release. The executor cannot write the verdict on its own repair. **Outcome:** sufficient passing evidence can support `CURED`. A required later reconfirmation keeps the boundary `IN_PRODUCTION_UNCONFIRMED`; a failed verdict can make it `RECURRENT`. Inconclusive evidence does not justify closure. [Inspect independent verification](https://www.orchestro.org/docs/tools#tool-verify) 7. ### Fresh checkpoint: continue and watch for a return Reconstruct state again before selecting more work. Packet B or C may be next; a matured evidence plan may now be eligible. When S06 has two new occurrences, its next job is to run the probe, not to start an assumed fix. **If the session bug returns:** preserve its earlier investigation, deployment and verdict, then investigate the new occurrence. Compare it with the previous cause before deciding whether the cure failed or a different variant needs its own boundary. [Follow the seven-day recurrence example](https://www.orchestro.org/docs/how-it-works#seven-day-example) ### Then measure the user outcome A technically verified repair and a better product metric answer different questions. For onboarding, compare completion rate against the agreed baseline, population and observation window. A target of +2 percentage points remains a target until measured; a passing test does not establish that lift. [See the onboarding measurement example](https://www.orchestro.org/docs/use-cases#onboarding) and [the current product-outcome roadmap](https://www.orchestro.org/docs/roadmap). ## Group the cause. Keep the history. Factory has two related mechanisms. Family grouping lets the selector investigate related signals together. A durable `same_cause` relation declares that two identities represent the same underlying problem and lets the capability map count that problem once. A family label alone is not proof of equivalence. For example, an onboarding failure, a rejected AI tool call and a server error may all point to lost workspace context. Establish that shared cause before treating one repair as covering all three. Preserve the member evidence and release checks. A later failure must remain visible. The ARVO label `DUPLICATE_CONFIRMED` is not a Factory lifecycle state and should not be used as a shortcut to `CURED`. Similarly, an existing fix must be linked to the relevant release and verification; a similar description is not enough. If a group turns out to contain different causes, Factory records `family_reclassification`. The parent becomes `RECLASSIFIED_INTO_CHILDREN`, and the child identities carry the work. Retirement is not a cure. ## Factory's lifecycle vocabulary | Lifecycle | Meaning | | --- | --- | | `ACTIONABLE` | Eligible for the next work packet. An investigation or probe may still be needed. | | `EVIDENCE_PENDING` | The cause is unconfirmed. A recorded evidence plan defines what to inspect and when to return. | | `IN_REMEDIATION` | A repair boundary is in progress. A merge alone does not prove release. | | `WAITING_VERIFICATION` | A deployment is recorded; the independent verdict is still pending. | | `IN_PRODUCTION_UNCONFIRMED` | The first verification passed, but a required later measurement has not confirmed the cure. | | `CURED` | The release and required verification support a technical cure. Product benefit is measured separately. | | `RECURRENT` | A verification or later reconfirmation failed, or a cured signal was observed again. | | `DESIGN_DECISION_PENDING` | A product or design decision needs the owner's answer. | | `OPS_OR_COST_DECISION_REQUIRED` | An operational or spending decision needs authority. | | `EXECUTOR_RETRY_EXHAUSTED` | The bounded execution attempts ran out. The failure remains visible for recovery. | | `RECLASSIFIED_INTO_CHILDREN` | A wrongly grouped parent is retired. Its child identities carry the remaining work; the parent is not marked cured. | | `LIFECYCLE_UNKNOWN` | The available history does not establish a reliable lifecycle. This is not evidence of a cure. | `merge` and `deploy` are distinct receipt kinds. This framework does not add ARVO's `MERGED_AWAITING_RELEASE` to its lifecycle enum. Read the release evidence rather than inferring “live” from a merged pull request. ## When does the owner need to step in? Product, business, high-risk authorization and access blockers require the relevant human answer. A parked identity does not need to stop unrelated authorized work. A configured independent verifier can take over a deployed boundary while the coding worker moves on. Without that verifier configuration, do not assume the wait releases the execution boundary. The checkpoint also supports a deliberate draft-PR handoff, an evidence-only wait and no actionable work. “The run can end” is not the same as “every problem is cured.” terminal ``` npm run northstar -- checkpoint --pack packs/my-app npm run northstar -- status --pack packs/my-app ``` [See the complete CLI reference](https://www.orchestro.org/docs/tools) for intake, evidence recording, relations, verification and owner decisions. ## Small rules worth auditing next Keep these as review candidates: make linked work stop appearing as an independent repair only when its authority is proven; keep every wait's return condition measurable; compare headline counts with the canonical problem view. Prove changes with projector/selector invariants and regression tests before reconciling raw statuses. No bulk closure to make a number look better. This page documents the current Factory implementation. It does not claim that ARVO's campaign outcomes, backlog counts or every proposed duplicate-inheritance rule have been ported. --- Source: https://www.orchestro.org/docs/agents Updated: 2026-09-26 # Run with your coding agent. Updated September 26, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/agents.md) Factory brings the context and the working rules. Your coding CLI does the agent work. Agent execution uses locally installed CLIs authenticated with your existing subscription. Factory does not add a model API billing layer or automatically fall back to a paid API key. Provider quotas and terms still apply. ## Current compatibility | Agent | Setup & context | Loop execution | | --- | --- | --- | | Claude Code | Shared onboarding skill | Claude adapter | | Codex | Shared onboarding skill | Codex adapter | | Grok | Via a compatible skill host | Grok adapter; CLI required | | Muse Spark (Muse CLI) | Mapping + Product Advisor + Governor | No selectable repair worker adapter yet | | Gemini CLI | Shared onboarding skill | No selectable worker adapter yet | | Other agents | Can read the workflow instructions | Requires a supported adapter | ## Muse Spark for mapping, advice and Governor Factory uses the installed `muse` CLI to propose mapping content and run Product Advisor reviews. The Governor also has a Muse runner for bounded decisions and recovery reviews. [Muse Code is Meta’s terminal agent for Muse Spark](https://research.meta.ai/blog/introducing-muse-code-and-muse-spark-1-2). In the current Factory adapter set, Muse supports these review roles; it is not selectable as the autonomous repair worker. Product Advisor with Muse ``` npm run northstar -- product-advisor run --pack packs/my-app --agent muse ``` See the [full command reference](https://www.orchestro.org/docs/tools) for mapping, intake and execution tools. ## One workflow across hosts The project includes a provider-neutral onboarding skill at `.agents/skills/onboard-project/SKILL.md`. A host that does not discover skills can read that file directly and follow it. Reading a skill is different from being a supported unattended worker. The existence of a new CLI or model does not automatically add a new Factory adapter. ## Check your selected agent terminal ``` npm run northstar -- preflight --agent codex ``` For a configured provider chain, check the actual project pack: terminal ``` npm run northstar -- preflight --pack packs/my-app ``` ## When a provider runs out of quota A project can declare a provider chain. When a provider exhausts its subscription quota, Factory can hand the work to the next installed, configured provider. The handover is recorded with the issue. If no configured provider can work, the quota limit remains a visible stop. The models still consume subscription usage. “No separate model API bill” does not mean zero tokens or unlimited capacity. ## Your permission settings travel with the work Provider choice does not expand what Factory is allowed to do. Keep the project’s scope, acceptance criteria and release boundaries explicit, whichever agent handles the task. --- Source: https://www.orchestro.org/docs/tools Updated: 2026-10-04 # Tools for coding agents. Updated October 4, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/tools.md) Skills are what a person asks: connect a project, add or investigate work, ask how the Factory is doing, or start or recover it. The command list underneath is the reference. Give your coding agent the commands to register work, inspect a capability, run a repair and verify the result. This reference covers36 commands from the September 15 catalog snapshot, plus the everyday read commands checked below. Run examples from your installed Factory checkout. `npm run northstar --` invokes the CLI; `factoryctl` is the compatibility alias. These are terminal tools. For MCP connections, see [MCP & integrations](https://www.orchestro.org/docs/mcp). discover the installed command set ``` npm run northstar -- --help npm run northstar -- intake --help ``` ## From a goal to a configured Factory Commands checked against agentic-factory main at `50329f7` on 4 October 2026. The executable is `northstar`; `factoryctl` remains an alias. There is no public Orchestro installer. create the domain scaffold ``` northstar init \ --dir packs/content-factory \ --slug content-factory \ --goal "Build an evidence-led content system for danielepelleri.com: publish useful work, improve discoverability and learn from results." ``` `init` writes a validated domain manifest. It does not discover or connect adapters, grant permissions, or start a live loop. Complete project onboarding and capability reconciliation first. The following are separate operations on that configured project. operate a configured Factory ``` # Check the configured project northstar readiness --pack packs/content-factory # See what can move next northstar checkpoint --pack packs/content-factory # Run the selected work northstar run --pack packs/content-factory # Keep the configured loop watching northstar watch --pack packs/content-factory # Read the cloud connection northstar cloud status --pack packs/content-factory # Ask for the local owner view northstar stato --pack packs/content-factory ``` ## Real commands for everyday questions Read-only operations checked against the private core on 2026-09-26, revision `4dbd119`. Replace `packs/my-app` and example work IDs with your project’s values. These commands require an installed checkout and configured pack; they are not public MCP endpoints. ### Project status Current work, latest durable result, blocker and source freshness. terminal ``` npm run northstar -- stato --json --pack packs/my-app ``` ### Complete backlog All registered work. Filter its returned items in your client. terminal ``` npm run northstar -- backlog list --pack packs/my-app ``` ### Work evidence Lifecycle and recorded receipt kinds for one work identity. terminal ``` npm run northstar -- diary --signal backlog:demo-checkout --pack packs/my-app ``` ### Governor recap Interventions, technical waits and owner escalations in the period. terminal ``` npm run northstar -- governor recap --hours 24 --pack packs/my-app ``` ### Cloud connection Binding, last synchronization and errors; does not run a sync. terminal ``` npm run northstar -- cloud status --pack packs/my-app ``` ### Product map Persisted topology, revision, links and freshness. terminal ``` npm run northstar -- map status --pack packs/my-app ``` ### Success evidence Declared contracts and stored measurement/verification references. terminal ``` npm run northstar -- capability-success status --pack packs/my-app ``` ### Advisor history Recorded advisory runs, provider and published recommendation count. terminal ``` npm run northstar -- product-advisor runs --pack packs/my-app ``` The homepage and How it works use these commands with labelled illustrative output excerpts. Live Factories reads public observations instead of simulating command output. JSON field names follow the current command output, including Italian keys in `stato`. Omitted fields, sample IDs and sample measurements are not production receipts. Check `--help` in your installed version. ## Promote an accepted problem recommendation `owner-decision promote` takes a decision ID and explicit promotion input; `--dry-run` checks eligibility without writing. `owner-decision work` reads back the resulting work. V1 supports `canonical_problem` subjects; capability-level recommendations cannot be promoted directly. Promotion does not launch execution. terminal ``` npm run northstar -- owner-decision --help ``` ## Start from the agent skills * `.agents/skills/onboard-project/SKILL.md` connects a repository, checks prerequisites and configures a project pack. * `.agents/skills/intake-work/SKILL.md` turns the owner’s request into classified work with acceptance criteria, then submits it through intake. A compatible agent can discover these skills or read them directly. The pack defines project sources, commands and permissions. ## Example: register an onboarding experiment The agent classifies the request and prepares the batch. Save this example as `intake.json` after adapting it to the project: intake.json ``` { "items": [ { "request": "Test whether skipping optional setup improves onboarding conversion from 62% to 64%.", "classification": "experiment", "priority": "P2", "requester": "owner", "acceptanceCriteria": [ "Compare eligible new accounts using the same 24-hour activation definition.", "Record the result and sample size for each experiment group.", "Keep project creation p95 below 2 seconds." ] } ] } ``` register and inspect the work ``` npm run northstar -- intake --pack packs/my-app --file intake.json npm run northstar -- backlog list --pack packs/my-app npm run northstar -- checkpoint --pack packs/my-app ``` Intake returns `created` or `deduplicated`, a stable `backlogItemId` and an `intakeDecisionId`. It accepts `verify`, `fix`, `feature`, `experiment` or `decision`. Registering a request does not start execution. ## Example: inspect history and propose a target read the product and its history ``` npm run northstar -- map show --pack packs/my-app npm run northstar -- map history --pack packs/my-app npm run northstar -- memory report --pack packs/my-app npm run northstar -- capability-success status --pack packs/my-app npm run northstar -- product-advisor fact-pack --pack packs/my-app ``` Use the real capability ID returned by your map in place of `onboarding`. Its measurement source and success contract must already be declared. measure, record a hypothesis, then ask the Advisor ``` npm run northstar -- capability-success measure --pack packs/my-app --capability onboarding npm run northstar -- capability-success expect --pack packs/my-app --capability onboarding --hypothesis "Removing optional setup raises 24-hour activation from 62% to 64%." npm run northstar -- product-advisor run --pack packs/my-app --agent muse npm run northstar -- product-advisor brief --pack packs/my-app ``` Muse Spark uses the installed Muse CLI for the advisory step. A recorded hypothesis or accepted Advisor recommendation does not grant engineering or release permission. ## The repair sequence 1. `checkpoint` establishes whether to continue, resume a PR or stop. 2. `triage` produces a bounded task packet. 3. `confirm-cause` validates the cause and failing reproducer before the edit. 4. The worker makes the approved change; `confirm-fix` validates tests and records remediation. 5. `record` records the actual merge and release when authorized. 6. `verify` checks the released behavior independently. `cures` keeps the repair available for later rechecks. `run` supervises worker sessions; `watch` starts work on the configured schedule. A worker cannot award itself independent verification through `record`. ## Complete command reference Snapshot: 2026-09-15, framework revision `5b3cc3a`. Names, syntax, subcommands and listed flags are taken from the CLI registry. Expand a command for its syntax; use installed `--help` for command-specific input schemas and version changes. Find a command 36 of 36 commands ### Connect a project `preflight`Check prerequisites Checks only Checks Node, coding CLIs and GitHub tooling before a project is connected. Reports the missing prerequisite. syntax · replace placeholders ``` npm run northstar -- preflight [--pack ] [--agent ] ``` **Listed options** * `--pack ` * `--agent ` installed help ``` npm run northstar -- preflight --help ``` `adopt`Connect an existing repository Creates a pack Builds a project pack from Git history, including work, release markers and recurring activity. Review the proposed release convention. syntax · replace placeholders ``` npm run northstar -- adopt --repo --pack [--yes] [--force] [options] ``` **Listed options** * `--repo ` * `--name ` * `--mission ` * `--north-star ` * `--release-marker ` * `--release-pattern ` * `--routine-min ` * `--family-min ` * `--limit ` * `--offline` * `--yes` * `--force` installed help ``` npm run northstar -- adopt --help ``` `refresh`Complete readable product context Writes with flags Finds missing labels and user outcomes. --fix applies mechanical corrections; --propose asks an agent for reviewable wording. syntax · replace placeholders ``` npm run northstar -- refresh [--pack | --packs ] [--fix] [--propose] [--json] ``` **Listed options** * `--pack ` * `--packs ` * `--fix` * `--propose` * `--propose-family` * `--propose-value` * `--agent ` * `--batch ` * `--passes ` * `--from ` * `--json` installed help ``` npm run northstar -- refresh --help ``` `truth`Read current problems Runs a probe Runs the probe declared by the pack and returns identified signals with priorities. The configured probe determines source access. syntax · replace placeholders ``` npm run northstar -- truth --pack ``` installed help ``` npm run northstar -- truth --help ``` ### Intake, mapping and planning `intake`Turn a request into durable work Writes backlog intake Validates a full batch of classified requests, checks existing evidence and duplicates, appends the intake decision and returns stable backlog IDs. syntax · replace placeholders ``` npm run northstar -- intake --pack (--json | --file ) ``` **Listed options** * `--json ` * `--file ` installed help ``` npm run northstar -- intake --help ``` `backlog`Manage declared work Writes by subcommand Lists, adds, links and changes work status. Can accept legacy Advisor gaps and import Strategist proposals. Status updates append history. syntax · replace placeholders ``` npm run northstar -- backlog [list|add|accept|link|set-status|import-proposal] --pack [options] ``` **Subcommands:** `list``add``accept``link``set-status``import-proposal` **Listed options** * `--title ` * `--priority ` * `--evidence ` * `--id ` * `--status ` * `--signal ` * `--family ` * `--gap ` * `--proposal ` installed help ``` npm run northstar -- backlog --help ``` `roadmap`Review and update the roadmap Writes by subcommand Reads and validates the roadmap, previews a patch, applies it or activates a node. Preview first and preserve revision checks. syntax · replace placeholders ``` npm run northstar -- roadmap [status|validate|preview|apply|activate] --pack [--file ] ``` **Subcommands:** `status``validate``preview``apply``activate` **Listed options** * `--file ` installed help ``` npm run northstar -- roadmap --help ``` `milestone`Set a measurable project milestone Writes by subcommand Records a milestone, selects the active one or records completion. Declaring a target and achieving it are separate events. syntax · replace placeholders ``` npm run northstar -- milestone [list|add|set|done] "" --pack [options] ``` **Subcommands:** `list``add``set``done` **Listed options** * `--name ` * `--hint ` * `--progress ` * `--tail ` * `--node ` * `--no-node` * `--no-activate` installed help ``` npm run northstar -- milestone --help ``` `issues`Schedule work Plan changes state Reads the work plan or assigns an issue identity to a sprint, target date and position. Supports an expected revision for writes. syntax · replace placeholders ``` npm run northstar -- issues [status|plan] --pack [--identity --sprint --target-date --position ] ``` **Subcommands:** `status``plan` **Listed options** * `--identity ` * `--sprint ` * `--target-date ` * `--position ` * `--expected-revision ` installed help ``` npm run northstar -- issues --help ``` `relations`Connect causes and dependencies Add changes state Lists or adds same-cause and dependency relationships. Validates the graph and rejects dependency cycles. Confirm shared causes with evidence. syntax · replace placeholders ``` npm run northstar -- relations [list|add] --pack [--from --to --kind --note ] ``` **Subcommands:** `list``add` **Listed options** * `--from ` * `--to ` * `--kind ` * `--note ` installed help ``` npm run northstar -- relations --help ``` `map`Build and maintain the capability map Writes by subcommand Scans and proposes topology, detects Git-based drift, revises or declares nodes and links, and reads current or historical capability views. Proposed and declared links remain distinct. syntax · replace placeholders ``` npm run northstar -- map [scan|drift|revise|declare|propose-topology|propose-links|retract-link|status|history|show] --pack [options] ``` **Subcommands:** `scan``drift``revise``declare``propose-topology``propose-links``retract-link``status``history``show` **Listed options** * `--patch ` * `--file ` * `--node ` * `--edge ` * `--expected-revision ` * `--link ` * `--label ` * `--batch ` * `--agent ` * `--revision ` * `--revisit` * `--history` installed help ``` npm run northstar -- map --help ``` `reproject`Correct a derived view Preview or governed write Previews and applies controlled projection corrections while preserving the raw ledger. Use the frozen count, hash and cutoff safeguards. syntax · replace placeholders ``` npm run northstar -- reproject --pack (--json | --file ) [--dry-run] ``` **Listed options** * `--json ` * `--file ` * `--dry-run` installed help ``` npm run northstar -- reproject --help ``` ### Advice, decisions and product metrics `strategist`Review the selected work Records a review Evaluates a bounded task packet against mission, metrics and history. Produces a recommendation and rationale, not lifecycle proof. syntax · replace placeholders ``` npm run northstar -- strategist --pack [--agent ] ``` **Listed options** * `--agent ` installed help ``` npm run northstar -- strategist --help ``` `audit`Find reproducible work Investigates and writes Investigates under the pack’s declared audit perspective, records evidence and turns findings into backlog work. Each pass tracks what changed. syntax · replace placeholders ``` npm run northstar -- audit --pack [--agent ] ``` **Listed options** * `--agent ` installed help ``` npm run northstar -- audit --help ``` `advisor`Track gaps against a goal Writes gap records Scans threshold gaps or records a declared opportunity. Gaps become backlog work through backlog accept. This is distinct from product-advisor. syntax · replace placeholders ``` npm run northstar -- advisor [scan|add|dismiss] --pack [options] ``` **Subcommands:** `scan``add``dismiss` **Listed options** * `--kind ` * `--title ` * `--why ` * `--score <1|2|3>` * `--lane ` * `--short ` * `--gap ` * `--source ` * `--url ` * `--voices ` * `--last-at ` * `--limit ` installed help ``` npm run northstar -- advisor --help ``` `product-advisor`Review capabilities and engineering history Records advice Builds fact packs, candidates and bounded model reviews. Records advisory runs without changing the lifecycle, backlog or product map. syntax · replace placeholders ``` npm run northstar -- product-advisor [fact-pack|candidates|run|brief|runs|audit|review-pack] --pack [options] ``` **Subcommands:** `fact-pack``candidates``run``brief``runs``audit``review-pack` **Listed options** * `--agent ` * `--top ` * `--batch ` * `--json` installed help ``` npm run northstar -- product-advisor --help ``` `owner-decision`Keep owner decisions and outcomes Records decisions or explicitly promotes eligible work; no execution Records owner judgments on Advisor recommendations. Explicit promotion checks eligibility and enters the existing governed intake; work reads back its state. Neither action launches an executor or grants release permission. syntax · replace placeholders ``` npm run northstar -- owner-decision [record|history|position|outcomes|metrics|promote|work] --pack [options] ``` **Subcommands:** `record``history``position``outcomes``metrics``promote``work` **Listed options** * `--run ` * `--subject ` * `--subject-type ` * `--decision ` * `--decision ` * `--rationale ` * `--by ` * `--supersedes ` * `--json ` * `--file ` * `--dry-run` installed help ``` npm run northstar -- owner-decision --help ``` `capability-success`Measure a capability’s product benefit Measures and records Reads status, runs declared measurements, records a hypothesis and compares stored before/after observations with an explicit attribution basis. Does not authorize engineering work. syntax · replace placeholders ``` npm run northstar -- capability-success [status|measure|expect|verify-benefit] --pack [options] ``` **Subcommands:** `status``measure``expect``verify-benefit` **Listed options** * `--capability ` * `--hypothesis ` * `--by ` * `--baseline ` * `--expectation ` * `--after ` * `--before ` * `--release ` * `--attribution-kind ` * `--attribution-ref ` installed help ``` npm run northstar -- capability-success --help ``` `approve`Approve a Strategist proposal Owner authority required Records the owner’s approval for a specific proposal. A coding agent must already have authority to represent that decision. syntax · replace placeholders ``` npm run northstar -- approve --pack --proposal ``` **Listed options** * `--proposal ` installed help ``` npm run northstar -- approve --help ``` `approvals`Inspect approvals and expired claims Sweep changes state Lists approvals. The explicit sweep operation releases expired claims; it is not an automatic background action. syntax · replace placeholders ``` npm run northstar -- approvals [list|sweep] --pack [--max-age-minutes ] ``` **Subcommands:** `list``sweep` **Listed options** * `--max-age-minutes ` installed help ``` npm run northstar -- approvals --help ``` `upstream`Review framework drift Decision writes Compares declared upstream baselines with mirrors and records decisions on differences. Use for framework maintenance, not ordinary product repair. syntax · replace placeholders ``` npm run northstar -- upstream [check|decide|decisions] [--repo ] [--ref ] [--dir ] ``` **Subcommands:** `check``decide``decisions` **Listed options** * `--repo ` * `--ref ` * `--dir ` * `--json | --file ` * `--priority ` * `--promotion-title ` installed help ``` npm run northstar -- upstream --help ``` ### Run, verify and watch `triage`Select one task Reads state Returns at most one task packet with its issue boundary and required evidence. It does not start a worker. syntax · replace placeholders ``` npm run northstar -- triage --pack ``` installed help ``` npm run northstar -- triage --help ``` `checkpoint`Decide whether the loop can stop Reads state Reports executable work, an active PR to resume, a human dependency or a valid stop. Use at the start and end of a run. syntax · replace placeholders ``` npm run northstar -- checkpoint --pack ``` installed help ``` npm run northstar -- checkpoint --help ``` `run`Execute bounded repair work Executes work Starts a coding worker in a dedicated worktree and resumes according to checkpoint results. Pack permissions and per-run budgets apply. syntax · replace placeholders ``` npm run northstar -- run --pack [--agent ] [--require-strategist] [limits] ``` **Listed options** * `--agent ` * `--agent-args ` * `--require-strategist` * `--strategist-agent ` * `--resume-worktree ` * `--max-hours ` * `--max-invocations ` * `--max-consecutive-failures ` * `--max-consecutive-no-progress ` * `--max-consecutive-execution-only ` * `--worker-timeout-minutes ` installed help ``` npm run northstar -- run --help ``` `watch`Keep checking on a schedule Schedules work Records periodic observations and launches the configured run command when work exists. Requires the pack schedule and a running host. syntax · replace placeholders ``` npm run northstar -- watch --pack ``` installed help ``` npm run northstar -- watch --help ``` `confirm-cause`Validate the cause before editing Validates and records Checks the evidence and failing reproducer before a repair begins. Rejects unsupported cause claims without writing a receipt. syntax · replace placeholders ``` npm run northstar -- confirm-cause --pack (--json | --file ) ``` **Listed options** * `--json ` * `--file ` installed help ``` npm run northstar -- confirm-cause --help ``` `confirm-fix`Record a tested repair Validates and records Checks the passing reproducer, test suite and bounded change. This is the command that creates a remediation receipt. syntax · replace placeholders ``` npm run northstar -- confirm-fix --pack (--json | --file ) ``` **Listed options** * `--json ` * `--file ` installed help ``` npm run northstar -- confirm-fix --help ``` `record`Record a lifecycle event Writes a receipt Appends evidence of a merge, deployment, decision or resolution. It cannot create remediation or independent verification receipts. syntax · replace placeholders ``` npm run northstar -- record --pack (--json | --file ) ``` **Listed options** * `--json ` * `--file ` installed help ``` npm run northstar -- record --help ``` `verify`Independently check the released fix Runs checks and records Runs the configured verifier against the released revision outside the worker’s worktree. Can detect recurrence on a previously verified repair. syntax · replace placeholders ``` npm run northstar -- verify --pack [--signal ] ``` **Listed options** * `--signal ` installed help ``` npm run northstar -- verify --help ``` `cures`Inspect and recheck repairs Rechecks with a flag Lists verified repair boundaries and their measuring commands. --cure reruns the check for a selected repair. syntax · replace placeholders ``` npm run northstar -- cures --pack [--cure ] ``` **Listed options** * `--cure ` installed help ``` npm run northstar -- cures --help ``` ### Inspect, measure and preserve history `diary`Read lifecycle history Reads state Reads ledger receipts for a signal identity or family. Use it to reconstruct attempted fixes, releases and verification. syntax · replace placeholders ``` npm run northstar -- diary --pack [--signal | --family ] ``` **Listed options** * `--signal ` * `--family ` installed help ``` npm run northstar -- diary --help ``` `metrics`Measure project metrics Measures; optional record Runs the declared metric sources and reports values and history length. --record saves an observation. Missing values remain unknown. syntax · replace placeholders ``` npm run northstar -- metrics --pack [--record] ``` **Listed options** * `--record` installed help ``` npm run northstar -- metrics --help ``` `board`Read the owner board Reads; optional export Builds a view across project packs. Unreadable packs remain visible. --html writes the board to a local file. syntax · replace placeholders ``` npm run northstar -- board [--packs ] [--project ] [--view owner] [--html ] [--plain] ``` **Listed options** * `--packs ` * `--project ` * `--view owner` * `--html ` * `--plain` installed help ``` npm run northstar -- board --help ``` `serve`Open the local board Starts local server Serves a live view of project packs on a local port. This starts the board server, not a repair worker. syntax · replace placeholders ``` npm run northstar -- serve --packs [--port ] ``` **Listed options** * `--packs ` * `--port ` installed help ``` npm run northstar -- serve --help ``` `durability`Back up or restore Factory state Restore replaces state Checks whether state has a mirror, copies the complete .factory directory, or restores it from a chosen mirror. Restore replaces local Factory state. syntax · replace placeholders ``` npm run northstar -- durability [status|mirror|restore] --pack [--from ] ``` **Subcommands:** `status``mirror``restore` **Listed options** * `--from ` installed help ``` npm run northstar -- durability --help ``` `memory`Reconcile engineering evidence Writes imported evidence Imports bounded evidence from database, Git and diaries; links identifiers and reports reconciliation or mapping eligibility. Reads source repositories without modifying them. syntax · replace placeholders ``` npm run northstar -- memory [import-db|import-git|import-diary|link|report|delta] --pack [--repo --repo-slug |--offline] [--docs ] ``` **Subcommands:** `import-db``import-git``import-diary``link``report``delta` **Listed options** * `--repo ` * `--repo-slug ` * `--docs ` * `--offline` installed help ``` npm run northstar -- memory --help ``` ## Exit codes and authority Read the command’s result, not only its process status. For example, `checkpoint` exit 2 means work must continue or an active PR must resume. `verify` exit 2 means a check failed or a repair recurred. `run` exit 0 can represent a declared human dependency, not a completed repair. Commands that approve decisions, apply roadmap changes, restore state or execute work require the corresponding owner authority and pack permissions. Use actual evidence files for receipts; do not invent release or verification claims. --- Source: https://www.orchestro.org/docs/mcp Updated: 2026-10-04 # Web, chat and CLI. One project history. Updated October 4, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/mcp.md) 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. **Private hosted MCP is deployed. Chat-client acceptance is separate.** 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](https://www.orchestro.org/live) or [inspect the local CLI reference](https://www.orchestro.org/docs/tools#everyday-jobs). ## Conversation expresses intent; the Factory remains the authority Chat client → authenticated Orchestro MCPCloud intent → local pull → canonical intake / decisionAuthorized execution → independent evidence → cloud readback 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](https://www.orchestro.org/how-it-works#intent). ## 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. 1. Configure the tools and credentials in your coding host. 2. Use the [private onboarding path](https://www.orchestro.org/docs/quickstart) to declare project sources, evidence rules and allowed actions. 3. 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. [Legacy MCP repository](https://github.com/khaoss85/mcp-orchestro) ## Documentation for agents [/llms.txt](https://www.orchestro.org/llms.txt) and each page’s Markdown export are generated from the same visible documentation. [commands.json](https://www.orchestro.org/commands.json) is the dated CLI catalog, not the hosted MCP tool inventory above. [Check availability and remaining acceptance work](https://www.orchestro.org/docs/roadmap). --- Source: https://www.orchestro.org/docs/use-cases Updated: 2026-09-30 # Product capability monitoring for app teams. Updated September 30, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/use-cases.md) These are product-metric examples (onboarding, tool calls, errors, analytics), not the Governor cases false-blocker, owner decision, self-healing, or self-learning. Start with an outcome your users need. Connect it to the code and evidence that explain what happens. Give that capability one primary metric and a few guardrails. **Illustrative app data.** These baselines and targets explain the workflow. They are not customer results or measured Factory benchmarks. Past observations establish the history. Current measurements identify the gap. The Advisor can recommend a target and a course of action; the owner decides what to pursue. An accepted recommendation does not grant release permission. ## Onboarding flow “Create my first project without getting stuck.” Sign-up → email verification → Create project → Shared session context ### Accounts activated within 24 hours Past sample**63%** Current baseline**62%** Proposed target**64%** Definition Activated accounts / eligible new accounts. 1,000 mature accounts per sample; exclude test and bot accounts. Evidence Funnel events + server logs + reproduced session failure Observation Session refresh loses the workspace ID. Advisor proposal Restore session continuity, then test removing one optional onboarding step. +2 percentage points. Target for the next 30 days. Guardrail Project creation p95 <2s [Follow shared issue F-17 through repair, verification and recurrence →](https://www.orchestro.org/docs/how-it-works#seven-day-example) ## AI assistant “Have the agent complete the action I asked for.” Chat interface → Tool router → Shared session context ### Successful tool calls Past sample**90%** Current baseline**91%** Proposed target**95%** Definition Tool calls with a validated result / eligible tool calls. 1,000 calls per sample, same tool mix. Evidence Tool traces + permission errors + shared cause confirmed in F-17 Observation Tool requests lose the same workspace context. Advisor proposal Fix session-related failures and validate tool arguments before dispatch. +4 percentage points. Target for the next 30 days. Guardrail Tool response p95 <3s [Follow shared issue F-17 through repair, verification and recurrence →](https://www.orchestro.org/docs/how-it-works#seven-day-example) ## Server reliability “Finish the action without a server error.” App requests → API services → Structured logs + traces ### Requests without a server error Past sample**99.1%** Current baseline**99.5%** Proposed target**99.9%** Definition Requests without a 5xx response / eligible production requests. 100,000 requests per sample, same endpoints. Evidence Request logs + trace IDs + synthetic checks; example sample only Observation Error logs identify where requests fail. A quiet log alone is not proof of recovery. Advisor proposal Rank error clusters by affected user flow; repair the recurring timeout first. +0.4 percentage points. Target for the next 30 days. Guardrail API response p95 <500ms ## Analytics dashboard “Open a report and trust that it is current.” Report screen → Query service → Warehouse + event pipeline ### Report load time, p95 Past sample**2.8s** Current baseline**1.8s** Proposed target**<1.0s** Definition p95 across 1,000 report loads per sample. Same report mix and device segment. Evidence Browser timings + query traces + ingestion freshness checks Observation The event pipeline is current; slow queries still delay report loading. Advisor proposal Optimize the slowest query path and verify that cached reports stay fresh. At least 0.8s faster. Target for the next 30 days. Guardrail Data freshness <15 minutes ## A passing test and a better product are separate results. First verify the released repair independently. Then compare mature samples using the same metric definition and population. Record missing evidence or an inconclusive result. A before-and-after increase does not, by itself, establish that the repair caused the change. [Use the capability-success commands](https://www.orchestro.org/docs/tools#tool-capability-success) to define contracts and record measurements. See [current availability](https://www.orchestro.org/docs/roadmap) for the remaining Advisor-to-work integration and full product-outcome pilot. Running campaigns instead of an app? [See the growth loop →](https://www.orchestro.org/docs/grow) --- Source: https://www.orchestro.org/docs/grow Updated: 2026-10-03 # Content runs on the same kernel. Updated October 3, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/grow.md) Content is the second real domain: evidence mining, thesis, articles, editorial reviews, SEO and internal linking, publishing, post-publish verification, measurement and learning. **Content Factory: live pilot, manually configured.** The pilot on danielepelleri.com reuses the Reliability kernel. Only editorial work, evidence, policies, adapters and completion rules are domain-specific. General campaign integrations are not shipped. The campaign example below remains illustrative; the Content pilot is not evidence of traffic, conversion or revenue lift. ## One campaign loop, week by week A team wants more trial sign-ups from content. Their loop declares one primary metric — qualified trials per week — plus guardrails: spend cap, brand voice, and no publish without owner approval. | When | What changes | What Orchestro retains | | --- | --- | --- | | Week 1 | Baseline measured: 40 qualified trials, same offer. | Metric definition, population, window, baseline | | Week 2 | Two variants drafted; you approve one to publish. | Hypothesis, approved variant, publish receipt | | Week 3 | 55 trials measured; spend and voice guardrails hold. | Outcome sample; movement recorded, not proof of cause | | Week 4 | Results favor one angle; the loop proposes round two. | Decision history; losing variant retired with reasons | ## What carries over from the repair loop * **Success contracts:** one primary metric plus a few guardrails, declared before work starts. * **Approvals stay yours:** spend, publish and voice decisions need the owner; drafting does not. * **Doing ≠ certifying:** whoever drafts the variant never declares it a winner alone. * **Honest attribution:** before/after movement is movement, not proof the loop caused it. ## Shape it with us Grow partners bring one campaign or experiment with a metric they already read. We scope the loop together, starting from measurement — never from automation. [Join as a Grow partner](https://www.orchestro.org/early-access?track=grow) --- Source: https://www.orchestro.org/docs/faq Updated: 2026-10-04 # Questions about Orchestro. Updated October 4, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/faq.md) What Factory does, what it costs to run, and where the owner stays involved. ## What is Orchestro? Orchestro is the control plane for autonomous software agents. It maintains persistent AI-agent loops with durable state, work selection, recovery, independent verification, production feedback and learning. Your models supply intelligence and agent harnesses execute; Orchestro keeps the work and evidence connected. Super private beta, primarily used on our own internal projects. The preview is free with hands-on onboarding; users supply their own agents, subscriptions and infrastructure. Public self-service access and broader unattended autonomy remain in development. [Read the product overview →](https://www.orchestro.org/docs) ## What does ‘Same kernel. Different domain.’ mean? The Reliability Factory and Content Factory pilot reuse the same durable work, ledger, lifecycle, selector, executor and verifier. Content adds editorial vocabulary, evidence, policy, reviews and publishing adapters. We did not build a second orchestrator. This proves reuse across two domains, not universal domain support. [Read the discovery →](https://www.orchestro.org/story#content-factory) ## Does Factory replace my coding agent? Factory coordinates your existing coding agents. Codex, Claude Code and Grok have repair-worker adapters. Muse Spark supports mapping proposals, Product Advisor reviews and the Governor runner through the Muse CLI. The project keeps its issue history, evidence and permissions across supported agents. [Check supported roles →](https://www.orchestro.org/docs/agents) ## What can Factory monitor in an app? Factory maps product capabilities such as onboarding, an AI assistant, server reliability and analytics. Each capability connects a user goal to screens, services, agents and data. Its success contract defines a metric, population, observation window, baseline, target and guardrails. [Explore app use cases →](https://www.orchestro.org/docs/use-cases) ## How does Factory recognize a bug that comes back? It preserves the confirmed cause, attempted fixes, releases and independent checks. When a later failure reproduces the same cause, the issue can reopen with its earlier repair history attached. A similar complaint alone is not enough to establish recurrence. [Follow the repair example →](https://www.orchestro.org/docs/how-it-works) ## Can the agent loop keep working for several days? A configured watch process can keep checking and launching authorized work across days. It needs an awake host, a project schedule, authenticated CLIs and available quota. Individual worker runs still have limits; missing permission or evidence can require owner attention. [Set up scheduled operation →](https://www.orchestro.org/docs/quickstart) ## Does Factory require a separate model API bill? The supported CLI workflow uses your coding-agent subscriptions rather than adding a separate model API billing layer. Model calls still consume subscription quota, and provider terms and limits apply. This is not zero-token or unlimited model execution. The private preview is free; users cover their own agent and infrastructure costs. [Understand providers and quotas →](https://www.orchestro.org/docs/agents) ## Does accepting an Advisor recommendation deploy a change? No. An owner decision records intent and rationale. It does not grant code, merge or release permission. An explicit promotion can pass an accepted canonical-problem recommendation into governed intake after checking its scope and current evidence. That promotion still does not start execution. [See current availability →](https://www.orchestro.org/docs/roadmap) ## How do you distinguish a successful fix from a product improvement? An independent check establishes whether the released repair works. Separate capability measurements compare product outcomes using the same definition and population. For example, onboarding activation might move from 62% to a proposed 64%. Before-and-after movement alone does not prove the repair caused it. [See metrics and guardrails →](https://www.orchestro.org/docs/use-cases) ## How does a coding agent add work to Factory? The intake-work skill turns an owner request into a classified batch with acceptance criteria. The intake command validates the batch, checks for duplicates and returns stable backlog and decision IDs. Registering work does not start an agent. The CLI reference includes a complete JSON example. [Copy an intake example →](https://www.orchestro.org/docs/tools#intake-example) ## Is Orchestro publicly available? Orchestro is in private early access with hands-on setup. The owner cockpit and authenticated hosted MCP endpoint are deployed. Content has a public read-only observation; ARVO’s public view is Coming online. Public self-service onboarding and complete ChatGPT / Claude client acceptance remain unfinished. [Read access requirements →](https://www.orchestro.org/docs/quickstart) ## Is Orchestro the same as the old MCP package? Orchestro is the product. The legacy mcp-orchestro package remains a separate implementation with its own repository. Nothing migrates automatically: tasks, data, settings and MCP installations stay where they are. [Name and history →](https://www.orchestro.org/docs/orchestro) ## Can I define my own loop? The original Reliability and Content pilots were manually configured. In the private core, northstar init creates a valid domain manifest from a goal; it does not connect tools or start the loop. Domain Builder / Compiler V1 and agent-guided bootstrap reconcile real capabilities and report ready or not ready. Public self-service onboarding is still in development. [See the loop model →](https://www.orchestro.org/docs/loops) ## Can Orchestro run marketing campaigns? A Content Factory pilot runs on danielepelleri.com using the same kernel as Reliability: evidence mining, thesis, articles, reviews, publishing and post-publish checks, with measurement and learning work retained. It is manually configured. General campaign, outbound sales and paid media integrations are still directions to validate, not shipped products. [See the growth loop →](https://www.orchestro.org/docs/grow) ## Which views are live, historical or illustrative? Live Factories uses a dedicated public-safe read model with observation times and honest stale or unavailable states. Product illustrations and the retained operating examples use labelled sample data. Their metrics are not customer benchmarks. The Story page identifies real historical cases separately. [Review implementation status →](https://www.orchestro.org/docs/roadmap) ## What does the Governor do? The Governor supervises the Factory within configured authority, evaluates stalls and records interventions. It cannot grant itself new permissions. Owner decisions, unavailable dependencies and insufficient evidence may still require a wait. A resolved blocker and verified resumption are separate facts. [Read the product overview →](https://www.orchestro.org/docs) ## When does the owner need to step in? The owner steps in when a recorded gate needs their decision or access: for example strategy, publishing approval or a missing credential. External dependencies and evidence waits are separate categories. The cockpit reports what is blocked and its scope when canonical data supports it; unknown scope is not inferred. [See owner decisions →](https://www.orchestro.org/how-it-works#blockers) ## What happens overnight? A configured local loop can select and execute authorized work while its host and providers are available. The private cockpit summarizes recorded movement, requests and interruptions. Last durable progress is shown separately from a heartbeat. No activity is invented when the projection is missing or stale. [See current availability →](https://www.orchestro.org/docs/roadmap) ## Can I use my existing MCP tools? Your coding agent can use MCP servers configured in its host, within the project’s permissions. Separately, the private hosted Orchestro MCP endpoint exposes project-scoped reads and bounded owner intent. The local Factory materializes work and verifies results. ChatGPT / Claude client onboarding still needs end-to-end acceptance. [See the MCP workflow →](https://www.orchestro.org/docs/mcp) ## Are Web, Chat, and CLI different systems? Web, hosted MCP and the local CLI expose the same project model. Cloud requests remain intent until consumed locally; they do not directly mutate the ledger or start a worker. The private cockpit and MCP endpoint are deployed. A complete ChatGPT / Claude owner conversation is not yet claimed as proven. [See chat and integrations →](https://www.orchestro.org/docs/mcp) ## Can I check my Factory from the cloud? Yes, for configured private projects. The deployed cockpit shows work, requests, owner actions, progress and Blockers & Recoveries, with observation freshness. Execution stays on the project’s Mac or server. Content also has a smaller public read-only projection; ARVO’s public view is Coming online. Public self-service setup remains in development. [See cloud availability →](https://www.orchestro.org/docs/mcp#cloud-factory) ## Are the CLI examples real commands? The examples use actual private-core CLI syntax for status, backlog, Governor, mapping, capability success and Advisor history. Responses are illustrative excerpts using the command output fields, not live project receipts. Run commands from an installed checkout with your own configured project pack. [Read the command setup →](https://www.orchestro.org/docs/tools#everyday-jobs) --- Source: https://www.orchestro.org/docs/roadmap Updated: 2026-10-04 # Built, next, and still being explored. Updated October 4, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/roadmap.md) A running private product, public observations and clear limits on what has been proved. Availability and evidence snapshot · 4 October 2026 ## Deployed / private preview * **Owner cockpit:** project switching, current work, freshness, requests, owner actions, progress and Blockers & Recoveries. Some historical scope and recovery facts are not recorded; they remain unknown. * **Content public view:** a current read model with timestamps and a dedicated sanitized projection. [Live Factories](https://www.orchestro.org/live) shows the latest availability, including stale or unavailable states. * **Hosted MCP:** authenticated, project-scoped reads and bounded owner intents. Local canonical intake and decisions remain authoritative. The deployed transport is not proof of a complete ChatGPT / Claude onboarding experience. ARVO’s public cockpit is **Coming online**. Its historical Reliability work is a real case, not a live public feed. Owner access remains private; there is no general self-service SaaS. ## Proven historical domains * **Autonomous Reliability Factory:** ARVO supplied real investigation, repair, verification and operating lessons. Actual actions depend on the pack’s permissions and release authority. * **Autonomous Content Factory pilot:** danielepelleri.com reuses the same ledger, backlog, lifecycle, selector and executor / verifier. The manually configured domain adds evidence, thesis, writing, editorial reviews, SEO, internal linking and publishing checks. These cases demonstrate domain reuse. They do not establish traffic growth, revenue impact or universal integrations. The [dated ARVO account](https://www.orchestro.org/story#proof) retains its historical adoption and benchmark limits. ## Implemented in the private core * **Goal scaffold:** `northstar init --dir --goal ` creates a validated domain manifest. It does not connect adapters, grant permissions or start execution. * **Domain Builder / Compiler V1:** validates an agent’s proposal against real capabilities, materializes work and reports READY or NOT\_READY. * **Capability reconciliation:** names gaps in truth, execution, verification, durability, mapping, cloud, watch and board. * **Cloud intent processing:** passes allowed requests through local intake, roadmap and owner-decision primitives with idempotent receipts. Requested, materialized, selected and delivered remain separate. * **Executor chain:** ordered alternatives exist for configured providers. No automatic failover or unattended Mac reboot story is claimed as proven live without the corresponding runtime receipts. * **Sales domain:** cross-domain implementation and test evidence exist. This is not a live sales pilot or proven CRM / revenue integration. ## In development / not yet proven end to end * **Self-service onboarding:** public installation, credentials, integration setup and a ready Factory from a goal without hands-on assistance. * **Chat client acceptance:** ChatGPT / Claude client installation and a complete owner request → local work → outcome conversation. * **Recovery evidence:** comprehensive unattended recovery, meaningful interruption duration and proof of work resuming where historical canonical facts are missing. * **Owner outcomes:** domain-defined mission and readiness metrics need a configured definition and real measurements. No configured metric means “Owner outcome metric not configured”. * **Broader autonomy:** general event-driven wakeups, automatically promoted learning rules and complete Operational Zero certification require separate evidence and governance. ## Cloud and runtime have different responsibilities Cloud guides. Local Factory executes. Evidence decides. The cloud holds project-scoped observations and owner intent. The execution host retains canonical work, authority checks and verification. A remote request cannot grant itself merge or release permission. [Read the MCP and cloud boundaries](https://www.orchestro.org/docs/mcp#cloud-factory). ## Real observations versus examples [Live Factories](https://www.orchestro.org/live) reads public-safe operational data and labels its age. It does not use a simulated backlog. [How it works](https://www.orchestro.org/how-it-works) uses labelled product illustrations to explain the system. The [retained operating examples](https://www.orchestro.org/docs/operating-examples) are simulations, including campaign workflows and synthetic metrics. No example click executes a command, deploys code or publishes an article. Technical verification and measured product benefit remain separate. ## Try a bounded private pilot Bring a goal with readable evidence and clear limits. Setup is hands-on. [Request private access](https://www.orchestro.org/early-access) or follow the [repository setup guide](https://www.orchestro.org/docs/quickstart). --- Source: https://www.orchestro.org/docs/orchestro Updated: 2026-10-03 # Orchestro, and what came before. Updated October 3, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/orchestro.md) Orchestro is the product. Older pieces keep their names where the code still uses them. Orchestro began with a straightforward idea: help people and coding agents turn product ideas into working software. It is now the runtime for autonomous operations: a shared kernel maintains work, evidence, verification and authority across domains. Reliability and Content are the first two proof points. The ARVO Reliability Factory taught us why active agents do not automatically mean useful progress. [Read our story and the lessons behind Orchestro](https://www.orchestro.org/story), or [explore the core and project packs](https://www.orchestro.org/how-it-works#domains). ## One name across this site The old landing page, screenshots and installation pitch have been replaced by the product explanation and documentation. Builders run the repair loop; a Content Factory pilot reuses its kernel. General campaign operations remain a direction to validate. ## What happens to an existing MCP installation? An existing mcp-orchestro installation is a separate project. This website does not change its code, data or configuration. Keep using the [legacy repository](https://github.com/khaoss85/mcp-orchestro) for the documentation corresponding to that package. The previous `npx @orchestro/init` command belongs to that package. It does not install Orchestro. ## Why do commands say “northstar”? The current private repository uses `northstar` as its package command. `factoryctl` remains a compatibility alias. Orchestro is the public product name; the documentation uses the actual executable names so examples match the code. ## Make a fresh connection Orchestro onboarding starts from your project and its current evidence. There is no automatic migration of legacy tasks, memory or MCP configuration advertised at this stage. [Read the Orchestro quickstart](https://www.orchestro.org/docs/quickstart)