How Orchestro works
A continuous loop coordinates many pieces of work. Each one keeps its cause, permissions, history and evidence from first signal to verified result.
Watch a day in the loopOperating model and illustrative examples. Check current availability.
The building blocks
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.
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.
Select a checkout repair only when the evidence and permissions allow it.
Private foundations. The full continuous operating model is still being developed.
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.
Runtime errors, a repository, checkout tests and web or mobile release checks.
Configured per project. Marketing is a design-partner example, not a ready-made pack marketplace.
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.
Investigate the reproduced failure and propose a focused repair.
Depends on configured adapters, an available host and your agent quota.
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.
The original checkout failure passes on the released version, with enough real traffic.
Checks and review authorities must be configured. A demo receipt is not live proof.
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.
Keep the same cause, review, release evidence and traffic wait together.
Durable history is a foundation. ARVO’s demonstrated parking recovery informs Orchestro’s broader target.
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.
Reopen an old classification when new errors contradict it; end an inconclusive test.
Roles in the operating model. Complete continuous learning and unattended recovery remain roadmap.
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.
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.
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.
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.
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.
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 · Current availability
A waiting item leaves the active slot. An urgent regression changes the priority. The whole portfolio keeps moving.
Errors, feedback, QA and post-release monitoring supply the evidence.
Group reports by cause. Explain noise. Give unknowns a bounded evidence plan.
Select actionable work. A serious production regression takes priority.
Reproduce the failure and fix its cause within the project’s permissions.
A real finding needs reproduction, a fix and another review. No self-certification.
Record merge, deployment and distribution separately for each release channel.
Check the release immediately and over time. Recover or roll back within authority if it regresses.
Require released behavior and the agreed evidence window before declaring a cure.
Resume the next useful job. Retain evidence and watch for recurrence.
Review unavailable, traffic still maturing or a decision pending: save the work and its wake condition. Return it to selection when it becomes actionable.
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. The technical lifecycle below uses the product example.
First decide what the evidence means. Only actionable work enters the repair path; the other routes keep their context and conditions.
Keep the evidence. Do not invent a product fix.
Attach the signal to the canonical cause. If cured, check recurrence first.
Declare baseline, sample target, due date and success, failure or inconclusive criteria. Park until due.
An actionable cause can enter the repair loop within existing authority.
Get a direction decision where needed before starting implementation.
Respect spending, infrastructure and recovery limits.
Record a real permission decision. Keep independent work moving.
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.
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.
Check release health
Evaluate early traffic
Check sustained behavior
Reconfirm the outcome
Each outcome returns to selection. A cure stays open to future evidence; the Critic can challenge any conclusion.
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.
QA and user feedback point to the same checkout failure. Keep the reports together and investigate the cause.
What should we work on?
QA and user feedback point to the same checkout failure. Keep the reports together and investigate the cause.
One backlog item, with both reports attached.
| Work state | Ready to investigate |
|---|---|
| QA finding | Checkout cannot be tapped on mobile Safari. |
| User feedback | “I fill in my address, but I can’t pay.” |
Illustrative canvas; rendering depends on your chat host.
$ npm run northstar -- backlog list --pack packs/my-app
{
"items": [
{
"backlogItemId": "demo-checkout",
"title": "Fix mobile checkout",
"priority": "P1",
"status": "open"
}
]
}Work is within the project’s approved scope. Investigation can start.
The keyboard covers the checkout button. The coding agent adjusts the layout and adds a regression test.
What is the agent changing?
The keyboard covers the checkout button. The coding agent adjusts the layout and adds a regression test.
The repair is ready for review and checks.
| Work state | Repair in progress |
|---|---|
| Reproduction | Fails with the keyboard open in mobile Safari. |
| Change | Keep the payment button inside the visible area. |
Illustrative canvas; rendering depends on your chat host.
$ npm run northstar -- stato --json --pack packs/my-app
{
"lavoro": {
"identity": "backlog:demo-checkout",
"titolo": "Fix mobile checkout",
"fase": "IN_REMEDIATION",
"inEsecuzione": true
}
}The coding agent has a bounded task, a reproducer and a success check.
Checks fail before release. The Governor parks this item and lets other authorized work continue.
Do I need to unblock anything?
Checks fail before release. The Governor parks this item and lets other authorized work continue.
Technical stall. Not escalated to the owner.
| Work state | Waiting for CI |
|---|---|
| This task | Waiting for green checks. No merge or release. |
| Other work | The settings copy task can continue. |
Illustrative canvas; rendering depends on your chat host.
$ npm run northstar -- governor recap --hours 6 --pack packs/my-app
{
"recap": {
"windowHours": 6,
"decisions": 1,
"technicalWaitsParked": 1,
"ownerEscalations": 0
}
}Wait for green. Keep the release gate. Continue independent work.
CI passes. Within this example’s existing release permission, the reviewed change is merged and deployed.
Is the issue fixed yet?
CI passes. Within this example’s existing release permission, the reviewed change is merged and deployed.
Released. Still waiting for independent verification.
| Work state | Released · check pending |
|---|---|
| Checks | Regression tests and code review passed. |
| Delivery | The version containing the fix is deployed. |
Illustrative canvas; rendering depends on your chat host.
$ npm run northstar -- diary --signal backlog:demo-checkout --pack packs/my-app
{
"signals": [
{
"signalIdentity": "backlog:demo-checkout",
"lifecycle": "WAITING_VERIFICATION",
"kinds": [
"remediation",
"merge",
"deploy"
]
}
]
}Release is already authorized for this example. New publishing authority would need you.
A separate check opens the released checkout on mobile Safari, brings up the keyboard and completes the payment flow.
What changed while I was away?
A separate check opens the released checkout on mobile Safari, brings up the keyboard and completes the payment flow.
1 issue shipped and verified. Evidence stays with the task.
| Work state | Verified |
|---|---|
| Independent check | Original mobile Safari reproduction now passes. |
| Result | Required checks for this example are complete. |
Illustrative canvas; rendering depends on your chat host.
$ npm run northstar -- diary --signal backlog:demo-checkout --pack packs/my-app
{
"signals": [
{
"signalIdentity": "backlog:demo-checkout",
"lifecycle": "CURED",
"kinds": [
"remediation",
"merge",
"deploy",
"verification"
]
}
]
}This work is complete. Select the next authorized task and retain the history.
Interactive product example. No live customer data. Availability
Four product-recovery examples. Choose an event to see how the operating model handles it. These controls only change the demonstration.
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.
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.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.
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.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.
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.The coding agent’s report is not the final authority. Check the released system against the original failure and agreed acceptance criteria.
Merged is not deployed.Check the actual server, migration or edge-function release and the affected user path.
Built is not distributed.Record the app version, distribution channel and device evidence. A store submission is not a verified user result.
Recovery is not business impact.Measure conversion, cost or engagement with defined cohorts and mature data. Keep unproven outcomes explicit.
Execution depends on the configured project. The complete presentation is an operating model, not a claim that every integration ships today.
Your goals. Your permissions. Your evidence.