What are Capabilities?

A Capability is a connection that lets an AI specialist do something in an external system — look up an order, process a cancellation, check delivery status, verify account ownership, or call any HTTP API you can describe. Without capabilities, an Agent Stack can only talk. With capabilities attached to its specialists, it can act on the customer’s behalf.

You build capabilities once in Settings → Capabilities, then assign them to specialists in your Agent Stack. A billing specialist can issue refunds while the product specialist only looks things up — each agent gets only the powers it needs.

The lifecycle

Every capability moves through a clear set of states:

• Draft — Work in progress. Not available to any specialist. Edit freely.
• Published — Live. Specialists you’ve granted access to can call it in real customer conversations.
• Archived — Retired. Preserved for reference but no longer callable.

You can run test executions against any capability before publishing — see How to test a capability. Always test against a real endpoint before flipping the switch — a broken capability means the AI confidently tells the customer “I just cancelled your order” when nothing happened.

Two ways to build

Visual canvas

For complex capabilities — anything with branching logic, multiple API calls, or data transformation — Atender provides a drag-and-drop canvas. You connect nodes (Trigger, API Call, Condition, Transform, Response, and others) into a flow that runs when a specialist invokes the capability. See Node types reference for the full set.

Simple Tool mode

For straightforward “call this endpoint with these parameters and return the result” capabilities, skip the canvas. Simple Tool mode gives you a single-form interface: pick the endpoint, map inputs to parameters, declare outputs. Done. Most order lookups and status checks fit here.

How a capability authenticates

Most external systems require authentication. Capabilities support the common patterns: API key in a header or query string, Bearer token, Basic auth, OAuth2, and custom-header schemes. On top of the auth type, you choose an auth mode that decides whose credentials are used — the customer’s (External OAuth), your team’s (Proxy Auth), a service account (Full Access), or a flow you define yourself. See Authentication options.

Identity verification before sensitive actions

Before a capability that touches real money, real data, or real accounts runs, you can require the AI to verify the customer’s identity conversationally — “what email is on the account?”, “what’s the order number?”, “what’s your billing zip?”. The capability won’t execute until the answers match. This is layered on top of the capability’s own security level, which decides how much oversight (logging, agent confirmation, supervisor approval) each call needs.

Redaction and security

You can define redaction rules that strip sensitive patterns — credit card numbers, SSNs, anything you specify — from the data flowing into and out of a capability before it’s logged. Combined with security levels and identity verification, this lets you give the AI useful powers without those powers becoming a privacy risk.

Where to start

• Build your first one: Create a capability
• Pick the right nodes: Node types reference
• Set up auth correctly: Authentication options
• Test before going live: Test and publish a capability
• Try a complete pattern: Order lookup recipe