Add a Capability to a Specialist

Without capabilities, an Agent Stack can only talk. With them, it can act — call your order API, process a cancellation, look up a customer record, fire a webhook. Capabilities are attached per specialist, so the order tracker can call the order-lookup API while the billing agent can only read invoices.

Before you start

• The capability must already exist in Settings → Capabilities. If not, create one first.
• Decide the required proof — what the customer must have shown before this capability may fire. The picker offers exactly three levels:
• No proof (level 0) — always available, even to anonymous callers (e.g. order-status lookup with the order ID).
• Verified customer (level 2) — a code sent to a channel already on the customer’s account, or a login.
• Signed-in customer (level 3) — the customer is signed in on the connected system.

Level 1 no longer exists. Nothing at runtime grants it, so it is not offered; an assignment left over from before renders as Legacy level 1 — retired. Do not write policies around L1.

Pick the lowest level that’s safe. No proof is fine for read-only public data; Signed-in customer is required for anything that moves money.

For voice stacks and phone calls, only level-0 capabilities run at all. Anything at level 2 or 3 is dropped from the agent’s tool list on a call rather than being offered and refused, so a call cannot complete a Read, Act or Transact capability.

Steps

1. Open Settings → Agent Stacks → [stack] → Orchestrator.
2. Click the specialist node that should get the new capability.
3. Click the Capabilities sub-tab.
4. Click Add capability. (If every capability you have is already assigned, the button reads New capability instead and takes you to Settings → Capabilities to create one.)
5. A search popover opens — Search capabilities… — listing what your tenant has defined. Picking a row assigns it immediately. There is no confirm step and no Save button; you should see a Tool assigned successfully toast.
6. Adjust the required proof for this assignment if you need to. The select defaults to Inherit (), which uses the capability’s own level. Overrides are grouped as Require more proof, Require less proof, Same as inherited and Retired.
   A capability whose connection signs the customer in has a floor: lower options are shown greyed out and the server refuses them, because a lower level would hand the AI a tool that then refuses every call it makes.
7. To remove a capability, click the × on its row. That also takes effect immediately, with no confirmation.

Verify it worked

• The Capabilities sub-tab now shows the new capability, grouped under its action tier, with the required-proof line you configured.
• The specialist’s slide-out summary card (top of the panel) shows a non-zero Capabilities count.
• Open the Testing tab and ask the specialist a question that should trigger the capability. The reply should include the action result (e.g. order status, refund confirmation).

When to override the default security level

Capabilities have a default security level set at the capability itself. Override on a per-specialist basis when:

• A specialist serves higher-risk customers and you want to require stronger auth (e.g. an enterprise specialist requires L3 for actions that another stack runs at L1).
• A specialist serves lower-risk customers and you want to relax auth (e.g. internal-only stack runs everything at L0).

When in doubt, leave it as Inherit — the capability’s default is usually correct.

Troubleshooting

• Symptom: A warning triangle appears next to a capability in the list. Fix: that is the level-0-on-a-gated-tier warning — “This capability changes the customer’s account, but asks for no proof of who they are.” Raise it to Verified customer or Signed-in customer unless you have a deliberate reason.
• Symptom: The capability never fires in test. Fix: confirm the test session’s proof level meets the capability’s effective level. In the Testing tab, enter a test user ID, click Simulate login, then retry the prompt. Simulated login is server-backed for synthetic test sessions; if you don’t enter a user ID, the session is not elevated and scoped tools remain unavailable. For capabilities gated by a real customer sign-in connection, trigger the tool, use the Sign in card, complete the hosted provider or proxy login, then click I have signed in. Use simulated login only when you intentionally want to bypass the real customer sign-in flow. If you’re testing over voice, confirm the capability is L0.
• Symptom: The capability fires but the AI doesn’t reference its result. Fix: check the specialist’s Instructions — sometimes a poorly worded instruction tells the AI to ignore certain capability outputs. Also check the capability’s response format in Settings → Capabilities; if the AI can’t parse the response, it won’t use it.
• Note on approval modes. A per-capability approval policy is stored on the assignment, but the control is deliberately hidden and nothing reads the value at run time — no capability is currently held for human approval on this path. Do not configure a stack expecting a pause here.

See also

• What is a specialist agent?
• What are Capabilities?
• Add a specialist agent