> ## 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. # TFU Live builder guidance > The canonical topic guidance retrieved by the TFU Live conversational builder. The TFU Live conversational builder has a read-only `read_authoring_guide` tool. With no topic it returns a short index. With a topic it returns that section's guidance and the relevant editor tools. The topic text below is generated from the same source the tool executes; it is not a separate prompt written for the documentation site. The builder also retrieves current capability schemas, configuration and connected resources on demand. Those depend on the agent and sub-account, so this page does not substitute a static example for live discovery. Customer backends use the discovery requests in [Build a TFU Live agent](/tfu-live/authoring). The topic index is `overview`, `editing`, `capabilities`, `campaigns` and `readiness`. Guidance grants no permissions. The authenticated executor still controls which actions the caller can perform. The internal builder's tool list includes operations that the customer API does not expose, such as starting a roleplay. This page documents guidance, not a public endpoint for calling those tools. ## overview Choose the part of the agent or campaign to change. * brain: Business identity, personality, knowledge and behaviour shared by calls and messages. * voice: Audio delivery and selected voice. * capabilities: Equipped abilities and their structured business configuration. * workflows: The agent’s abilities. Each workflow is one tool the AI calls: its name is the tool name, its description is when to call it, and its steps are nodes (Collect information, Conditions, actions, Transfer, appointments, webhooks) that run when it is called. * campaign: Triggers, caller numbers, calling window, timezone, concurrency and cadence. Read the topic relevant to the request; then read actual state before editing. Use existing editor tools, never infer public API access from this guide. ## editing Preserve existing content and save against the reviewed revision. * Change part of the Brain with edit\_prompt (exact passages, each found once); rewrite the whole Brain only when the whole script changes. Read the complete saved text before replacing it. Preserve unrelated instructions. * Use add for a missing configuration root; replace requires an existing path. Nested changes require the parent to exist. * The editor saves the working definition against its reviewed definitionHash. Dependent campaign writes first persist equipped tools; remaining edits save at the end of the turn. A stale version must be re-read; never force an overwrite. * Explicit drafts save without provisioning. A saved edit is not proof of runtime readiness. ## capabilities Discover supported business abilities and connected resources. * An agent’s abilities are workflows: a name (the AI’s tool name), a description (when the AI should run it) and steps built from nodes. There are no special workflows; every node can be used in any workflow. Read them with read\_workflows and change them with patch\_workflows. The equipped tools that stay tools are texting, earlier conversations and business playbooks (list\_capabilities). * A whole agent can start from a Brain template (read\_brain\_templates): appointment booking on one calendar, on several calendars chosen by one question, an inbound receptionist, or live transfer with booking as the fallback. Each already holds Schedule a callback and Stop contact. start\_from\_brain\_template builds it at once, replacing the agent’s workflows; its toFill values are optional (actual calendars and transfer destinations from find\_resources, and the operator’s answers, when known). A setting not given stays empty as a setup item: the agent can take a test call straight away, running it on test data, but is prepared and goes live only once every setup item is filled. Then replace the prompt’s \[bracketed] placeholders with the business facts. * Start from a template when one fits: Live transfer, Book appointment, Cancel appointment, Human assistance (a description only), Stop contact, Check tag, Add tag, Schedule a callback, Check service area. Fill its settings with actual tenant resources; never invent an ID. * Collect information is the only way the AI supplies inputs: its items become the workflow tool’s arguments, reuse a value on file unless reconfirm is on, and ask the caller for what is missing. A Condition or node reads collected.\ only after the Collect information node that gathers it, and response.\ only on the Success output of a Webhook with response that maps it. An unknown or empty value never matches a Condition case. * A node with outputs ends its list: the steps after it go on its outputs. Nodes that wait (conditions, checks, the transfer, webhooks, bookings, Steer the agent) finish before the AI gets its answer; tags and field changes update the call’s working copy at once; notes, messages and notifications run after the answer. The AI is never told a CRM save is done when only the working copy holds it. * Transfer: one destination per node (one number, one team, everyone on shift, one rep, the assigned rep, or the campaign transfer settings) and three outputs, Connected, Nobody available and Not connected. A call makes one transfer attempt; a fallback transfer goes only on Nobody available. After Connected the AI has left the call: only actions and Conditions there. * Appointments: Find slots offers times from one calendar, or from routing rules over collected answers (first match wins, an unknown answer is asked for, no default calendar: add a last rule with is\_set for a catch-all). Book appointment books the time chosen there, or moves the caller’s existing appointment, as its mode allows (book\_or\_move by default, book\_only, move\_only); Cancel appointment lists and cancels on its calendars. * Tags are never chosen by the AI: Check tag, Add tag and Remove tag each hold one tag. The current state says which CRM the sub-account uses: the native CRM has no tags, so never offer or build tag nodes there (they are refused). Put on DND ends the lead’s journey; nothing follows it. * Every new agent starts with Schedule a callback and Stop contact. Keep a way to stop contacting a lead: change those workflows rather than removing the only one that puts a lead on DND. * For an operator-supplied HTTP endpoint use a Webhook with response node. It sends the call context automatically (workflow, ids, contact, call) plus the fields the operator names: fixed text, a contact field, a call detail, or a collected value. Map response fields in resultMapping and use response.\ in Conditions and \{\{response.\}} in text. Authentication headers are secrets the operator enters in Brain; keep a saved one (\{secret:\{id}}) at the same step, sending to the same host, and never set or ask for its value in chat. Moving a saved secret to another step or host is refused: the operator must enter it again. * Read workflows before changing them. A Steer the agent reference suggests another workflow or tool without running it. Preflight uses the runtime validator and saving validates again; a refusal names its code, the workflow, the step and the setting. Saving never runs a workflow. * Use find\_resources for custom fields, pipelines, calendars, reps and teams. Saving checks the custom fields a step writes (Set field, a Collect information item saved to a field) and reads (a Condition case, Check zip code, a webhook contact field), the Move stage pipeline stage and the Find slots and Cancel appointment calendars. Slack main/alerts mapping remains runtime-owned; saving does not prove notification delivery. ## campaigns Change triggers, caller settings and follow-up timing. * For Power Dialer setup read the bound campaign and its cadence first. Report current values and ask missing business decisions one at a time: calling window, caller ID, simultaneous calls and follow-up timing. Equipping outreach tools does not configure these settings. Save only supplied decisions and report the specific saved settings, never blanket completion. * New agent creation automatically attaches a paused campaign and private cadence, including empty drafts. Configure its settings and Brain trigger; do not create another campaign. Existing unlinked agents are not automatically migrated. * Read campaigns bound to this profile; resolve ambiguity by business name. Current transfer recipients/numbers must come from these settings and resolved reps/teams, never Brain prose or the outgoing caller-number pool. * Transfer settings use the shared campaign config. Discover agency reps/teams by business name. For advancedRouting=true set transferRoutes and remove repId, transferTeamId, transferToAssignedUser and transferToAnyRep. For simple routing set advancedRouting=false, remove transferRoutes and choose exactly one routing mode. Keep the explicit fallback transferNumber. Existing representative membership is preserved; selected reps are added. Assigned-user routing requires imported CRM users; these authoring tools do not synchronize the roster. * Use find\_resources caller\_numbers or read\_campaign\_settings.availableCallerNumbers for From Number; both use the same agency-owned registry as Configure Myself. CRM messaging\_phone\_numbers is a separate source and its absence does not mean no calling numbers exist. Transport configuration alone does not prove ownership. * Read the campaign-bound cadence, not a tenant default. Preserve timing modifiers and action delays/jitter. * A missing cadence can be created from supplied business timing. An unreadable linked cadence must not be replaced. * Campaign and cadence edits use their existing shared services and are not a single atomic transaction with agent edits. * These tools cannot activate campaigns, rebind runtimes or enable split/master agents. ## readiness Distinguish saved drafts, verified revisions and activation. * Being ready for a roleplay is about what you know, judged when you write your Brain; it is not provisioning evidence. * Explicit draft creation and incremental saves do not create provider agents. A requested roleplay provisions the saved revision and waits for bounded verification. * A roleplay must use the exact saved hash with no pending revision. Failure or timeout leaves the draft available and does not promise a later automatic start. * Provider setup may be blocked or uncertain. Refresh and inspect the failure before retrying; do not report success from HTTP acceptance alone. * A roleplay does not activate a campaign. Go Live is a separate explicit action with factual calling gates. * Split/master are unavailable until shared capabilities, verified family revisions and dispatch enforcement are implemented. ## going\_live Connect GoHighLevel, move onto it, set up the calling line and go live. * The rep leads, once the operator is happy with the roleplay: one question at a time, waiting after each. When a tool gives a line, that line is the whole reply, word for word; the lines are the owner's approved ones, with only their brackets filled. * Going live needs GoHighLevel for now. A rep already on a GoHighLevel sub account skips the CRM question and the move. On TFU AI's own CRM, crm\_status asks the CRM question; connect\_crm takes the answer: the Connect GoHighLevel button appears on the operator's screen and opens in a new tab. No link ever passes through the rep. * The rep notices the install by itself and never asks whether it is done. Several approved sub accounts are a choice: the rep asks which one it is for. A full plan, a failed or unconfirmed install and a disconnected sub account are said plainly. * move\_to\_crm runs only on the operator's yes. The rep keeps its Brain, Voice, name and workflows; its calendars, tags and fields are cleared to be filled again from GoHighLevel, one question at a time. Contacts, appointments, calls and the old sub account stay where they were. * check\_go\_live lists everything left at once, and the rep clears it one thing at a time: its own settings, prepare\_for\_calls, the calling line and the test call. A step the operator does themselves is said as such, and its page is opened (or a button to it put on screen when the browser blocks the tab). * The test call rings a real phone and is charged at the normal call rate: the rep asks which phone to ring, offering the one on the operator's account, and says to pick up. Its result arrives by itself. * go\_live is the only way the campaign goes live from the builder: patch\_campaign\_settings never sets isActive. It redeems the go-live question asked the turn before, with the operator's own answer, read by the application: only a plain yes counts, and a line said in a roleplay never does. The server checks readiness again as it switches the campaign on. ## Public operation support These states come from the same registry as the request guards. Paths are relative to one TFU Live agent. Runtime support does not grant scopes or establish readiness. | Operation | Runtime support | | - | - | | GET / | supported | | POST, PATCH / | supported | | GET /operations | supported | | GET /brain/catalog | supported | | POST /prepare | supported | | POST /restore | supported | | PUT /orb | supported | | GET, POST, PUT, DELETE /workflows | supported | | GET /resources | supported | | GET, PATCH /outcome-prompts | not\_applicable | | PATCH /post-call-field | not\_applicable | | GET, PUT, PATCH, POST, DELETE /campaign/workflow | not\_applicable | | GET, POST, PATCH, DELETE /split-test | not\_implemented | | GET, POST /campaign/master | not\_implemented | | GET, POST, PUT, PATCH, DELETE /skills | not\_implemented | | GET, PATCH /tools | not\_implemented | ## In the API Customer backends use [Create agent](/api-reference/tfu-live/create-tfu-live-agent), [Get agent](/api-reference/tfu-live/get-tfu-live-agent) and [Update agent](/api-reference/tfu-live/update-tfu-live-agent) with the [TFU Live contract](/tfu-live/authoring). See the [Agent glossary](/glossary#agents). ## Related * [Build a TFU Live agent](/tfu-live/authoring) * [Authentication](/authentication)