Skip to main content
Capabilities are what your genie can do — not just what it already knows, but what it can go check or act on. Think “what’s the status of my order,” or “do you have this in a size 10,” answered with the real, current answer instead of a guess. A capability can trigger during a call or after one ends, and both are built in the same editor. This page covers everything in that editor, field by field.
Capabilities editor showing a multi-step chain with executor types and on-failure settings

The two kinds of capability

Every capability is either:
  • During a call — the genie can call this mid-conversation, live, while the caller is on the line.
  • After a call — runs automatically the moment a call ends, no genie decision involved.
You choose this once, when you name the capability, and it shapes what else you can configure:
  • A during-call capability must have an input schema — the list of pieces of information the genie needs to fill in before it can call this capability (for example, an order number or an email address). Each piece needs its own plain-language description, since that’s what the genie reads to decide what to ask the caller for.
  • An after-call capability skips the input schema entirely — there’s no caller to ask anything of anymore, so it works from whatever the call itself produced (the transcript, the outcome, who called).
During-call capabilities also carry a speed requirement — see Speed matters below.

Name and description

  • Name — keep it short and function-like. This is what the genie sees when deciding whether this capability is the right one to reach for.
  • Description — write this in plain language, and be specific. This is the single biggest driver of whether your genie calls the right capability at the right moment — a vague description gets skipped or misused.
The description also seeds the Redesign feature (see below), so a good description pays off twice.

Building the step chain

A capability is a chain of one or more steps, run strictly in order — top to bottom, no branching. Each step has:
  1. A label — just for you, to keep the chain readable.
  2. An executor type — what this step actually does (see the five types below).
  3. An on-failure behavior — Abort (stop the whole chain right here) or Continue (move to the next step anyway). Pick Continue for steps that are “nice to have” but shouldn’t block the rest of the chain; pick Abort for anything later steps depend on.
  4. An optional output key — a name you give this step’s result so a later step in the same chain can reference it. Leave it blank if nothing downstream needs this step’s output.
Add as many steps as the task needs. A simple capability might be one step; a “look up the customer, then check their order, then draft a reply” capability is three.

The five executor types

Every step is one of these five.

Smart analysis

Hands text to Sync to interpret, summarize, extract structured information from, or reason over. Useful as a step that reads what an earlier step found and turns it into something usable by the steps after it (or by the genie). If this step defines a gate field — a true/false field in its own output — the chain checks that field after the step runs: if it comes back false, the whole chain stops here, even if this step’s own on-failure setting is “Continue.” Use a gate field when a later step should only run under a condition only this step can determine (for example, “only proceed if the caller’s request is clearly a cancellation”).

HTTP request

Calls any address on the internet directly — a method (GET, POST, PUT, PATCH, or DELETE), the address to call, whatever headers it needs, and a request body if the method sends one. Use this for services that don’t have a saved connection, or for one-off calls you don’t want to wire up as a full connection.

Connected service

The same idea as an HTTP request, but routed through one of your saved connections instead of a raw address — so credentials are already handled, and you just pick which connection and which part of that service to call. This is the step type to reach for whenever the system you need is already connected.

Send email

Sends an email: a recipient, a subject line, and the body content. The body can be built from simple content blocks (a heading, a paragraph, a bulleted list, a table) instead of raw text, and you can attach files or set a logo for the email header.
Be aware when testing this step type: running a test genuinely sends the email. There’s no dry-run mode.

Generate document

Produces a downloadable file — CSV, plain text, or PDF — with a file name you choose. For CSV and PDF you provide the column headers and rows; for plain text you provide the text content directly.

Passing information between steps

Later steps can use what earlier steps found. Give a step an output key, and any step further down the chain can pull that value into its own configuration — so, for example, a “look up the customer” step’s result can feed directly into the “send confirmation email” step’s recipient field, without you re-typing anything.

Speed matters (during-call capabilities)

A during-call capability runs while someone is on the phone waiting for an answer — so it has a strict 400-millisecond response budget. If a capability is consistently slow, you’ll see that reflected in its activity log; it’s usually a sign the system it depends on is responding too slowly, not a problem with the capability’s own configuration. This limit doesn’t apply to after-call capabilities, since the call has already ended by the time those run.

What Sync does — and doesn’t — decide

For during-call capabilities specifically: Sync’s job is to fetch or return data, not to reason over it or decide what to say next. The genie itself, not the capability, is what interprets the result and decides how to respond to the caller. Keep that in mind when writing a capability’s description and output — the clearer and more literal the data you hand back, the better the genie can use it.

Testing a capability

Every capability has a Test button once it has at least one step. Testing a during-call capability lets you fill in sample values for whatever the input schema asks for (anything left blank falls back to a generic placeholder) and runs the real chain — not a preview. Testing an after-call capability runs the real chain as if a call had just ended, and is billed and logged exactly like a live call would be; if the chain includes a Send email step, you’ll be warned before the test actually sends one.
Some tests complete immediately and show you each step’s result right there. Others are dispatched as a real background run — in that case you’ll get a toast with an execution id, and you can find the full result in the Activity log.

Letting Sync build the chain for you

Instead of adding steps by hand, you can click Redesign and let Sync generate the whole step chain from your capability’s name and description (plus any connections it can see you already use).
This replaces your current steps entirely — it’s destructive, and you’ll be asked to confirm before it runs.
The generated chain may come back with a few blanks it couldn’t fill in on its own — for example, a URL only you would know. Those are called out explicitly so you can fill them in before saving; the capability won’t work correctly until you do.

Turning capabilities on and off

Every genie’s During and After tabs list its assigned capabilities with a simple on/off switch — no need to rebuild or delete anything to temporarily disable one. A capability can also be assigned to more than one genie at once, and each genie’s toggle is independent.

Deleting a capability

Delete tool on a capability’s page is permanent and immediate: any genie using it loses access to it right away, and there’s no undo. If you just want to pause it, use the on/off toggle on the genie’s page instead.