The interactive loop

See what happens next.

A review arrives. Production needs attention. Evidence changes an old answer. Choose the next event and watch the work find its place.

Illustrative operating model. Product: private preview. Campaigns: design partners. Current availability.

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.

What changes

Search fix: waiting for review. Checkout bug: now active.

1 of 8 events · 3 work identities

Working now

1

The current actionable job

P-B

Checkout timeout

Investigate the checkout reports

Waiting, with a way back

1

Saved context. No active slot held.

P-C

Search improvement

Independent review pending

Returns whenReview arrives

Checked outcomes

0

Proof belongs to this result

Nothing verified yet. A release alone does not count.

Next in line
P-Q Next backlog cause

Illustrative operating model. Separate project histories; configured agents, tools and permissions. No live work or external actions. Current availability.

Read both complete examples

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.

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

The goal is useful progress, not just fewer open tasks. Read the ARVO lesson behind this loop.

What a healthy loop should leave behind

From Backlog Zero to Operational Zero

A healthy project.
Not just an empty list.

An open item can be understood, safely waiting and still important. The goal is to leave nothing urgent, unexplained or forgotten.

Unexplained signals

Know what each signal means, or the plan to find out.

Urgent work left ready

Handle the critical work that can be acted on now.

Outdated conclusions

Recheck decisions when their evidence gets old.

Waits without a limit

Every wait has a reason and a way back.

Expired experiments

End the test, make a decision and clean up.

Overdue release checks

Verify within the project’s agreed time limit.

Six things we aim to bring to zero. Design targets, not current live measurements.

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 YesRelease succeeded NoRecovery 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 MergedWork history Claims releasedProduction 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.

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.
Inspect the example workspaceMaps, metrics, backlog, decisions and evidence in Web, Chat + MCP and CLI

A separate product example for exploring capabilities, metrics and evidence. Its dated sample history is independent of the event stories above.

Your tools, connected by context

Many sources.
One place to make sense of them.

Issues, customer conversations, database events and failed checks all inform the work. Keep the evidence attached as it moves through Orchestro.

Try a source to follow its path.

orchestro.Context becomes work.
Issues & roadmap → orchestro.

A checkout bug with a reproducible failure.

An investigation with a clear success check.

Example sources via your configured tools and permissions. Connections depend on your project and host. MCP setup

orchestro.Product workspace / sample as of Sep 15, 2026
Ask your Factory
01 / Capability

Start with what your product does.

Pick a business capability. Its goal, dependencies and work stay together.

Try a use case
Example tool workflow · Onboarding
GitHub: inspect sign-in code · Supabase: read first-project events · PostHog: compare activation cohorts
Illustrative use through configured tools, APIs or MCP connections; availability depends on your host.
Capability · OnboardingSample workspace
What better looks likeFirst-project conversion

62%64%

No increase in account-creation errors.
1 / 7 · Product map + project context

Skills turn intent into a workflow

Ask for the outcome.

Start with a real job: connect a project, fix a bug, catch up or recover a stalled run. The skill brings the steps and tools together.

The skill behind the request

Onboard project

Map the project and check its tools.

  1. 1Read project context
  2. 2Map capabilities
  3. 3Check available tools

A product map, explicit missing sources and the next setup step.

Tools & evidence

Repository + project configuration

Actions: sync · read state. Exact tools depend on the project configuration.

Current command reference →
What can I explore in this demo?
  1. Capability

    Pick a business capability. Its goal, dependencies and work stay together.

  2. Map

    Trace the experience to its agents, services and evidence. Shared dependencies connect related failures.

  3. Success metrics

    Keep the baseline, target and observation window with the capability. A missing measurement stays visible.

  4. Backlog

    One confirmed cause gets one repair. A release still needs its behavior checked.

  5. Quick recap

    See the movement, what is still being observed and the decisions that matter.

  6. Advisor

    Explore an onboarding proposal with a hypothesis, baseline and success check. Acceptance and execution are separate steps.

  7. Inbox

    Review the product decisions that need you. Technical waiting stays with the work.

Try the paid-access, AI tool failure and reminder examples across Web, Chat + MCP and CLI. The same illustrative data powers every view.

Your projects. One continuous habit.

Make the loop
your own.

Request early access Start with observation. Define the checks and permissions for your project.