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

> ## Agent Instructions
> Use the public API base URL: https://api.teamfollowup.ai/api.
> Authenticate public API requests with Authorization: Bearer YOUR_API_KEY.
> Use product-owned terms: agents, calls, campaigns, contacts, phone numbers, billing, and configuration.

# Campaign types and capabilities

> Two choices make an agent: what starts the call, and what the agent can do on it.

Every agent is built from two decisions, and they are independent.

1. **The campaign type** decides *what starts the call*. There are three.
2. **Its capabilities** decide *what the agent can do* once the call is live. You
   pick one or more.

Type first, then capabilities. The type is fixed once the agent exists; the
capabilities you can add and remove whenever you like.

## The three campaign types

| What starts the call                        | Type         | Send this     |
| ------------------------------------------- | ------------ | ------------- |
| A tag lands on the contact in your CRM      | **Outreach** | `outreach`    |
| Someone rings your number                   | **Inbound**  | `inbound`     |
| An appointment gets booked on your calendar | **Reminder** | `appointment` |

The third column is the value the API expects as `agentType`. Clicking around
the dashboard, you can ignore it, the picker sends it for you. These three are
the only accepted values.

## The capabilities

A capability is one thing the agent can do on a call. Adding one is not just a
prompt line: it installs the tool the agent calls, the fields it fills in
afterwards, the route your campaign takes when it happens, and the setting it
needs before it can run. All at once, or not at all.

| Capability                                      | What the agent can do                                                                        | Needs                |
| ----------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------- |
| **Appointment Booking** (`appointment_booking`) | Offer real open times and book the one the lead accepts                                      | A calendar           |
| **Live Transfer** (`live_transfer`)             | Warm-transfer the caller to a person, with a spoken intro                                    | A destination number |
| **Add Tag** (`add_tag`)                         | Tag the lead in your CRM mid call, so your automations fire while the agent is still talking | At least one tag     |

Outreach and Inbound need at least one capability to start. Reminder always
starts with Appointment Booking, because rescheduling is the job.

Stack them freely. An Outreach agent with **Live Transfer** and **Add Tag** can
do both on the same call.

## Capabilities decide which outcomes exist

This is the part worth internalising. A call can only end in an outcome its
capabilities allow:

* **Transfer** is only a possible outcome when Live Transfer is installed.
* **Booked** and **Rescheduled** are only possible when Appointment Booking is
  installed.

Remove a capability and its outcome disappears from the campaign along with it.
So the set you pick is not decoration, it is the shape of everything downstream.
See [What your agent records](/agents/outcomes).

<Note>
  Capabilities are things the agent **can** do, not a ranked fallback chain. The
  agent does not try one and fall back to the next in a fixed order; it uses
  whichever fits the moment, guided by your prompt. If you want transfer
  attempted before booking, say so in the [prompt](/agents/prompt).
</Note>

## Creating one through the API

Send the type and the capabilities together:

```json theme={"dark"}
POST /api/agent-builder/agents
{
  "locationId": "loc_abc123",
  "name": "Roofing Follow Up",
  "agentType": "outreach",
  "capabilityIds": ["live_transfer", "add_tag"]
}
```

`GET /api/agent-builder/agent-types` returns the three types, each listing the
capabilities you can start it with.

## If you integrated before this

Older integrations sent a single combined id, like `live_transfer_and_tag`, as
`system`. Those seven ids were shorthand for the type-and-capability pairs that
happened to be common:

| Old id                      | Type     | Capabilities                        |
| --------------------------- | -------- | ----------------------------------- |
| `appointment_booking`       | Outreach | Appointment Booking                 |
| `live_transfer`             | Outreach | Live Transfer                       |
| `add_tag`                   | Outreach | Add Tag                             |
| `live_transfer_and_tag`     | Outreach | Live Transfer + Add Tag             |
| `live_transfer_and_booking` | Outreach | Live Transfer + Appointment Booking |
| `appointment_confirmation`  | Reminder | Appointment Booking                 |
| `inbound_receptionist`      | Inbound  | Appointment Booking + Live Transfer |

Sending `system` on its own still works, so nothing you built has broken. It is
the narrower way to ask, though: those seven are the only combinations it can
express, while type-plus-capabilities covers every combination. Send `agentType`
and `capabilityIds` for anything new.

<Note>
  You may still see one of the seven ids on a campaign, in the `system` field.
  It records which template the agent was built from, not what it can do. On an
  agent created with several capabilities it only names the first one, so read
  the capability list, not this.
</Note>

## Do / Don't

* **Do** pick the type by what triggers the call, not by what you want out of it.
* **Do** add a capability when you genuinely want the agent doing that thing.
  Every one you add is another thing the agent can reach for mid call.
* **Don't** stack capabilities that pull the call in different directions. A
  caller can feel an agent chasing three things at once.
* **Don't** rely on `system` to tell you what an agent does. Read its
  capabilities.