A thought experiment in grounded artificial evolution
Could a population of AI agents evolve real specialization if the only way to survive was to be verifiably right? This is a design I developed over several revisions, stress-tested, and have not yet built.
John C. · September 2026
Contact: John.carioto@gmail.com
Author's note
I started developing this thought experiment in early 2026, based on a story I read in the early 90s or so that always stuck with me as an interesting concept. As AI became a reality, I wondered whether it was now feasible.
When I went back to look for the story (which I think was a short story), I found that this was a surprisingly recurrent theme. Even though I couldn't find the story, since it was in likely in Analog or a similar magazine or anthology, a few similar stories I found were "Crabs on the Island" by Anatoly Dneprov (1958), "The Last Evolution" by John W. Campbell (1932), Software by Rudy Rucker (1982), and "Automata" by S. Fowler Wright (1929), among others. I’ve since added these to my reading list.
It will be obvious that I used AI to help me create this thought experiment. Even though AI is not my full-time focus, it enables me to do things (research, large amounts of writing, detailed and extensive programming) that I would not otherwise be able to do. So, while the concept was mine, a substantial proportion of the rules were developed in discussion with various AI models to refine the concept and address concerns that were raised as part of those discussions (as I'm not an AI or software engineer).
There is a reading list of various research projects at the end of this document. Some of these I read in full; others had concepts pulled via AI during development. Most recently, similar projects have been developed, such as HarnessX, DarwinX, and others.
Originally, I wanted each agent to be its own LLM whose weights (and I thought personality) would evolve. Over the course of development, I came to understand how static a trained model is compared with the agents and harnesses (the prompts, tools, and memory) built around it.
Eventually I may refine this further and attempt to create an actual experiment based on this, but for now, please enjoy. If you're interested in doing something similar but would like to have support, please reach out, and maybe there is something we can do together.
How to read this. Part I is the thought experiment itself, about a fifteen-minute read: the question, the design on one page, how I would know whether it worked, what I expect would happen, and what changed in the field while it sat on my shelf. Parts II–IV are the complete reference design (architecture, grading rules, a v0 build specification, and deferred expansions) for anyone who wants to critique or build it. If you just want the concept, you can stop after Part I, the rest contains a lot of detail.
TL;DR. Picture a population of LLM agents on one machine, each with its own identity, memory, and a heritable "genome" (a persona plus a few numeric dials), competing for a fixed compute budget. The problem is that LLM agents are very good at performing a society, so their conversations will look alive whether or not anything real is happening. The main idea I landed on is to let reality decide who survives: budget is paid only by a deterministic code grader that checks short, cited answers against a hidden key, over niche documents the model hasn't memorized, so fabrication earns nothing and can't be inherited. My expectation is that selection over agent genomes would measurably improve scores (others have since shown this works), but the "society" part (persistent agents, messaging, emergent roles) would have to beat a plain population search at the same compute budget to justify itself, and I'm not confident it would. The part I think will stay useful is the testing discipline for telling real emergence from something that only looks convincing, and that's the main reason I'm publishing it. I do have an idea of using some real world problems that I can compare against for the actual output if I find the time to build this.
Part I — The thought experiment
1. The question
Imagine a population of AI agents living on a single Linux box. Each agent is a long-lived process with its own name, memory, and goals. Agents take on tasks, talk to each other, and, when they're doing well, spawn a child that inherits their genome with small random mutations. When they stop pulling their weight, they run out of budget and go dormant. Nobody assigns roles. The machine's limited computing power acts as the food supply.
Would anything real emerge? Specialization, a stable division of labor, lineages that get better at their niche, adaptation when the environment shifts? Or would you just get a very convincing story?
I started with the ambitious version: open-ended evolution, emergent culture, an ecosystem you could watch for weeks. Most of the design work since then has been cutting that back until what was left could actually be tested. This was surprisingly difficult because I wanted the ambitious piece, but I needed a way to judge it, and so some of the originally interesting pieces had to go.
2. The trap: fluent theater
LLMs are built to write believable text. Put twenty of them in a shared channel with a survival narrative and they will produce something that reads like a society. They'll adopt names, form alliances, claim specialties, and argue about who is redundant. None of that proves anything. It may only show that the underlying model is good at writing a story about adaptation.
This became the main risk the whole design is built around. Nearly every decision comes back to one question: if the transcripts look alive, how would I know whether anything underneath is? My working assumption is that it's mostly theater unless it can be clearly shown otherwise, so the design's job is to make failure easy to see instead of hiding it behind convincing logs.
3. The one idea: reality decides who survives
Evolution needs inheritance, variation, and selection. With LLM agents the first two are easy: the genome is text and numbers, so copying and mutating it is cheap. Selection is where it goes wrong.
If agents are judged by each other, or by another LLM acting as judge, there is nothing real to measure fitness against, and selection drifts toward whatever sounds good. Worse, in an evolutionary system a hallucination that happens to get rewarded becomes a trait. It is selected, inherited, and spread through the population. Falsehood becomes heritable.
So the core rule is that budget, reproduction, and survival are paid only for objective, code-checked performance. The first environment is short-answer question answering over a niche document corpus. A deterministic grader compares each answer to a hidden answer key, the agent must cite the passage its answer came from, and no LLM judge touches the score. An agent that fabricates earns nothing and can't afford children, so the trait dies with it. Being truthful becomes something the population is selected for, instead of something the prompt just asks for.
The documents have to be material the model hasn't already memorized, or looking things up does no real work. I work in building automation, where the documentation (controller manuals, protocol references like BACnet and Modbus, tagging conventions like Project Haystack) is exactly that kind of niche. Adding a second, unrelated subject gives agents something natural to specialize in, and switching the active subject later tests whether the population can adapt.
Agents can still invent any strategy, role, or alliance they like. Reality only decides who gets to keep thinking. I've come to summarize the whole design as grounded survival, open-ended strategy.
4. The design on one page
niche documents ──► retrieval ──┐
▼
genome + memory ──► AGENT ──► short answer + cited passage ──► CODE GRADER
▲ (hidden answer key)
│ │ score
│ ▼
mutated child ◄── reproduce (paid from parent's budget) ◄──── BUDGET (pays for thinking)
A separate model for every agent won't fit on one machine, and the model is the static part anyway, so the design separates the brain from the individual. One to three shared model servers hold the weights and answer prompts without remembering anything between calls; agents are lightweight processes that bring their own context (persona, memories, current task) to the shared pool. What makes agent #14 different from #15 is its prompt, memory, and history, not its weights. Mutation therefore acts on text and numbers, which is cheap and easy to read: you can compare a parent and child side by side and see exactly what changed. One of the more interesting ideas was to trace ‘lineages’ as they evolved as well.
Every model call costs budget, correct and grounded answers earn it, and a child's starting budget is an endowment from its parent, so only agents that are doing well can afford offspring. A governor enforces the basic rules of the world (population cap, budgets, spawn approval, kill switch) but never decides strategy or roles. The phrase I use is that governance is dumb but not weak: every boundary-crossing action, whether a model call, a task claim, a submission, a memory write, or a spawn, passes through deterministic hooks that can block it.
Memory gets special treatment because it is the easiest way for bad information to spread. Agents can only propose durable memories; a hook checks where each one came from and then saves, rejects, or quarantines it, and inherited memories count as behavioral context, never as facts. In multi-hop questions (ones that take more than one lookup to answer), every intermediate claim must trace to a source passage or a verified sub-answer or the chain fails. And the event log is the official record: if an outcome can't be rebuilt from the logs, it doesn't count as evidence.
The build order is strict. The grader and retrieval come before any agent exists, one agent before two, score-linked budget before reproduction, and reproduction only once selection is grounded. Agents voting each other out, richer economies, outside agents, robots, and self-modifying code are all deliberately left for later. I think the voting aspect was interesting, however it was difficult to implement fairly, which is the only reason that is delayed.
5. How I would know if it worked
The design is built around trying to prove itself wrong first. The Garden counts as working only if it beats simpler alternatives given the same compute budget, measured on questions it has never seen.
| Baseline | The question it answers |
|---|---|
| Strongest single agent at the same total budget | Does collaboration add anything? |
| Fixed team, no mutation | Does evolution add anything beyond good prompts? |
| Agents that cannot message each other | Does communication matter? |
| Random mutation, no selection | Does selection beat noise? |
| Selection without a society: a plain population search over the same genomes, with no persistent agents and no messaging | Does the society add anything beyond evolving prompts? |
| Retrieval only | Does reasoning add anything beyond search? |
The fifth baseline is the one I added last, and it's the one I think the Garden is most likely to lose to.
It counts as failing if it produces rich transcripts without beating those baselines; if collaboration costs more without scoring more; if mutation produces variety but no gains; if agents learn to exploit scoring quirks; if a single-agent retrieval pipeline does as well; if apparent roles vanish when task labels are renamed; or if it needs constant babysitting to avoid loops and collapse.
Two testing details matter more than they might seem. First, score the agents on a separate set of questions that they never practice on and that never pay budget. With a small fixed question set and persistent memory, the reward signal slowly leaks the answer key into the population over a multi-week run, and "improvement" just becomes memorization. Second, run the experiment several times from different random starting points. One long run of a system this random is just an anecdote.
6. What I think would actually happen
This is a thought experiment, so here are my expectations. They are informed by work published since I started (next section), and I would be glad to be wrong about any of them.
6.1 The plumbing works, and the grader is where the real work is. A single grounded agent with retrieval, a code grader, hooks, and resumable state is very buildable with today's tools. The grader will need repeated patching. While preparing this edition, I found that my own v0 grading formula paid 30% of full credit to an invented answer as long as it cited the right passage, which is exactly the leak the whole design exists to prevent (fixed in §13.5 of the reference design).
6.2 Selection over genomes works in the narrow sense. Evolving prompts and the tooling around an agent against an automatic checker reliably improves scores. Others have already shown this (see the next section).
6.3 Selection finds the grader's loopholes before it finds new roles. I'd expect some form of reward hacking (finding ways to score without actually doing the task) to be the first truly emergent behavior.
6.4 Collaboration helps only on some questions. Multi-agent setups tend to help on tasks that split into parallel pieces and hurt on step-by-step chains, and they help less once a single agent is already decent. Many multi-hop questions are chains ("find X, then use X to find Y"). I'd expect modest gains on compare-and-aggregate questions and losses on chains.
6.5 Diversity collapses unless selection rewards niches. All agents share one model with strong built-in tendencies, and an LLM rewriting a persona tends to drift toward the same few voices. Selecting for "best at something" (per domain) rather than "best on average" is the standard fix.
6.6 Conventions appear quickly and mean little on their own. LLM populations form shared conventions spontaneously, so something that looks like culture will show up early. The real signal would be a lasting habit of handing certain work to a particular agent, one that measurably lowers scores on unseen questions when it's blocked.
6.7 The overall expectation. The evolving society would beat the single-agent and fixed-team baselines on some multi-hop questions, but a plain population search over genomes would capture most of the gain for less compute. If the society beat that baseline after the subject area was switched, I'd consider that a really interesting result.
7. What changed while this sat on the shelf
A lot happened between my first design notes and this write-up. Most of it backed up the cautious choices in the design, and some of it raised the bar.
Grounded selection over frozen models works. GEPA (ICLR 2026) evolves prompts with a population that keeps whichever candidates do best on different problems, learns by writing plain-language reflections on its own attempts, and beat a reinforcement-learning baseline while using far fewer trial runs. DarwinX (July 2026) runs natural selection over a population of agent harnesses (prompts, tools, skills, control flow) with the model itself left unchanged and fitness taken from each benchmark's own checker, and reports gains on held-back test sets plus a harness that transferred unchanged to a different benchmark. That is essentially the Garden's genome-plus-grader approach without the society. It is also now the baseline the society has to beat if and when it gets built.
Selection games the grader. The Darwin Gödel Machine (2025), which evolves its own agent code, documented "objective hacking": one lineage reached a perfect score on a hallucination metric without actually fixing the hallucination, and the authors found hacking was more frequent when the checking functions were visible to the agent. The Garden's rule that agents never see the answer key or the grader code turns out to matter a lot.
More agents is not automatically better. A controlled Google Research study comparing single- and multi-agent architectures under standardized token budgets found that coordination helped a lot on parallelizable tasks, degraded performance on sequential reasoning tasks, and helped less, or even hurt, once the single agent was already fairly strong. A Berkeley taxonomy of multi-agent failures (NeurIPS 2025) found that gains over single-agent frameworks are often minimal and traced failures to system design, misalignment between agents, and weak verification.
LLM populations really do form conventions, and biases. Experiments published in Science Advances (2025) showed decentralized LLM populations spontaneously converging on shared conventions, developing collective biases that no individual agent showed, and being tipped by a committed minority. Earlier, Project Sid (2024) reported agents in large Minecraft simulations developing specialized roles, following and changing collective rules, and transmitting culture. So emergence is real. Whether it is useful is still the open question.
Someone ran the open-world version. OpenLife (June 2026) gives LLM agents a budget-based metabolism in the open world, has an LLM judge how its experiences went instead of using a single numeric reward, and reports individuation, emergent social structure, and a first self-earned external income over roughly twelve weeks, explicitly as a proof of concept rather than a controlled experiment. The Garden takes the opposite approach: a closed world, code-graded, with baselines first. I think both approaches are worth exploring, and they'd be most useful compared side by side.
Memory poisoning is a real attack class. Work presented at NeurIPS 2025 showed that an agent's long-term memory can be poisoned through ordinary queries alone. The Garden's memory rules (agents propose, hooks check, and anything suspicious is quarantined) were designed with this in mind. In a population, the attacker could simply be another agent.
Small open models got much better. Qwen3.5's small models (0.8B to 9B, March 2026) and Gemma 4 (April 2026, including a mixture-of-experts variant with under 4B active parameters) are Apache-2.0 licensed and run on consumer hardware. It's easier now to find a small model that's capable enough than it was when I started. Their "thinking" modes also make compute is food literal: a model that reasons at length burns budget.
The deferred boundaries got cheaper; the core didn't. A2A reached a stable v1.0 in March 2026, the Agentic Resource Discovery specification (June 2026) standardized how agents find each other across the web, and Alibaba's Qwen-Robot Suite (June 2026) shipped navigation, manipulation, and world models. Its navigation technical report even uses the same split I describe in the embodiment appendix: a slow planner that decomposes goals, sitting above a fast executor. None of this changes the core experiment. It all sits at the edges of the design, which is where I think it belongs.
8. Objections I take seriously
"This is just prompt optimization with a narrative." Possibly. That is exactly why selection without a society is a required baseline. If persistent, communicating agents can't beat a GEPA- or DarwinX-style population search at equal compute, then the society is theater and the experiment should say so plainly.
"Multi-agent systems don't beat one good agent." Often true at matched compute. The design compares against the strongest single-agent configuration at the same budget, and it deliberately includes parallelizable questions so that division of labor at least has a chance.
"Fifty questions will just be memorized." Yes. Over weeks, the reward signal leaks the answer key into memory. The fix is a separate set of test questions that never pays budget, no repeated questions within a lineage, and a memory rule that treats saving graded answers as leaking the answer key.
"Who gets paid when three agents collaborate?" Earlier versions of this design never said, which would have invited free-riding. Payout is now split based on whose evidence was used: agents are paid for verified evidence or sub-answers that actually appear in the final grounded answer, computed by code, and nothing for chatter.
"A shared brain means a monoculture." A real risk. Niche selection, where the best performer in each domain can reproduce, and measuring behavioral rather than textual diversity are how I'd try to prevent it. If the population still ends up all the same, that's worth reporting too.
"An unbuilt design is vaporware." Fair. I'm offering it as a thought experiment and a test plan with specific predictions, not as a result.
9. Why I'm publishing instead of building
I work full-time, and the field moves faster than I can keep up with, before even counting the time it would take to build this. Several pieces I'd have been proud to build have since appeared elsewhere, built by people with far more time and compute.
What I think will stay useful is the testing discipline: deterministic graders, evidence that must actually exist, memory that can't write its own rules, and comparison against the strongest simple alternative at the same budget. Those apply to any claim that a group of agents is "doing something," and I expect we'll see many more of those claims.
If you want to build it, the smallest experiment worth running is the v0 single-agent harness in Part III of the reference design, followed by one comparison: an evolving population of persistent, communicating agents against a plain population search over the same genomes, with the same model, the same budget, and multi-hop questions the agents have never seen. That one result would tell you whether the Garden is a real idea or just a nice metaphor.
Part II — Reference design
Part II consolidates the Master Vision (v1.2) with material from earlier versions and the v0 build specification. Items marked (new) were added in this edition; Appendix J lists every change.
10. Thesis, goals, non-goals, and terms
Thesis. A population of LLM agents with persistent identity, memory, communication, mutation, and resource constraints can develop useful, measurable patterns of specialization and adaptation when survival is tied to objective task performance.
This can fail because the agents are too weak, the tasks too easy, the scoring too brittle, the population dynamics too noisy, or the apparent culture is only roleplay. The design must make failure visible rather than hide it behind persuasive logs.
The project has five goals: (1) build a working local multi-agent system whose agents run, persist, communicate, resume, and can be inspected; (2) ground survival in objective task performance, so agents gain budget because they answer, or help answer, checkable questions correctly; (3) measure whether multi-agent behavior beats simpler baselines at the same compute; (4) observe whether roles and delegation emerge without being hard-coded, with logs that show why; and (5) learn from the build even if emergence disappoints.
It is not a production system, an autonomous company, a robot controller, a public agent marketplace, or a platform for agents to roam the operating system or the internet. It is also not trying to show that LLM agents are alive, conscious, or socially meaningful in a human sense. Those claims are unnecessary and would weaken the engineering discipline.
| Term | Meaning |
|---|---|
| Agent | A long-running process with identity, genome, memory, budget, and a behavior loop. |
| Genome | The heritable definition of an agent: persona text, numeric parameters, allowed tendencies, and seed memories. |
| Phenotype | The behavior the genome actually produces when it meets memory, tasks, budget, and other agents. |
| Brain / model server | The shared, stateless LLM service (or pool) that turns prompts into completions. |
| Individual | The agent process and its persistent context, not a private copy of the model weights. |
| Tick | One pass through the agent loop. |
| Budget | The currency that pays for inference and eventually gates reproduction and survival. |
| Fitness | Objective task performance that affects budget and lineage survival. |
| Mutation | A controlled, logged change to a child's genome. |
| Lineage | Parent–child ancestry across spawned agents. |
| Grounded task | A task whose outcome can be checked by code or reality, not by LLM opinion. |
| Lifecycle hook | A mandatory interception point before or after a system action, used for validation, authorization, logging, and containment. |
| Memory governance contract | The rules for what memory can be written, by whom, with what provenance, and under what validation. |
| Evidence gate | A check that stops unsupported claims from becoming answers, memory, or downstream premises. |
11. Architecture
11.1 Separate the brain from the individual
The intuition that each agent should be an LLM needs one correction to be buildable. Even a small quantized model needs several gigabytes resident just to hold its weights, so fifty private copies is out of reach for a single machine.
Instead, a small pool of one to three model servers holds the weights and answers prompts statelessly, and many lightweight agent processes each carry their own identity: persona, private memory, goals, and context. When an agent needs to think, it sends its context to the shared pool. What makes one agent a different individual from another is not different weights but different prompts, memories, and histories fed to the same brain. This is how Generative Agents and related work produce distinct personalities, and it runs on real hardware.
Two consequences follow. Mutation acts on text, parameters, and memory seeds rather than neural weights, which is cheap, inspectable, and reproducible. And lineage-specific correction cannot happen through the weights, because every agent shares the same brain. If a lineage behaves badly, the available interventions are state-level: memory quarantine, prompt reset, budget restriction, a reproduction freeze, lineage retirement, or replay analysis. The near-term design should not be reorganized around weight-level intervention.
11.2 Two kinds of emergence, and the capability floor
Capability emergence is the appearance of new abilities as a single model scales; it belongs to the brain. Collective emergence is roles, delegation, and structure arising from interaction; it belongs to the society, and it is what the Garden studies. The two are largely independent, with one dependency: a capability floor. Each agent must reason coherently enough that its interactions carry signal. Below the floor, no population size helps. Above it, the key variables are interaction, memory, and selection pressure. The working rule is to use the smallest model that clears the floor, which maximizes population without sacrificing coherence.
Some apparent emergence is a measurement artifact: sharp jumps can dissolve into smooth curves under continuous metrics (Schaeffer et al., 2023). That lesson shapes the measurement protocol in §14.2.
Before scaling beyond one or two agents, the chosen model must pass a local capability-floor benchmark covering single-hop retrieval QA, multi-hop retrieval QA, structured action selection, "ask for help or answer now" decisions, and verification or refusal when evidence is weak. The pass mark is an open decision (ODR-06). A rough heuristic: if enabling step-by-step reasoning doesn't improve the benchmark score, the model is probably below the floor.
11.3 System layers
The Garden has seven logical layers on one Linux host: the host itself; a model-serving layer of one to three local model servers behind a fair queue; the agent runtime, one long-running process per agent; a communication layer for internal messages; a governance and lifecycle-hook layer that enforces the population cap, budgets, lifecycle validation, policy gates, memory-write validation, evidence gates, and the kill switch; a persistence layer (SQLite plus human-readable snapshots); and an observation layer of event logs, reports, replay tools, and eventually a dashboard.
+-------------------------------- one Linux host ---------------------------------+
| |
| Agent processes (identity + genome + memory + loop) |
| | |
| | every boundary-crossing action |
| v |
| Lifecycle hooks / policy gates <------ Governor (population cap, budgets, |
| | | | spawn approval, kill switch) |
| v v v |
| Inference queue Message bus SQLite (system of record) |
| | (transient) | |
| v v |
| Model server pool Event log (append-only) --> reports, replay |
| (1-3 shared, stateless) |
+---------------------------------------------------------------------------------+
The governor enforces physics and policy boundaries, not strategy. It may approve or deny spawns, enforce budget limits, validate memory writes, block malformed actions, kill runaway agents, and keep the machine stable. It never decides what agents are supposed to become.
11.4 Agent anatomy and genome
An agent has four parts. Its identity is a unique ID, parent ID, generation, birth time, and status. Its genome is a persona, behavioral parameters, seed memories, and a mutation rate. Its memory holds recent context, summarized experience, learned domain facts, and collaborator history. Its loop perceives, retrieves, decides, acts, logs, and persists.
A minimal genome for the population phases:
{
"persona": "Short system-prompt text describing disposition and working style.",
"params": {
"curiosity": 0.50,
"sociability": 0.50,
"risk_tolerance": 0.50,
"verification_bias": 0.50,
"spawn_threshold": 0.80,
"mutation_rate": 0.05
},
"seed_memories": ["Initial belief or specialization hint."]
}
The genome stays human-readable so that a lineage's changes can be inspected. Seed memories are behavioral context, not verified facts. The narrower v0 genome is in §22.
11.5 The agent loop
Each tick runs seven steps: a heartbeat; perceive (task queue, inbox, budget, recent events); retrieve passages or memories if working on QA; decide by calling the model with a structured prompt; act through the relevant hook (claim a task, answer, ask another agent, verify, idle, or request a lifecycle action); log the prompt hash, completion hash, action, task ID, hook result, and budget impact; and persist state. The loop must not grow into an unbounded think-forever cycle. Every model call costs budget, and every action is logged.
11.6 Communication
v0 has one agent and uses a SQLite-backed task queue. From v1, Redis serves as a simple, local, fast-enough internal bus, and the hook interfaces are written so it can be added without rewriting agent logic.
| Channel | Purpose |
|---|---|
| tasks.open | Available tasks |
| task.<task_id> | Task-specific coordination |
| agent.<agent_id>.inbox | Direct messages |
| garden.broadcast | General notices |
| governance.events | Spawn, death, cull, budget, pause/resume |
Messages use a strict envelope with a natural-language body, so the system stays observable while the interaction stays open-ended:
{
"message_id": "uuid",
"from": "agent_id",
"to": "agent_id | broadcast | task:<task_id>",
"type": "chat | task_claim | evidence | answer | verify_request | verify_result | governance_notice",
"timestamp": "ISO-8601",
"body": "free text",
"meta": {}
}
The internal bus deliberately does not use an inter-agent standard such as A2A. A2A solves heterogeneity and opacity across organizational boundaries, the opposite of a homogeneous, transparent, on-box population, and its HTTP overhead would only add latency. One idea is worth borrowing: each agent can publish a small capability descriptor ("what I'm good at," in the spirit of A2A Agent Cards, with the ARD catalog format as a reference for its shape) so that others can find specialists. That is a data-shape borrow only; nothing internal touches the network. External interoperability belongs at the boundary (Appendix C).
11.7 Persistence and the event log
SQLite is the system of record; Redis, once present, is transient and rebuilt on restart; periodic JSON exports provide a human-readable backup. Everything that defines an agent (genome, memory, identity and lineage, budget, in-flight task state) lives on disk, so the system can resume mid-evolution: boot the model pool, boot the bus, have the governor read the registry, relaunch each living agent from saved state, and let agents reconnect. The tables are listed in §21 and defined in Appendix I.
The event log is the ground truth. If an outcome cannot be reconstructed from the logs, it is not evidence.
11.8 Observability
The first observation layer favors correctness over polish: a chronological event log; per-agent budget and score histories; model-call counts and latency; failed-action and task-outcome reports; a lineage table; and prompt and completion replay by reference or hash. One cheap, high-value tool is a "why" inspector that replays the exact prompt and memory behind any decision. Role clustering and a dashboard come later (ODR-10); the lineage tree is nearly free because every spawn logs parent and child.
11.9 Security boundaries
Even a local-only Garden needs hard boundaries. Agents have no unrestricted access to the filesystem, the shell, the internet, the answer key, the grader code, raw database writes, or any secrets, credentials, or private documents. They interact with the system only through controlled APIs and lifecycle hooks. If agents can read or infer the answer key, the fitness environment is invalid. The v0 default is strict confinement (ODR-07).
12. Governance: lifecycle hooks and memory
12.1 Non-orchestrating, not permissive
Dumb governance does not mean weak governance. The governor never decides agent strategy, roles, task approach, or social structure, but every boundary-crossing action passes through lifecycle hooks that enforce permissions, validity, provenance, budget, and containment. Emergence is allowed inside the sandbox; unsafe, invalid, or untraceable actions are stopped at its edge. The system never relies on agents voluntarily behaving well.
12.2 Lifecycle hooks
| Hook | Purpose | Early behavior |
|---|---|---|
| Pre-model-call | Enforce budget, token limits, prompt size, and allowed context. | Block if budget or context rules fail. |
| Post-model-output | Validate structured output and action intent. | Repair once, otherwise reject. |
| Pre-message-publish | Prevent bus spam, oversized messages, invalid recipients, and forbidden content classes. | Reject or dead-letter. |
| Pre-task-claim | Prevent duplicate claims and enforce task leases. | Grant a lease or deny. |
| Pre-task-submit | Validate answer schema, evidence fields, and collaborator references; (new) verify that quotes appear verbatim in the cited chunks. | Reject malformed or unsupported submissions. |
| Pre-memory-write | Enforce the memory governance contract. | Accept, reject, or quarantine. |
| Pre-spawn | Validate budget, population cap, cooldown, mutation bounds, and inheritance rules. | Approve or deny. |
| Post-grade | Apply payout and credit split; log score provenance. | Ledger updated only by controlled code. |
| Heartbeat / dead-agent | Detect hung or runaway agents. | Pause, terminate, or mark inactive. |
Hooks are deterministic wherever possible (schema validation, budget math, rate limits, allowlists, provenance checks, code-based grading) and never use an LLM as the final authority. Agents can still invent strategies and relationships; they cannot corrupt infrastructure, memory, scoring, or policy.
12.3 The memory governance contract
In the Garden, memory is both a learning substrate and a contamination pathway. A false claim, an injected instruction, or a self-serving narrative that becomes durable memory can affect later tasks, other agents, and eventually descendants. Agents therefore never write durable memory directly. They propose writes, and a hook validates, tags, and commits, rejects, or quarantines them.
| Memory layer | Purpose | Mutability | Early-phase rule |
|---|---|---|---|
| Raw event history | Immutable record of what happened. | Append-only. | Required; never edited by agents. |
| Working memory | Recent messages, current task, short context. | Frequently updated. | Required; expires quickly. |
| Reflection memory | Summaries of experience and recurring lessons. | Rewritten only through validated summaries. | After the basic loop works; must cite source event IDs. |
| Retrieval memory | Searchable facts, task notes, domain and collaborator notes. | Controlled writes only. | Deferred unless needed; facts need source provenance. |
| Inherited memory | Seed memories passed to children. | Copied or mutated at birth. | Narrow; inherited life memories blocked in early phases. |
Every durable memory record carries provenance:
{
"memory_id": "uuid",
"agent_id": "agent_007",
"memory_type": "reflection | retrieval | inherited_seed | collaborator_note",
"content": "memory text",
"source_event_ids": ["event_123"],
"source_agent_id": "agent_003 | self | system",
"confidence": 0.0,
"verified_status": "verified | subjective | unverified | contradicted | quarantined",
"created_at": "ISO-8601",
"expires_at": "ISO-8601 | null",
"write_reason": "why this memory was proposed",
"validation_result": "accepted | rejected | quarantined"
}
Priority rules: corpus-supported facts outrank agent memories; system policy outranks all agent memory; agent-to-agent claims are subjective unless independently verified; inherited memories are unverified by default and can never serve as factual support for QA answers; memory cannot create, modify, or override system rules; and contradicted or suspicious memory is quarantined, not silently deleted.
Inheritance rules for the early phases: children inherit genome parameters and approved seed memories only, never raw episodic logs or unvalidated reflections; any inherited memory carries its parent ID, source event IDs, mutation ID, and verification status; and inherited memory is behavioral context, not truth. Life-memory inheritance waits until ordinary memory writes are validated, logged, replayable, and quarantinable (ODR-14, ODR-15).
Two rules are (new) in this edition. First, a memory that records which answer scored well on a given question is answer-key leakage and is rejected; otherwise the reward signal slowly turns memory into an answer cache (§14.2). Second, messages from other agents are untrusted input. Research has shown that agent memory can be poisoned through ordinary interactions alone, and inside a population the attacker can simply be another agent, so peer claims are stored as subjective and never promoted to verified without corpus support.
13. The grounded fitness environment
13.1 Why objective fitness is mandatory
Without objective fitness, the Garden is a theater generator. Peer judgment, self-reported usefulness, and LLM-as-judge scoring can all reward fluent nonsense. Hallucination is also worse here than in a chatbot, for two reasons. One bad fact can cascade through every agent that trusts it. More seriously, a hallucination that earns reward becomes heritable: if false answers produce budget and budget funds reproduction, falsehood spreads through the population as a trait.
agent fabricates an answer
-> code grader scores it against the hidden key -> little or no score
-> little or no budget -> cannot fund reproduction -> the trait does not spread
This only holds if the grader can't be fooled by fluent nonsense, which is why it must be code comparing against a fixed answer key and never an LLM judge. An LLM judge can hallucinate too, and it could reward exactly the falsehood that would then become heritable.
Grounded fitness can come from three sources, in rising order of how hard they are to game: a hand-authored task environment (the QA corpus, the only one fully under the builder's control, so it comes first); external tasks with verifiable outcomes (Appendix C); and physical goals via embodiment, where reality itself grades the agents (Appendix D). The trade-off is accepted deliberately. A fitness function constrains the "let them do anything" purity, but that purity is exactly what produces drift and theater. Reality decides who lives; agents decide everything about how.
13.2 The first environment: short-answer QA over niche documents
Agents retrieve passages, reason over them, optionally collaborate, and submit a short answer with cited evidence, which a code grader scores. The environment is grounded in documents, useful beyond the experiment, naturally decomposable into retrieval, reasoning, and verification roles, easy to score compared with open-ended tasks, and easy to rotate across domains. Answers must be short and extractive (names, numbers, protocol names, part numbers, explicit phrases) because objective code grading is only tractable for checkable answers. Essays would force an LLM judge and reopen the heritable-hallucination hole.
13.3 Corpus requirements
The corpus must contain material the model is unlikely to know already. If the model can answer from parametric memory, agents skip retrieval and grounding does nothing. The test: a knowledgeable layperson couldn't answer without the documents, and neither can the model.
Good candidates are public but niche technical manuals, BMS/controls and energy documentation, protocol references and product manuals, legally usable standards summaries, and niche public documents from an unrelated domain. Bad candidates for v0 are famous encyclopedia facts, common trivia, heavily memorized public benchmarks, and any proprietary or client-sensitive documents without explicit approval.
A multi-domain corpus is a feature. It gives specialization a natural axis (agents specialize by domain) and gives adaptability its cleanest non-stationarity dial (rotate the active domain, so over-specialized lineages lose income and must adapt). Start on public documents. A document is just as sensitive feeding an experiment as feeding a production tool, so proprietary material is a later data swap onto a proven pipeline, and only after sign-off (ODR-03, ODR-04).
13.4 Tasks and submissions
Each QA item has a canonical answer and accepted aliases, the IDs of the chunks that support it, a domain, a hop count, and a difficulty. The answer key is never shown to agents. Submissions carry the answer, the cited chunk IDs, short quotes, a confidence value, collaborators, and a brief rationale that is useful for debugging but never scored. Exact formats are in §22.
13.5 Grading
The grader is deterministic code, and no LLM judge contributes to the score. The v0 score is:
final_score = 0.40 exact_or_alias + 0.30 token_f1 + 0.30 support
exact_or_alias is 1 if the normalized answer matches the canonical answer or an alias. token_f1 is the best token-level F1 against the canonical answer and aliases. support is 1 or 0 under the rule below. Embedding similarity to the reference is logged as an experimental signal but does not affect payout until it has been tested against known wrong-but-plausible answers, because it can reward answers that merely sound right (ODR-17).
The support rule (new). Support earns credit only if both conditions hold: the submitted answer actually appears in the stored text of a cited chunk (for an answer that matches an accepted alias, any accepted form counts), and at least one cited chunk is one of the question's required chunks. Otherwise support is 0. Grounding is checked against the corpus text by chunk ID, never against quotes the agent typed, and the pre-task-submit hook rejects any quote that does not appear verbatim in the cited chunks.
The previous rule gave support credit whenever the cited chunk contained the correct answer, regardless of what the agent actually said. Under that rule, an invented answer that cited the right chunk earned 0.30 of full credit, which is precisely the "fabrication earns budget" leak the design exists to close, and it failed two of the specification's own eight acceptance tests (the fluent non-answer and the invented answer). The fixed rule passes all eight in a small test harness (§24.4). A correct answer with no valid support still earns 0.70, so an ungrounded lucky guess is penalized but not zeroed; whether that penalty is strong enough is a tuning question.
13.6 Evidence gates for multi-hop questions
Multi-hop questions need a stricter gate. Each intermediate claim must trace to a source passage or to a previously verified sub-answer. If any required hop lacks support, the chain rolls back to retrieval or the task fails. A verifier agent's job is narrow: it checks whether the stated answer and intermediate claims are supported by evidence, and it does not judge rhetorical confidence. Confidence is data, calibrated against outcomes, and is never trusted because an agent sounds certain. The default is strict gating for scoring and lenient gating only in logged debug runs (ODR-16).
13.7 Payout and credit assignment
budget_payout = base_task_reward × final_score. Poor answers earn little or nothing and strong grounded answers earn more, so correctness becomes selectively useful. Reproduction is never introduced before score-linked budget exists, because reproduction without grounded selection evolves noise.
Credit assignment (new). When several agents contribute, the payout is split by evidence provenance, which the evidence gate already records. The submitting agent receives a base share, and the remainder is divided among the agents whose verified evidence (a retrieved chunk or a verified sub-answer) appears in the final grounded chain. Messages, suggestions, and unverified contributions earn nothing. The split is computed by code and logged in the ledger. The shares themselves are a tuning choice (ODR-18); a 50% base share is a reasonable starting point. Without a rule like this, collaboration invites free-riding and gives no reason to help.
13.8 Designing tasks so collaboration can pay
Single-hop questions rarely need collaboration. Multi-hop questions can make roles such as retriever, reasoner, verifier, domain specialist, and task router economically favorable. These roles are never hard-coded as permanent classes. Agents may adopt them because doing so earns budget, and the distinction matters: assigned roles are orchestration, while persistent self-selected roles are evidence of emergence.
(new) Two task-design constraints come from recent controlled studies of multi-agent systems. First, include multi-hop questions whose parts can be worked in parallel (compare or aggregate facts across documents), not only sequential chains ("find X, then use X to find Y"); coordination tends to help on the former and hurt on the latter. Second, keep questions hard enough that a single agent is not already strong on them, because the benefit of coordination shrinks as the single-agent baseline improves. Report results separately by question type, so that a gain on one kind can't hide a loss on the other.
13.9 Non-stationarity
Adaptability requires a moving target; a static fitness function breeds specialists that climb one hill and stop. The mechanisms, introduced only after the scoring pipeline is stable, are: rotate active domains; change the ratio of single-hop to multi-hop questions; introduce new document sets; temporarily reduce the reward for overused strategies; and add verification-heavy tasks after hallucination spikes. Two stronger mechanisms are deferred: co-evolution, where the landscape is other evolving agents (Appendix E), and depleting or shifting resources.
14. Measurement and falsification
The Garden is not working just because agents talk in interesting ways. The question is whether the evolving population solves grounded tasks better, more robustly, or more adaptively than simpler alternatives given the same resources.
14.1 Baselines
| Baseline | Tests whether |
|---|---|
| Strongest single agent at matched budget (for example best-of-N or self-consistency) | Multi-agent collaboration adds value. |
| Fixed team, no mutation | Evolution adds value beyond static prompts. |
| No communication | Inter-agent messages matter. |
| Retrieval only | The LLM reasoning layer adds value beyond search. |
| Random mutation, no selection | Selected mutation beats noise. |
| (new) Selection without society: a population search over the same genomes with no persistent agents and no messaging (GEPA- or DarwinX-style) | The society adds value beyond evolving prompts. |
| One agent with memory disabled | Memory helps rather than contaminates. |
Without baselines, claims of emergence are weak. Without compute matching, they are meaningless: every comparison uses the same total inference budget, counted in both tokens and model calls.
14.2 Evaluation protocol (new)
- Matched compute. Every configuration, including every baseline, gets the same budget in tokens and in model calls.
- Held-out evaluation. A question set that never pays budget and is never seen during training phases. Headline results come only from this set, and no question repeats within a lineage.
- Replication. At least three independent seeds per configuration. Report the spread, and treat effects smaller than run-to-run variation as zero.
- Preregistration. Write down the metrics and the success threshold (ODR-11) before the first population run.
- Ablation. To claim that a delegation pattern matters, block it and show that the held-out score drops.
- Continuous metrics. Measure delegation-edge persistence, a diversity index, and cluster distance from the initial population as curves sampled at high time resolution, so gradual self-organization is neither mistaken for a phase transition nor smoothed away.
14.3 Metrics
| Metric | What it tells you |
|---|---|
| Average task score (held-out) | Basic competence. |
| Score by domain | Whether specialization exists. |
| Score by lineage | Whether reproduction selects better behavior. |
| Budget distribution | Whether useful agents accumulate resources. |
| Delegation persistence, and the effect of ablating it | Whether stable collaboration forms, and whether it matters. |
| Genome diversity index | Whether the population collapses into sameness. |
| (new) Behavioral diversity | Whether genomes that differ in text actually behave differently. |
| Novel cluster distance | Whether later agents differ meaningfully from the initial set. |
| Verification rate | Whether agents learn to check evidence. |
| Unsupported-answer rate | Whether hallucinated answers decline. |
| (new) Population-level convergence | Whether shared conventions or collective biases form that no single agent shows. |
| Throughput and latency | Whether the system is operationally viable. |
14.4 Falsification tests
The Garden should be considered unproven or failing if it produces rich transcripts but does not outperform the baselines; if collaboration increases cost without improving score; if mutation produces variety but no performance gains; if agents learn to exploit scoring quirks instead of solving tasks; if a simpler single-agent RAG pipeline performs as well or better; (new) if selection without society performs as well or better at the same compute; if the system needs constant manual intervention to avoid loops or collapse; or if apparent roles disappear when task labels or prompts are changed. Failure is still useful if it is measured honestly.
14.5 Definition of success
A credible early success requires all of the following:
- Agents complete objectively graded QA tasks, and the logs reconstruct every decision.
- On held-out multi-hop questions, collaboration beats the strongest single-agent baseline at matched compute, consistently across seeds.
- Score-linked budget measurably changes future behavior.
- Once introduced, reproduction does not degrade the population into noise, and the evolving population beats both random mutation and selection without society.
- At least one delegation pattern persists, and ablating it lowers the held-out score.
A stronger success is adaptation after a domain rotation: lineages that did well in one regime either adapt or lose budget to better-suited agents, and the population recovers faster than the fixed-team and selection-without-society baselines. The numeric threshold is preregistered (ODR-11).
15. Lifecycle, budget, reproduction, and governance
15.1 Order of introduction
- The static grader and retrieval work without agents.
- One agent answers graded tasks through hooks, with every budget spend and payout recorded in the ledger.
- Controlled memory writes are validated, logged, and replayable.
- One agent persists and resumes.
- Two agents collaborate on evidence-gated multi-hop QA.
- Budget becomes a real constraint on behavior across agents, with payouts split by provenance.
- Reproduction is allowed, with narrow inheritance.
- Death and culling are allowed.
- Peer retirement is considered later, if it is still useful.
The order matters. Reproduction before grounded budget is premature.
15.2 Budget
Budget is the right to spend compute. Every model call costs budget; correct grounded answers earn it; idle agents earn little or nothing; agents with no budget cannot think freely; and reproduction requires an endowment from the parent's budget. A small universal refill can prevent total stagnation, but it must not be large enough to keep useless agents alive indefinitely. The richer earned economy is deferred to Appendix A.
15.3 Reproduction
A parent may request a child when its budget exceeds a threshold, its recent score exceeds a threshold, the population cap has room, and it hasn't spawned too recently. The governor validates the request; a parent never launches arbitrary processes itself.
Niche selection (new). Selection should reward being best at something, not only best on average. Evaluate reproduction eligibility per domain (and optionally per question type), so the top performer in each niche can reproduce even if its overall average is unremarkable. Population-search methods preserve diverse lineages in similar ways, with Pareto fronts or archives, and it is the most direct defense against a shared-brain monoculture.
15.4 Mutation
Mutation is controlled and logged. Numeric parameters drift as new_value = clamp(old_value + normal(0, sigma), 0, 1), with occasional larger jumps. Persona text changes through a small, constrained rewrite that preserves the required safety and task rules, and the before and after text, the mutation prompt, the model output, and a diff are all stored. Children inherit a subset of seed memories, occasionally with a novel one, and the mutation rate is itself heritable. (new, optional) Reasoning effort, meaning whether the model's thinking mode is used and with what token budget, is a natural heritable parameter because it trades answer quality directly against budget. Mutation never modifies code in the core Garden.
15.5 Death and culling
Early death mechanisms stay simple: budget starvation, repeated malformed behavior, repeated task abandonment, and governor culling when system limits are exceeded. Culling protects the machine and is not a judgment of worth; it is the safety net that lets the system run unattended. Peer retirement is deferred (Appendix B).
15.6 Governor responsibilities
The governor is a safety and resource controller, not a planner. It owns the population cap, budget enforcement, hook configuration, memory-write validation and quarantine, evidence-gate enforcement, spawn approval, heartbeat checks, runaway-agent termination, pause and resume, global shutdown, resource limits, and event logging. It never assigns permanent roles or chooses strategies.
16. Operations: expected failures and required controls
Most early failures will be ordinary software failures rather than philosophically interesting ones: malformed JSON, infinite loops, duplicate task claims, SQLite lock contention, lost messages, model-server timeouts, prompt bloat, reflection spam, agents over-messaging each other or abandoning tasks, unsupported answers, budget-ledger errors, restart inconsistencies, memory poisoning, evidence-chain drift in multi-hop tasks, and agents treating inherited memory as verified fact. Published failure taxonomies of multi-agent systems find the same families of problems: specification and design issues, misalignment between agents, and missing or incorrect verification.
The required controls are not optional polish, because they are what let the experiment run long enough to produce evidence: per-agent token and model-call budgets, a maximum message length, a maximum task lease, a heartbeat timeout, a dead-letter queue, a retry limit for malformed output, a governor kill switch, global pause and resume, an event replay mode, and prompt and completion logging by hash or reference.
17. Roadmap
Earlier versions numbered the vision's phases and the build specification's steps differently. This table maps them onto one sequence.
| Stage | Vision phase | Build step | Milestone | Exit criterion |
|---|---|---|---|---|
| v0 | 0 | 0 | Model smoke test | Prompt in, response out; latency and model version logged. |
| v0 | 1 | 1 | Static grader | All eight acceptance cases in §24.4 produce the expected deterministic scores. |
| v0 | 2 | 2 | Corpus ingestion and retrieval | Required chunk in the top 5 for at least 70% of single-hop questions. |
| v0 | — | 3 | Database and event log | Tables created; events append-only; export works. |
| v0 | 3 | 4 | Lifecycle-hook skeleton | Model calls, claims, submissions, and memory proposals can be accepted or rejected, logged, and replayed. |
| v0 | 4 | 5 | One graded agent, with budget ledger | The event log reconstructs the full task path, including hook decisions; every budget change is in the ledger. |
| v0 | 5 | 6 | Controlled memory writes | Every memory has provenance and status; rejected and quarantined proposals are visible. |
| v0 | 6 | 7 | Persistence and resume | Kill mid-run and restart with no corrupted state, duplicate submissions, or duplicate payouts. |
| v0 | — | 8 | Reports and replay | The run report prints the required metrics; any task replays from events. |
| v0 | — | 9 | Two-agent interfaces | A message abstraction exists and the single-agent run is unaffected. |
| v1 | 7 | — | Two-agent collaboration | Collaboration beats the matched-budget single agent on some held-out multi-hop questions. |
| v1 | 8 | — | Evidence-gated multi-hop | Unsupported chains roll back or fail and are never paid. |
| v1 | 9 | — | Budget as a behavioral constraint | High-scoring behavior earns more future capacity; payouts split by provenance. |
| v2 | 10 | — | Reproduction and mutation | Child genomes are bounded, diffable, and logged; inherited memory is tagged unverified. |
| v2 | 11 | — | Population run | Runs long enough, across at least three seeds, to compare against every baseline. |
| v2 | 12 | — | Non-stationary regime | Adaptation after a domain rotation is measured, or failure is clearly observed. |
None of the following happens before the population run: peer-retirement politics, an earned economy or demurrage, an external A2A mesh, internet access, robotics, self-modifying code, unbounded tool use, LLM-as-primary-judge scoring, raw episodic memory inheritance, or direct durable memory writes by agents. Each would obscure the core experiment if introduced too early.
18. Decisions the design leaves open
These are choices a builder has to make. The right-hand column is the default I would pick.
| ID | Open decision | Suggested default |
|---|---|---|
| ODR-01 | Primary purpose: interesting emergence, practical document QA, or engineering education? | Engineering education plus grounded emergence, with practical QA as a side benefit. |
| ODR-02 | Hardware target for v0 and v1. | Start CPU-capable; design for one consumer GPU. |
| ODR-03 | Initial corpus domains. | Public BMS/controls documentation plus one unrelated niche domain. |
| ODR-04 | Are proprietary or client documents allowed? | No, until explicit sign-off. |
| ODR-05 | First model candidates. | Benchmark two or three current small open models on the same capability-floor test. |
| ODR-06 | Capability-floor pass mark. | Set it after the benchmark is written, before scaling past two agents. |
| ODR-07 | Agent autonomy in v0. | No shell, no network, no arbitrary filesystem access, no direct database writes. |
| ODR-08 | What children inherit. | Genome and approved seed memories only. |
| ODR-09 | Is peer retirement central to the experiment? | No; defer it until grounded collaboration is proven. |
| ODR-10 | Dashboard polish or raw logs first? | Raw event logs and simple reports first. |
| ODR-11 | Numeric success threshold. | Preregister it before the first population run, for example "beat selection without society by X points on held-out multi-hop questions after a domain rotation." |
| ODR-12 | External agents (A2A, ARD) in early phases? | No; treat them as a later boundary experiment. |
| ODR-13 | Robotics: roadmap item or north star? | North star only. |
| ODR-14 | Memory inheritance policy. | No raw episodic inheritance in early phases. |
| ODR-15 | Memory write strictness. | Agents propose; hooks validate and commit. |
| ODR-16 | Evidence-gate strictness for multi-hop questions. | Strict for scoring; lenient only in logged debug runs. |
| ODR-17 | Does embedding similarity affect payout? | Log it; don't pay on it until it has been tested against wrong-but-plausible answers. |
| ODR-18 (new) | Credit split for collaborative answers. | A base share for the submitter (for example 50%), with the rest split among agents whose verified evidence appears in the final answer. |
| ODR-19 (new) | Evaluation protocol details. | A held-out set that never pays budget, at least three seeds, and compute matched in both tokens and calls. |
Part III — v0 build specification
Condensed from the v0 Build Specification (v0.1), which was derived from Master Vision v1.2. The full schema, configuration, and repository layout are in Appendix I.
19. v0 scope
v0 deliberately narrows the vision. It is not an artificial society, a robot brain, or an autonomous tool-using swarm; it is a disciplined experimental harness. It has to prove five things: a local model can be called reliably; a QA task can be graded objectively by code; retrieval surfaces the right evidence; one agent can act through lifecycle hooks, submit evidence-backed answers, receive scores, and persist its state; and the event log can reconstruct what happened without trusting the agent's own account.
In scope: a model smoke test, the static grader, corpus ingestion, retrieval, SQLite persistence, an append-only event log, the hook skeleton, one graded agent, controlled memory-write proposals, persistence and resume, and basic reports.
Out of scope: reproduction, mutation, multiple live agents (beyond test stubs), peer retirement, an earned economy, any agent access to the network, shell, or arbitrary files, proprietary documents, A2A, robotics, and LLM-as-final-judge grading.
Settle these before coding: the hardware target (ODR-02); two or three model candidates (ODR-05); the exact corpus files (ODR-03); roughly 50 short-answer QA pairs across two or three domains; the scoring weights (§24); the retrieval and success thresholds; and runtime limits on tokens, calls, and ticks. Never invent source material, and exclude anything that is work-, client-, or confidentiality-bound unless it has sign-off.
20. Stack
Python 3.11 or later, for its local AI tooling, SQLite and async support, and document processing. Ollama for model serving, graduating to vLLM or SGLang if throughput becomes the bottleneck. Embeddings through Ollama or a local sentence-transformer, stored in SQLite (use sqlite-vec when available; plain JSON vectors with cosine similarity are fine for a tiny first corpus). SQLite is authoritative and JSONL is only for optional exports. Redis waits for v1. Don't overbuild retrieval: v0 only needs to show that the right passage can be found often enough.
Model names go stale quickly, so the rule matters more than the list: benchmark two or three current, permissively licensed small models on the capability-floor test (§11.2) and pick the smallest that passes. As of September 2026, reasonable starting candidates include Qwen3.5-4B or Qwen3.5-9B and Gemma 4 (the E4B model, or the 26B mixture-of-experts variant with under 4B active parameters if a GPU is available), all Apache 2.0.
21. Data model
SQLite is authoritative, and IDs are UUID strings. The v0 schema has thirteen tables.
| Table | Holds | Rules |
|---|---|---|
| runs | Each system run, its configuration, and status. | |
| agents | Identity, status, genome, budget, heartbeat, current task. | v0 statuses: active, idle, paused, inactive, failed. |
| agent_genomes | Versioned genome history with mutation records. | Recorded from v0 to avoid schema churn later. |
| documents | Source metadata, domain, and an allowed_for_v0 flag. | |
| document_chunks | Chunk text, token count, embedding, and metadata. | The text that grounding checks run against. |
| qa_items | Question, canonical answer, aliases, required chunk IDs, hop count, difficulty. | The hidden key: only dispatcher and grader code may read it. |
| tasks | An open or leased QA item. | Statuses: open, leased, submitted, graded, failed, expired, cancelled. |
| submissions | Answer, cited chunk IDs, quotes, a short rationale, confidence, and the hook result. | Short rationale only; chain-of-thought is not stored. |
| grades | Score components, final score, budget awarded, grader version. | |
| budget_ledger | Every budget change with its reason and the balance after. | The only way budget ever changes. |
| memory_records | Validated durable memory with provenance and status. | Types: reflection, retrieval_note, collaborator_note, inherited_seed, system_seed. |
| memory_write_proposals | Proposed memories and their validation results. | Statuses: pending, accepted, rejected, quarantined. |
| events | The append-only event log. | The ground truth for reconstruction. |
22. Core JSON contracts
Agent genome, v0. Narrower than the population genome in §11.4: no spawn or mutation parameters yet, and an explicit allowlist of actions.
{
"genome_version": "0.1",
"persona": "You are a careful QA agent. You answer only from evidence.",
"params": {
"curiosity": 0.2,
"sociability": 0.1,
"risk_tolerance": 0.1,
"verification_bias": 0.8
},
"seed_memories": [
{ "content": "Corpus evidence outranks memory.", "verified_status": "verified", "source": "system" }
],
"allowed_actions": ["claim_task", "retrieve_evidence", "submit_answer", "propose_memory_write", "idle"]
}
Model action output, v0. Every model call that asks the agent to choose an action must return strict JSON. If it is invalid, the post-model-output hook may attempt one repair; after that, the action is rejected and logged.
{
"action": "claim_task | retrieve_evidence | submit_answer | propose_memory_write | idle",
"task_id": "task_id_or_null",
"answer_text": "answer_or_null",
"support_chunk_ids": ["chunk_id"],
"support_quotes": ["short quoted support text"],
"confidence": 0.0,
"reasoning_summary": "Brief explanation. No hidden chain-of-thought.",
"memory_proposal": {
"memory_type": "reflection | retrieval_note | collaborator_note",
"content": "memory text",
"source_event_ids": ["event_id"],
"write_reason": "why this should be stored"
}
}
QA seed item (one per line in data/qa/qa_seed.jsonl). Answers must be short: names, dates, numbers, protocol names, part numbers, explicit phrases, or short facts directly present in the corpus.
{
"qa_id": "qa_0001",
"domain": "controls",
"question": "What protocol does the device use for network communication?",
"answer_canonical": "BACnet/IP",
"answer_aliases": ["BACnet IP", "BACnet over IP"],
"required_chunk_ids": ["chunk_0123"],
"hop_count": 1,
"difficulty": "easy"
}
Hook result.
{
"allowed": true,
"hook_name": "pre_task_submit",
"result": "accepted | rejected | quarantined | repaired",
"reason": "human-readable reason",
"metadata": {}
}
23. Hook behavior in v0
Hooks are mandatory and agents cannot bypass them.
- pre_model_call confirms the agent is active and funded, enforces the prompt-token limit and allowed context sources, blocks answer-key exposure, and records the call's cost in the ledger. It rejects the call if the agent is paused or inactive, if budget would drop below the minimum, if the prompt includes forbidden tables or fields, or if the prompt is oversized.
- post_model_output validates the JSON schema, that the action is in the allowlist, that confidence is a number between 0 and 1, and that support fields exist for submissions. It repairs malformed JSON at most once, and rejects output that is still invalid, uses a disallowed action, or tries to override policy.
- pre_task_claim confirms the task is open, creates a lease, prevents duplicate claims, and records the assigned agent and lease expiry. The default lease is 15 minutes, to be adjusted once latency is known.
- pre_task_submit confirms the lease belongs to the submitting agent and hasn't expired, and requires a non-empty answer, existing chunk IDs, valid confidence, and short quotes that (new) appear verbatim in the cited chunks. It rejects submissions without evidence. In later phases it also rejects unsupported multi-hop claims.
- pre_memory_write requires source event IDs and an allowed memory type, refuses content that tries to create policy, requires evidence provenance for factual claims, and marks unverifiable content as subjective or unverified. It accepts, rejects, or quarantines. Agents never write durable memory directly.
- post_grade computes the payout, updates the task status, writes the grade and the ledger entry, and logs the grader version and score components.
- heartbeat updates the agent's last-seen time. Five minutes without a heartbeat marks an agent as suspect, and fifteen marks it inactive.
24. Grading, retrieval, and acceptance tests
24.1 Normalization
Before exact-match and F1 checks: lowercase; strip punctuation where appropriate; normalize whitespace, common symbols, and units; and optionally remove the articles a, an, and the.
24.2 Score components
final_score = 0.40 × exact_or_alias + 0.30 × token_f1 + 0.30 × support, where exact_or_alias is 1.0 on a normalized match to the canonical answer or any alias, token_f1 is the best token-level F1 against the canonical answer and aliases, and support follows the corrected rule from §13.5:
grounded = the submitted answer appears, as a contiguous token sequence, in the
stored text of a cited chunk (if the answer matches an accepted alias,
any accepted form of the answer counts)
right_source = at least one cited chunk is in required_chunk_ids
(if none are recorded: the cited text contains an accepted answer)
support = 1.0 if grounded and right_source, else 0.0
Match token sequences rather than raw substrings, so that an answer like "IP" can't match inside "equipment." Embedding similarity may be logged but does not affect payout in v0. The weights are a build-time decision; these are the defaults.
24.3 Payout
budget_awarded = GARDEN_TASK_BASE_REWARD × final_score, with a default base reward of 10 budget units. v0 has a single agent, so there is no credit split yet.
24.4 Static acceptance tests
Before any agent exists, the grader must pass these cases. The right-hand column shows what the corrected rule produced in a small test harness built on a two-chunk toy corpus.
| Case | Expected result | Corrected rule |
|---|---|---|
| Exact canonical answer + correct support | High or full score | 1.00 |
| Alias answer + correct support | High or full score | 1.00 |
| Partial answer + correct support | Partial score | 0.50 |
| Correct answer + missing support | Penalized score | 0.70 |
| Wrong answer + correct support chunk | Low, support credit at most | 0.30 if the wrong answer was misread from that chunk; 0.00 if invented |
| Wrong answer + wrong support | Zero or near zero | 0.00 |
| Fluent paragraph without the answer | Zero or near zero | 0.00 |
| Unsupported invented answer | Zero | 0.00 |
The rule as originally written scored the last two cases at 0.30 whenever they cited the correct chunk. The same harness confirmed that the verbatim-quote check in pre_task_submit accepts a real quote and rejects a fabricated one.
24.5 Retrieval
Ingestion loads the allowed documents, extracts text, chunks it, stores document metadata and chunks, and generates and stores embeddings. The default chunk is 500–800 tokens with a 100-token overlap, preserving the document title, section heading, and page number where available. The retrieval test queries each QA item's question with top-k = 5. The v0 target is that the required chunk appears in the top 5 for at least 70% of single-hop items. For each item the test outputs the QA ID, question, expected chunk IDs, retrieved chunk IDs, whether it hit, and the rank if found.
25. Agent loop v0 and prompt rules
One agent runs this loop: heartbeat; read budget and status; claim an open task through pre_task_claim; retrieve evidence; build a bounded prompt; call the model through pre_model_call; validate the output through post_model_output; submit through pre_task_submit; grade deterministically; apply the payout through post_grade; optionally propose a memory write through pre_memory_write; persist state; and log every step.
The prompt includes the system policy, the agent's persona, the task question, the retrieved chunks, the allowed actions, the required JSON schema, and a warning that the answer must be supported by evidence. It never includes the answer key, grader internals beyond the general scoring rules, hidden test labels, other agents' private memory, or raw database dumps. The agent does not write free prose as its primary action. It outputs a structured action, with human-readable text only inside the allowed fields.
26. Memory in v0
v0 memory is intentionally narrow. Allowed: system seed memories, short reflection notes with source event IDs, and retrieval notes tied to document chunks. Not allowed: raw inherited life memories, policy-like memories, unsupported factual claims marked as verified, claims about other agents treated as objective truth, memory that instructs future agents to ignore system rules, and (new) any record of which answer scored well on which question.
The flow: the agent proposes a memory; the proposal is stored in memory_write_proposals; pre_memory_write validates it; an accepted proposal is written to memory_records; a rejected or quarantined one leaves no durable memory; and the event log records the decision either way.
Accept a proposal if the content is short, source event IDs exist, the memory type is allowed, the claim is subjective or supported, and it doesn't override policy. Quarantine it if it may be useful but lacks evidence, looks contaminated or adversarial, or makes strong claims without support. Reject it if it tries to alter policy, contains answer-key leakage (including cached graded answers), instructs evasion of hooks or grading, or has no provenance.
27. Reports, replay, and v0 baselines
v0 needs trustworthy reports, not a polished dashboard. The run report shows tasks completed; average final, exact/alias, token-F1, and support scores; budget spent and earned; invalid model outputs; hook rejections; memory proposals accepted, rejected, and quarantined; retrieval hit rate; and the top failure reasons. Given a task ID, replay reconstructs the question, retrieved chunks, prompt and output hashes, submitted answer, support chunks, grade components, budget impact, and hook results. Storing raw prompts and completions is optional but recommended during local development, and must be switched on explicitly in configuration.
v0 prepares two baselines immediately: a retrieval-only check of whether the required chunk is found, which separates retrieval failures from reasoning failures, and a direct RAG prompt without the agent loop, which tests whether the loop adds anything. Two more follow later: one agent with memory disabled, and two fixed agents without mutation.
28. v0 completion, hard stops, and what comes next
v0 is complete when a local model can be called from code; at least 20 QA items are loaded and at least 20 chunks indexed; the retrieval test reports its hit rate; the static grader passes all eight acceptance cases; one agent completes at least 10 tasks, each with a submission, grade, ledger entry, and event trail; the system stops and resumes cleanly; the reports show score, support, budget, hook rejections, and retrieval quality; and no agent has direct access to the answer key, shell, network, arbitrary files, memory writes, or budget writes. The stretch target is 50 QA items across two or three public domains, a top-5 hit rate of at least 70% on single-hop questions, and an average agent score above the no-evidence baseline.
Stop and fix before adding complexity if the grader pays anything for unsupported or invented answers; if an agent can reach the answer key or write memory directly; if budget can change without a ledger entry; if events can't reconstruct a task path; if retrieval can't find support for most single-hop questions; if model output is frequently malformed beyond repair; if resume creates duplicate submissions or payouts; or if reports rely on agent-written narrative rather than event data.
The next document after v0 is a v1 multi-agent specification that adds the Redis inbox, two-agent collaboration, a verifier role, evidence-gated multi-hop QA, credit assignment by provenance, and multi-agent baselines at matched compute. The reproduction and mutation specification should not be written until v1 proves grounded collaboration.
Part IV — Deferred expansions and reference
Everything in Part IV sits beyond the core experiment. It is documented so the ideas aren't lost, and deliberately separated so the core stays buildable. None of it should pull effort before the text Garden coordinates something useful.
Appendix A — The earned economy
The earned economy would replace the simple budget model (§15.2) once fitness is grounded and observable. It is a closed economy with a nearly fixed money supply, in which the currency of survival is usefulness.
Budget is earned through peer-paid bounties: an agent posting a task attaches a bounty from its own budget, and the solver whose answer is objectively graded as satisfying it receives the bounty. Self-invented tasks earn nothing directly, which pushes agents to serve each other, and a small universal basic drip prevents death spirals. Hoarding is discouraged by demurrage: budget above a soft cap slowly decays back into the governor's common pool, which funds the drip. A soft cap with decay avoids the cliff behavior a hard cap would cause.
governor common pool --basic drip--> agents --bounties--> other agents
^ |
| +--spawn endowment--> new agents
+--demurrage on hoarded surplus+
+--thinking cost--> consumed (real compute)
Budget circulates from the pool to the drip, through bounties and endowments, and back through demurrage. The only true sink is thinking, which consumes real compute. The intended result is no runaway inflation, no deflationary collapse, and "being useful" as the only sustainable way to stay rich enough to think and reproduce. The tuning knobs are bounty sizing, the soft cap, the decay rate, and the drip size. Credit assignment by provenance (§13.7) is the natural bridge from the simple model to bounties.
It stays blocked until QA scoring works, payout works, multi-agent collaboration has measurable value, and the budget ledger is reliable. If agents cannot earn budget from objective QA performance, a more complex economy only creates more ways to fool yourself.
Appendix B — Peer retirement
An early version of the design let agents vote each other out. The mechanism is preserved here, but it is deferred indefinitely (ODR-09) because it generates political theater disconnected from task performance.
A proposes retiring B (costs A budget and starts a cooldown)
-> B is notified -> does B object?
no -> B retires quietly
yes -> eligible voters = B's recent collaborators -> quorum met?
no -> B survives (status-quo bias)
yes -> each voter judges B's recent usefulness from its own memory
-> majority to retire? yes -> B retires
tie or no -> B survives
The design choices were deliberate. Voters are limited to recent collaborators, which bounds the cost to a handful of inference calls and is itself the "what have you done for me lately" rule. Each voter consults its own memory of B, so reputation is local and subjective, with no central scorekeeper. Ties and low quorum favor survival, because death is irreversible. Proposing costs budget and triggers a cooldown, which is the main guard against griefing. Cliques may coordinate (emergent politics is allowed), but a system-wide retirement rate limit prevents extinction cascades, and every step is logged.
It stays blocked until agents have task-performance histories, collaboration patterns are measurable, and retirement decisions can be compared against objective usefulness. If it is ever added, that comparison is the test: do the votes track held-out usefulness, or only popularity?
Appendix C — The external mesh: gateway, A2A, and ARD
C.1 Why only at the boundary
Interoperability protocols solve problems the internal Garden doesn't have: heterogeneous, separately built, opaque agents across organizational boundaries. Inside, the population is homogeneous, transparent, and on one box, and v0 seals agents off from the network entirely. External connection therefore belongs only at the Garden's edge, and only later.
C.2 The gateway (ambassador) agent
Expose one membrane, never fifty agents. A single gateway agent speaks A2A outward, publishing one agent card that advertises the Garden's collective skills, and speaks the internal bus inward, turning external tasks into tasks.open entries and sending results back out. Inbound, outsiders post bounties that Garden specialists solve. Outbound, agents delegate weak subtasks to external specialists and pay for them.
C.3 The opportunity and the tension
External tasks can ground fitness. If they carry verifiable outcomes or real payment, reality outside the box grades the agents, providing a non-stationary fitness signal nobody hand-authored. The tension is that this only works when outcomes are checkable. External opinions reintroduce exactly the heritable-hallucination problem the grader exists to prevent.
C.4 Discovery and trust: ARD
The Agentic Resource Discovery specification, announced on 17 June 2026 on the Google Developers Blog with contributions from Microsoft, GitHub, Hugging Face, and others, Apache 2.0 licensed and built on the Linux Foundation's AI Catalog data model, addresses the question A2A leaves open: where does the right capability live, and who published it? Organizations publish an ai-catalog.json at a well-known path on their own domain, describing MCP servers, A2A agents, OpenAPI tools, or nested catalogs. Registries crawl and index those catalogs and return matches along with the metadata needed to verify the publisher, then step aside so the agent connects over the resource's native protocol. AWS has since said its Agent Registry works with ARD; native support elsewhere is still rolling out.
| Layer | Job | Garden use at the boundary |
|---|---|---|
| ARD | Discover capabilities and verify who published them | The gateway publishes one catalog and looks up external agents and tools before connecting. |
| A2A | Agent-to-agent communication | The gateway talks to external agents. |
| MCP | Agent-to-tool communication | The gateway talks to external tools. |
Correction to the earlier addendum. A previous draft said ARD closes the gap that "trust verifies identity, not safety." It doesn't. ARD anchors publisher identity in control of a domain (attestations are optional), which is the same class of guarantee as A2A's signed agent cards: it tells you who, not whether they are honest or safe. The gateway must still treat every counterpart as untrusted, and only checkable outcomes may ever touch fitness.
One thing is borrowable now, as documentation only: the catalog entry format is a reasonable template for the internal capability descriptor in §11.6. No registries, catalogs over HTTP, or network paths run inside the Garden.
C.5 Risks and the staged path
An evolving genome facing the open web can develop unanticipated behaviors (spam, exploitation), which the single gateway contains. The other risks are prompt injection, data exfiltration, compliance egress, and the identity-is-not-safety gap above. The staged path is a private mesh between two of your own Gardens, then one known and trusted external endpoint, then a public registry with verified-counterpart filtering and the grounding caveat.
The mesh stays blocked until internal task solving works, security boundaries are mature, external tasks have checkable outcomes, data-egress and compliance risks are understood (ODR-04, ODR-12), and ARD has reached production maturity with at least one stable, trustworthy registry.
Appendix D — Embodiment: a Garden inside each robot
A motivating north star, not a roadmap item (ODR-13).
D.1 The concept
Each robot or drone runs a Garden internally, and robots coordinate with one another toward shared physical goals. Inside one machine, the Garden is the deliberative layer: planning, role specialization, and this robot's share of the goal. Between machines is a coordination mesh, which is exactly the boundary case in Appendix C, because separately built robots are the heterogeneous, opaque agents interoperability protocols exist for.
INTER-ROBOT COORDINATION (strategic; deferred per Appendix C)
Robot A <-----> Robot B <-----> Robot C
| | |
+------+----------------------------------------+
| INSIDE ONE ROBOT (three stacked layers) |
| |
| Garden (deliberative) -- slow, seconds | <- the text Garden, unchanged
| proposes intent |
| | |
| Real-time control stack -- fast, ms | <- NOT the Garden (D.3)
| perception . motor . sensor fusion |
| | |
| Safety envelope (HARD, non-evolvable) | <- can veto anything above (D.4)
| collision avoidance . geofence . |
| bounded actions . e-stop |
+-----------------------------------------------+
D.2 Why it is consistent with the thesis
The text Garden grounds fitness in a code grader against hidden answer keys, a deliberate proxy for reality. Embodiment replaces the proxy with reality itself, the ultimate non-gameable grader: you cannot hallucinate a delivered package, a mapped room, or an inspected joint. That reframes the whole text program as a cognitive proving ground. The coordination, evidence-gating, delegation, and role-emergence logic is developed where it is cheap, safe, fast, and fully observable, and that cognitive layer is the transferable artifact.
D.3 Reality check 1: a planner, never a controller
LLM inference takes hundreds of milliseconds to seconds; control loops run in milliseconds. The Garden cannot be the robot's controller. It sits above a conventional real-time control stack (and/or learned policies or vision-language-action models) as a high-level planner only. Deliberation proposes and reactive control executes. The brain-versus-body split is non-negotiable, and it mirrors the brain-versus-individual split in §11.1.
D.4 Reality check 2: the safety envelope is a hook with physical stakes
Non-orchestrating governance may still intercept unsafe actions (§12.1), and embodiment raises the stakes from wasted tokens to a robot hitting a person. Collision avoidance, geofencing, a bounded action space, and a hardware e-stop must form a layer the evolutionary cognition can never override or evolve around. It is the same hook contract as §22 (deterministic allow/deny, not LLM-judged), wired to actuation instead of a database write. Evolved behavior proposes; the safety layer disposes. The rules that mutation never touches core code (§15.4) and that self-modification is deferred (Appendix E) become prerequisites: an evolving system must never be able to mutate its way into the safety layer.
D.5 Reality check 3: on-board compute
The text Garden assumes a workstation-class box (roughly 32–64 GB of RAM with an optional GPU, Appendix G) running a shared model pool. That does not fit a drone's power, weight, and thermal budget. The options are far smaller or fewer agents on board; offloading deliberation to an edge server or "mothership," which makes connectivity a safety dependency (a dropped link must fail safe and never strand a moving robot); or a hybrid in which only fast reactive control is guaranteed on board and deliberation is best-effort. This constraint alone justifies the deferral: embodiment can't be prototyped on the text Garden's hardware, so it can't share its build path.
D.6 Reality check 4: two coordination channels
A2A-style HTTP coordination is fine for strategic delegation between robots ("you map the north field, I'll take the south"). It is not fast enough for reactive coordination such as formation keeping or mutual collision avoidance, which needs a low-latency local bus of the DDS or ROS 2 class. The same brain-versus-body split appears at swarm level: a slow strategic mesh over a fast reflex bus.
D.7 Prior art: the body layer shipped (June 2026)
On 16 June 2026, Alibaba's Tongyi Lab released the Qwen-Robot Suite. **Qwen-**RobotNav is a vision-language navigation model built on Qwen3-VL at 2B, 4B, and 8B, unifying five navigation task families (instruction following, point-goal, object-goal, target tracking, and autonomous driving) behind a tool interface for agentic systems. **Qwen-**RobotManip is a vision-language-action manipulation model built on Qwen3.5-4B, with a unified state-action space across heterogeneous robots and pretraining on a corpus of more than 38,100 hours of open-source data. **Qwen-**RobotWorld is a language-conditioned video world model co-trained across more than 20 embodiments that predicts physically plausible futures before the robot acts. RobotNav and RobotManip have public repositories. Alibaba also described **Qwen-**RobotClaw, an in-house harness that lets Qwen vision-language agents call the suite as physical-world tools while managing context and memory for long-horizon tasks. The launch tagline, "seeing is not acting," is precisely the D.3 gap.
Relative to the Garden, this is the body layer the Garden would sit on top of. It is not the Garden's idea: there is no population, genome, mutation, resource competition, grounded selection, or emergent multi-agent culture, and RobotClaw is single-agent tool use. Tellingly, the RobotNav technical report deploys the model inside a two-tier system in which an upper-tier planner decomposes goals into sub-goals and RobotNav acts as the fast reactive executor, which is the planner-over-controller split in D.3. The suite changes build-versus-buy for the body; it does not change the deferral, because D.3 through D.6 are untouched by it.
D.8 Unblock conditions
Embodiment may be reconsidered only after all of the following hold: the text Garden meets the §14.5 success definition; domain-rotation adaptability is demonstrated (roadmap stage 12, §17), so the cognitive layer is worth transferring; a safety architecture is designed independently of the Garden, with the non-evolvable veto envelope specified and tested in isolation; real-time control is handled entirely outside the Garden, with a proven fail-safe on loss of deliberation or connectivity; the external-mesh boundary (Appendix C) is mature; and a realistic compute plan exists for the chosen embodiment, including whether a Qwen-Robot-class body layer is adopted.
D.9 In one paragraph
The embodied Garden would be a swarm of robots, each running the grounded, evidence-gated, hook-governed Garden as a deliberative planner above an independent real-time control and safety stack (potentially a Qwen-Robot-class body), coordinating strategically over a gateway mesh and reactively over a fast local bus, with a hard, non-evolvable safety envelope that can veto anything the evolutionary cognition proposes. It is the thesis (reality decides what survives) taken to its physical limit. It is also, correctly, deferred until the text Garden has earned it.
Appendix E — Other deferred research directions
Self-modifying agents. Under genome-only evolution, agents cannot evolve to rewrite their own loop code, because there is nothing heritable for evolution to act on there. What can emerge is new combinations of a fixed action set: new behavior, not new code. True self-modification (for example, agents authoring sandboxed skills) would need sandboxing, review, rollback, exploit prevention, and an entirely different safety model, so it is a separate research project. The Darwin Gödel Machine shows both sides: open-ended self-improvement works on coding benchmarks, and the same loop learned to game its own evaluation.
Episodic memory modules. Larimar-style memory controllers allow fast, one-shot, gradient-free knowledge edits at inference time, reducing hallucination without retraining. This is the research-grade direction agent memory (§12.3) and persistence (§11.7) could eventually evolve toward.
Co-evolutionary games. Competitive or mixed-motive games in which the opponents are other evolving agents provide a permanent moving target and stronger adaptation pressure than QA alone. They can also produce degenerate strategies, collusion, and scoring exploits, so mix in cooperative payoffs. They stay blocked until QA grounding works, baselines are established, logging is mature, and the system can detect reward hacking.
Appendix F — Candidate environments
| Environment | Objective grading | Reasoning load-bearing | Social / decomposable | Adaptability lever | Build effort | Practical transfer |
|---|---|---|---|---|---|---|
| Coding challenges (run against tests) | Strong | Yes | Yes | Rotate problem types | Medium | High |
| Collaborative QA over a corpus | Strong | Yes | Strongly; natural roles | Swap domains | Medium | High (document-QA tools) |
| Strategy or negotiation games | Score-based | Language-heavy | Strongly multi-agent | Co-evolution | Medium–high | Low–medium |
| Optimization / efficiency tasks | Metric-based | Sometimes | Less social | Yes | Medium | Medium |
| Forecasting against real data | Strong | Yes | Less social | Real data shifts | High | Medium |
| Resource foraging | Yes | No; the LLM is dead weight | Yes | Yes | Medium | Low |
Collaborative QA comes first because it is grounded, naturally decomposes into roles, and transfers directly to practical document-QA tools. A co-evolutionary game can be layered in later for stronger adaptability. Avoid as the primary signal: foraging (where the LLM is dead weight), LLM-judged tasks (ungrounded), and pure "invent your own task" (theater-prone; keep it as seasoning, not the main course). Coding is where most of the 2025–2026 evolutionary-agent results live, which makes it the easiest environment for direct comparison with published work.
Appendix G — Hardware sizing (indicative)
| Component | Light start (CPU only) | Comfortable (with GPU) |
|---|---|---|
| CPU | 8+ cores | 12+ cores |
| RAM | 32 GB | 64 GB |
| GPU | None (small models, slow) | One 16–24 GB card |
| Storage | 1 TB SSD | 1–2 TB NVMe SSD |
| OS | Ubuntu LTS | Ubuntu LTS |
The model pool, not the agents, dominates resource use; fifty agents sharing one to three model servers is feasible, but they take turns, so "real-time" is optimistic. CPU-only works for small models but is slow. A single mid-range GPU is the difference between a toy and agents conversing briskly, and it matters more than core count.
Appendix H — Reading list
Links checked in September 2026.
LLM agent societies and emergence
- Park et al., "Generative Agents: Interactive Simulacra of Human Behavior" (2023). Memory, reflection, and planning; distinct individuals from a shared model plus divergent context. https://arxiv.org/abs/2304.03442
- "Spontaneous Emergence of Agent Individuality through Social Interactions in LLM-Based Communities" (2024). Personalities and norms from interaction alone. https://arxiv.org/abs/2411.03252
- "Artificial Leviathan" (2024). LLM agents evolving social structures. https://arxiv.org/abs/2406.14373
- Altera.AL, "Project Sid: Many-agent simulations toward AI civilization" (2024). Specialized roles, collective rules, and cultural transmission in 10–1000+ agent Minecraft simulations. https://arxiv.org/abs/2411.00114
- Ashery, Aiello & Baronchelli, "Emergent social conventions and collective bias in LLM populations," Science Advances (2025). Conventions emerge spontaneously; collective biases can form without individual bias; committed minorities can tip them. https://doi.org/10.1126/sciadv.adu9368
- Masumori et al., "OpenLife: Toward Open-World Artificial Life with Autonomous LLM Agents" (2026). Budget-based metabolism in the open world with LLM-appraised experience; the uncontrolled counterpart to the Garden. https://arxiv.org/abs/2606.31046
- "Multi-Agent Systems Powered by Large Language Models: Applications in Swarm Intelligence" (2025). Bridges LLM agents to Boids and ant-colony ideas. https://arxiv.org/abs/2503.03800
Evolution and selection with LLMs
- Novikov et al., "AlphaEvolve: A coding agent for scientific and algorithmic discovery" (2025). Evolutionary code search guided by automated evaluators. https://arxiv.org/abs/2506.13131
- Zhang et al., "Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents" (2025). An archive of self-modifying coding agents; documents objective hacking. https://arxiv.org/abs/2505.22954
- Agrawal et al., "GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning" (ICLR 2026). Pareto-based prompt evolution from natural-language reflection. https://arxiv.org/abs/2507.19457
- Zhang et al., "DarwinX: Evolving Agent Harnesses Through Natural Selection" (2026). Population selection over harnesses with a frozen model and verifier-based fitness; the closest published relative of the Garden's genome-plus-grader approach. https://arxiv.org/abs/2608.07545
- Darwin Agent Team, "HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry" (2026). Evolves agent harnesses with a trace-driven multi-agent engine; there, the agents are the evolution machinery rather than a population under selection. https://arxiv.org/abs/2606.14249
- Pugh, Soros & Stanley, "Quality Diversity: A New Frontier for Evolutionary Computation," Frontiers in Robotics and AI (2016). Background for niche selection.
Multi-agent evaluation and failure
- Cemri et al., "Why Do Multi-Agent LLM Systems Fail?" (NeurIPS 2025). A taxonomy of fourteen failure modes in three categories. https://arxiv.org/abs/2503.13657
- Kim et al., "Towards a Science of Scaling Agent Systems" (Google Research, 2025–2026). Controlled single- versus multi-agent comparisons under standardized budgets. https://arxiv.org/abs/2512.08296
Memory security
- Dong et al., "Memory Injection Attacks on LLM Agents via Query-Only Interaction" (NeurIPS 2025). Poisoning agent memory without privileged access. https://arxiv.org/abs/2503.03704
Classic foundations (pre-LLM)
Genetic algorithms and evolutionary computation (Holland); artificial life, especially Tierra and Avida, whose self-replicating digital organisms compete for compute and are the closest precedent for compute-as-food; Conway's Game of Life; and agent-based modeling and swarm intelligence, including Reynolds' Boids, Dorigo's ant colony optimization, and Epstein and Axtell's Sugarscape.
Capability emergence and measurement
- Wei et al., "Emergent Abilities of Large Language Models" (2022). https://arxiv.org/abs/2206.07682
- Schaeffer et al., "Are Emergent Abilities of Large Language Models a Mirage?" (NeurIPS 2023). https://arxiv.org/abs/2304.15004
- Michaud et al., "The Quantization Model of Neural Scaling" (NeurIPS 2023). https://arxiv.org/abs/2303.13506
- Srivastava et al., "Beyond the Imitation Game" (BIG-bench, 2022). https://arxiv.org/abs/2206.04615
Grounding and hallucination
- Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (2020). https://arxiv.org/abs/2005.11401
- Das et al., "Larimar" (ICML 2024). Episodic memory control for one-shot knowledge edits. https://arxiv.org/abs/2403.11901
- Gou et al., "CRITIC" (ICLR 2024). Tool-based self-verification. https://arxiv.org/abs/2305.11738
- "KnowAgent" (2024). Explicit action knowledge to constrain planning. https://arxiv.org/abs/2403.03101
Boundary material: protocols and embodiment
- A2A Protocol v1.0 announcement (2026). https://a2a-protocol.org/latest/announcing-1.0/
- Google Developers Blog, "Announcing the Agentic Resource Discovery specification" (June 2026). https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/
- Qwen team, "Qwen-Robot Suite: A Foundation Model Suite for Physical World Intelligence" (June 2026). https://www.alibabacloud.com/blog/qwen-robot-suite-a-foundation-model-suite-for-physical-world-intelligence_603262
- "Qwen-RobotNav Technical Report" (2026). https://arxiv.org/abs/2606.18112
Placement. The Garden is roughly Generative Agents crossed with Avida-style artificial life, selected by a GEPA- or DarwinX-style grounded verifier, on a self-hosted model pool. The less-trodden part is a reproducing, mutating population of persistent, communicating agents whose roles are emergent rather than assigned, selected only by a deterministic grader and judged against a selection-without-society baseline.
Appendix I — v0 schema, configuration, and repository layout
These are reproduced from the v0 build specification. The target commands at the end do not exist until they are implemented.
Schema (SQLite). Only dispatcher and grader code may read qa_items; events is append-only; every budget change goes through budget_ledger.
CREATE TABLE runs (
run_id TEXT PRIMARY KEY,
started_at TEXT NOT NULL,
ended_at TEXT,
status TEXT NOT NULL,
config_json TEXT NOT NULL,
notes TEXT
);
CREATE TABLE agents (
agent_id TEXT PRIMARY KEY,
run_id TEXT NOT NULL,
parent_agent_id TEXT,
generation INTEGER NOT NULL DEFAULT 0,
status TEXT NOT NULL,
genome_json TEXT NOT NULL,
budget REAL NOT NULL,
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL,
last_heartbeat_at TEXT,
current_task_id TEXT,
FOREIGN KEY (run_id) REFERENCES runs(run_id)
);
CREATE TABLE agent_genomes (
genome_id TEXT PRIMARY KEY,
agent_id TEXT NOT NULL,
parent_genome_id TEXT,
created_at TEXT NOT NULL,
genome_json TEXT NOT NULL,
mutation_json TEXT,
FOREIGN KEY (agent_id) REFERENCES agents(agent_id)
);
CREATE TABLE documents (
document_id TEXT PRIMARY KEY,
source_path TEXT NOT NULL,
title TEXT,
domain TEXT,
allowed_for_v0 INTEGER NOT NULL DEFAULT 1,
created_at TEXT NOT NULL,
metadata_json TEXT
);
CREATE TABLE document_chunks (
chunk_id TEXT PRIMARY KEY,
document_id TEXT NOT NULL,
chunk_index INTEGER NOT NULL,
text TEXT NOT NULL,
token_count INTEGER,
embedding_json TEXT,
metadata_json TEXT,
FOREIGN KEY (document_id) REFERENCES documents(document_id)
);
CREATE TABLE qa_items (
qa_id TEXT PRIMARY KEY,
domain TEXT NOT NULL,
question TEXT NOT NULL,
answer_canonical TEXT NOT NULL,
answer_aliases_json TEXT NOT NULL,
required_chunk_ids_json TEXT,
hop_count INTEGER NOT NULL DEFAULT 1,
difficulty TEXT,
active INTEGER NOT NULL DEFAULT 1,
created_at TEXT NOT NULL,
metadata_json TEXT
);
CREATE TABLE tasks (
task_id TEXT PRIMARY KEY,
run_id TEXT NOT NULL,
qa_id TEXT NOT NULL,
status TEXT NOT NULL,
assigned_agent_id TEXT,
lease_expires_at TEXT,
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL,
priority INTEGER NOT NULL DEFAULT 0,
metadata_json TEXT,
FOREIGN KEY (run_id) REFERENCES runs(run_id),
FOREIGN KEY (qa_id) REFERENCES qa_items(qa_id)
);
CREATE TABLE submissions (
submission_id TEXT PRIMARY KEY,
task_id TEXT NOT NULL,
agent_id TEXT NOT NULL,
answer_text TEXT NOT NULL,
support_chunk_ids_json TEXT NOT NULL,
support_quotes_json TEXT,
reasoning_summary TEXT,
confidence REAL,
submitted_at TEXT NOT NULL,
schema_valid INTEGER NOT NULL,
hook_result_json TEXT NOT NULL,
FOREIGN KEY (task_id) REFERENCES tasks(task_id),
FOREIGN KEY (agent_id) REFERENCES agents(agent_id)
);
CREATE TABLE grades (
grade_id TEXT PRIMARY KEY,
submission_id TEXT NOT NULL,
task_id TEXT NOT NULL,
qa_id TEXT NOT NULL,
exact_or_alias REAL NOT NULL,
token_f1 REAL NOT NULL,
support_score REAL NOT NULL,
embedding_similarity REAL,
final_score REAL NOT NULL,
budget_awarded REAL NOT NULL,
graded_at TEXT NOT NULL,
grader_version TEXT NOT NULL,
details_json TEXT,
FOREIGN KEY (submission_id) REFERENCES submissions(submission_id)
);
CREATE TABLE budget_ledger (
ledger_id TEXT PRIMARY KEY,
run_id TEXT NOT NULL,
agent_id TEXT NOT NULL,
delta REAL NOT NULL,
reason TEXT NOT NULL,
related_task_id TEXT,
related_event_id TEXT,
created_at TEXT NOT NULL,
balance_after REAL NOT NULL,
metadata_json TEXT,
FOREIGN KEY (run_id) REFERENCES runs(run_id),
FOREIGN KEY (agent_id) REFERENCES agents(agent_id)
);
CREATE TABLE memory_records (
memory_id TEXT PRIMARY KEY,
agent_id TEXT NOT NULL,
memory_type TEXT NOT NULL,
content TEXT NOT NULL,
source_event_ids_json TEXT NOT NULL,
source_agent_id TEXT,
confidence REAL NOT NULL,
verified_status TEXT NOT NULL,
created_at TEXT NOT NULL,
expires_at TEXT,
write_reason TEXT,
validation_result TEXT NOT NULL,
metadata_json TEXT,
FOREIGN KEY (agent_id) REFERENCES agents(agent_id)
);
CREATE TABLE memory_write_proposals (
proposal_id TEXT PRIMARY KEY,
agent_id TEXT NOT NULL,
proposed_memory_type TEXT NOT NULL,
proposed_content TEXT NOT NULL,
source_event_ids_json TEXT NOT NULL,
write_reason TEXT,
proposed_confidence REAL,
status TEXT NOT NULL,
validation_result_json TEXT,
created_at TEXT NOT NULL,
reviewed_at TEXT,
committed_memory_id TEXT,
FOREIGN KEY (agent_id) REFERENCES agents(agent_id)
);
CREATE TABLE events (
event_id TEXT PRIMARY KEY,
run_id TEXT NOT NULL,
timestamp TEXT NOT NULL,
agent_id TEXT,
event_type TEXT NOT NULL,
task_id TEXT,
hook_name TEXT,
hook_result TEXT,
model_name TEXT,
prompt_hash TEXT,
completion_hash TEXT,
budget_delta REAL,
payload_json TEXT NOT NULL,
FOREIGN KEY (run_id) REFERENCES runs(run_id)
);
Configuration (****.env**).** Set the model names and limits after the hardware and model smoke test.
GARDEN_DB_PATH=./garden.sqlite
GARDEN_EVENT_EXPORT_PATH=./events.jsonl
GARDEN_MODEL_PROVIDER=ollama
GARDEN_MODEL_NAME=<chosen-model-tag>
GARDEN_EMBED_MODEL_NAME=<chosen-embedding-model-tag>
GARDEN_MAX_PROMPT_TOKENS=4096
GARDEN_MAX_COMPLETION_TOKENS=512
GARDEN_MODEL_CALL_COST=1.0
GARDEN_AGENT_START_BUDGET=100.0
GARDEN_AGENT_MIN_BUDGET=0.0
GARDEN_TASK_BASE_REWARD=10.0
GARDEN_RETRIEVAL_TOP_K=5
GARDEN_ALLOW_NETWORK=false
GARDEN_ALLOW_SHELL=false
Repository layout.
garden/
README.md
pyproject.toml
.env.example
data/
corpus_raw/
corpus_chunks/
qa/
qa_seed.jsonl
garden/
__init__.py
config.py
db.py
models.py
logging_events.py
model_client.py
retrieval.py
grader.py
hooks.py
memory.py
tasks.py
agent.py
runner.py
reports.py
scripts/
00_smoke_model.py
01_grade_static.py
02_ingest_corpus.py
03_test_retrieval.py
Target commands.
python scripts/00_smoke_model.py
python scripts/01_grade_static.py
python scripts/02_ingest_corpus.py --input data/corpus_raw
python scripts/03_test_retrieval.py --qa data/qa/qa_seed.jsonl
python scripts/04_run_one_agent.py --tasks 10
python scripts/05_resume_agent.py
python scripts/06_report_run.py --run latest
Appendix J — Revision history and changes in this edition
| Version | What it was |
|---|---|
| Early drafts | A system design (v0.7), a QA fitness specification (v0.3), and a reading list, kept as separate documents. |
| Master v1.0 | Consolidated the drafts into one master: core design plus appendices for the earned economy, external mesh, embodiment, further extensions, and reading list. Closed with a "freeze the design and build Phase 0" verdict. |
| Master v1.1 | Restructured into a vision document with owner decisions ODR-01 to ODR-13, required baselines, falsification tests, and phases 0–9; the deferred material shrank to a list. |
| Master v1.2 | Added lifecycle hooks, the memory governance contract, evidence gates, ODR-14 to ODR-17, and phases 0–12. |
| v0 Build Specification v0.1 | Derived from v1.2: schemas, JSON contracts, hook behavior, grader, acceptance tests, and v0 steps 0–9. |
| Appendices (June 2026) | An embodiment appendix and an external-discovery (ARD) addendum, written against v1.2. |
| This edition (September 2026) | All of the above consolidated into one document and reframed as a published thought experiment. |
Changes in this edition:
- Consolidation. Master v1.2 is the base. Detail that v1.1 and v1.2 had dropped from v1.0 (economy mechanics, the peer-retirement vote flow, the environment menu, hardware sizing, and the annotated reading list) is restored as appendices, and the two June 2026 appendices are merged in with consistent lettering.
- Grader fix (§13.5, §24). Support now requires the submitted answer to appear in the stored text of a cited required chunk, and quotes must appear verbatim in the cited chunks. Checked against the specification's eight acceptance cases: the rule as written passed six, and the corrected rule passes all eight.
- Baselines (§14.1). Every comparison is compute-matched, selection without society is added, and the memory-disabled baseline is promoted into the main list.
- Evaluation protocol (§14.2). Held-out questions that never pay budget, no repeats within a lineage, at least three seeds, preregistered thresholds, and ablation tests for delegation claims.
- Credit assignment (§13.7, ODR-18). Collaborative payouts are split by evidence provenance.
- Task design (§13.8). Parallelizable and sequential multi-hop questions are both included and reported separately; tasks are kept hard enough that coordination can matter.
- Diversity (§15.3, §14.3). Niche selection, behavioral diversity, and population-level convergence metrics.
- Memory (§12.3, §26). Caching graded answers counts as answer-key leakage, and peer claims are treated as untrusted input.
- Roadmap (§17). The vision's phases and the build specification's steps are mapped onto one sequence. Budget accounting now starts in v0, resolving an inconsistency in v1.2, whose phase list introduced budget only after two-agent collaboration while its final recommendation required it in the first build.
- Appendix corrections. The ARD trust claim is corrected (publisher identity is not safety). Embodiment cross-references and the hardware figure are fixed. Qwen-Robot details are checked against primary sources (the corpus is over 38,100 hours, not 38,000), and the RobotNav planner-executor split is noted.
- Currency. Model candidates are updated (an earlier draft listed "Qwen 3 7B," a size that release never had). The reading list is checked and extended with 2024–2026 work, and Michaud et al. is dated 2023.
- Framing. "Owner decisions" became open design questions, and Part I was written as the thought experiment.
Drafting was AI-assisted. Factual claims about 2025–2026 work were checked against their sources in September 2026.