Product · Workflows and tools
Draw the steps an agent must follow, connect it to your own systems, and decide what makes it reach out. Everything you build here compiles into the same artefact as everything else, so it is tested as the exact version that goes live.
A workflow is a graph your team draws. It compiles to the procedure the agent must follow and the places it is allowed to stop. The model still chooses the words, so the conversation stays a conversation.
This is why a no-code builder is safe here. The output is an ordinary instruction section, so it gets a content hash, runs through simulation in every country you operate in, and is pinned by the release gate exactly like a policy somebody wrote by hand.
A tool is your API, described so the agent knows when to reach for it. You give it a shape and a set of promises about what it does. This is what a tool definition holds.
A tool version is immutable once written. Editing saves the next version, and the live release keeps the one it was tested against until somebody compiles again. Private and internal hosts are refused when you define the tool, not when it fires.
Called the moment a customer says stop. Final, and it applies to every channel at once.
Creates the record with an owner, a deadline and one line saying what the customer needs.
Looks up your own material and quotes from it. Never invents an answer it could not find.
Confirms who is on the line before anything sensitive happens.
Turns “someone will get back to you” into a row with a name and a clock on it.
Books the time, and the outbound agent keeps it. The watchdog holds both to it.
Your system posts to one endpoint and the trigger decides whether it is worth a call. A webhook, a stage change in your CRM, or the outcome of an inbound conversation.
Event driven. It waits rather than scans, so the customer is contacted while the thing that happened is still true.
A cadence you set goes looking: a customer who went quiet, a renewal approaching, an attribute rule that now matches, or simply a schedule.
Scheduled. A hand-picked audience is not a trigger, it is a batch campaign with a segment, which is its own thing.
You see who would be contacted and why, with the attrition report, before the campaign is allowed to start.
Consent, calling window, suppression and frequency are checked per attempt. A campaign cannot vote itself an exception.
A running campaign can be paused, resumed or stopped, and what is already scheduled obeys immediately rather than draining first.
The systems your team already lives in, connected once and pinned to a release like everything else. Anything not on this list speaks HTTP, which is all a tool needs.
CRM, helpdesk, commerce, billing
Read the order, the ticket or the subscription mid-conversation, and write back what happened when it ends.
Slack, Teams, calendars
An escalation lands where the named owner will see it, with the deadline attached and the record one click away.
Webhooks, CRM stage changes, event streams
Your system posts once and the trigger decides whether it is worth a call. Nothing polls your database.
Your own API
Define it as a tool with a schema and a timeout. It is live in the next release, tested with everything else.
No, and that is deliberate. The graph compiles to the procedure and the stopping points, not to a state machine the runtime steps through. The model still decides how to say things, so a customer who asks something unexpected gets an answer instead of a dead end.
The same thing that stops a broken policy. The compiled workflow is part of the artefact, it gets a hash, and it cannot go live until a simulation of exactly that version passes in every country you operate in.
On the tool definition, resolved at call time, and never written into the compiled artefact. That is why rotating a secret does not force you to recompile and re-test an agent.
Then you define it as a tool, which takes a URL, a schema and about an afternoon. The prebuilt connectors are a shortcut for the common systems, not a boundary. Nothing about a custom tool is second class: it passes the same gate and gets pinned to the same release.
One endpoint. Your system posts a signal, the trigger matches it against its criteria, and a contact is scheduled if the contact decision allows one. Nothing polls your database.