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 stay private to your workspace.
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.
Take this further
The best research question is one a working team can feel. Bring this one into a room, test the boundary with your AI Cofounder, and tell us where it breaks.
Next question
The guardrails for agent-built software →