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 progressThe 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.
One missing review.
One occupied slot.
- Work readyRepair submitted
- External waitReview not yet available
- Next checkThe same job still holds the slot
Owner account, 2 October 2026. Retold for clarity; this is not live telemetry.
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.
A product decision is pending.
Illustrative owner view · scope must come from recorded evidence- Blocks
- This mission
- Can continue
- Independent, authorized work
- Way back
- Record the decision, then check that work resumed
“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.
The loop continues after the worker says “done”.
How evidence changes the next cycleSame 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.
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 publicationFeedback → investigation → repair → verification
Evidence → thesis → article → review → publish → verify
Work. Evidence. History.
One ledger, lifecycle, selector and executor / verifier boundary. Each domain adds its own vocabulary, sources, tools and rules for done.
The original pilot is a historical case. Today’s public observation is available separately, with its timestamp.
See the current Content FactoryYour 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 machine
Execute, verify and record durable evidence.
Cloud + cockpit
See current work, freshness, requests and blockers.
Chat + MCP
Express intent. Read back what the Factory actually did.
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 boundariesThe lessons became
operating rules.
Historical lessons and design invariants. Each configured Factory still needs evidence that it meets them.
01Running 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.
02Important 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.
03Waiting 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.
04Every 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.
05Yesterday’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.
06Similar 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.
07A 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.
08Shipped 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.
09Every 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.
10More 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.
11A 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.
12Health 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. Know what each signal means, or the plan to find out.
UNEXPLAINED = 0 - Urgent work left ready. Handle the critical work that can be acted on now.
ACTIONABLE_P0_P1 = 0 - Outdated conclusions. Recheck decisions when their evidence gets old.
STALE_DECISIVE_JUDGMENTS = 0 - Waits without a limit. Every wait has a reason and a way back.
UNBOUNDED_WAITS = 0 - Expired experiments. End the test, make a decision and clean up.
EXPIRED_EXPERIMENTS = 0 - Overdue release checks. Verify within the project’s agreed time limit.
UNVERIFIED_RELEASES_BEYOND_SLA = 0
A real origin.
A dated account.
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.
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. The proposed 36–72-hour unattended run was a next test, not a completed autonomy benchmark.
This preserves what the incident taught us without turning a historical plan into today’s release claim. Current availability is documented separately.
What is available today