Organizations & Multi-Tenancy

What Is This Feature?

Your platform serves multiple businesses at once — each with their own users, data, assistants, and settings. "Multi-tenancy" is the technical term for this, but the real-world meaning is simple: every customer gets their own completely isolated workspace. What one organization sees, another cannot. This deep dive explains how that separation works and why it's critical to your product's security and scalability.

---

Why It Matters to Your Business

When you sell to multiple customers, the very first question any security-conscious buyer will ask is: "Can other customers see my data?" The answer must be an unequivocal no — and this feature is what makes that promise real.

• Customer trust. Data isolation is a non-negotiable requirement for enterprise sales. This feature lets you confidently answer security questionnaires and compliance audits.
• Custom branding. Each organization can have its own subdomain (e.g., acme.yourassistant.com) or even a fully custom domain (e.g., assistant.acme.com). This makes the product feel native to their brand.
• Per-org features and limits. Some customers on a higher tier get more features or higher usage limits. Multi-tenancy is the foundation that makes per-customer configuration possible.
• Safe scaling. As you add more customers, the architecture ensures they don't interfere with each other's performance or data.

---

How It Works (No Technical Jargon)

Think of each organization as having its own locked room in a shared building. The building (your platform) handles shared infrastructure — servers, uptime, security patches — but each room is completely private.

1. When a request comes in, the system immediately identifies which organization it belongs to. It does this by reading the subdomain, a custom domain header, or an organization identifier.
2. Every action is tagged with that organization's identity. Reading data, writing data, running reports — all of it is scoped to the correct organization automatically.
3. Guard checks run throughout the system to catch any code that tries to access data without properly specifying which organization it belongs to. These are enforced by automated tests on every code change.
4. Domain conflicts are caught before they go live. If two organizations somehow end up with the same custom domain, the system blocks the deployment and raises an alert before any customer is affected.

---

What This Means for Your Customers

• They get their own branded URL, so the assistant feels like a native part of their product
• Their conversation history, knowledge base, settings, and user data are completely invisible to other customers
• They can enable or disable features independently of other organizations
• Usage limits and quotas apply to their account only, not shared across customers

---

Security Guarantees

• If the system can't clearly determine which organization a request belongs to, it rejects the request and returns an error — it never guesses or defaults to a shared pool
• Write operations and sensitive reads always require explicit organization context; there is no way to accidentally access another tenant's data
• Every routing decision is logged, so you have a clear audit trail if a question ever arises

---

What to Expect on the Roadmap

The team is building out:

1. Automated checks on every endpoint to enforce organization-scoped access (estimated 3 weeks)
2. Deploy-time duplicate domain detection to catch configuration errors before they reach production (estimated 2 weeks)

These changes will make the multi-tenancy guarantees fully verifiable and auditable — giving you concrete evidence you can share with security-conscious customers.