> ## 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, campaigns, projects (GoHighLevel sub-accounts), contacts, calls, outcomes, skills, cadences, phone numbers.
> Scope requests by locationId rather than projectName.
> Read the guide linked from each API reference group before recommending an endpoint.

# Master agent

> One agent and one campaign, running across many sub accounts at once. You edit the parent, and every linked project gets the change. Each project keeps its own calendar, pipeline and phone number.

A master agent is one agent and one campaign that run across **many sub
accounts at once**.

The builder calls this a **master agent**. It shares a campaign across projects;
the ordinary [Campaigns](/campaigns/overview) guides still explain its script,
triggers and workflows.

You build it once. Every project you link to it gets its own working copy. When
you edit the parent, the change reaches all of them.

<Info>
  This is the tool for running the same offer across many locations: a franchise
  with forty branches, an agency running one proven campaign for thirty clients.
  If you only have one sub account, you want a normal campaign.
</Info>

## The one idea that makes it work

Every linked project has a **real campaign of its own**. A master agent is not a
template you copy once and then maintain in forty places. The children stay
connected to the parent for as long as they are linked.

That leaves one question, and it is the whole design:

<Steps>
  <Step title="Some things must be identical everywhere">
    The script, the call flow, the tag names, the retry cadence, what happens
    after the call. If these differed per project, you would not have one
    campaign, you would have forty.
  </Step>

  <Step title="Some things cannot possibly be identical">
    The calendar it books onto. The pipeline stage it moves people to. The
    number it transfers to. Every sub account owns its own, and they are
    different records with different IDs.
  </Step>
</Steps>

The first kind syncs from the parent. The second kind is set per project. The
system calls the second kind **bindings**, and getting them connected is the
only real work of setting a master agent up.

See [what syncs and what stays local](/campaigns/master-agent/what-syncs) for
the full split, and [connecting a project's own
assets](/campaigns/master-agent/bindings) for how bindings get filled in.

## What you actually do

<Steps>
  <Step title="Build the parent like any other campaign">
    Script, audience, calling window, post-call actions. Nothing special.
  </Step>

  <Step title="Link the projects">
    Each one gets a child campaign, and the system tries to connect that
    project's own calendar and pipeline automatically by name.
  </Step>

  <Step title="Fix whatever it could not match">
    Anything it could not connect confidently is reported rather than guessed.
    A child cannot go live until its bindings are sorted.
  </Step>

  <Step title="From then on, edit the parent">
    Every save fans out to the children in the background.
  </Step>
</Steps>

## Where it lives

Linking projects to a master agent happens in the **Settings tab**, and the
setup state for each linked project is shown in **Project Manager**.

## The failure this design prevents

If a local calendar ID were allowed to sync from the parent, every linked
project would start booking into **one sub account's calendar**. Forty clients'
appointments landing in one calendar, silently, and looking fine until someone
checks.

<img className="block dark:hidden" src="https://mintcdn.com/teamfollowupai/QX4GFVxyRVTtiDDs/images/master-agent/one-calendar-light.gif?s=1f1d104a8d55679c122a28fe88107f44" alt="Three clients each book one appointment. If the calendar were copied from the master, all three bookings would land in Oak's calendar, the sub-account the master lives in, and Peak and Bay would get none. Because each keeps its own, every client gets its own booking." width="1000" height="400" data-path="images/master-agent/one-calendar-light.gif" />

<img className="hidden dark:block" src="https://mintcdn.com/teamfollowupai/QX4GFVxyRVTtiDDs/images/master-agent/one-calendar-dark.gif?s=08ecbb6e73cdc1c9b27ca0a8418a4c6a" alt="Three clients each book one appointment. If the calendar were copied from the master, all three bookings would land in Oak's calendar, the sub-account the master lives in, and Peak and Bay would get none. Because each keeps its own, every client gets its own booking." width="1000" height="400" data-path="images/master-agent/one-calendar-dark.gif" />

That is why bindings are never inherited, and why a project with an unresolved
binding is blocked from going live rather than allowed to run and be wrong.

## In the API

* [Update campaign](/api-reference/campaigns/update-campaign) with `masterCampaignEnabled: true` makes a campaign the parent
* [Link a project to this master agent](/api-reference/master-agent/link-a-project-to-this-master-agent) adds a child
* [Get master agent state](/api-reference/master-agent/get-master-agent-state) shows every linked project
* [Master Agent](/master-agent/overview) is the field-level reference, and [Rolling out a change](/campaigns/master-agent/rolling-out-changes) explains the timing