---
title: "Support Agents"
description: "An agent for your product, inside your own site, with Inbox handover."
source: https://hiy.ai/docs/support-agents
---

# Support Agents

## Try the homepage demo

The Companion icon identifies hiy where an agent has no custom portrait. Its movement indicates activity, not proof that sources were checked. “Preparing a response” is a neutral waiting state; use the answer’s actual citations to inspect its evidence. Sending a handover is not confirmation that your team has received it—wait for the success message. Motion stops when reduced motion is enabled.

The chat bar sits below the sample exchange, above the disclaimer. Type your own question, or press its send arrow (or Enter) to ask the example question it shows.

The [homepage demo](/#home-demo) lets you start a chat with the hiy agent — a real Support Agent, and it answers from these docs: the same pages you're reading now, grounded exactly the way your own agent would ground itself in yours. Choose **Chat**, then send a question from the chat bar. Open the source behind an answer, or ask something the docs do not cover. The normal conversation limits and handover rules apply.

The **Voice** tab previews the upcoming mode; voice is not available yet and selecting it never accesses your microphone. Switching modes keeps your chat mounted. If the demo cannot connect, press the send arrow again or try it full-screen at [/try](/try) — or see [how it answers](/support-agent#loop), drawn from the product itself. A demo session lasts ten minutes; refresh the page and start again if it expires.

> **Early access.** Grounding and honest gaps are on every plan, always. Instant handovers and token gating come with Support Agents — part of Founding, free during your 14-day trial, and in an [Early Access](/docs/early-access) free month. Resolution analytics, helpdesk integrations and admin controls are on the [roadmap](/roadmap).

Your public twin speaks as you. A **Support Agent** speaks for something you own — your product — inside your own site or app.

It answers in a neutral voice from the product knowledge you give it, never sells, and when it can't answer it does the one thing bad support bots don't: it says so, and offers to pass the question to a person. The visitor leaves an email and the question lands in the agent's **Inbox** tab **immediately** — a handover means someone is stuck right now, so it's recorded whatever your notification settings say. Where email is set up you're also mailed what they asked and how to reach them, and the visitor gets a receipt — and the Inbox has it either way, so nobody dead-ends.

Each handover opens the conversation that produced it, so you can see everything the agent tried before it gave up rather than replying to one line of context. That view is never behind a plan on a Support Agent: a handover you can't read has dead-ended, which is the one thing this agent promises not to do. See [Where a lead came from](/docs/conversations).

When it hands over, who that reaches and what the visitor reads are yours to set on the agent's **Handover** page — including turning handover off altogether. See [Handing over to a person](/docs/handover).

## Your team can read it, not run it

Support rarely has one owner. Invite a colleague and tick this agent under **Agents they can open** (an
invite is just an email address — see [Team Agents](/docs/team-agents)) and they
can sign in, find the agent in their twin switcher under **Shared with you**,
and open its Inbox: every handover, every person waiting, and the whole
conversation behind each one.
In the new app you can also invite people on the last step of setup, and invite from **Workspace → Team → Members**.

That is the entire grant. An invited colleague can read; they cannot change the
agent's knowledge, voice or rules, cannot publish it or see its token settings,
cannot mark a follow-up done or delete anything, and cannot touch billing.
Those stay with the account that created the agent. Full shared administration
is on the [roadmap](/roadmap), and this is not it.

## Put it on your site

A Support Agent has no public link: its address exists only so your dashboard
and your snippet can name it, and asking for it without a token returns the
same "not found" a made-up slug does. There are two ways onto your site, both
on the agent's **Publish → Install** tab, and the one that needs no server
comes first.

### One line, no server

For a help centre, a docs site, a blog — anywhere your visitors don't sign in.

1. **Add your site and save** — The first card on **Install**: type the website it goes on, such as `yoursite.com`, then **Save**.

2. **Switch on Open on your site** — It asks you once before it opens.

3. **Copy the line and paste it** — It appears on the same card. Paste it on every page of that site, just before `</body>`.

hiy signs each visitor in itself, for frames on your listed websites only.
Anyone there can ask — and so can a script — so **everything an open agent
knows, and its instructions, counts as public**; the card says so beside the
switch. The limits are in [Open on your site](/docs/embed#open-on-your-site).

### Signed in by your server

The developer option, for apps whose users sign in. A visitor gets in through a
**signed token your own server mints** — your site vouches for its visitors,
which is why they never need hiy accounts, and the agent can be told who is
asking. Below the first card on **Install**, in three steps:

1. **Copy your signing secret** — It's on the agent's **Publish → Security** tab.

2. **Mint a token per page view on your server** — The exact code is on **Publish → Install**.

3. **Drop the widget snippet** — The floating bubble or the chat bar — it fetches each visitor's token from your route.

**Warning:** Keep the secret server-side, always. If it ever leaks, rotate it yourself under **Publish → Security**.

Both can run at once: a token your server mints still works on an open agent,
with its facts. Once the list has a site, it decides where the signed widget can
appear too — list every site it runs on.

### The signing secret

It's on the agent's **Publish → Security** tab and nowhere else, click-to-reveal — screens get shared, and a secret in a screenshot is a secret you have to rotate today. It belongs on your server and nowhere else: it signs the token, and it never travels to a browser or into a repository. **Rotate** is on the same card: every token your server has already signed stops verifying the moment you press it, so put the new secret in your server's environment straight afterwards.

If the secret can't be read, the Security tab says so, and everything that doesn't depend on it stays where it is: **publishing** the agent, [who can read the Inbox](#your-team-can-read-it-not-run-it), and [what your site tells this agent](/docs/actions#what-your-site-can-tell-your-agent) — that declaration is saved with the rest of the agent's settings, not with the secret. Only the wiring steps — this secret, the mint example, the widget snippet — need the secret itself, and they come back when it loads.

### The widget

The signed route's snippet on **Publish → Install** is the whole install: one `<script>` carrying your agent's address, the mode — the floating **bubble** or the **chat bar** — and `data-token-url`, the route on your own site that mints each visitor a fresh token. A snippet with no token gets exactly the "not found" a stranger gets; an expired token shows *This session has expired* and tells your page to mint again.

On a phone the Install tab shows the first line of each snippet — the one-line route's included — with its **Copy** button beside it, rather than a box you scroll sideways: copying is how these strings are meant to travel, and a box that cuts a token mid-character is a token nobody can read anyway.

## Four presets, one agent

When you create a Support Agent you choose a **preset** — a named setup rather than a different kind of agent. There is one Support Agent underneath, answering under exactly the same rules whichever you pick, and everything a preset sets is yours to change afterwards on the **Rules**, **Lists** and **First impression** tabs.

**The first preset is preselected, and shown open.** Its scope line — what it
will and won't answer — is on screen the moment you land on this step, so
you're reading a real choice rather than guessing. One click swaps it for
another, and the next screen shows exactly what your pick set.

Each preset does three things: it adds the [lists](/docs/records) that setup usually needs, it writes down [what the agent covers](/docs/what-it-answers) so it declines everything else plainly, and it seeds a starting [greeting](/docs/first-impression) and a starting [handover sentence](/docs/handover) — both yours to edit before anyone sees them.

| Preset | Starts from | Scope it declares |
| --- | --- | --- |
| **SaaS product support** | Known issues, Common questions | How your product behaves — setup, limits, troubleshooting |
| **Orders & billing** | Products, Common questions | Plans, prices, orders, refunds and cancellations |
| **Docs/developer assistant** | Common questions, Resources | Your API and docs — endpoints, limits, error codes |
| **Careers/HR** | Open positions, Common questions | Open roles, and how to apply |

A preset changes no rule. It does not make the agent sell, loosen what it will answer, or unlock anything — the neutral voice, the token gating and the honest gap are the same either way. If your org already has one of those lists, the preset reuses it rather than making a second copy, and if you are already at the limit of eight lists it attaches what exists and leaves the rest to you.

Prefer to start empty? **Start from scratch** sits on the same list as a peer choice, not a fallback: no categories, no declared scope, no opening line — you add all of it yourself.

## Turning it on

A Support Agent is a draft until you publish it, and it answers nobody until
then — not even through a valid token, and not even when it is open on your
websites. The control is on its **Publish** tab, beside a card that names both
ways onto your site and opens **Install**, and on Overview. If the agent is
still waiting for its [check](#review-before-it-answers), the control says so:
publish whenever you like, and it starts answering once it's approved. Unpublishing is immediate and acts
only on the agent you are looking at; your own public twin and every other
agent carry on untouched.

Publishing hands you the agent's own version of the [launch
kit](/docs/sharing): who can reach it in one sentence, the widget snippet with
the place your token goes, and a way back to the signing secret. No public
link, no QR code and no ready-made posts — a Support Agent has no public page
for any of them to point at.

### See it answer, before you write any server code

A Support Agent only answers through a token your own server mints, which
leaves a real gap: there's no way to watch it work until that server exists.
**See it answer**, on the Publish tab, closes it.

The button appears once the twin has something to answer from — with nothing
imported or pasted yet there is nothing to watch, so it isn't offered. Once
your agent is live, pressing it opens the launch kit, and **See it answer**
inside that panel mints a short-lived token and mounts the real widget right
there. It's a ten-minute token, and never one you can copy or paste, so it
can't be mistaken for one to drop into your own site. Before it's live — most
Support Agents queue briefly for [identity
review](#review-before-it-answers) — the same button opens [Test
chat](/docs/testing) instead, which already answers for real and needs no
token at all.

A new Support Agent starts on [**Strict** scope](/docs/what-it-answers): it
answers what your material supports and declines the rest plainly, because a
confident guess about your own product is the most expensive kind of wrong.
That is a starting point, not a rule — change it on the Rules tab whenever you
like.

## What it knows

Only what you give it, exactly like your own twin: paste docs, import your help site, add corrections. It quotes limits and steps verbatim, cites its sources, and never guesses at how your product behaves — an invented answer about your own product is the most expensive kind of wrong.

Give it a *Known issues* list and it can look up what's broken right now and say what the workaround is.

## It shares your monthly allowance

A second agent does not come with a second allowance. Your plan's visitor
messages are one pool for the whole account, and every twin and agent you own
draws from it — so adding this one divides the month rather than doubling it.
The meter on your Overview and in **Settings → Plan & billing** counts it that way.
See [Plans and billing](/docs/plans-and-billing).

## Review before it answers

The same identity rule applies: you twin yourself, or something you own — confirmed at creation, and checked again on our side. Unless its name matches your own account, a new Support Agent is checked by a person before it can answer — usually within one business day. That's deliberate.

The decision shows on your dashboard — don't wait on your inbox: it reads **Awaiting review** while it waits, turns Live when it clears, and if it's declined it says so with the reviewer's reason and what to send us, for as long as that's the state. You can keep testing and adding material the whole time.