Capabilities

Status: Current | Last reviewed: 2026-09-21

A capability is a reusable bundle you attach to an agent node: tools, prompt guidance, session variables, availability rules, and a small configuration form, all packaged under one name. Built-in capabilities (Customer Authentication, Payments, External Consult, Message Injection, Multimodal UI, Video) ship with the platform; custom capabilities are authored by your team and can be enabled on any number of agents.

Custom capabilities are expanded into concrete tools, prompt text, variables, tool logic, and UI-action captures. Draft Preview performs that expansion on the fly; publishing embeds an immutable snapshot for the released agent version.

Browse capabilities

Open Tools & Templates and select the Capabilities tab. The table lists:

Built-in capabilities (Payments, Customer Authentication, …) are not listed here — they are part of the platform and are enabled directly on an agent node.

Create a capability

Capabilities are authored pro-code in the Studio editor (VS Code in your browser), with schema-assisted editing and Claude available inline.

  1. Select New capability, give it a name (its permanent identifier derives from the name, so choose it carefully), a description, and a category — the category groups it in the agent editor's Add-capability library.
  2. Select Create & open editor. The Studio editor opens the capability's workspace — one file per section, each with a rich form editor (dropdowns, typed rows; the file itself is still plain JSON — use Open as JSON or "Open With… → Text Editor" for raw editing):
  3. tools.json — the tools the capability adds: Manual API endpoints (URL, method, header rows, a body-template editor that warns about placeholder typos, and an Auth picker — none, a fixed integration, or an integration the agent author chooses through a config field), sandboxed Python (pick or create the tools/<name>.py file from the form), Knowledge search, or existing saved tools — including MCP servers and A2A agents — picked from your Tools list (the capability carries a reference, so server URLs and credentials stay on the saved tool).
  4. config-schema.json — the config fields an agent author fills in when enabling the capability (text/number/toggle/choice/list rows, plus an Integration field kind that renders a picker over the tenant's integrations — use it to let each agent choose which API credentials the capability's tools call with). Config values substitute into the prompt and into tool settings via {{capability_config.<field>}}.
  5. constraints.json — singleton, stage-type checkboxes, and required companion capabilities (picked from your registry).
  6. logic.json — tool availability gates (the tool dropdown reads tools.json), full tool logic entries (gate + fixed argument bindings + captures that save a tool-result field into a session variable), UI-action captures that save component results, and Agent Logic rules.
  7. variables.json — the session variables the capability declares.
  8. prompt.md — the prompt guidance appended to the agent node at publish. Use {{capability_config.<field>}} to insert a config value and {{TOOL:<tool_name>}} to reference one of the capability's tools.
  9. capability.json — name, description, category, version.
  10. Author the capability — through the forms, by hand in JSON, or ask Claude in the editor (it knows the capability contract via the built-in authoring skill; its file edits appear live in the forms).
  11. Publish: run TrueServe: Publish Capability from the editor's command palette (or right-click capability.json), or use Publish from workspace on the capability's row in Tools & Templates. TrueServe: Validate Capability checks without publishing.

Validation errors block publishing and are listed in the editor's Capability panel (or in the Tools & Templates panel when publishing from there). Publishing bumps the version automatically when content changed.

Test a capability

In the Studio editor, open the Capability panel using TrueServe: Validate Capability, then select Testing. This opens testing.json as a form.

  1. Add output schemas to the capability's tools. Select Generate missing responses to create examples, then edit the results to match realistic success and failure cases.
  2. Create named Scenarios and choose a response variant for each tool. Supervisor scenarios can approve, decline, ask a question or time out.
  3. Select Check responses to verify the examples against the tool schemas.
  4. For Python tools, add implementation tests with inputs and expected results, then select Run implementation tests. This executes your code with the supplied dependency fixtures and external connections disabled.
  5. Publish the capability when ready. In an agent's Run tests window, edit a test and choose the scenario under Responses during the test.

Use Open as JSON for advanced fixture state, timing and dependency settings. An existing saved tool still owns its test responses in Tools → Testing. Running or checking a capability's tests does not publish it.

Version changes

Published agents are not affected by capability edits — each published agent version embeds a snapshot of the capability as it was at publish time. To pick up a new capability version, publish the agent again. Reopening the editor never overwrites your in-progress workspace edits.

Enable a capability on an agent

The agent editor shows enabled capability cards and the always-available Turn control card. Optional capabilities are found through the searchable library:

  1. In the agent editor, open a node's inspector and select the Behavior tab.
  2. In the Capabilities section, select Add capability.
  3. Search the library (grouped by category, built-ins first), then select Add. The capability's card appears with its config form open.
  4. Fill in the config fields. The capability is live immediately in the editor's Preview test calls (drafts expand on the fly), and Publish applies it permanently to the released agent.

The capability's tools appear by their callable names in the prompt editor's @ and {{ menus, so you can place them in instructions without adding the tools separately. At the bottom of the prompt, select the capability's auto-injected chip to see both its prompt guidance and its tools. Because the capability owns those tools, they are grouped there instead of appearing as removable items in the ordinary Actions row. Published versions show the same authored prompt and footer arrangement as the draft; Copy full prompt still includes the expanded guidance actually sent to the model. Main and each subagent prompt tab have their own Include this guidance switch inside the expanded capability chip. Use it when one specialist should not receive a capability's instructions. Editing the shared text or choosing Remove everywhere still applies to the whole stage; the per-tab switch changes guidance only and never unregisters the capability's tools.

To remove a capability, switch its card off — the card disappears and its node configuration is removed.

Conversation controls

Turn control uses the same collapsible card as other capabilities. It is always available because turn detection is part of a conversation; open its settings to configure interruptions, turn detection and audio cleanup. It has no global off switch.

Use Add capability → Idle detection → Add to enable idle prompting. Set Idle timeout (seconds) and Max prompts. Switching this card off disables idle prompting and retains its settings for reuse. Other turn-control settings are preserved. Existing agents with idle detection enabled show the card automatically.

Deleting a capability that agents still reference blocks their next publish until the reference is removed from the node; already-published versions keep working.

See also