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

# What your agent records

> After every call, the agent decides what happened and writes down the useful details. That record is what powers your follow up.

Every call leaves behind a small record, and it is the most useful thing the call
produces. That record has two parts: the **outcome** (what happened) and the
**details** (the facts worth keeping). Get both right and every follow up
downstream gets sharper.

## The outcome: what happened

The agent sorts each call into one clear result. Did they book? Ask for a
callback? Ask you to stop calling? This one word summary is called the
**outcome**, and it's how the campaign knows what to do next (see
[After the call](/campaigns/after-the-call)).

Some outcomes are decided for you and always work the same way. A handful are
yours to describe in your own words, so the agent knows exactly what each one
means for your business:

* **Asked for info.** The person wanted details sent over, not a booking yet.
* **Callback.** They asked to be reached at a better time.
* **Needs a human.** Something came up that a person on your team should handle.
* **Opt out.** They asked not to be contacted again. The agent respects this.

For each of these, you write a short line telling the agent when it applies. Plain
language is best: "Opt out means the person clearly asked us to stop calling."

### Your capabilities decide which outcomes exist

Not every outcome is available to every agent. The ones that describe something
the agent *did* only exist when the agent can actually do it:

| Outcome                     | Only exists when                 |
| --------------------------- | -------------------------------- |
| **Transfer**                | Live Transfer is installed       |
| **Booked**, **Rescheduled** | Appointment Booking is installed |

The rest, callback, opt out, needs a human, voicemail, and so on, are always
available, because they describe the call rather than the agent's action.

Add a capability and its outcome appears. Remove it and the outcome goes with
it, along with whatever your campaign had routed off it. So it is worth settling
the [capabilities](/agents/agent-types) before you build out the follow-up.

## The details: your AI-generated fields

Beyond the outcome, the agent can pull specific facts out of the call. These are
your **AI-generated fields**: the agent generates each one from what was actually
said. It always saves the basics, like a short summary, and on top of that you can
ask it to grab whatever else you care about.

You add an AI-generated field by describing it in plain English:

* A name for it (like "roof age").
* What kind of answer it is: text, a number, yes/no, or one from a list.
* What the agent should listen for ("the age of the roof in years").

The agent then fills it in from the conversation, when it comes up. It's like
handing the agent a small form to complete after each call.

### Signals: the yes/no ones

A yes/no field has its own name: a **signal**. Signals are the ones your campaign
can act on. "Wants a callback" flips to yes, and a follow up fires. Think of a
signal as a switch the rest of your campaign can wire into, so a plain fact from
the call turns into an action (see [After the call](/campaigns/after-the-call)).

<Note>
  When you update your agent later, your own signals and AI-generated fields are
  the only ones that change. The standard, system managed ones are always kept
  safe, even if you don't mention them.
</Note>

<Note>
  A few fields belong to a [capability](/agents/agent-types) rather than to you:
  the booking time and the booked signal come with Appointment Booking, the
  failed-transfer signal with Live Transfer. You can reword what the agent
  listens for, but you cannot delete one or change its type while the capability
  is installed, and trying to will come back as an error. Remove the capability
  and its fields go with it.
</Note>

## Why this matters

The record is the bridge between the call and everything after it. A clean outcome
plus a few good fields means your follow up can be sharp: text the people who
asked for info, leave alone the ones who opted out, and flag the ones who need a
human. Garbage in, garbage out, so it's worth describing your outcomes and fields
clearly.