Take a Web Agent to production

A Web Agent that answers on your machine needs four things before it runs for your users: a place to try versions before they go live, limits on where it loads, limits on what it does without asking, and a way to know when it breaks.

The agent has to exist and its analysis has to be finished. To get there, see Build your first Web Agent.

Give yourself a place to try versions

Publish creates a version and serves it on the release target in the same step. When the release target is the environment your site loads, every publish reaches your users immediately.

Keep two environments, with Staging as the release target. A publish then lands on Staging, and Production changes only when you deploy a version to it.

1. Add the environment you are missing and make Staging the release target. See Deploy a version to an environment.
2. Point your staging site at it. With the npm loader, pass env: 'Staging' to init. With the script tag, add &env=Staging to the URL.
3. If Staging and Production call different backends, set the variables for each. See Set variables for each environment.

The chat model and web search are not part of a version. A change to either applies to every environment as soon as you save it, so try a new model at a quiet time, not on Staging.

Limit where the agent loads

Anyone who copies your snippet can load the agent on their own page, and the conversations run on your model provider's tokens. List your domains on each environment: your public domains on Production, and your staging host and localhost with its port on Staging.

See Restrict the domains that can load the agent.

Tell the agent who the user is

Without identity, every conversation is anonymous and stays in the browser where it started. Sign a token for the signed-in user on your backend and pass it to the widget. Users then keep their history across devices, and Logs show who had each conversation.

1. Verify your users with a signed token.
2. Once every call sends a token, enforce verified identity, so that a name typed in the browser console is ignored.

Decide what the agent may do without asking

The agent acts as the signed-in user, so it can do what that user can do. Go through the Actions tab once with that in mind.

• Turn off the actions the agent should not have. See Turn an action on or off and test it.
• The analysis turns Ask to confirm on for every action that sends a DELETE request. Turn it on for the other writes a user would want to see before they happen, such as sending an invoice or changing a price. See Require confirmation for an action.

Test before each deploy

Generate a test suite once and run it on Staging before you deploy a version to Production. A suite runs the agent's actions inside your real app, in a page you opened with a debug session, and creates and deletes real records, so run it against staging data.

1. Generate and run a test suite.
2. Keep debug sessions off on Production. They are off there unless you turn them on. See Open a debug session.

Watch it after the deploy

Read the first conversations in the agent's Logs. A conversation with an error carries a badge, and each turn shows the actions the agent ran with their input and output. See Read the logs.

If a version misbehaves, serve the previous one on Production. The switch does not need a build of your app. See Roll back to an earlier version.

Checklist

Next steps

• Versions, environments and deployments: how a change travels from the draft to your users.
• Keep the agent up to date: what happens when your code changes.
• Appearance: make the widget look like part of your app.