Agents use the real interface. Counterworld owns the state behind it.

The agent boundary stays production-shaped

An existing agent connects through the interface it already uses: a product API, its SDK configured with another base URL, or MCP tools matching the production surface.

Every interface reaches the same state

A change made through an API must appear through the UI, SDK, tools, event history and subsequent user decisions. Parallel interface-specific fixtures would break world coherence.

Persistent state

Mutations survive across requests, actors and time advancement.

Relational state

Entities reference the same customers, orders, invoices and tickets.

Observable effects

Side effects become records, events, schedules or downstream mutations.

Isolated instances

Each world has independent state, credentials, clock and event queue.

Mutations enforce software behavior

The runtime does more than return schema-valid responses. It checks permissions, preconditions, invariants and side effects before committing a change.

Agent actions and world control are separate

The agent can operate the software. The test harness controls the simulation. Keeping these surfaces separate prevents an agent from resetting mistakes, inspecting hidden state or moving time.

Control a running world with the SDK

const world = await counterworld.worlds.get("world_01J...");

await world.pause();

const checkpoint = await world.checkpoints.create({
  name: "before-policy-change",
});

await world.resume();
await world.clock.advance({ days: 14, mode: "until-idle" });

const branch = await world.forks.create({
  from: checkpoint.id,
  name: "new-policy",
});

Only the runner receives this control client. The agent receives credentials created by world.interfaces.connect().

A world has an explicit lifecycle

Definitions create instances. Instances can run, pause and create immutable checkpoints. Checkpoints can restore the same instance or begin independent forks.