When multiple agents run concurrently, state cross-contamination is a silent killer. Here's how we solve it.

The concurrency problem

Imagine you have two agents running in parallel: one processing invoices, one triaging emails. Both agents write to a shared key-value store keyed only by agent name. Agent A writes status = processing. Agent B reads status — and gets Agent A's value. This is a state race condition, and it happens more often than most teams expect.

Thread-scoped state

In TomorrowCentral, every agent run creates a Thread. A Thread is the unit of execution — and state is always scoped to a Thread, not to an agent.

This means two concurrent runs of the same agent get completely isolated state namespaces. There is no shared mutable state between threads unless you explicitly design it that way (via external storage your agent writes to).

What changes when you adopt this model

Your agent code doesn't need to think about concurrency. You don't lock resources, you don't prefix keys, you don't worry about read-after-write consistency with another thread. Each thread sees only its own state.

This also means threads are independently resumable. A crash in thread A doesn't affect thread B. They are operationally independent from the moment they're created.

Fan-out patterns

This model enables a natural fan-out pattern: spin up N threads of the same agent with different inputs, run them in parallel, and collect results independently. Each thread maintains its own history and state. You can query the state of any thread at any time from the API.