Tenant boundaries under pressure
Notes from designing a multi-tenant software factory where one team's speed cannot become another team's risk.
Multi-tenancy is not a database feature. It is the rule that every identity, action, and artifact belongs to the right customer.
Every new surface must preserve the chain from intent to execution to review—or be rejected.
Show method and boundaries ↘
Method
Adversarial build-log review across identity, capability issuance, tenant-local execution, and external coordination.
Boundary
We publish the question, method, and decision surface. Customer source, credentials, and private work remain tenant-local.
The test
Can a team of agents work quickly inside one tenant without ever receiving another tenant's context, credentials, artifacts, or release authority? Can the outer orchestration layer coordinate progress without seeing the proprietary data it does not need?
The constraint
Every new surface has to keep intent, execution, and review connected. If a feature creates another place where state can drift, it has failed the test.
The implication
Multiplayer is not a presence badge. It is a different data model for getting software made.
The best research question is one a working team can feel. Bring this one into a room, test the boundary, and tell us where it breaks.
Start building →