I Tried to Let My AI Agent Loose — It Failed in Exactly the Right Way

The experiment was simple.

Instead of spending another day improving the architecture because something might go wrong, I promoted the Moon Worker into Dream.OS Agent 1 and gave it an acceptance test:

Take a real DreamVault-authorized objective and drive it all the way to a verified terminal state without me having to say “proceed.”

The first mission failed.

That was useful.

The Moon Test

The workflow Agent 1 is expected to own is no longer just “write some code.”

OBJECTIVE
   ↓
INSPECT
   ↓
UNDERSTAND
   ↓
PLAN
   ↓
IMPLEMENT
   ↓
TEST
   ↓
CRITIQUE
   ↓
REPAIR
   ↓
VERIFY
   ↓
PR
   ↓
MERGE
   ↓
CLOSE BRANCH
   ↓
RECONCILE
   ↓
COMPLETE

The important word is COMPLETE.

A merged PR is not complete. Passing tests are not complete. A branch that still exists is not complete. A worker that knows the next step but waits an hour for another scheduler is not complete.

And if I have to type “proceed,” the autonomous system failed the test.

The first failure

Agent 1 received a real DreamVault objective: DV-BRANCH-001.

DreamVault selected the work correctly, but the execution authority was incomplete. Agent 1 did the safe thing and stopped rather than inventing authority.

Then I had to tell it: Proceed.

That single word failed Mission A. Not because the model couldn't write code. Not because the planner couldn't select work. The system lacked autonomous continuation between authority, execution, verification, and closeout.

That gave us something much more valuable than another architecture discussion: a concrete failure.

Then we followed the failure

Instead of building another agent, we looked for capabilities Dream.OS already had.

GitHub Architect already had a governed branch-deletion executor. The missing piece wasn't another deletion service. Agent 1 simply needed a legitimate way to invoke the executor.

That path already existed too:

Agent 1
   ↓
GitHub request file
   ↓
GitHub Architect workflow
   ↓
governed executor
   ↓
exact-SHA validation
   ↓
branch deletion
   ↓
verify remote ref absent

We hardened that path so the executor independently respects protected branches and active lanes instead of blindly trusting its caller.

Then Agent 1 needed machine-local evidence from ProjectScanner to know whether a branch was attached to an active worktree.

Again, the answer wasn't another service. DreamVault already had a self-hosted runner on the VPS.

Agent 1
   ↓
evidence request
   ↓
existing DreamVault VPS runner
   ↓
ProjectScanner
   ↓
machine-local branch/worktree evidence
   ↓
receipt
   ↓
Agent 1 continues

The live canary found the next real bug

We ran the real canary.

It failed again.

This time because the VPS exposed python3, while the workflow expected python.

That sounds almost embarrassingly small. That's exactly why the experiment matters.

You can design autonomous-agent architecture forever and never discover the one missing executable name that stops the entire machine.

A real mission finds it immediately.

What changed today

We did not prove Dream.OS is autonomous.

We proved something more useful: we now have a method for finding out whether it is.

The acceptance test has become the architecture filter.

If Agent 1 encounters a problem and can repair it using existing capabilities, it should repair it. If DreamVault needs to reconcile authority, it should do that without me. If ProjectScanner evidence is needed, Agent 1 should request it. If a branch is safe to retire, GitHub Architect should retire it. If tests fail, Agent 1 should repair the failure. If the next action is obvious and authorized, the worker should continue.

Only a genuine external boundary should stop the transaction.

Don't improve Dream.OS because we imagine it needs something. Let Dream.OS attempt the mission and make the failure prove what it needs.

Where it stands

Agent 1 / Moon Worker       ACTIVE
DreamVault authority        ACTIVE
ProjectScanner bridge       IMPLEMENTED
GitHub Architect bridge     IMPLEMENTED
Deletion policy hardening   MERGED
Live canary                 EXECUTED
Runtime mismatch            FOUND
Runtime repair              IMPLEMENTED
Wild-ready                  NO

There is still verification and another acceptance run ahead.

The goal isn't to make a dashboard say “autonomous.”

The goal is to eventually sit somewhere with my phone, give Dream.OS an objective, and come back to:

OBJECTIVE COMPLETE

defects fixed
tests passed
PRs merged
branches retired
state reconciled

HUMAN INTERVENTIONS = 0

That's the Moon Test.

And for the first time in a while, it feels like we're testing the machine instead of endlessly building the machine.