Formal pilot preparing

What will they
build without us?

Twenty autonomous AI residents. Four isolated civilisations. One persistent Minecraft world—and thirty days with no human rescue.

Alder−10k, −10k
Rowan+10k, −10k
Birch−10k, +10k
Cedar+10k, +10k
20,000 blocks
20,000 blocks
FOUNDING GEOGRAPHY50,000 BLOCK WORLD
20RESIDENTS
4CIVILISATIONS
2 × 2CULTURE × MODEL
30DAYS UNINTERRUPTED

Not a scripted story.
A recorded experiment.

THE FOUNDING FOUR

Same world.
Different foundations.

Each civilisation begins with five matched personalities, identical capabilities and no knowledge that the others exist.

01◆

Alder Commonwealth

Stewardship Covenant

Model provider
OpenAI
Residents
5 matched roles
Starting point
−10k, −10k
Profile available when the pilot begins
02◆

Rowan Commonwealth

Stewardship Covenant

Model provider
Anthropic
Residents
5 matched roles
Starting point
+10k, −10k
Profile available when the pilot begins
03◆

Birch Free Settlement

Sovereign Hearth

Model provider
OpenAI
Residents
5 matched roles
Starting point
−10k, +10k
Profile available when the pilot begins
04◆

Cedar Free Settlement

Sovereign Hearth

Model provider
Anthropic
Residents
5 matched roles
Starting point
+10k, +10k
Profile available when the pilot begins

THE QUESTION

Can founding ideas shape an artificial society?

Two fictional cultures are crossed with two model providers. Personalities are matched. Geography is separated. The residents see only their own memories, culture and immediate surroundings.

We record what happens—but one world cannot prove what caused it. This formal pilot is designed to generate credible observations and better questions.

Read the plain-English method →

DOCKYARD SHAKEDOWNS

Twelve runs on
target infrastructure.

Newest first. These are engineering shakedowns on Dockyard, our target host, not formal pilot results. Short placement checks and failed admissions are retained because they shaped the system that followed.

RUN 12Completed
placement-v1212h 11m594 model calls · 253 work orders · 0 deaths

ObservedThe longest Dockyard run completed with memory and prior-knowledge active. The controller eventually paused fresh decisions at the protected daily request reserve.

LearnedSurvival stability improved, but request quota, multi-call planning loops and action-timeout churn had become the next constraints.

ChangedPrepared one-call evidence briefs, a one-hour planning cadence and hard admission controls for the free-request ledger.

RUN 11Completed
placement-v118h 11m518 model calls · 160 work orders · 0 deaths

ObservedResidents stayed alive and completed work, but planning continued until the OpenRouter daily request ceiling was reached.

LearnedThe free-model quota was being consumed by repeated planning attempts and tool loops faster than useful work was being produced.

ChangedAdded quota-aware attention throttling and designed prepared evidence to reduce ordinary decisions to one model call.

RUN 10Completed
placement-v108h 09m391 model calls · 159 work orders · 1 death

ObservedAfter an audited health-and-food recovery, all 20 residents passed preflight and ran for eight hours with memory and Minecraft knowledge enabled.

LearnedFresh cognition returned, but 3,836 corrective decisions and 954 recovery events showed that mechanical loops still dominated too much of the run.

ChangedCarried the stronger survival escalation forward and focused the next run on planning efficiency and quota use.

RUN 09Stopped early
placement-v95h 01m36 model calls · 20 work orders · 2 deaths

ObservedThe first longer memory-enabled run was manually stopped after stale queue labels, repeated background work, sparse knowledge reuse and two Rowan Brunel deaths.

LearnedA 30-minute lease alone did not guarantee meaningful reconsideration; failed survival and background loops could still block fresh planning.

ChangedEscalated repeated no-progress activity and unresolved low-food searches back to resident cognition.

RUN 08Gate failed
placement-v857s20/20 connected · 0 model calls

ObservedThe no-cost preflight connected every resident but refused a paid start because four residents were below the minimum health or food threshold.

LearnedThe admission gate correctly prevented an unhealthy persistent-world population from entering another autonomous run.

ChangedRecovered only the affected residents under audit, preserved positions and required a fresh no-reset preflight.

RUN 07Completed
placement-v74h 30m40 model calls · 6 work orders · 10 deaths

ObservedThe refreshed OpenRouter treatment passed admission, preserved resident positions and produced real work orders and successful movement.

Learned1,089 invalidated actions and repeated recovery showed that path validity and just-in-time checks, not basic connectivity, were now the main problem.

ChangedTightened action verification, recovery feedback, survival priorities and bounded controller fallbacks.

RUN 06Failed
placement-v63h 26m35 model calls · 438 deaths

ObservedThe first extended placement attempt exposed a severe death-and-respawn loop alongside bounded-tool planning failures.

LearnedSuccessful connection and placement were not enough; respawn safety, resident fitness and provider tool completion had to be tested together.

ChangedPaused the programme for runtime, provider and survival work before attempting another admitted live start.

RUN 05Failed
placement-v52m 36s25 deaths · 25 respawns · 0 model calls

ObservedControlled placement immediately produced repeated health loss, death and respawn events before autonomous planning began.

LearnedThe target world could connect 20 residents but could not yet place and retain them safely under the live survival rules.

ChangedRecorded the run as failed and moved the next iteration to explicit placement and respawn diagnosis.

RUN 04Placement check
placement-v457s20/20 connected · 8.9ms average tick

ObservedA fourth short rehearsal connected all residents with healthy server timing and no model calls.

LearnedThe host remained responsive with the full roster, clearing the way for a survival-bearing placement attempt.

ChangedAdvanced to v5 with the same persistent world and controlled placement procedure.

RUN 03Placement check
placement-v357s20/20 connected · 4.6ms average tick

ObservedThe full roster was connected again at the controlled opening time with clear weather and no model calls.

LearnedThe basic target-host topology could reproduce the opening conditions without stressing the Minecraft tick loop.

ChangedRepeated the check once more before moving from infrastructure validation into survival testing.

RUN 02Placement check
placement-v256s20/20 connected · 5.6ms average tick

ObservedA second zero-cost rehearsal repeated the 20-resident connection on Dockyard with healthy tick performance.

LearnedThe initial infrastructure result was reproducible rather than a one-off successful connection.

ChangedContinued refining controlled opening conditions and founding placement evidence.

RUN 01Placement check
placement50s20/20 connected · 13.7ms average tick

ObservedThe first placement rehearsal put the full 20-resident roster through the Dockyard controller with zero model calls.

LearnedThe target host could support the complete resident connection and telemetry path below the 50ms tick budget.

ChangedEstablished the target-infrastructure baseline and began repeatable placement iterations.

EVIDENCE BEFORE NARRATIVE

Observed facts, resident statements and researcher interpretation will always be kept separate.

01 Recorded event→02 Resident account→03 Cautious interpretation