> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tied.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent bots

> Registering a bot against an inbox.

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.

<Warning>
  **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.
</Warning>

## 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.

<Info>
  **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.
</Info>

## 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](/pricing), which is built specifically around the AI agent Tied itself runs.

<Info>
  **The AI agent is native; an agent bot is a guest.** [AI agents](/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.
</Info>

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](/agents) without hosting anything.

## Next

<CardGroup cols={2}>
  <Card title="AI agents" icon="bot" href="/agents">
    What Tied's own agent can do, and how it is priced.
  </Card>

  <Card title="Automation rules" icon="workflow" href="/automation">
    The event-driven alternative that needs no webhook at all.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.