Skip to main content
An agent bot is Tied’s oldest integration point for outside automation, and it is a genuinely different thing from the AI agent described elsewhere in these docs — worth being precise about, since the two get confused constantly.

​
What it is

An agent bot is a name, an outgoing webhook URL, a configuration blob, and an access token it uses to call Tied’s own API back. You host the logic; Tied hands it events and lets it act through the token. Registering a bot against an inbox is its own record, separate from the bot itself, with an active or inactive switch — so a bot can be wired to an inbox and then switched off without deleting the registration or the bot. Today there is exactly one transport: webhook.

​
What the bot receives

There is no status gate. Tied sends the bot’s webhook events for any conversation in its inbox, whatever that conversation’s status — open, pending, snoozed or resolved: conversation_created, conversation_opened, conversation_resolved, message_created, message_updated, and webwidget_triggered. The only filter is on message type — incoming, outgoing and template messages are sent; activity messages are not.
Private notes are sent to the bot’s webhook. Tied stores a private note as an outgoing message, and the type filter above has no separate public/private check — so anything your team writes in a private note on a conversation with an active agent bot leaves your system exactly as a reply to the customer would. Treat the webhook endpoint as seeing the whole thread, not just the parts the customer sees.

​
How the bot acts back

This is fire-and-forget. Tied sends the webhook and ignores whatever comes back in the response body — there is no reply payload for the bot to speak through. Instead, it acts by calling Tied’s API directly with its own access token: reopening a conversation and routing it into ordinary assignment, resolving it outright, replying, relabeling, whatever the API allows.
A reply carrying a structured “hand off” or “resolve” directive is a Dialogflow-integration pattern, not a webhook agent bot’s. An agent bot’s webhook response is not read at all, so there is no directive for it to send back — everything it does, it does by calling the API.

​
How this differs from a Tied AI agent

An agent bot is bring-your-own-logic. Tied does not know what runs inside the webhook, does not run it, and does not price it — it does not participate in the resolution-based pricing described in Pricing, which is built specifically around the AI agent Tied itself runs.
The AI agent is native; an agent bot is a guest. AI agents covers what Tied’s own agent can do — answering from knowledge, reading your systems, acting in them — and how that maps to a billable resolution. An agent bot has none of that structure. From Tied’s side, it is simply another source of messages and status changes carrying an API token.
Reach for an agent bot when you already have a bot investment — an existing flow engine, a system you run yourself — that you want inside the same inbox. Reach for the AI agent when you want the capability in AI agents without hosting anything.

​
Next

AI agents

What Tied’s own agent can do, and how it is priced.

Automation rules

The event-driven alternative that needs no webhook at all.