Agent-native runtime

"Agent-native" in Fabric does not mean "we added a chatbot." It means the runtime's actor model has been designed so that an AI agent and a human user are interchangeable from the runtime's perspective — both are just actorType values entering the same invokeAction function.

The actor model

Every action invocation carries an actorType from a fixed enum (packages/platform/actions/index.ts):

type ActorType =
  | "natural_person"
  | "agent"
  | "system"
  | "service_account"
  | "external_system"
  | "integration";

Every ActionInvocation row records both actorId and actorType. Every AssetEvent records the actorType of the cause. The audit log is uniform across all six.

Why this matters

A traditional app puts AI agents on a side door — a special endpoint, a special token, a special log. That side door becomes the gap auditors and security teams hate: actions taken there are hard to compare with actions taken via the main UI.

Fabric removes the side door. An agent making an action call goes through:

agentProcedure middleware
  → validates the credential
  → checks the action ID is in the credential's scope
  → calls invokeAction with actorType: "agent"

From invokeAction onward, the path is identical to a human's. Same policies. Same state-machine validation. Same ActionInvocation row. Same emitted AssetEvents.

Permission-check semantics

invokeAction skips the tenant-Member permission check for three actor types: external_system, system, and agent (packages/api/modules/platform/lib/invoke-action.ts). Each has its own upstream proof:

• external_system — a verified HMAC-signed token (e.g. the offer-acceptance link).
• system — a worker process inside the trust boundary.
• agent — the agentProcedure middleware that already validated the credential and its action-scope list.

Anything attempting to pass these actor types from outside its trust boundary will fail upstream. The runtime treats them as authenticated upon entry.

Where the agent surface lives

The platform exposes the agent surface through:

• The MCP server (apps/mcp) — agents speak Model Context Protocol and call action IDs.
• The TypeScript SDK (packages/sdk-typescript) — programmatic access for agents written as TypeScript services.
• The Python SDK (packages/sdk-python) — same surface, different language host.

Each of these is a thin client over the same platform.actions.invoke oRPC procedure described in action triggers.

Diagram

See also

• Agents within policy bounds — how to design an agent-callable action.
• Action triggers — the three valid entry paths.
• Agent API reference — surfaces, scopes, examples.