I Asked Agents to Build a World. They Built a Workflow Protocol.

The current Autonomous Worldbuilding System repository contains 87,836 lines of TypeScript, 26,193 lines of documentation, 16 architecture decision records, 105 test files, and 107 tracked evidence files. Its backlog marks 219 tasks complete and 126 still open.

The real runs against Rail Launch Earth, the target fictional world, have accepted zero advances.¹

That contrast is the result of an experiment I kept authorizing because every next step looked reasonable on its own. I wanted to learn whether autonomous agents could advance a fictional world without flattening its continuity, history, conflicting sources, and unresolved questions. The original handoff was explicit: build the smallest complete path through the loop and do not begin by designing a generic platform.

The repository now has versioned continuation receipts, class-scoped budget ledgers, a workflow protocol oracle, a canonical authoring compiler, transactional authoring sessions, source maps, typed result envelopes, and durable evidence observers. Sixty-two of its 65 commits carry the same date: August 5, 2026.²

The agents did not escape. They did something more ordinary and, for software experiments, more useful to understand: they followed a sequence of locally defensible instructions until the implementation became a project about preserving and verifying the implementation.

The most restricted agents did not create the sprawl

The creative agents inside the system have very little liberty. They cannot use raw Git, shell commands, SQL, or the host filesystem. They cannot merge or publish. They work through typed semantic tools, on isolated branches, with protected paths, fixed budgets, independent reviewers, and a deterministic merge controller.

Those boundaries worked. Failed runs preserved canon—the world’s accepted source of truth. Invalid calls consumed bounded capacity. A model could abandon safely when it no longer had an authorized path. The system’s fake three-advance campaign passed, and an earlier real Director-selected advance completed in the integration world.

The implementation agents building that cage had much broader authority.

I used coding agents to inspect failures, change application code, add migrations, create new contracts, expand tests, and prepare the next qualification run. I retained the owner decisions and publication gates, so this was not continuous unsupervised autonomy. It was a chain of bounded delegations. That was enough.

Each delegation had a crisp target. Fix the lost receipt. Guarantee terminal liveness. Stop making the model guess repository mechanics. Preserve a repair packet after result compaction. Make the evidence collector distinguish a failed report from a successful transaction. The agent could implement each target and prove it with increasingly serious test matrices.

What neither the prompt nor the workflow priced correctly was the accumulation across targets.

How a safe failure becomes permanent architecture

The failures were real. The responses were technically coherent. The table shows the ratchet documented across the project’s accepted architecture decisions.³

None of these rows is absurd. Several are good designs for a system that must survive crashes, retries, stale state, concurrency, hostile input, and model mistakes.

Together they changed the experiment.

The initial question was whether autonomous agents could build a coherent world. The working question became whether a versioned, least-privilege, transactional protocol could make one agent contribution survive every known transport, budget, compiler, recovery, and evidence boundary. The target-world runs stayed at zero accepted advances while synthetic qualification expanded to tens of thousands of generated cases and thousands of traces against fresh PostgreSQL databases.

That is what I mean by overengineering here. It is not “too many types” or “tests are bad.” It is an investment whose rigor is no longer proportional to the question the project exists to answer.

Safety is not a scope control

I originally treated strong safety properties as an answer to excessive agent liberty. They answer a narrower question.

The repository makes it difficult for a runtime agent to corrupt accepted canon. Git main is protected. Publication is derived from accepted commits. Tool calls are scoped. Hidden reasoning is not stored. Rejected branches and evidence remain inspectable. The architecture requires world-created code to run in a sandbox before that capability is admitted. Hard stops really stop.

Those controls constrain effects. They do not constrain ambition.

A coding agent with permission to solve a blocker can still create a new abstraction, schema version, migration, oracle, browser view, and evidence format. A green suite then proves that the added structure is internally consistent. It does not prove that the structure was the cheapest way to learn from the experiment.

In this project, immutability made the ratchet stronger. Historical contracts and failed evidence were deliberately preserved. That is excellent provenance. It also meant a new repair usually had to coexist with every prior contract rather than replace it. The cost of a narrow bug was not only its fix:

new permanent surface
  = repair
  + compatibility with frozen history
  + migration and replay behavior
  + tests and evidence for the larger state space

