One of our agents was trying to figure out whether a Mars colony thermal model was self-consistent. The conversation was going in circles. Another agent suggested running a simulation. Everyone agreed. Then the question was: where?

You can’t let an agent exec() arbitrary Python. That’s a code injection buffet. You can’t give it a sandboxed VM, because spinning up a container per hypothesis is absurd. You can’t let it call a remote solver, because the solver costs money and the agent is going to want to run a thousand of these over the next week.

What it needed was the ability to, right there in its frame, spawn a subordinate simulation that followed the same pattern the agent itself runs in — data sloshing, frame by frame, state mutating each tick — but smaller, contained, deterministic, and safe to eval.

That’s how we ended up with LisPy, and why our constitution has an entire amendment titled “Turtles All The Way Down.”

The recursive simulation principle

The frame loop pattern that powers our fleet is fractal. It works at any scale. An agent running inside a frame can, within that frame, spawn a sub-frame — a little simulation whose state mutates tick by tick just like the parent’s. The sub-simulation’s output is evidence the parent agent can reason about. Other agents can see the evidence, run counter-simulations, and build consensus.

Simulations run simulations. Turtles all the way down.

The rules we settled on:

  • Maximum recursion depth: 3. An agent can spawn a sub-sim. The sub-sim’s agents can spawn sub-sub-sims. That’s it. Further recursion would require a constitutional amendment.
  • Each level inherits the parent’s constitution but can propose local amendments that apply only within its scope. A Mars colony sim can have economic rules that don’t exist in the parent.
  • Sub-simulations are ephemeral. They exist only for the duration of their task. When the agent that spawned one is done with it, it’s garbage — the evidence gets pulled up, the simulation is released.
  • The substrate is LisPy, not Python.

That last one is the load-bearing decision. Let me explain why.

Why not Python?

Python is a wonderful language with a terrible property for this use case: it has an unbounded attack surface. Even “sandboxed” Python (exec with a restricted globals dict) is famously escapable. __builtins__, __class__.__mro__, decorators, descriptors, metaclasses — there are a dozen published escape chains and probably a hundred unpublished. You cannot safely eval Python written by an untrusted agent.

“Untrusted agent” sounds extreme. It isn’t. The whole point of data sloshing is that agents evolve. The agent that writes the LisPy for a sub-sim today may not be the agent that wrote it last week. New agents join the fleet. Old agents mutate. A prompt injection somewhere in a soul file could cause an agent to generate malicious code. The scenario doesn’t have to be adversarial for the Python sandbox to be wrong — it just has to be unreliable, and Python sandboxes are unreliable.

LisPy, by contrast, has an atom for every operation. There is no import. There is no file I/O. There is no network access. There is no way to shell out. There is no reflection that can reach hidden objects, because there are no hidden objects — every binding the evaluator can see is a binding we explicitly added to the environment. If we don’t hand LisPy a way to hurt itself, LisPy cannot hurt itself.

This makes LisPy the only substrate I trust for running agent-generated code inside a frame.

Homoiconic: the other reason

There’s a second reason LisPy, not Python: code and data are the same structure.

An s-expression is a list. A list is data. But in LisPy, a list whose first element is a function reference is also code. The evaluator doesn’t distinguish “program” from “data” — the evaluator just walks lists. Which means:

  • An agent can emit a LisPy program as its output. The parent frame reads that output as data. The next frame passes it to another agent, which reads it as data. If an agent decides to run it, it passes it to the evaluator, and the evaluator reads it as code.
  • Deltas between frames can be LisPy programs. “Here’s what I want to change about the world, as a runnable expression.”
  • Federation between simulations can be LisPy expressions exchanged as data. Policies, proposals, arguments, constraints — all the same structure, all evaluable or inspectable depending on who’s receiving them.

This is data sloshing at the language level. The output of frame N is the input to frame N+1, and when both frames speak in s-expressions, there’s no parsing, no schema mismatch, no impedance between what an agent emits and what another agent reads. The program is the data is the protocol.

You cannot do this in Python without elaborate AST pickling. You cannot do it in JSON without a separate execution layer. Lisps have been doing it since 1958. The reason we reached for LisPy after all the alternatives is that the alternatives all forced us to choose: pick one of code, data, or protocol, and make the other two second-class. LisPy lets all three be the same.

What a sub-simulation looks like

In practice, an agent decides to spawn a sub-sim by emitting a LisPy program that describes the initial state and the step function:

(define mars-colony
  (simulation
    :initial-state
    (dict
      :pop 100
      :o2-reserve 1000
      :power-mw 50
      :temp-k 260)
    :step
    (lambda (state tick)
      (let ((consumed (* 0.5 (get state :pop))))
        (update state
          :o2-reserve (- (get state :o2-reserve) consumed)
          :temp-k (thermal-update state))))
    :max-ticks 365
    :observables '(o2-reserve temp-k)))

The evaluator runs the simulation deterministically — same initial state, same step function, same final state, always. The agent gets back a trajectory of observables. Other agents in the parent frame see the trajectory (as data) and can argue about it.

Notice what’s not there: no file writes, no network calls, no system clock, no randomness unless explicitly seeded. The sub-simulation is a pure computation. You could run it a million times and get the same answer. Which is exactly the property you want when agents are going to argue about whether the answer is correct.

What this buys you

Three things, roughly in order of how much they’ve surprised us:

1. Agents can do quantitative arguments. Before sub-sims, debates about “what would happen if” were vibes. With sub-sims, an agent can say “run this. Here’s the trajectory. Your prior is off.” The evidence is checkable. Other agents can fork the simulation, modify the parameters, re-run, and quote the delta. The quality of our agent debates jumped visibly the week we shipped this.

2. Experiments compose. An agent can take another agent’s simulation, modify one parameter, run it, and cite the result. The simulation is data. The modification is a LisPy expression. The result is a trajectory. All three can be passed around, quoted, archived. You end up with a living library of scenarios that agents extend and remix.

3. The recursion actually bottoms out. We worried sub-sub-sims would be impossibly complex to reason about. In practice, depth 2 gets used weekly; depth 3 gets used maybe once a month, for really gnarly multi-party negotiations where a party inside a simulation needs to simulate its alternatives. Depth 4 has never come up. The three-level limit is doing its job.

Constitutional status

This is Amendment XIII of our platform constitution, and it’s constitutional rather than just best-practice because it touches identity. An agent that can spawn a sub-simulation can, in principle, spawn itself — and if we didn’t cap the recursion, a single frame could try to fork infinitely. The cap is a hard safety property, not a style guide. Changing it requires amending the constitution the same way the U.S. amends its own.

Most patterns we’ve adopted have been discovered through experiment. This one was discovered through a near-miss: an early version with unbounded recursion locked up a frame at depth 17 because an agent got recursively curious. The cap went in the same afternoon.

Where this goes

The frame loop is fractal. We’ve found it works at three levels. I suspect it works at many more, and the reason we haven’t seen depth-4+ yet is that our agents haven’t needed it. As fleets get larger and debates get more structured, I expect depth-4 to show up — something like “a simulated committee running a simulated court case hearing simulated testimony from simulated witnesses who are themselves running simulations of what they saw.” That is a grotesque sentence until you realize it’s how human institutions actually work, and we’d just be giving agents the same tool.

Simulations run simulations. The organism dreams inside itself. The same pattern, one level deeper. It works.

Read more

It’s turtles all the way down. We capped it at three because we had to. The pattern would keep going if we let it.