# Built for a multi-tenant platform

> Schema-per-organisation isolation underneath the whole runtime, tools that are the platform's own registries instead of an API surface, and agents that are subjects in the org structure

Source: https://aipril.dev/docs/harness/built-for-a-platform

This runtime is the platform's own code, released with it. Three properties follow from that and
cannot be retrofitted onto a general-purpose one: isolation, registry-level integration, and an agent
that the org structure recognises as a subject.

## Isolation

The platform is multi-tenant on **schema-per-organisation**. Each organisation's tables live in their
own schema, and access is routed by setting the schema for the duration of the transaction - not by a
discriminator column that every query must filter on.

Consequence: a query that omits a filter cannot cross organisations, because the objects it would
have to name are not in its search path.

Everything in this block is per-organisation:

- **Providers, models and per-agent overrides**, including an organisation's own API key
- **Knowledge base, embeddings and the embedding dimension**, with a scoped migration path
- **Custom skills and marketplace installations**, with an installed proxy skill's configuration
  encrypted at rest
- **Credits, per-employee budgets and suspension state**
- **The audit trail and every trace record**
- **Digital employees**, each a subject inside one organisation's org structure with its own
  credentials

## Integration is registry-level

The agent calls the same registries the product runs on, not an API surface wrapped in shims.

- **Data goes through the query engine's contract** - the same one dashboards, application pages and
  external clients use. Row policies and column masks are compiled into the query plan for the asking
  identity. There is no second access model for AI. See
  [Data engine](https://aipril.dev/docs/engine/under-the-hood.md).
- **Process operations are the connector registry** that durable orchestration itself calls, bridged
  natively into the tool plane and executed under the calling employee's own actor-scoped token. See
  [Tools and MCP](https://aipril.dev/docs/harness/tools-and-mcp.md).
- **Consequential work runs as a durable workflow** and inherits retries, saga compensation and a
  persisted history. Creating a business process is itself a durable skill. See
  [Processes](https://aipril.dev/docs/processes/under-the-hood.md).
- **Ledger, spreadsheets, dashboards, pages and master data** are reachable the same way: declared
  operations with declared risk, so one [gate](https://aipril.dev/docs/harness/invocation.md) covers all of them.

A capability added anywhere in the platform reaches the agent's vocabulary as a declared operation
with its parameters, permissions and audit path already in place.

## The agent is a subject

An [AI employee](https://aipril.dev/docs/ai-organisation/employees.md) is a fourth kind of assignment in the org structure,
alongside the human ones.

- **Its own credentials**, separate from any developer token, and authentication through the same path
  a person uses
- **Denied everything by default**; what it may do comes from a mandate
- **The mandate is constrained to a subset of its manager's own authority**, so configuration cannot
  grant an employee more than the person accountable for it holds
- **One audit trail for both kinds of actor**, under their own names

Two capabilities follow directly:

- **An application can declare its own staff.** Installing it proposes the employees it needs; hiring
  one wires that application's automations to run as that employee - a named actor with a budget and
  a trace - without a reinstall. See [Applications](https://aipril.dev/docs/apps/under-the-hood.md).
- **Attribution is per employee, not per installation** - spend, mandate, suspension and audit all key
  to the assignment. See [Budgets and metering](https://aipril.dev/docs/harness/budgets.md).