AI does not only accelerate work inside a system. It exposes every part of the system that still assumes one durable worker at a time.

This began for me with an ordinary integration constraint. An external system needed to know where to return a request. That address had to be established in advance. One environment could use it reliably; several temporary environments could not simply invent new addresses as they appeared.

More containers did not create more usable environments. The constraint was not compute. It was identity.

Constraints like this often exist for good reasons. Current OAuth security guidance, for example, recommends exact matching against pre-registered redirect addresses because permissive matching can leak credentials or create an open redirect (RFC 9700). The wider point is not that every gated system behaves like OAuth. It is that an ephemeral worker cannot assume every dependency will become ephemeral with it.

Systems were provisioned for durable workers

When the worker was a developer, employee or contractor, the cost of establishing an identity and environment could be absorbed across a relatively long relationship. Accounts, network access, test data and integration settings took time to arrange, but the person might use them for months or years.

Agents change that economic assumption. A worker may exist for minutes, hours, days or weeks. An agentic workflow can begin several independent streams of work before a human team would previously have finished provisioning one new environment.

The underlying problem predates AI. Continuous-integration jobs, test farms, preview environments and temporary teams all encounter versions of it. Agents exacerbate it because they increase the number, turnover and variability of workers trying to enter systems designed around durable identities.

In an earlier note, I argued thatspeed moves pressure to whatever comes next. This is one infrastructure consequence. Agentic workflows multiply workstreams, but the systems around them do not automatically multiply their identities, environments or safe capacity.

Parallelism ends at the least elastic dependency. Making that boundary explicit is the beginning of improving it.

The first step was a stable slot

My first response has been a small, reusable pool of deployment slots. A worker does not create a complete identity from nothing. It acquires an exclusive lease on one that has already been established.

The slot supplies a stable external identity and a manifest describing the environment available to the worker. Mutable runtime state remains isolated to that slot: application data, messages, caches, files, sessions and credentials where the dependency requires them.

A slot is therefore not merely a reserved address or a running container. It is a boundary around the capabilities and state required for one stream of work to proceed without silently colliding with another.

The word lease matters. Gray and Cheriton introduced leases as time-bounded rights in a distributed cache (Gray and Cheriton, 1989). Deployment environments are a different problem, but the useful principle carries across: ownership needs an expiry and a recovery path, not merely a flag saying that something is in use.

The decoupling journey

  1. 01 · PressureDurable identity, serial workTemporary workers queue behind one gated environment
    Worker AWorker BFixed dependency
  2. 02 · First stepStable slots, bounded parallelismExclusive leases separate identity and mutable state
    Slot ASlot BSlot N
  3. 03 · Next questionIdentity separated from environmentOne stable boundary routes safely to more elastic slots
    Identity layerEnvironment AEnvironment N
Slots are the first decoupling: workers no longer need permanent environments, but slot capacity is still tied to pre-established identity. Extracting identity is a future hypothesis, not a completed architecture.

Identity is only one face of isolation

The callback address made the constraint visible, but the same shape appears elsewhere. A network may require a fixed peer or allow-listed identity. A licensed system may expose only a small number of test seats. A legacy application may need a slowly provisioned account or tenant.

Databases make the state problem harder to ignore. If two agents test divergent migrations against the same mutable database, one can invalidate the assumptions of the other. The resulting tests may pass or fail because of execution order rather than because either change is correct.

A safe slot might provide a dedicated database, a clone or an isolated schema, depending on the database and the kind of migration. Queues and caches may need separate namespaces or instances. Sessions and test identities must not cross the lease boundary. The mechanism varies, but the invariant is stable: one worker should not be able to change the meaning of another worker's environment accidentally.

This is why “shared registration but isolated authority and runtime state” remains important. The reusable part should be the smallest stable surface demanded by the external system. Secrets, sessions, data and the authority to act should remain bound to the active lease.

Bounded parallelism is still a constraint

A finite slot pool does not make the system infinitely scalable. If there are N safe slots, there can be at most N active environments. The next worker must wait, time out or receive an explicit refusal.

That is a limitation, but it is also more honest than allowing several workers to share hidden state and hoping their work does not overlap. The pool turns accidental serialisation into visible capacity and gives the workflow somewhere to apply backpressure.

