01 · Sources
Import your help site in one crawl, paste docs, and keep a Known issues list it can quote. Your agent answers from that, and nothing else.
Three sources. Nothing else is in scope.
Any chat widget can answer from docs; this one shows the passage — cited from your own docs — so the customer can check it. When the docs run out, it says so plainly, and the question reaches your inbox instead of an improvised answer reaching your customer.
A card-free 14-day trial that starts when your agent goes live — not when you sign up.
…your first paid invoice can be refunded in full within 14 days of the charge — email billing at acme.example from the address on the account and the refund is issued to the original payment method within five business days.
Not a screenshot. The question, the answer and the passage under it come from the demo below: Acme is a fictional product, and the citation quotes its refunds doc verbatim.
Acme is a fictional developer tool — eight short docs, nothing else. Its Support Agent is the same widget your own site would embed: real retrieval, citations you can open, and a real handoff when the docs run out.
“Can I get a refund on my first invoice?”
Answered from Acme’s refunds doc, with the passage attached — open the citation and read it.
“What are the API rate limits?”
Exact numbers, quoted from the doc rather than remembered — the difference between grounded and plausible.
“Does Acme support single sign-on?”
Nothing covers it. Watch it say so in so many words and offer a person, instead of improvising a feature.
Live conversations here are counted like any visitor's. How it decides what to say — the platform.
Five stages, and support changes what each one means — not how it works. The mechanism itself lives on the platform page; this page won't re-explain it.
01 · Sources
Import your help site in one crawl, paste docs, and keep a Known issues list it can quote. Your agent answers from that, and nothing else.
Three sources. Nothing else is in scope.
1 of 5
Five stages, one thread. Choose any stage directly or move through them in order; every state is drawn in the product's own parts.
The conversation behind a handoff is never behind a paywall on a Support Agent. A handoff you can't open has dead-ended, and not dead-ending people is the one thing this agent promises — so that carve-out is written into the product, not the pricing table.
And not only by you: invite a colleague and they can open the same Inbox and read the same conversations. They cannot change the agent, publish it or touch billing — an invite is a key to the Inbox, not a seat at the controls.
A Support Agent is restricted from the moment it's created. It opens only through a signed token your own server mints per visitor — your site vouches for its people, so they never need hiy accounts — and asking for it without a token returns the same “not found” a made-up address does. It reaches your users as an embed on your own site, or through the same token-gated API.
The three-step setup — copy the signing secret, mint a token, drop the snippet — is on the agent's Publish tab and in the docs. The full security posture — how the tokens are built, identity review, what happens to conversation data — is on the trust page. The sequence itself — your server, your page, and the request hiy checks before it answers — is drawn in how a token is minted and checked.
Not a claim about how fast or how good — those would be numbers nobody measured. The bounds a chat request meets are printed under the name each one has in the code — a constant where there is one, the schema field or the call where there isn't — beside the file it lives in: the limits, with the names they have in the code.
Every playbook on this site carries a section like this, because a page that only lists what works is marketing. These four are structural — behavior of the variant itself, not settings you have to remember to switch off — so each one is stated with the thing in the code that enforces it. A restraint nobody can point at is a promise, and this page does not make promises.
A support conversation that turns into a pitch is a broken one, so the catalogue is removed on the way in rather than forbidden once there: the services category is dropped before the prompt is assembled, and the sign-up link is withheld on any other bookable category — from the tool result as well as the card. A bound, not a blanket: another list you attach stays answerable, prices and all.
allowServices: false · lib/agent-kinds.ts — usableCatalogue · lib/records/catalogue.ts — hiddenBookingField · lib/records/lookup.ts
The same fact, as a proof rowThe admission is matched, not assumed: the gap queue is written when the answer reads as a decline in the wordings the model actually produces, measured against a corpus of real stored answers — never from a guess inferred out of weak retrieval scores, because a queue full of questions it did answer is a queue nobody reads. Support also starts at the firmest scope any variant has.
looksLikeGap · lib/rag/gaps.ts, which holds a literal isHonestUncertainty as one wording of several — defaultStrictness: "strict" · lib/agent-kinds.ts
How scope and gaps behaveThere is no voice to borrow: the persona layer that carries somebody's phrasing and rhythm is never built for this variant, and the rules it runs on are one shared, name-free block rather than a per-agent string anyone can edit. It says it is the product's support, in its own header, and that it may make mistakes.
mimicVoice: false · lib/agent-kinds.ts — buildSystemPromptParts + VARIANT_RULES.support · lib/rag/prompt.ts
What a Support Agent isDe-branding is a swap, not a deletion: the plan resolves at render to one of two nouns — the brand one or the category one — and there is no third branch that returns nothing. The de-branded wording is the more disclosing of the two, which is why the entitlement is safe to sell, and why no plan removes the AI label, the honest gap, or the report link.
brandingFor · lib/appearance.ts
What each plan changesOne product underneath — you pick a preset when you create the agent, and it’s a starting setup built from machinery that ships today: record-list templates your agent quotes row by row, and the same scope controls every hiy has. Everything it sets is yours to edit afterwards.
“Why is my deploy stuck in ‘queued’?”
Starts from
Known issuesCommon questions
Scope held to how your product behaves — setup, limits, troubleshooting — and nothing off-product.
“Where’s my refund?”
Starts from
ProductsCommon questions
Scope held to plans, prices and policy, quoted from your own rows — the price it names is the price.
“What’s the rate limit, and which header says back off?”
Starts from
Common questionsResources
Scope held to your API docs and guides, with citations a developer can open mid-integration.
“Is the platform engineer role remote?”
Starts from
Open positionsCommon questions
Scope held to open roles and how to apply, straight from the listing rows — no speculation beyond them.
The templates are real and editable — how lists answer and how scope is set.
Mostly in what it refuses to do. Doc-chat is easy to start and hard to trust: a widget that always has an answer is improvising some of them, in your product's name. This one holds the source up beside a grounded answer, and admits the gap when the material runs out — both reproducible on the demo above. Its restraints are code rather than settings: what the code refuses to do. And it is not a helpdesk: handoffs land in one Inbox and the reply comes from you. If you run routing and SLAs, keep your helpdesk — this answers the questions your docs already cover, and hands the rest to a person.
No — Support Agents are part of Founding, alongside your own twin and Team Agents. The 14-day trial is card-free, and it starts when your agent goes live rather than when you sign up. Plans and numbers are on pricing.
Founding includes a monthly message allowance, and the number you were sold is the number that's enforced. At the cap the widget says it's at its limit and still offers the hand-to-a-person form — it never goes quiet, never invents, and nothing bills you by surprise. The mechanics are in plans & billing.
It answers in the visitor's language. The boundary, stated rather than glossed: the interface around it — the disclosure line, the handoff form, errors — is English today, and citations are shown in the language of the source they quote, because a translated quotation is no longer a quotation.
The account that created the agent, and any colleague it invites. An invited teammate can open the Inbox and read the conversation behind every handoff — the conversation view shows everything the agent tried before it handed off. Reading is all they get: changing the agent, publishing it and the billing stay with the account that created it.
Point it at the help pages you choose. Break the agent privately, then publish — part of Founding, on the card-free trial above.