# The Sandbox Is the Fixture, Not the Record

> On a test floor you swap fixtures all day because the record lives in the database. Ramp's Laminar agent platform makes the same split: throw the sandbox away, keep the session.

- Canonical URL: https://webofmike.com/sandbox-is-the-fixture-not-the-record/
- Author: Mike Moore (https://webofmike.com/about/)
- Published: 2026-10-30
- Last modified: 2026-10-21
- Tags: AI Agents, Platform Engineering, Thoughts
- Cite as: Mike Moore, "The Sandbox Is the Fixture, Not the Record", Web of Mike (webofmike.com), 2026-10-30. https://webofmike.com/sandbox-is-the-fixture-not-the-record/


On a test floor, nobody gets attached to a fixture.

Fixtures wear out. Pogo pins bend. Somebody drops one. You pull it, bolt in the spare, and the line keeps moving. Nobody panics, because the fixture never held anything that mattered. The test record lives in the database. Serial number, station, limits, measurements, pass or fail. Swap every fixture on the floor and the history is still there.

The stations that got into trouble were the ones where somebody saved results to the local disk "just for now."

Agent platforms are learning the same lesson.

## What Ramp built

Ramp published [a long post on Laminar](https://builders.ramp.com/post/building-laminar), its in-house agent harness. Around May 2026 the team decided to stop spreading products across a dozen platforms and build one common harness. The v1 was built in six weeks, and five months later, per Ramp, every agentic product at the company runs on it.

The list of what the harness has to do is long: conversation history storage, compaction, tool calling, message queuing, durable execution that survives deploys, sandboxes, subagents, human-in-the-loop, observability. But the choice I care about is the first one on their list of early decisions. Ramp calls it ["sandbox-as-a-tool"](https://builders.ramp.com/post/building-laminar):

> A Laminar agent session lifetime is completely decoupled from whether we have sandbox infra provisioned or running at any given moment.

They store the agent definition, conversation history and turn-level state in a database. When the agent needs a computer, it issues tool calls that run commands in a sandbox. The sandbox is something the agent uses. It is not where the agent lives.

That is the fixture and the record, separated on purpose.

## Boring storage, disposable workers

The storage is deliberately unexciting. Ramp chose [Postgres, Temporal and S3](https://builders.ramp.com/post/building-laminar) for persistence and workflow execution, and says plainly why: the team knows how to run that stack in production, scale it, and fix it when it breaks.

The compute is the opposite. From day one the whole stack runs on a fleet of generic disposable workers, cattle not pets, rather than a pool of carefully tended sandboxes or servers. Their request flow saves sessions and messages in PostgreSQL, signals Temporal, and has workers pick up tasks from queues and write state back.

I have seen this pattern before. The fixtures are cheap and interchangeable. The database is the thing you back up, monitor and never touch casually.

In my sketch of this setup, the sandboxes are named Tek 465, Tek 2465, Fluke PM3394 and HP 1740A.

## Why this split matters for agents

An agent session that lives inside its sandbox inherits every failure mode of that sandbox. The node gets recycled, the session is gone. A deploy rolls the pool, the session is gone. Somebody's laptop goes to sleep, and Ramp has a good line about engineers walking around the office with laptops cracked open so their agents keep running. That's the "local disk just for now" station all over again.

Pull the record out, and three things get easier:

1. **Recovery.** If the sandbox dies, you start a new one and the session picks up from the stored turn state. A dead fixture is a part swap, not a lost lot.
2. **Waiting.** Ramp makes non-blocking async the default: human approvals, new messages arriving mid-turn, subagents handing work back. A session that waits hours for a person should not be holding a sandbox the whole time. I wrote about this pressure in [agent runtimes need a scheduler](/agent-runtimes-need-a-scheduler/).
3. **Evidence.** When something goes wrong, the trace is in durable storage, not in a container that got reaped. That is the whole argument of [stopping an agent without losing evidence](/stopping-an-agent-without-losing-evidence/). Ramp clearly cares here too: their CTO [prints traces on paper](https://builders.ramp.com/post/building-laminar) to make waste visible.

## The test I'd run

If you're building or buying an agent runtime, run the fixture test. Kill the sandbox in the middle of a session and watch what happens.

- Does the session survive?
- Does it resume from the last completed turn, or start over?
- Is the history and every tool call still readable afterward?
- Does a new sandbox come up without anyone tending it?

If the answer to the first question is no, the record lives in the fixture. Fix that before you scale anything.

This is the same shape I keep pointing at in [what a cloud native agent harness is](/what-is-a-cloud-native-agent-harness/): state that matters goes somewhere durable and boring, and the things doing the work are replaceable.

Swap the fixture. Keep the record.