Skip to content

Capabilities

A capability is something the agent can do while it talks that must be switched on, and that usually needs a connection to an outside account. Scheduling books calls. People remembers who the agent is talking to. Notifications alerts your team. A custom integration calls your own HTTP endpoint. You configure a capability rather than write one, which is what separates it from Behavior.

That test is the whole definition. When switching something on changes nothing the agent can do mid-conversation, it is not a capability. Two things are commonly mistaken for one. Knowledge is what the agent knows; every agent has it from the moment it exists and it cannot be switched off. Starting conversations is set up with Outreach, which has nothing to enable and no account to connect.

The four faces of a capability

Every capability, built in or custom, presents the same four faces.

Face Where you see it
What it lets the agent do Its card on the Capabilities page.
What you configure Its page under Capabilities.
What it adds to what the agent reads A short read-only text on its card: the guidance the agent gets while a Playbook uses it.
Whether it is ready Its status: Ready, Needs attention, or Off.

The third face follows from the promise described in Agents: the agent only reads what you can see. A capability may not teach the agent anything in secret, so whatever it tells the agent is printed on its card.

The capability lifecycle

Every capability moves through the same four stages.

  1. Enable. Some capabilities are explicit switches. Others turn on when their configuration exists, the way setting availability enables Scheduling.
  2. Configure. Supply the settings the capability needs: hours, fields, destinations. Configuration is structured forms, never prompt text.
  3. Connect. A capability that acts through an external account, such as Google Calendar or Slack, needs a connection. Connections are made once for the whole workspace, at Workspace · Connections, and every agent in it can act through them.
  4. Ready. The capability's machinery runs and Playbooks can act through it.

A capability with incomplete configuration is never offered to the agent, so it fails visibly during setup rather than silently in a conversation.

Scheduling

Lets the agent offer real available times, then book, reschedule, and cancel calls with your representatives, in the person's time zone, with a calendar invite. The platform runs the machinery around it: reminders, day-of completion, double-booking guards, and a deterministic backstop that shows times even when the model falters.

You configure availability (business hours, blackout dates, call length, same-day policy) on the Hours & booking tab of Capabilities · Scheduling, and the representative directory on its Representatives tab: names, titles, phone numbers, and optionally a Google Calendar connection for each.

Representatives are part of scheduling's configuration. They are who the booked calls are with, and each Person can be assigned one. With none configured, booking still works and calls are scheduled with "someone from our team", but the capability reports that it needs attention and the per-representative features stay off: the rep card, tap-to-call, calendar sync, and the notification email.

Adds to what the agent reads: when to offer times, to confirm before booking, to cancel or reschedule only on a clear request, and the availability fetched for this turn.

Guide: Schedule calls.

People

Lets the agent remember the human it is talking to. One Person record per person, per agent, with contact details, the People fields you define, product interest reconciled against your Things catalog, funnel status, an assigned representative, and a journal of what the agent has learned. The record is in front of the agent on every turn.

You configure the field schema at Capabilities · People fields, and one switch: whether the agent may update People with what it learns. With the switch on, the agent saves facts as they come up naturally and never by interrogation. With it off, the agent reads but never writes.

Adds to what the agent reads: this person's record, and, when the switch is on, which fields it may fill and the rule about how to fill them.

Concept: People. Guide: Manage people.

Notifications

Lets the agent alert your team when something needs attention: a booked call, a request for a human, an event you choose. Alerts go to Slack or email. The agent's vocabulary never changes with the destination, so you can move alerts from one service to another without touching a Playbook.

You set the destination and sender on Capabilities · Notifications. Until you do, the capability is off and the agent cannot notify anyone, so it does not claim a teammate was told.

Secret values such as API keys, webhook URLs, and auth headers are write-only. They are stored encrypted, shown as set with a Replace action, and left out of an exported document. Changing the from-address never means re-entering the API key.

Adds to what the agent reads: which events it may raise, and the rule not to promise a human reply time.

Guide: Turn on capabilities.

Custom integrations

Lets the agent use an ability backed by your own HTTP endpoint: check an order, look up a membership, create a ticket. To the agent it is one more thing it can do, and you implement what happens.

You define each one on Capabilities · Custom integrations: a name, a description of when to use it written the way you would brief a new teammate, the inputs to gather from the conversation, and the endpoint the platform calls, with method, URL, and an optional write-only authentication header. When the agent decides the ability applies, the platform calls your service with the inputs, hands back the response, and the agent continues the turn.

An integration with no endpoint is not offered to the agent, so it can never promise something it cannot do.

Adds to what the agent reads: the name and when-to-use text you wrote, and nothing else.

Guide: Turn on capabilities.

What a Playbook uses

A Playbook declares the capabilities it acts through on the Playbooks page, under Needs: one chip per capability. In the portable document and the API this is the Playbook's uses list, with the ids scheduling, people, notify, and integration:<id>. Saving a Playbook that names a capability the agent does not have is refused.

Needs is explicit and required. Every Playbook lists exactly the capabilities it may act through, and an empty list means none. There is no fallback that grants everything: a Playbook naming nothing can talk and answer from Knowledge, and do nothing else.

Knowledge is never a Need. The agent searches it and reads its business info, Things, and Media in every Playbook, so naming it changes nothing, and the console leaves it out of the Needs picker.

Whether a Playbook's body and its declaration agree is a question of meaning rather than structure, so lint does not guess at it. A review is where "this Playbook talks about booking but does not use Scheduling" gets reported.

Readiness

Every capability answers one question the same way everywhere: is it ready? The Capabilities page, the readiness card, and the runtime all read the same answer from the same check.

When a Playbook uses a capability that is not ready, the Playbook can still be chosen. While it is active, the agent is told plainly that the capability is unavailable, so it says so and does not promise it. An agent with Scheduling switched off says "I can't book from here, but you can call the clinic at…" rather than offering times it cannot deliver. The Capabilities page and the readiness card name what is missing and link to the page that fixes it.

A capability that is ready but not named in the active Playbook's Needs is listed in the Behavior document under Other capabilities. The agent loads it when the person needs it and then uses it like any other, and the turn record shows that it did. What the agent has at hand is what the active Playbook uses, plus Knowledge. What it can reach is everything that is ready.

Capabilities in an exported agent

An exported agent carries capability configuration in its capabilities layer: scheduling settings and representatives, people fields, Things and collections, outreach settings, and custom integration contracts. It never carries connections, secrets, or data such as Sources and Person records. Those are per-agent and re-established after an import.

What's next