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.
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.
Three sources. Nothing else is in scope.
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.
Can I change my plan mid-month?
Yes — switching takes effect immediately and the next invoice is prorated to the day.
Source: Plans & limitsOpen it and you read the passage, not a title.
A neutral product voice — deliberately not yours — with the passage behind every grounded answer visible to the customer deciding whether to trust it.
Can we be invoiced in euros?
Not in the source material
The same card the widget renders, not a paraphrase of it.
When the material runs out, it says so in so many words. No confident filler about your own product: an invented answer there is the most expensive kind of wrong.
Your words, typed once, in your queue.
The unanswered question waits in your queue. You answer once, in your own words.
Can we be invoiced in euros?
Yes — EUR invoicing is available on annual plans.
Source: CorrectionSame question, next visitor — now a citable source.
Your answer becomes a cited source for everyone after. The agent gets better because it was used, not because you rebuilt it.
Five frames, one thread — scroll it sideways, or focus it and use the arrow keys. The frames are drawn in the product's own parts, and the whole loop is reproducible on the live agent above.
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 twin'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.
There is no address to find. It lives inside your own page.
A Support Agent reaches your users as an embed on a page they are already reading, and it opens only for the visitors your own site signs in — which is why there is no public address for anyone else to try, and why your customers never need an account here.
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 from the first-person “I don't know” the model actually wrote, never from a guess inferred out of weak retrieval scores — a queue full of questions it did answer is a queue nobody reads. Support also starts at the firmest scope any variant has.
isHonestUncertainty · lib/rag/gaps.ts — 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.
Because that's its name in the app today. Support Agent is the public name for the same thing — one variant, one set of rules — and the app's vocabulary is catching up. The docs still say support twin too.
Point it at the help pages you choose. Break the agent privately, then publish — part of Founding, on the card-free trial above.