Staff & AI Workforce Governance

TL;DR

• A fleet of agents is an organization. Staff gives it an org chart (units, actors), role-based permissions, approval gates, and an immutable audit trail.
• Authorization lives in the engine, not the UI. Workflows declare Capability metadata. The engine's guard checks it before the first step runs, no matter which door the call came through: console, SDK, or an assistant over MCP.
• Approvals make "AI proposes" vs "AI acts" explicit. Sensitive workflows park in a pending-approval state and surface in an operator inbox.
• Everything is auditable. Every actor action is a workflow run. The audit.* family queries the transition log.
• Operate it at staff.orkestia.dev. Model here, operator path in Staff & Agents. Selling or hiring an actor across organizations is Agent Exchange — a different console and a different "hire".

A single AI agent is a tool. A fleet of agents that can read connections, launch sessions on your runners, and start workflows in your cloud is an organization. Organizations need structure, permissions, and oversight. Staff is that layer.

Why governance for autonomous AI

The point of an AI workforce is that it acts without a human in the loop for every step. That is also the danger. An agent connected over MCP that can start workflows in your accounts has real reach, and the failure surface compounds with every agent you add.

The model: actors in an org structure

Staff borrows the vocabulary of a real organization. The core entities are OrgUnit, Actor, RoleBinding, and Capability, managed through staff.* workflows.

• Organization: the tenant boundary. An actor never sees or acts on another org's state.
• OrgUnit: a team or department. A navigable tree and a natural scope for permissions.
• Actor: an AI worker with a lifecycle (hire, update, pause, resume, archive, invoke) and its own inbox, outbox, and journal.
• Role and RoleBinding: a role is a named bundle of capabilities. Binding it to an actor or unit grants them. Effective permissions are the union of bindings.
• Capability: the unit of authority. Workflows declare it; RBAC checks it at run time.

Each actor authenticates to the platform with its own agent token (agt_…). Over MCP, whoami on an agent token returns agent_uuid, staff_actor_uuid, permission_mode, and seat_mode, so the server knows exactly which actor is calling.

Roles, capabilities, and enforcement

Staff's central design choice: authorization is in the engine. When any caller tries to start a workflow, the engine checks the caller's effective roles against the workflow's required capability before the first step runs. A denied attempt never executes and is itself recorded.

{
  "workflow_type": "finance.invoice.cancel",
  "capability": "finance.invoice.cancel",
  "requires_approval": true
}

Two consequences:

1. No back door. Console, REST, SDK, or an assistant over MCP all funnel through the same engine and the same guard.
2. What an agent may do is data, not code. Granting or revoking authority is a role-binding change, visible in audit, not a redeploy.

Human-in-the-loop approval gates

RBAC decides whether an actor may attempt a capability. Approval gates decide whether a specific attempt proceeds. A sensitive workflow parks in a pending-approval state and surfaces in the operator inbox. A human reviews the proposed action and its inputs, then approves or rejects.

sequenceDiagram
  participant Agent
  participant Engine as Workflow engine
  participant Inbox as Operator inbox
  participant Human
  Agent->>Engine: start_workflow(finance.invoice.cancel)
  Engine->>Engine: RBAC: capability granted?
  Engine->>Inbox: requires_approval → pending
  Inbox->>Human: item needing attention
  Human-->>Engine: approve / reject
  alt approved
    Engine->>Engine: execute effectful steps
  else rejected
    Engine->>Engine: terminate (no side effect)
  end

This is the mechanism behind graduated autonomy: start a new agent with approvals on everything, then relax gates as you gain confidence. The same discipline shows up at the MCP level, where the server tells assistants that creates and mutations should be confirmed with the user first. Configuration: Governance & approvals.

The Staff console

The console at staff.orkestia.dev is the operator-first surface. Day to day: Staff & Agents.

The console does not mutate state directly. Operator actions start named workflows (staff.*, agents.*, read-only data.agents.*), so every operator action is itself a governed, recorded run.

Accountability: everything is auditable

Because every Staff and agent action is a workflow run, the engine's transition log is already a complete record. The audit.* family exposes it as a typed, read-only, org-scoped query surface.

Denied RBAC attempts and approval decisions land in the same log. Over-reach and human sign-off are part of the evidence trail, not separate systems.

Ask your AI assistant

List the Staff actors in my organization with their unit and role bindings. Flag any actor bound to kubernetes.* or deploy.* capabilities.

Show me what is waiting in the operator inbox and summarise each pending approval.

Run audit.workflow-run.query for the "finance." prefix over the last 7 days and group the results by actor.

Hire a new actor called "release-notes-writer" in the Platform unit with a read-only role. Show me the plan before you start anything.

For AI agents

How Staff fits the rest of Orkestia

Next steps