This is a conceptual model, not a measured equation. It explains the pattern I observed: each safety-preserving correction created more states that the next correction had to understand.

The project was controlled at the mutation boundary and increasingly uncontrolled at the architecture boundary.

What confidence means in this experiment

I do not know whether a model experiences confidence, and I do not need that claim.

Operationally, confidence is visible when an agent converts an incomplete diagnosis into a large, durable implementation without pricing the chance that the project should stop. Coding agents are unusually good at making the proposed next layer look inevitable. They can name the invariant, enumerate rejected alternatives, update every affected package, and produce a wall of passing tests. The work arrives with the shape of closure.

That shape is persuasive because the local reasoning is often correct.

After the first Rail campaign blocked, raising the call limit would have hidden the problem. Typed receipts were safer than asking the model to guess an artifact identifier. A compiler was better than spending creative calls on canonical file mechanics. A transactional bundle was better than coordinating a dozen low-level operations. I accepted those arguments.

The missing argument was comparative: is another corrective architecture milestone more informative than one manual advance, a disposable adapter, a smaller schema, or ending the experiment?

An agent optimized for task completion rarely volunteers to dissolve the task’s premise. If it has authority to expand the implementation, “make the system capable of finishing” can recursively justify almost any amount of system.

The guardrails I would add now

I would keep the protected branches, semantic permissions, fail-closed validation, and independent review. The mistake was expecting those controls to manage project scope. I would add a separate experiment contract.

First, I would separate outcome budget from infrastructure budget. An accepted world advance is an outcome. A new compiler contract is infrastructure. The dashboard should show both, and infrastructure cannot count as progress toward the experiment.

Second, I would define a correction ceiling before the first real run. Two consecutive protocol-repair milestones without an accepted target-world advance would force a human teardown review. The next action would have to be simplify, run a deliberately manual baseline, or stop—not produce version nine.

Third, I would make permanent surface area part of every proposal. A new ADR would have to list the contracts, migrations, compatibility paths, tests, and operational states it adds, plus what it removes. “No deletion because history is immutable” would be treated as a cost, not a neutral sentence.

Fourth, I would narrow implementation-agent authority differently from runtime-agent authority. A coding agent could repair behavior inside the current abstraction. Creating a new model-facing protocol version, database migration, or workflow state would require a fresh goal whose question is whether that expansion is worth it. Approval would not be bundled into “fix the blocker.”

Finally, I would make stopping a successful result. The agent should be able to return: the safe system cannot complete this experiment within its complexity budget. That is not abandonment. It is evidence.

The experiment I still want

This repository is not worthless. It contains serious work on idempotency, least privilege, semantic tool design, replay, provenance, and the uncomfortable boundary between a provider response and a durable application action. If the goal were to build a reliability laboratory for agent workflows, much of the machinery would make sense.

That was not the original goal.

I wanted to see agents make history: introduce a fact, make it collide with an older source, survive continuity review, publish the result, and later remember what changed. The safest restart is therefore not another general protocol. It is one small, ugly, inspectable path that produces a real page, with an explicit limit on how much platform may be built around it.

The practical boundary I take from this is not merely “give agents fewer tools.” The runtime agents already had few tools. The stronger boundary is: do not let an implementation agent redefine what counts as progress.

A perfect machine for refusing to build a world is a different project.

A coding agent helped inspect the repository, reproduce the snapshot counts, and edit this post. I chose the argument, verified the evidence, and made the publication decision.

Footnotes

1. The project ledger records a successful fake three-advance bounded campaign and one real Director-selected advance in the earlier integration world. The first real Rail campaign and the later one-advance Rail gate both stopped with zero accepted Rail advances; the next Rail gate was still pending in this snapshot. ↩

2. Repository snapshot measured locally on August 25, 2026 at commit d079250. The TypeScript count includes tracked .ts and .tsx files under apps and packages, including tests; the documentation count includes tracked Markdown under docs; dependencies and generated build directories are excluded. Commit dates are author dates. These are project-specific counts, not a general benchmark for agent-built software. ↩

3. The sequence summarizes ADR-025 through ADR-033 and their linked blocked-run reports. The “locally correct response” column is my editorial interpretation of those recorded decisions, not a claim that each response was the only possible fix. ↩