orchestro.
Persistent AI-agent loops Private preview

Give your project a goal.
Keep it moving.

A Factory turns your goal into durable work. It runs your agents on your machine, verifies the results and remembers what happened—so the next cycle starts with context.

See how a Factory works Explore the real build

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

  1. 01Init
  2. 02Build
  3. 03Run
  4. 04Watch
  5. 05Evolve
01Give 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.

Real command in the private core. init creates the scaffold; onboarding must establish readiness before the loop can run.

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
02Build the work system

The goal becomes
a roadmap.

Onboarding connects the goal to capabilities, observable sources, evidence rules and the work to do first. It checks what the project can actually observe, change and verify.

Metrics need measurable sources. Permissions need authority. Missing capabilities stay visible.

The roadmap keeps evolving from authorized evidence and learning.

Domain Builder / Compiler V1 is implemented in the private core. Guided public onboarding is still in development.

Content Factory / operating modelIllustrative view
GoalA publication that keeps getting better.
Evidence miningWritingSEOInternal linkingDistributionMeasurement
Durable workPriority
ArticleTurn a real engineering incident into a storyP1
SEOMake every published article discoverableP2
LinkingConnect the article to its topic clusterP2
MeasureReview results when a GSC export arrivesP2
New evidence can become the next authorized work.
03Turn on the loop

Your agents do the work.
The Factory keeps continuity.

The loop runs on the Mac or server that has access to your project. An ordered executor chain can move between Claude Code, Codex and Grok.

Work is selected, executed, independently checked and recorded. A wait for evidence can leave unrelated work free to move.

“Done” needs evidence. A chat message is not enough.

How verification works

A running host, configured tools, permissions and provider quota are required. Durable state supports recovery across sessions and restarts; execution pauses when the host is offline.

Your Mac or serverExecution stays here
Factory loopConfigured executor chain
Claude CodeCodexGrok
ObserveSelectExecuteVerifyRecordLearnNext
Content work · example sequenceFrom source evidence to a published article
Source evidence attached
Draft produced and reviewed
Published output checked
Select the next eligible item
RepositoryTestsAPIsProject tools
04Watch from anywhere

The Factory runs there.
You see it from here.

The owner view puts the useful questions on one screen: what is running, what was delivered, what is waiting, and what needs you.

Open one URL on your phone. Switch projects. See the last durable progress and how fresh the snapshot is.

The Mac does the work.
Your phone shows what happened.

Owner cockpit live in private preview. The illustrated numbers are sample data; public observations are available on the Live page.

The owner viewOne glance.
The next useful decision.
orchestro.Design preview
RunningSample data
Working on

Cluster linking sprint

Codex · last durable progress 4 min ago
Requests3New
Delivered12This week
Needs you0Decisions
What’s left5 ready · 2 waiting
Blockers & recoveriesNo active blockers ↗
Recent activity
Article published
Request accepted
SEO audit completed
Snapshot synced 1 min ago

Owner cockpit · live private preview.
Interactive illustration, not a live project.

05Keep 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.

The control path is explicit: chat → Orchestro MCP → cloud intent → local governed intake → execution and evidence → cloud readback.

Conversation expresses intent.
The Factory remains the authority.

Hosted MCP is implemented in private preview. ChatGPT / Claude require a configured client; public self-service chat onboarding is not yet available.

ChatGPT / ClaudeIllustrative conversation
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
Add a P2 task to build a downloadable content audit tool.
Orchestro

Request sent. The local Factory checks it through governed intake.

After local acceptance
backlog:example-audit-tool · P2

Eligible work enters the same backlog. Sending a request alone does not mean it is running.

Why hasn’t the measurement item moved?

It needs external evidence. The wait belongs to that item; it does not erase its context.

Chat-to-Factory experience in development
06Operate directly

And everything still
has a command.

Read readiness. Inspect the next work. Run the loop. Check the cloud connection. The direct local interface stays available.

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.

Explore the CLI reference

Current CLI, illustrative pack path. These are separate operations on a configured project, not a copy-and-run installation script.

After project onboardingnorthstar
# 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 project / danielepelleri.com

A real Factory.
Actual published work.

We gave a Content Factory a goal: build an evidence-led publication from real work. Editorial, SEO and discovery work became durable jobs on the same kernel used for software reliability.

Real projectReal backlogReal outputPublished 3 October 2026
Pillar article01

Building the Autonomous Company

A long-form guide connecting real failures, operating loops and designed control.

Publication commit f40812fEngineering story02

Il retry che riceveva per sempre la riga morta

An evidence-led article about an idempotency key that kept returning a failed job.

Publication commit 3a9e1bfProduct lesson03

Quando le pagine di marketing promettono ciò che il prodotto non fa

A published account of finding and correcting unsupported product claims.

Publication commit 51a52d8
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.

Publications and Git history checked 4 October 2026. Output is proven here; audience growth, conversion lift and fully hands-off operation are not inferred. Remote owner access is the next product layer.

From the ARVO origin to the Content Factory
One project identity. One history.

One Factory.
Every interface.

Direction from anywhere. Execution stays with the project.
Evidence decides. History survives the agent.

You set the direction
Web cockpitChatGPTClaude

Observe on the web. Ask and guide through MCP.

Orchestro MCP / cloud control plane Remote experience in development
Cloud intent ↓↑ Status + evidence readback
Your machineCLI connects here
Orchestro FactoryCanonical intake · permissions · work selection
Claude CodeCodexGrok

Repository · APIs · tools

Independent verificationDurable history
The cloud carries intent and visibility. The local Factory applies authorized work and records what actually happened.
Web
Observe progress, deliveries and decisions.Owner cockpit · private preview
ChatGPT & Claude
Ask questions and send governed requests.Configured MCP client required
MCP
Expose the control plane to agents.Configured MCP client required
CLI
Operate the canonical local project directly.Available in the private core
Local loop
Execute, verify, record and select again.Used in real project pilots

Different goals.
Separate project truth.

Each Factory has its own domain, tools, permissions, metrics and backlog. The Orchestro core is shared.

C

Content Factory

Running

Build a useful, discoverable publication.

Own goal · tools · permissions · history
P

Product Reliability

Waiting for evidence

Keep critical product journeys working.

Own goal · tools · permissions · history
S

Sales Factory

Needs you

Develop a qualified pipeline within agreed limits.

Own goal · tools · permissions · history
C

Customer Support

Running

Turn recurring questions into better service.

Own goal · tools · permissions · history

Illustrative workspace states. Content and Reliability are real pilots; Sales and Support are further domains to validate, not generally available products.

A project that continues
after the conversation.

A typical agent session

Prompt → work → answer

The conversation ends.
With Orchestro

Goal → durable work → cycles → evidence → learning

The next cycle starts with history.

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.

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.

How the lifecycle and safeguards work

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.
BLOCKERS & RECOVERIES

The worker can stop.
The project keeps its history.

Know what is blocked, its scope, and who can unblock it. A recovery action and proof that work resumed are separate facts.

A provider runs out of quota.

An ordered executor chain can try the next configured worker. A handoff receipt preserves the switch; later progress proves continuation.

Implemented · automatic recovery is not claimed for every Factory.

A decision needs the owner.

The affected work waits for an authorized answer. Independent work can continue when the checkpoint and authority allow it.

Illustrative · scope must be recorded, never assumed.
Understand blockers & recoveries

Give one project a goal.
Build its loop.

You set the direction. The Factory keeps the project moving.

Get early access Read the docs
Private preview · hands-on onboarding · your agents and tools