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. If a published capability is unpublished, it returns to Draft and specialists can no longer call it because the linked agent tool is disabled.
• Published — Live. Specialists you’ve granted access to can call it in real customer conversations. Published capabilities can be unpublished back to Draft when you need to take them offline or make changes safely.
• Archived — Retired. Preserved for reference but no longer callable.

You can publish or unpublish capabilities from the row actions in the Capabilities list, or select multiple capabilities and use the bulk actions. Unpublishing is the fastest way to stop specialists from calling a capability without deleting its configuration.

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

Guided

Every new capability opens in the guided builder, and there is no mode question to answer first. It is a single form for “call this endpoint and return the result” capabilities: name it, pick the connection and the action, say which parameters the customer would know, set the action tier, write the guidance. Most order lookups and status checks fit here.

Advanced

The editor also has an Advanced canvas, where you connect nodes (Trigger, API Call, Condition, Transform, Response, Loop, Delay, Variable, AI Process) into a flow. It is not offered while you are creating a capability, and not on a guided-built capability with an empty canvas — the Switch to advanced editor item only appears on an existing capability that has a node graph. See Node types reference for the full set.

How a capability authenticates

Most external systems require authentication, and that is a property of the connection the capability calls, not of the capability itself. Two questions live there. First, what credential does the API expect? The detected type is one of API Key, Bearer, Basic, OAuth 2.0, or Custom Header. Second, whose credential is used: Shared credentials (one key Atender uses for every customer) or External OAuth (each customer signs in on your provider’s page). See Authentication options.

Proving who the customer is

You don’t configure a per-capability identity check. What proof a capability demands is decided by its action tier, and the platform holds it there — the tiers and the proof each one requires are not configurable:

• Public — No customer data — hours, status, FAQ — None
• Read — Reads one person’s data — order status, sign-in diagnostics — Verified caller — a code to a channel already on their record, or a login
• Act — Changes one person’s data — send a link, update an address — Verified caller
• Transact — Money — refund, cancel a paid order — Signed-in customer; on a phone call it is handed to a person instead

The enforcement security level is derived from the tier and from what the connection can actually ask a customer for — you never set it by hand. Above Public, a capability also needs the connection to name the field that carries the customer, so every call is narrowed to that customer’s own records.

Redaction and security

On each connection, Sensitive data protection strips sensitive fields out of API responses before they reach the AI’s context — twenty-odd built-in field names (ssn, card_number, cvv, password, account_number and the rest) plus SSN and 16-digit-card patterns, and any custom field names or dot-paths you add. Combined with action tiers and the ownership check, 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