Building an assistant

What an assistant is

An assistant is a chat window you embed on your own site that can actually do things — look up an order, check stock, price a basket — by calling your workflows. You choose which of your tools it can reach, what it's allowed to say, who has to sign in first, and what it looks like.

Each assistant is configured on the Agentic page and embedded with a snippet. You can run as many as you like: a support assistant on your help pages and a sales one on your product pages, with different tools and different instructions.

Instructions

Free text telling the assistant what it is, what it should do, and what it must not do. This is the single biggest lever on how it behaves.

Useful things to put here: who it is talking to, which topics to stay on, what tone to use, what to do when it doesn't know something, and when to hand off to a human. Be explicit about limits — "never quote a delivery date, direct the customer to the tracking page instead" works better than hoping it won't.

Tools

An assistant can only do what you connect. Tools come from your MCP servers, each of which exposes a set of your workflows.

Attach a server and every tool on it becomes available. The assistant decides which to call and when, based on your instructions and what the customer asks. A turn can involve several calls in sequence — looking up a customer, then their orders — up to the maximum tool steps set under Settings.

Two things worth knowing:

• Tool descriptions matter as much as your instructions. The assistant picks tools by reading them, so a workflow route described as "Handles the thing" will be used badly or not at all.
• Only attach what the assistant genuinely needs. Every extra tool is another thing it can choose wrongly, and another thing a customer can provoke it into calling.

Appearance

Controls how the widget looks on your site: title, opening message and input placeholder; accent, background and text colours; font and font size; width, height and corner radius; button position; an avatar image URL; and whether to show the "Powered by Younifyd" line.

The opening message is worth more thought than the colours — it is what sets a customer's expectation of what this assistant can help with.

Access

Controls whether visitors must sign in before they can chat, and what the assistant knows about them once they have.

Require sign-in

Off by default: anyone who can see the page can chat. Turn it on for anything that touches a customer's own data.

Custom Login posts the username and password to a workflow you wrote, so the platform never sees how credentials are checked. Choose the workflow and the route within it, and name the body fields it expects.

Your login workflow's HTTP status is the whole verdict. A 2xx signs the visitor in; anything else rejects them. Nothing is read from the response body to decide this. If your workflow answers 200 with {"error":"bad password"}, everyone gets signed in — it must return a non-2xx status for bad credentials.

OAuth Provider redirects to an external identity provider instead. Give it the authorization and token URLs, client ID and scopes. The client secret is write-only: once saved it is encrypted and never shown again, and leaving it blank on a later save keeps the existing one.

Forwarded headers

Once somebody signs in, your workflows need to know who they are. Forwarded headers map values out of the sign-in response into headers sent with every tool call:

Header	Value
Authorization	Bearer {{body.data.access_token}}
X-Customer-ID	{{body.data.customer_id}}
X-Request-ID	{{header.x-request-id}}

{{body.…}} reads a dot-path out of the sign-in response body (array indexes work: {{body.users[0].id}}), and {{header.…}} reads one of its response headers, case-insensitively. Anything else in the value is sent literally, which is where the Bearer prefix comes from.

Three behaviours to rely on:

• A header whose template can't be filled is left out entirely, never sent as Bearer undefined. An absent header is far easier to diagnose than a present but empty one.
• They are resolved once, at sign-in. Changing the mapping doesn't affect sessions that are already open, and the sign-in response itself isn't kept around for the life of the session.
• They are merged after the assistant's own arguments, so the assistant cannot overwrite them. It cannot name somebody else's customer id and read their prices — identity comes from the sign-in, never from the conversation.

Session expiry

How long before a visitor has to sign in again. Longer sessions mean fewer interruptions; shorter ones limit how long a shared or forgotten browser stays signed in.

Signed-in visitors get a Sign out link in the chat header, which clears their session, the forwarded headers derived from it, and the conversation.

Embed

Two snippets, both pointing at your assistant:

• Script — adds a floating chat button that opens the conversation, and only loads it on first open. This is the usual choice.
• Iframe — places the conversation directly in the page, for a dedicated support page or a sidebar.

Under Settings → Allowed websites you can list which sites may embed the assistant. Leave it empty to allow any.

Settings

• Name and Description — for your own reference.
• Allowed websites — as above.
• Maximum tool steps per message — how many times the assistant may call a tool before it has to answer. Higher allows more thorough answers and costs more per message.
• Message limits — see below.

Message limits

Anyone who can open your chat can also call it from a script. These limits are what keep that bounded. Set any to 0 to switch it off.

Limit	Default	What it does
Per visitor, per minute	10	Slows one person down without affecting anyone else
Per visitor, per day	200	Caps what a single visitor can cost you in a day
Per conversation	100	After this, the visitor starts a new conversation
Total per day	5000	The hard ceiling on this assistant's daily cost

The first three key on the visitor's network address, so they limit one abuser rather than a distributed one. Total per day counts every message the assistant answers regardless of who asked, so nothing gets past it — it is the number to set with your budget in mind.

When a visitor hits a limit the chat tells them so and the message isn't answered.

The model

Assistants use a platform-managed model by default — there is nothing to choose and nothing to pay for separately. It is selected centrally and may be upgraded over time without any action from you.

If you would rather use your own provider account, pick the provider and the connection to use. Your own key, your own quota, your own bill.

Going live

1. Write the instructions.
2. Attach the MCP servers holding the tools it needs — no more.
3. Set the appearance, especially the opening message.
4. Decide on sign-in, and if it's on, map the forwarded headers your workflows expect.
5. Check the message limits against what you're willing to spend.
6. Copy the embed snippet onto your site.

Test with sign-in turned on before you launch: the difference between an assistant that can see a customer's own orders and one that can't is entirely in the Access tab.