Atender — Capabilities, from talking to acting.

The core idea

What a capability is

A connection to one of your systems, expressed in one of three computer-to-computer languages. Each connection is something the AI can call during a conversation when it decides the customer needs more than words.

1Connection types — the languages computers use to talk to each other

{ }

API

HTTP-based connections — most integrations

◈

MCP

Model Context Protocol — AI-native tools

CLI

Command-line — internal scripts and legacy tools

Whichever connection type you pick, here’s what building one looks like ↓

2How you build one — a five-step setup, in order

Step 1

Define the API

Give the capability a name and point it at a service. Paste an OpenAPI spec and Atender will parse every operation automatically. Or provide just a docs URL — the parser reads the docs and builds the endpoint definitions for you. For services with no spec, you can describe endpoints by hand.

Step 2

Choose how it authenticates

Pick the auth mode — whose credentials are in play. External OAuth means the customer signs in with their own account. Proxy Auth uses your team’s credentials on the customer’s behalf. Full Access uses a service account for back-office work. Then choose the protocol the service expects: API Key, Bearer Token, Basic Auth, OAuth2, or a custom header.

Step 3

Set the verification level

Decide what the customer must prove before this capability is allowed to run, on a four-step ladder from L0 (Public) to L3 (Authenticated Session). A simple order-status lookup might sit at L1; cancelling a subscription belongs at L2 or L3. The full ladder is in the next concept.

Step 4

Protect sensitive data

Define redaction rules so credit-card numbers, SSNs, tokens, and anything else you flag never get logged or stored. Atender strips the matched fields out of the capability’s inputs and outputs before the data ever reaches your conversation history.

Step 5

Connect and browse the endpoints

Once it’s wired up, every endpoint is visible inside the capability — you can pick which ones agents are allowed to call, replay the last successful run with all real values stripped to safe placeholders, and confirm the shapes are what you expect.

Security model

How a capability is secured

Capabilities can act on real customer data. Atender’s security model has three pieces: who the capability authenticates as, how the customer is verified before it runs, and what data is allowed to leave the conversation.

1Authentication — whose credentials are in play?

External OAuth customer signs in

The customer authenticates directly

The capability acts on behalf of the customer, using their own connected account. Common when the customer is the only one with permission to authorise the action.

Proxy Auth your team’s creds

Atender proxies through your credentials

Your operations team’s credentials are used to act on the customer’s behalf. The customer never sees an auth screen.

Full Access service account

A service account with full access

For back-office reads and writes — internal records, CRM updates, internal APIs that don’t need per-user identity.

Custom your flow

Define your own authentication flow

For systems that don’t fit one of the standard patterns. You wire up the auth steps the way the target service expects.

And underneath, the protocol the capability speaks ↓

2Authentication protocol — how the credentials are sent

Six options to match your target service

None API Key Bearer Token Basic Auth OAuth2 Custom Header

3Security level — how should customers be verified before this capability runs?

L0 Public no verification needed

Anyone can trigger this capability

For low-risk reads and public information — store hours, public product info, tracking links shared by URL alone.

L1 Context Proof customer provides info

The customer proves they know something

Email, order number, postal code, phone — something the customer would plausibly only know if the account is theirs. Lightweight, conversational, good for read-only lookups against their own data.

L2 Code Verification SMS or email OTP

A one-time code, sent to a known channel

Atender sends a one-time code to the customer’s phone or email and waits for them to read it back. Stronger than context proof — the customer has to control the channel, not just remember a fact.

L3 Authenticated Session portal login

The customer logs in through a portal

Full customer authentication — they sign in with their own credentials and the capability inherits that session. Reserved for actions where you need confidence the person on the other end is the account owner: cancellations, refunds, payment changes, anything that’s hard to reverse.

Match the friction to the risk. Light verification on light actions. Strong verification on the things customers can’t easily undo. The wrong call in either direction is costly — too much friction and customers bounce; too little and the AI takes irreversible action for someone who shouldn’t be allowed to ask.

On top of all that, two data hygiene tools. Redaction rules strip sensitive fields (credit card numbers, SSNs, anything you define) from inputs and outputs before they’re stored or logged. Consent tracking records the customer’s explicit consent before any sensitive action runs.

Operational state

How a capability lives

Every capability moves through four lifecycle states. While it’s running in production, every execution is recorded — and you can replay the most recent one safely from inside the editor.

1The four states — promote forward, never skip

✎

Draft

Being built. Not available to agents.

⦿

Testing

Available in the test environment only.

●

Active

Live for agent stacks in real conversations.

▣

Archived

Retired, preserved for reference.

Always promote through Draft → Testing → Active. A capability that goes live without being exercised in test can take real, irreversible actions on customer data — a wrong cancellation, a duplicate refund, a misdirected booking. The lifecycle is not red tape; it’s a tripwire.

While it runs, two ways to look at what happened ↓

2Observability — what happened, and what to expect next time

Execution history

Every run of a capability is recorded — when it ran, who triggered it, what the input was, what came back, and whether it succeeded. Filter by failure to find where customers got stuck.

Replay last execution, safely

The editor can reload the most recent successful run — but with every real value (names, IDs, tokens, addresses) replaced by typed placeholders. You see the shape of the data without ever pulling production values into the editor UI.