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.
- 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.
- 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.
- Ledger, spreadsheets, dashboards, pages and master data are reachable the same way: declared operations with declared risk, so one gate 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 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.
- Attribution is per employee, not per installation - spend, mandate, suspension and audit all key to the assignment. See Budgets and metering.