Building a guide

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.

​

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.

​

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.

​

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. Tools ride your org’s connectors: 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.