It also creates new failure cases. A worker can disappear while holding a slot. A delayed operation from an expired lease can arrive after the slot has been reassigned. The Chubby lock service paper describes this broader stale-holder problem and the use of sequencers when a lock protects resources in other systems (Burrows, 2006). An allocator must do more than prevent two successful acquisitions at the same instant. The resources behind the lease must also reject a stale owner.

Allocation is not the whole lifecycle

The slot manager should decide who owns a slot, issue its manifest, renew or expire the lease and limit what happens when the pool is full. It should not silently make every environment lifecycle problem part of allocation.

Starting services, preparing data, checking health, applying a known schema, stopping processes, revoking credentials and proving that state has been removed are separate operations. The allocator may coordinate them, but availability should follow their outcome.

My current work does not yet treat complete setup and teardown as solved. That is the next operational step. In the fuller design, releasing a lease should move the slot through cleanup before it becomes available again. If cleanup fails, the slot should be quarantined rather than handed to the next worker on trust.

Recycling is not housekeeping. It is the proof that reuse has not turned yesterday's isolation into today's state leak.

What I still need to prove

The architecture is still forming. A diagram can state an intended boundary; it cannot establish that the boundary holds under failure. Before I would describe the system as strongly isolated, I want evidence that:

  • two workers cannot acquire the same active slot
  • an expired worker cannot continue acting through a recycled slot
  • one slot cannot observe another slot's data, messages, sessions or authority
  • cleanup either restores a known starting state or quarantines the slot
  • stable inbound traffic reaches the correct current lease in each supported runtime mode
  • capacity exhaustion produces deliberate waiting or refusal, not hidden sharing

These are code, configuration and runtime claims. They need concurrent tests, cross-slot negative tests, lifecycle tests and failure injection. The slot pattern is useful before all of that evidence exists; the confidence of the language should not outrun the evidence.

The next boundary is identity

Slots relieved the first constraint, but they also preserved part of it. Each slot is still paired with a pre-established external identity. Increasing capacity can therefore mean creating and maintaining more external registrations.

The next idea I want to explore is extracting identity from the slot. One stable external boundary could receive the request, bind it to an active lease and route it to the correct isolated environment. The number of environments behind that boundary would no longer need to match the number of externally registered addresses.

One stable identity, many isolated environments

Stable external identityOne registered boundaryReceives the inbound interaction
Lease-aware identity layerAuthenticate, resolve the active lease, route
Bind transactionKeep slot authority separateReject stale or replayed delivery
  1. Active lease AEnvironment AIsolated runtime state
  2. Active lease BEnvironment BIsolated runtime state
  3. Active lease NEnvironment NIsolated runtime state
The identity remains stable while the environments behind it can change. The routing layer must preserve each lease's authority and isolation; it is a proposed boundary, not yet a proven implementation.

That could make slots more elastic. It would also create a new security and reliability boundary. The identity layer would need to authenticate the transaction, prevent cross-slot routing, reject replay and late delivery, survive failure and avoid becoming the new serial bottleneck.

It is therefore a hypothesis rather than the inevitable final design. The first architecture made isolation easy to see by giving each slot a stable identity. The next architecture would have to preserve that isolation while making the identity shared.

A compatibility layer, not a permanent excuse

Not every fixed dependency needs a slot. If a system supports safe dynamic registration, disposable database branches, isolated namespaces or genuinely asynchronous work, using those capabilities may be simpler than maintaining a pool.

Slots are most useful where the constraint is outside our control, expensive to reproduce or embedded in a legacy system that cannot be redesigned yet. They allow more parallel work without pretending the dependency has changed.

But a compatibility layer can outlive the reason it was built. The presence of slots should not stop the underlying system becoming easier to provision or more naturally concurrent. Their capacity limits and operational costs are evidence about what to decouple next.

That is the part of this work I find most useful. The first design does not need to be the final design to teach us something. Slots make the constraint explicit. Their limits show where identity, environment and lifetime remain joined.

A useful architecture does not pretend every dependency can scale. It makes fixed constraints explicit, leases them safely and keeps looking for the next coupling to remove.

Further reading

These books offer related perspectives rather than direct proof of the slot pattern. I am including them as a reading list to examine, not as endorsements of every claim they contain.