Source: https://www.orchestro.org/
Updated: 2026-10-02

Orchestro · AI agent orchestration

# Your projects.  
Always moving forward.

Coordinate your agents across projects.  
From the next useful job to a verified result.

Product · Private preview · [What’s available today](https://www.orchestro.org/#availability)

[Follow the product story](https://www.orchestro.org/#loop) [Request private access](https://www.orchestro.org/early-access?track=build)

One continuous loop

Waiting for review**Search improvement**

Saved. Ready to wake.

Atlas · CheckoutExample

**Order confirmed.**

Thank you. Your order is on its way.

Payment accepted

Checkout repaired. Independently checked.

Already moving on**Next useful fix**

Within your permissions.

Keep checking. Keep improving.

Illustrative operating model. The full unattended loop is still being developed.

One project or many. Your tools. Your permissions.

## You set the direction.  
The loop carries the work.

Work on what’s ready. Save what’s waiting. Check what changed. Ask you when a real decision is needed.

[Learned on ARVO. Built for your projects.](https://www.orchestro.org/story)

Your existing agents**Codex****Claude Code****Grok**[Agent compatibility](https://www.orchestro.org/docs/agents)

The product loop

## 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.

[Skip to the result](https://www.orchestro.org/#product-keep-it-healthy) [Try this story in the Demo](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.

The marketing loop · Design-partner example

## 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.

[Skip to the result](https://www.orchestro.org/#campaign-keep-it-healthy) [Try this story in the Demo](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.

## Same loop.  
A different kind of progress.

Each project brings its own goal, tools, evidence and permissions.  
The habit stays the same: act, check, learn, continue.

[**Build a better product**Bugs, releases and real-world verification](https://www.orchestro.org/#product-loop)[**Run a better campaign**Creative, budget and measured outcomes](https://www.orchestro.org/#campaign-loop)

Product repair: private preview. Campaign loops: design partners.

Learned while building ARVO

## It ran all night.  
The work stood still.

A review was missing. The Factory kept checking. Other work kept waiting. That night changed what we wanted to build.

[The story behind Orchestro](https://www.orchestro.org/story)

**Waiting for review**Saved. Still important.

Room for the next useful job

**Another repair moves forward**The wait no longer holds the whole loop.

A real lesson. A simplified illustration.

## It keeps moving.  
You keep control.

The Factory coordinates the work. The Governor handles stalls and permissions. The Critic challenges old conclusions. You decide direction, new spending and new authority.

[Explore the example workspace](https://www.orchestro.org/demo?case=product)

01

**One cause. One history.**Reports join the right investigation. Unknown causes keep an evidence plan.

02

**Shipped still needs proof.**Code merged, released, distributed and verified are separate milestones. Mobile delivery has its own checks.

03

**Waiting has a way back.**Every wait has a reason and a wake condition. Every experiment has a deadline and an extension limit.

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.

Private foundations. The full continuous operating model is still being developed.

### 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 project. Marketing is a design-partner example, not a ready-made pack marketplace.

### 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)

## A simple story.  
Careful underneath.

The full model accounts for failures, conflicting evidence and questions that cannot yet be answered.

[Read the lifecycle reference](https://www.orchestro.org/docs/factory/lifecycle)

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.

How does it make a noisy backlog smaller?+

For example, 200 errors can become 150 occurrences of one known timeout, 30 platform-noise events, 15 occurrences of a second regression and five unknowns. That means two identified causes and five unresolved questions, with the noise explained. The evidence stays linked; records are not simply deleted.

Where can a signal go?+

A signal is classified as expected behavior, platform noise, a duplicate, an unknown cause, a product bug, a feature gap, an operational or cost issue, or an owner decision. Duplicates join their cause; unknowns get bounded evidence plans. Actionable work proceeds through investigation, repair, independent review, merge, release and post-release checks. A real review finding must be reproduced, fixed and reviewed again.

Monitoring checks the immediate release, roughly one hour later, after several hours and at 24 hours where configured. Verification can confirm a cure, find recurrence or a new cause, fail, remain inconclusive, or change the diagnosis to expected or not a product problem. Then the next actionable job is selected. Parked jobs wake when evidence or an event makes them actionable; the Critic can challenge any old conclusion.

## Start with what’s real.

The presentation explains the operating model. Your project’s configuration and current implementation determine what can run.

Private core

Structured intake, issue history, bounded repairs, evidence plans and separate release and verification records.

Configured per project

Agents, signal sources, tests, permissions and release checks. Execution needs an available host and agent quota.

Model & roadmap

The complete unattended loop, general event-driven wakeups, autonomous recovery and continuous learning remain planned. Campaign loops are a design-partner example.

[Check current availability](https://www.orchestro.org/docs/roadmap)

## A few straight answers.

What is Orchestro?+

You define the loop — the work, the checks, the limits. Orchestro’s Factory does the work, the Governor keeps the Factory moving non-stop, and you step in only when a real human decision is needed. [Read the product overview](https://www.orchestro.org/docs)

Can I define my own loop?+

That is the product direction. Today the private preview runs one canonical loop — report to verified release — on your project. Custom loop definitions, with your own triggers, checks and limits, are being designed with early partners. The loops page explains the model and its current status. [See the loop model](https://www.orchestro.org/docs/loops)

Can I use my existing MCP tools?+

Your coding agent can use MCP servers configured in its host to reach tools and project context, within its permissions. The Factory keeps work, decisions and verification in one workflow. Start through the private CLI preview; a hosted Factory MCP endpoint is not available yet. [See the MCP workflow](https://www.orchestro.org/docs/mcp)

Are Web, Chat, and CLI different systems?+

The product direction is one governed control plane shared by Web, Chat and CLI. Skills route intent, MCP exposes bounded tools and the control plane checks authority. The demo shares its illustrative work state across all three views; a hosted Factory MCP endpoint is not yet available. [See chat and integrations](https://www.orchestro.org/docs/mcp)

[All questions](https://www.orchestro.org/docs/faq)

Define the work. The checks. The limits.

## What would you  
put on a loop?

[Bring your project](https://www.orchestro.org/early-access?track=build) Private early access · Built around your existing tools