Agents — the execution substrate

TL;DR

• An agent config is the definition of a worker: model profile, guidance, workflow-backed skills, MCP servers, budget.
• Skills are the guardrail. Tool calls are policy-gated against the workflows the agent's skills grant. No skills, no actions.
• A session is where it runs: on runner capacity in your cloud, watched live, cost-tracked per session and rolled up per actor.
• Memory is Engram, switched on per config. End-user agents put a governed agent in front of your app's users.
• Every agent talks to Orkestia through the same MCP server you do, with its own agt_ token.

Staff is how you govern an AI workforce. The agents substrate (agents.*) is what a worker actually is. Every primitive on this page is itself a governed workflow surface you can automate.

Agent configs

An agent config is the declarative definition an actor runs with:

Configs are managed by agents.agent-config.* workflows: create, update, clone, attach and detach skills, MCP servers, and guidance. A draft-from-description flow bootstraps a config from a natural-language role. Because a config is data, changing what an agent can do is an operational action, not a redeploy.

Skills are workflow-backed

A skill is not free-form tool access. It names the workflows that implement it, and the agent's tool calls are policy-gated against its attached skills. A call to a capability no skill grants is blocked before it executes. Skills bundle into skill packages for reuse.

An agent's reach is therefore the union of its skills' workflows, filtered by its role bindings, bounded by its budget. Three independent brakes, all declared as data.

Agents and the Orkestia MCP

An Orkestia agent reaches the platform the same way a human's assistant does: through the Orkestia MCP server, authenticated with its own agent token (agt_…). whoami on that token returns agent_uuid, staff_actor_uuid, permission_mode, and seat_mode, so every run the agent starts is attributed to the right actor.

The MCP servers attached to a config are additional tool servers the agent may call (a vendor API, an internal service). They are registered per agent and health-checked. Orkestia's own capabilities still arrive as skills, so the tool-policy gate applies uniformly.

Sessions

Launching an actor starts a session, a pipeline that assembles the config into a live worker:

The session executes on your runner capacity, the same Zero Code Custody boundary as every other run. Orkestia records session state, transitions, and cost entries. Sessions are observable live (the watch feeds the console's Activity stream) and cost-tracked per session, rolled up per actor.

Memory (Engram)

Memory is Engram, not a file on the runner.

Org-level memory_enabled (default on) is a second read gate. Contract: Write & recall. Live tail: engram.orkestia.dev.

End-user agents

Agents are not only for your team. The substrate exposes an end-user ask surface (agents.end-user.*, including streaming) so apps you build can put an agent in front of end-users. The end-user's identity is injected immutably into every run, exactly as with end-user data workflows. The agent acts only within its skills, roles, and budget, scoped to that user.

A Staff actor can also sit in an app's chat space as a member. It answers mentions, DMs or whole channels, either as its end-user seat in the app (only the app's end-user workflows as tools) or, in internal mode, as an organization session for a listed set of your own people. See Actors in chat.

Fine-tuning datasets (early)

agents.ft-dataset.* builds fine-tuning examples from recorded sessions: create, build, validate format, upload, finalize. Treat it as alpha.

The pieces in one view

Actor (Staff: unit, roles, approvals, audit)
└── Agent config
    ├── model profile        → your AI provider connection
    ├── guidance             → standing instructions
    ├── skills / packages    → workflow-backed abilities (tool-policy gate)
    ├── MCP servers          → extra tool servers, health-checked per agent
    └── budget               → spend ceiling
        └── Session          → launched on YOUR runner capacity
            ├── identity     → agt_ token; whoami → staff_actor_uuid
            ├── memory load  → Engram (last_k / pack)
            ├── live watch   → console Activity stream
            └── cost entries → per-session spend rollup

Ask your AI assistant

List the agent configs in my org. For each, show the model profile, attached skills, MCP servers, and budget.

Which of my actors have no skills attached? They cannot act until they do.

Show me the active agent sessions and how much each has spent so far.

Draft an agent config from this description: "reviews incoming support tickets and labels them by severity". Show the proposed skills before creating anything.

For AI agents

Where to go next