Configs, skills, and MCP
Staff shows an actor. The agent config is what that actor actually runs. Change the config and the next session picks it up — no redeploy.
Agent config
| Piece | What it declares |
|---|---|
| Model profile | Which LLM, via your org's AI connection |
| Guidance | Standing instruction documents |
| Skills / skill packages | Workflow-backed abilities the tool-policy gate allows |
| MCP servers | Extra tool servers, plus the built-in workflow MCP |
| Runner group | Must be agent-eligible |
| Budget | Spend ceiling checked as the session works |
| Memory flags | Engram read/write/strategy — Memory & cost |
Configs are agents.agent-config.* workflows: create, update, clone, attach/detach skills and MCP. There is a draft-from-description path (the hire wizard uses it).
Console: Build → Configs (/configs).
Skills
A skill is not free-form tool access. It names the workflows that implement it. The runtime blocks a call to a capability no attached skill grants — before execution.
Bundle skills into packages to reuse the same grant set across actors. Manage them under Build → Skills.
MCP servers
Two kinds:
- Built-in Orkestia workflow MCP — always-on for the org's agents. Same tools as MCP integration:
whoami,list_workflow_types,get_workflow_schema,start_workflow,watch_workflow, retry/stuck helpers. Hire attaches it by default. - Your servers — register a URL, refresh tools, attach to configs. Build → MCP servers. OAuth-capable servers have a callback route in Staff.
Register → refresh → attach to the config → next session loads the tool list. Health-check failures show on the MCP detail page.
How a call is allowed
tool call
→ skill policy (is this workflow granted on the config?)
→ Staff RBAC (does this actor's role allow the workflow?)
→ budget check
→ engine starts the workflow (same RbacGuard as a human)
Denied attempts are recorded. There is no "Staff chat bypass."
End-user agents
Apps you build can put an agent in front of end-users (agents.end-user.*, including streaming). The end-user identity is injected into the run; the agent still only has its skills, roles, and budget. That is a product feature on top of this substrate, not a second runtime.
One Identity app → one AgentConfig. If you need two agent products (app vs legacy, or two brands), provision two Identity apps. Do not copy another app's virtuals or configs onto this one.