Change-level tenancy

Treating each in-flight change as the tenant of the development platform, rather than each developer, team, or agent. Proposed in new-tenant-is-change as the answer to a capacity model that breaks when one person supervises several coding agents at once.

The unit matters because every pre-production policy is denominated in it. A per-developer kubernetes namespace, a staging environment booked by team calendar, a nightly database seed refreshed for everybody, a capacity plan derived from the hiring plan — each of those is a seat-denominated policy, and each misprices a workload where changes outnumber people several times over.

Three requirements

Change-level tenancy is defined by what it demands, and the demands are what separate it from the per-developer environment this spoke already documents under internal-developer-platform:

Creation must be near free. Hundreds of tenants a day is the target, so a tenant that costs a full environment and tens of minutes of setup is still person-level tenancy wearing a new label.
Isolation must cover only what changed. The tenant owns the one or two modified services plus a writable database branch; everything else resolves against a shared baseline continuously deployed from main.
The lifecycle must bind to the change. Created when work starts, destroyed on merge or abandonment — no ticket at the front, no cleanup script at the back.

The argument for the change over the agent

The obvious candidate for the new tenant is the agent, and new-tenant-is-change rejects it on durability grounds: agents are interchangeable and short-lived, two can share one change, one can move through five, and a crashed one is replaced without downstream effect. The change is the thing that accumulates private state (a migration, test writes, service versions, emitted messages) and the thing that ends. The worker is not the unit of isolation; the work is.

Why this is a platform-ops subject and not an AI one

The load-bearing observation is independent of agents. Organizations already run their product as a competent multi-tenant system — shared substrate, per-tenant ownership of only what differs, self-service onboarding, reclamation on exit — and run their pre-production on the opposite rules, provisioning by ticket or by seat and isolating by duplicating the stack. Agents did not create that inconsistency; they made it expensive, by raising concurrent changes well past headcount.

That places the idea beside this spoke's existing tension between the paved path and its cost. Golden paths were designed to make the right way the easy way, and "an environment per developer" was one of the paths they paved. This argues the path itself was sized against the wrong denominator.

The measurement it proposes

Two numbers, and the spoke has neither for any real organization: changes in flight at peak (open pull requests with activity in the last day is offered as the proxy) and the marginal cost of one more concurrent change, in money and in minutes of setup. They are the diagnostic — if the second answer is "a full environment, tens of minutes," the platform is still seat-denominated.

Standing caveat

The whole model comes from one sponsored source written by a vendor selling ephemeral environments (signadot), and no measurement in it is the author's own. The frame is testable and untested here. See new-tenant-is-change for what is borrowed and what is asserted.

new-tenant-is-change · internal-developer-platform · platform-engineering · platform-ops · kubernetes · gitops · compute-sandbox · signadot · agent-loops-verification · synthesis