Capabilities¶
Preview
Framework v2 is not yet available to all accounts.
A capability is something the agent can do beyond talking. You do not write capabilities; you switch them on, configure them, and connect any account they need. Every capability, built in or custom, has 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 settings page. |
| What it adds to what the agent reads | A short read-only text on its card: the how-and-when guidance the agent gets while a Playbook uses it. |
| Whether it is ready | Its status: Ready, Needs attention, or Off. |
The third face is the one v2 adds. Under the one promise (the agent only reads what you can see), a capability may not teach the agent anything in secret. Whatever it tells the agent is printed on its card. The five capabilities below share one rule for readiness, described at the end. Outreach, the agent starting a conversation, works as it does today and is described in Reaching Out to People.
Scheduling¶
Lets the agent offer real available times, book, reschedule, and cancel calls with your representatives, in the person's time zone, with a calendar invite. Reminders and day-of follow-up run on the platform.
You configure availability (hours, blackout dates, call length, same-day policy) at Settings · Scheduling and the representatives at Settings · Representatives, optionally with a Google Calendar connection each.
Adds to what the agent reads: when to offer times, to confirm before booking, and to cancel or reschedule only on a clear ask; plus, each turn, the availability it fetched.
Mia uses Scheduling in Book a consultation call.
Knowledge¶
Lets the agent answer from your documents (uploaded or imported from your website) and present your product catalog. Documents are searched each turn for the passages that match what the person said; products can be shown as cards and recorded as interest on the Person record.
You manage documents and products in the agent's Knowledge area. Knowledge is on when content is present.
Adds to what the agent reads: a summary of the catalog when it is small enough to carry, otherwise a way to search it; the passages found for this turn; and the instruction to answer from them and not to name internal files.
Mia uses Knowledge in Answer treatment questions: the treatment pages from glowaesthetics.com and a catalog of eight treatments.
People¶
Lets the agent remember the person it is talking to: one Person record per person, with contact details, the People fields you define, product interest, funnel status, and an assigned representative. If you allow it, the agent saves what it learns as it comes up.
You configure the fields at Settings · People fields and one switch: whether the agent may update People with what it learns.
Adds to what the agent reads: this person's record, and (when the switch is on) which fields it may fill in and the rule to fill them from conversation, never by interrogation.
Mia uses People in Qualify (fills in treatment interest and timeframe) and in Book a consultation call (name and email are already known and are not asked again).
Notifications¶
Lets the agent alert your team when something happens: a call booked, a person asking for a human, an event you choose. Alerts go to Slack or email; you can change where they land without touching the Brief.
You configure connections at Settings · Tools & connections.
Adds to what the agent reads: which events it may raise and the rule not to promise a human reply time.
Mia uses Notifications in Talk to a person: the Glow front desk gets a Slack message with the person's name and question.
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; you implement what happens.
You define each one at Settings · Custom integrations: a name, when to use it (written the way you would brief a new teammate), the inputs to gather, and the endpoint with an optional write-only auth header.
Adds to what the agent reads: exactly the name and when-to-use text you wrote. Nothing else.
Mia has none today. A membership lookup would be one.
When a capability is not ready¶
Every capability answers one question the same way everywhere: is it ready? The answer you see on the Capabilities page, the answer the readiness card gives, and the answer the runtime uses on a turn are the same answer, from the same check.
When a Playbook uses a capability that is not ready:
- The Playbook is not a candidate on any turn. Anychat will not enter it.
- If that Playbook is the default, the turn still runs, and the agent is told plainly that the capability is unavailable, so it says so and does not promise it. Mia with Scheduling switched off says "I can't book from here, but you can call the clinic at…" rather than offering times she cannot deliver.
- The Capabilities page and the readiness card say what is missing and link to the page that fixes it.
A capability that is ready but not named in the active Playbook's
uses is not offered on that turn either. What the agent can do at any
moment is the intersection of what is ready and what the active
Playbook uses.
Declaring what a Playbook uses¶
You declare a Playbook's capabilities on the Playbooks page, under
Uses capabilities: one chip per capability (Scheduling, Knowledge,
People, Notifications, and each custom integration by name). In the
portable document and the API this is the Playbook's uses list, with
the ids scheduling, knowledge, people, notify, and
integration:<id> for a custom integration. Saving a Playbook that
names a capability the agent does not have is refused.
A Playbook with no declaration is not broken. It gets every capability
that is ready, so an agent switched to v2 before its Playbooks were
annotated keeps working. The cost is precision: such a Playbook can do
anything, and lint cannot tell you whether its body and its reach
agree. Lint therefore reads the body and suggests the list to declare
("Book a consultation call draws on Scheduling and People but declares
no capabilities"); the finding appears on the Readiness card with a
one-click Declare fix that saves the suggested list. Once declared,
the two-way check takes over: a body that talks about booking without
Scheduling in uses is a warning, and a declared capability the body
never draws on is a note.
Mia's Qualify was saved with no uses. The Readiness card offered
Declare People; after one click, Qualify may fill in People fields
and nothing else, which is what its body describes.
On the Generic runtime the same chips are shown and saved, and lint validates the ids, but the runtime does not read them.