How a turn is answered

The panel runs in your app’s pages, and Super Assist answers. Every turn draws on two sources: what your organization set up in the dashboard, and what the open page lends at that moment. This page follows one message from the panel to the reply.

The project lets the panel in

The panel connects with the project’s publishable key. Before anything else runs, Super Assist checks four things:

The key belongs to a project.
The page’s origin is one of the project’s allowed origins.
The agent belongs to the organization. It is the project’s default agent, or the one the hook’s agent option names.
The panel names an end user: the signed-in user you pass, or a visitor id the browser keeps.

A failed check closes the connection with a code, and nothing else happens. The codes are in Use the hosted runtime.

The key grants nothing past this door. It opens threads for its project from the allowed origins. It can’t change an agent, read a database or pick a model, so it is safe to ship in your bundle.

Each end user has their own threads

An end user gets their own list of threads with each agent in each project, and sees only those. A visitor’s list stays with their browser, and a signed-in user’s follows them across browsers. The first message names a thread, and each turn moves its thread to the top.

The agent keeps notes as it works. Each thread has its own memory for that conversation. The end user’s threads with the agent also share one memory, for facts that should outlast a conversation. No other end user sees either.

The agent answers

The agent is what your organization configured in the dashboard:

Instructions. A template filled in at every turn with the date, the agent, the organization, and the agent’s skills and databases. Instructions saved while a conversation runs apply from its next turn.
A model. An end user’s turn always runs on the agent’s model and thinking level. The panel’s model choice is ignored, so a browser holding the key can’t run another model on your organization’s spend.
Skills. The prompt lists each of the agent’s skills by name and description. The agent loads a skill’s instructions only when the description fits the request. So the skill editor writes the description as three labelled lines from its What, Use when, and Not for fields:
```
What: Reviews a pull request against the team checklist.
Use when: Asked to review a pull request, a diff or a branch.
Not for: Writing the fix or reviewing a design doc.
```
Not for keeps the agent from loading a skill for a request that only looks like a fit. Through the API, write the same lines into description. A description written another way opens in the editor whole, under What.
Databases. An agent with databases gets two tools: one returns a database’s schema, and one runs a single SQLite statement. A statement that writes to a database the agent may only read is rolled back.
Knowledge bases. An agent with knowledge bases gets search_knowledge, and its prompt tells it to search before answering a question they may cover, to answer from the passages, and to cite no source the search didn’t return. The passages show under the answer in the sources card. See Knowledge bases.
The core rules. Four fixed rules close every prompt, whatever the instructions say: answer only from the instructions, the knowledge bases, the open page and tool results; one step at a time; claim an action done only when a tool call completed it; say what a handoff or a consequential page action will do and wait for a yes.

In an end user’s thread the agent can’t fetch URLs. That stays with your members, who try agents in the dashboard.

After the reply, a decision model reads the exchange

Once the reply is on screen, one call to Clef, Cloudflare’s decision model, reads the agent’s purpose and the last thirty turns and answers six questions at once: is the issue resolved, is the user done, should a person take over and why, did the reply stray off the agent’s purpose, and did it expose something it shouldn’t. The answers are the thread’s signal, and the next user message clears it.

The resolution prompt. The panel asks Did this resolve your issue? under the reply only when the issue reads as resolved or the user reads as done, not after every reply. The answer sets the thread’s outcome on the project’s page.
The handoff offer. When a person reads as needed, the panel shows Talk to a person. Pressing it sends “I’d like to talk to a person.” and the agent hands off. A user who plainly asked for a person is handed off at once, without another turn.
Flags. A reply that strayed off purpose or exposed something it shouldn’t is flagged Off purpose or Sensitive beside the thread’s outcome on the project’s page and on the thread.

A reply Clef can’t judge is logged and shown as it is; the prompt, the offer and the flags simply stay off for that exchange.

A person can take over

Every thread has a handoff tool. When the agent calls it, or when the signal above says the user asked for a person, a handoff opens, your organization’s support address gets an email, and the panel tells the end user a person will reply there. The agent then stays out of the thread: the end user’s messages are kept, and no turn runs. A member reads the thread from the dashboard’s Inbox and replies into it, and the reply reaches the panel as that person’s message. Closing the handoff gives the thread back to the agent. See Handoffs.

The page adds what it lends

Every message from the panel carries what the open page lends through model context:

The instructions and the page’s note. They follow the agent’s own instructions in the prompt, so the agent knows which page the user has open and how to work there.
The lent tools. The page’s actions, fields and tools, and the provider’s built-ins such as go_to_page and show_table, join the agent’s own tools for the turn.
The call settings. A temperature or a system prompt set in the panel’s settings applies to the turn.

The lent tools have no code on Super Assist. When the agent calls one, the call streams to the browser, the page runs it, and the result goes back. The agent then continues the same turn. A tool with toModelOutput sends its result for the thread and, beside it, the text and files the model sees; Super Assist hands the model those parts, or their text alone when the model takes no files.

When a tool opens another page mid-turn, the next step already has the new page’s tools. The page section of the prompt still names the old page until the user writes again. The tool that changed the page answers with the new page’s note, and the universal instructions tell the agent that a note in a tool result is newer. So the agent can act on the new page in the same turn.

The browser keeps the rest

A page’s content leaves the browser only when the agent asks for it with get_page_content. See Why content is read on demand.

A consequential action’s approval pauses its tool call in the browser. Super Assist sees a tool call whose result arrives late, and needs nothing else for the pause. See Why consequential actions ring.

The organization pays for the turn

Super Assist pays the provider for each turn. The first dollars of a month come from the AI your plan includes; the rest come off your organization’s credits, bought in packs on the billing page. With nothing included and no credits left, turns are refused.