Apps and end users

An app is what you deploy. Create one under Apps, attach agents, configure who may use it, install the widget, and monitor its conversations and usage.

App tabs

• Overview: name, description, environment, system prompt for the app.
• Agents: the agents attached to the app. With one agent, every message goes to it. With several, the app's router picks the agent for each message based on the agents' descriptions and roles.
• Auth context: the identity policy and the user fields agents may see. Enforcement is either allow anonymous (visitors can chat without signing in) or require verified (the widget shows a sign-in gate until your site identifies the user). Custom claim fields declare which values from the identity token exist and whether they enter agent prompts.
• Credentials: the public app id (safe to ship in a web page) and the server-side app secret (never ship it to a browser). The secret authenticates your backend's calls and signs end-user identity tokens. It can be revealed once and rotated; rotating it invalidates the previous secret immediately.
• End users: the people who have used the app, with their sessions. Sessions can be revoked.
• Install: the widget snippet with your values, the chat UI settings (placeholder, welcome message, suggested prompts, accent colour, theme, position, launcher label, branding, and whether built-in tool activity is shown) and a live preview.
• Test: chat with the app as a builder.

How an app run works

A message to an app runs the app graph: the router selects an agent, the selected agent's published workflow runs as a nested run, the app's output gate streams only the selected agent's final answer, and a final safety check applies the app's guardrails. Nested runs are logged with the same detail as agent runs.

End users and identity

• Anonymous visitors get a server-issued anonymous id on first open; the widget keeps it so the visitor's conversations persist across visits.
• Signed-in users are identified with an identity JWT your backend signs with the app secret (HS256). Required claims: sub (your user id) and exp (expiry). Optional: email, name, a tool_token for authenticated tools, and custom claims declared in the Auth context tab (snake_case names, scalar values). Invalid tokens are rejected with explicit error codes; they never silently become anonymous sessions.
• If a visitor chatted anonymously and then signs in, the anonymous history is merged into the signed-in user.
• Sessions use an access token and a refresh token stored in the browser; the widget refreshes them automatically and reports when a session ends.