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

# Building a guide

> Write the instructions, attach the tools it reads with, set up its channels, and publish.

A guide is built on one page. Go to **Guides** and create a new guide; the **Design** tab is a single scroll — Instructions, Guardrails, Channels, Tools, Knowledge — and everything funnels up to the instructions. There is no Save button: edits autosave as you type, and **Publish** is the only explicit commit.

<Frame>
  <img src="https://mintcdn.com/threadsolutionsinc/zrnqSMRcQ5MGUbqN/images/screenshots/guides/guide-editor.png?fit=max&auto=format&n=zrnqSMRcQ5MGUbqN&q=85&s=e2daba4382a5b356d5e18d5160526307" alt="Guide editor Design tab: plain-English instructions, locked guardrail pills, texting/email/call channel rows, a connected HubSpot tool row, and knowledge files" width="3200" height="2000" data-path="images/screenshots/guides/guide-editor.png" />
</Frame>

## Write the instructions

The instructions are one plain-text box. No syntax, no variables, nothing to remember — you are writing for a capable agent in your own words. Cover:

* **The outcome** — what this guide exists to get done, for one person.
* **What done means** — one sentence that defines done and names the evidence that shows it. This is the definition the close is held to: *"Done means Profit Assist shows connected on their HubSpot record."* The done sentence lives here, in your words — no tool owns it.
* **Tone and voice** — who the guide speaks as and how it should sound.
* **Cadence** — how patient to be, when to nudge, when silence is the right move, and any deadline that matters.
* **When to bring a human in** — the situations where the guide should page you instead of pressing on.

Don't restate what the attached tools do — each tool's row already tells the guide what it sees and when to use it. The instructions carry judgment; the tools carry mechanics.

## Guardrails

The Guardrails row shows the locked floor every guide carries — consent before the first text, recipient-local quiet hours, instant STOP, never verifies its own work, pages you when stuck — plus any rules your org adds. Add your own with the **Add** pill; the floor itself cannot be edited or removed. See [Compliance](/guides/compliance).

## Set up channels

Channels are configured in place on the Design tab. Each row shows its live state as a chip, and a channel that looks armed but cannot deliver will always say what's actually wrong.

<Steps>
  <Step title="Texting">
    Pick the number the guide texts from and wakes on. The row shows the number and its readiness; if your org's texting registration is still pending with the carriers, a status line under the row says so. See [Phone and registration](/admin-guide/phone-and-registration).
  </Step>

  <Step title="Email (optional)">
    The guide emails **as a real person on your team** — pick the sender, who connects their own mailbox. Replies come back on your org's verified reply domain, which an admin sets up once, inline, and every later guide inherits. The row earns **EMAIL READY** only when both halves can round-trip. See [Email domain](/admin-guide/email-domain).
  </Step>

  <Step title="Phone calls (optional)">
    Pick a published voice agent from [Voice Studio](/guides/voice-studio/building-voice-agents) and the number it calls from. The guide calls when it judges a call would move the outcome — unless you switch on **Ask me before dialing**, which makes it propose the call, page you, and wait for your tap on each dial. Either way the same gates run before the phone rings. See [Calls and approvals](/guides/voice-studio/calls-and-approvals).
  </Step>
</Steps>

<Note>
  Texting is the most mature channel. Email and voice are newer — rehearse them before putting them in front of customers, and see [Channels](/guides/channels) for per-channel behavior including STOP and quiet hours.
</Note>

## Attach tools

Tools are the guide's eyes — every one is **read-only**, and every read lands in the conversation log as a receipt (source, reference, value, read-at). Attaching a tool is the whole act: its scope is bound by code, so there is no configuration to author. Connected-but-unattached tools appear as one-click boxes right in the Tools section.

| Tool         | What it sees                                                                     |
| ------------ | -------------------------------------------------------------------------------- |
| **HubSpot**  | The customer's HubSpot record — the one picked at enroll.                        |
| **Slack**    | A pinned channel — or, unpinned, the channels the workspace invited it into.     |
| **Jira**     | A pinned Jira project — its issues and their live status.                        |
| **DocuSign** | The customer's envelopes, matched by the email on their record at read time.     |
| **Gong**     | The calls with that customer, matched by the email on their record at read time. |

Tools ride your org's [connectors](/integrations/overview): connect the account once, and every tool on that pipe is available to every guide. A tool that is attached but whose connector has disconnected shows a fix-in-place banner — and blocks publish until it's connected again.

Three abilities are built in and always on, with nothing to attach: the guide **schedules its own check-ins**, **pages you when it's stuck**, and **proposes done for your tap** when no read tool is attached.

## Add knowledge

Drop your setup guides, FAQs, and product docs into the **Knowledge** section. The guide answers customer questions from them — and says it doesn't know when they don't cover it. Files are read live, so a newly indexed document is usable on the guide's very next wake, with no republish.

## Publish

Press **Publish**. The confirm dialog is a read-back, not a form:

* **Your instructions, verbatim** — with a reminder that the done sentence lives there, in your words.
* **The close mode** — *"Once live, it closes on fresh evidence — reads: HubSpot"* when at least one read tool is attached and connected, or *"Once live, it closes by your tap"* when nothing attached can read the world.

If the guide isn't ready, the dialog lists the blockers instead — no enabled channel that can reach anyone, empty instructions, an attached tool whose connector is down — each with its fix one click away. The same items render as banners at the top of the Design tab; they are one derivation, so the page and the gate can never disagree.

After publishing, the status line under the guide's name discloses the close mode permanently, and detaching the last connected read tool asks for a loud confirm that names the consequence: with nothing left to read, the guide will close by your tap instead.

<Tip>
  Before you enroll anyone, press **Try it live** and play the customer yourself. Rehearsal works on drafts — you don't need to publish first. See [Rehearsal](/guides/rehearsal).
</Tip>

<Note>
  Building guides requires the org admin role. See [User management](/admin-guide/user-management).
</Note>
