Skip to content

Publish Only the Verified Scope

Publishing is a decision to let a defined audience use a defined Agent version. Make the decision from the behavior you inspected, not from how complete the editor looks.

Confirm the release boundary

Before publishing, the expert or owner should confirm:

  • The first job and intended result are clear.
  • The must-pass cases for this release are passing.
  • Out-of-scope and high-risk situations use an approved fallback.
  • Enabled sources and tools belong to the published scope.
  • Someone is responsible for conversations that need a human reply.
  • Known limitations are written down and understood by the pilot team.

If one of these decisions is unresolved, keep testing rather than broadening the audience.

Prepare a release record

Before changing any live state, record:

  • The Agent and exact version being released
  • The case set, results, and must-pass condition used for the decision
  • The supported job, known limitations, and approved fallback
  • The Channel, access mode, and first intended users
  • The operator responsible for human replies
  • The expert or owner who approved the scope and the person who will perform the publish action
  • The conditions that should stop the pilot or trigger a return to a previously verified version

Keep this in your team's normal change record or another shared document. It is decision evidence, not a claim that the pilot will produce a business outcome.

Step 1: Create an unpublished Channel

For the fastest controlled pilot, use a Web Channel:

  1. Select Channels in the workspace.
  2. Click New Channel.
  3. Start from the verified Agent when prompted.
  4. Enter a clear name and stable slug.
  5. Choose Web Application as the type.
  6. Create the Channel, but do not click Publish yet.

A newly created Channel is not live until it is published. The published URL uses the slug, so choose one that is appropriate to share and avoid changing it without checking existing links.

For other delivery surfaces, see Launch Safely.

Step 2: Restrict access before publishing

Open Customers and set the workspace to Whitelist before the Channel goes live.

  1. Review the existing customer list. When an existing workspace switches to Whitelist, current customers become whitelist members.
  2. Add only an internal test identity at first, using the correct Channel type and external user ID.
  3. In the Web Channel configuration, keep Allow anonymous access off. When enabled, anonymous Web or Widget access bypasses whitelist restrictions.

Use Open only when anyone who reaches the experience should be allowed to enter.

→ Customers

Step 3: Publish the verified Agent version

The Agent version and Channel are published separately.

Before publishing the Agent, check whether this workspace already has a live Channel with broader access. A dedicated pilot workspace is the safest starting point because publishing an Agent can make it available to live workspace Channels.

  1. Select AI agents.
  2. Open the Agent you verified.
  3. Review the current draft and version.
  4. Click Publish.

After the version is live, the action changes to Unpublish. Later edits do not reach users until you publish the updated version.

Step 4: Publish the Channel and test it yourself

Return to the Channel, confirm the access settings and intended Agent, then click Publish.

Use only the internal test identity at this point:

  1. Open the live experience as that user.
  2. Confirm the Agent name, description, and input are available.
  3. Run one core situation.
  4. Run one important boundary.
  5. Confirm the conversation appears in Conversations.
  6. Confirm any handoff, form, or tool action behaves as expected.

This catches publication and Channel problems that Test Suite does not exercise. If the check cannot be completed safely, Unpublish the Channel before inviting pilot users.

If the client says No agents available

The Channel may be live while the intended Agent version is not. Return to AI agents, publish the verified version, and refresh the client.

Step 5: Add the pilot group

After the internal check passes, add the approved pilot identities to the whitelist and share the URL only with that group. Keep the audience small enough that an operator can review important conversations and respond to handoffs.

Ask people who can judge the actual work to try:

  • A normal situation they expect the Agent to handle
  • A boundary or exception they care about
  • A tool action when the published scope includes one

When a specific reply is wrong, ask them to use Improve and describe what the result should have done differently. They do not need to diagnose the implementation.

Useful feedback identifies:

  • The exact reply or action that was wrong
  • The missing question, evidence, next step, or handoff
  • An unsupported implication or promise
  • What an acceptable result would have done instead

Step 6: Decide whether to hold, fix, or expand

After the first real use, choose one of three actions:

  • Hold: The published scope remains appropriate; continue observing.
  • Fix: A current must-pass behavior needs a focused correction.
  • Expand: A repeated new situation is valuable enough to become a case for the next version.

Do not treat every new question as permission to expand. Keep unverified work on the approved fallback until the new case and its Standard are ready.

Stop or roll back

  • Stop Channel access: Use Unpublish on the Channel. This takes the Channel offline without deleting its draft configuration.
  • Stop the Agent version: Unpublish the Agent when no live Channel should use that version.
  • Return to verified behavior: Select a previously saved and verified Agent version, confirm its case evidence, and publish that version again.
  • Record the incident: Note what triggered the stop, who decided, which users or conversations may be affected, and what must pass before relaunch.

After a stop or rollback, repeat the internal end-to-end check before restoring pilot access.

Next steps