How to stage an enterprise agent rollout by operation

The release plan says the new agent goes to 10 percent of employees on Monday. The allowlist already contains every method the prompt might call, including the one that closes a ticket and the one that issues a credit. The 10 percent cohort hits both on the first morning. The other 90 percent are safe only because they never opened the chat. The dangerous surface was the operation list, and it was already at 100 percent.

This post shows how to stage that surface by operation: which methods are enabled, in what order, and when a write is allowed to leave approval.

Percentage of users is the wrong dial

A user-percentage rollout assumes the code path is the same for everyone and the risk is evenly spread. An agent does not work that way. Two people in the same cohort can trigger different methods because the model picks from whatever tooling.json allows. If refunds are on the list, the first person who asks for a refund sends one. Cohort size does not cap that.

Swytchcode's allowlist is per workspace, not a canary flag on a user id. Connected end users are a billing meter: one person counts once per workspace however many providers they connect. That meter does not split traffic 10 percent to a new prompt and 90 percent to an old one. If you need a user cohort, that switch lives in your app. The operation list is what you roll here.

Count the rollout as a share of methods. Twenty methods scoped, four enabled, is 20 percent of the surface. That number is visible in git. Put both numbers in the pull request.

A prompt line that says "do not call refunds" is not a stage. If the method ID sits in tooling.json, the model can call it. Remove the ID until the stage that is supposed to run it. The staff cohort never had a say in that.

Order the list by what a bad call costs

Sort the catalog you actually downloaded, not the vendor's full marketing list. swy list methods is the local list after swy get. Enable reads that only fetch a record the user could already see. Leave creates, updates, deletes, and anything that moves money off the list.

When a read has been quiet in the call log, add one write. Put approval on it. Approval on Slack or Telegram starts on Business and Enterprise. If nobody answers within 48 hours, the call does not run. A late approval never runs the call. Free and Pro are allow or deny only, so on those plans the staged write is either on or off. Do not pretend a hold exists there.

A week later, read swy audit stats on the machine that ran the calls, and the hosted log if you turned storage on. Retention is 7 days on Free, 30 on Pro, and 90 on Business. Storage stays off until you enable it. If the write's arguments match what you expected, you can narrow the approval rule. If they do not, remove the method. Removal is the rollback. You do not need a second deploy of the model to stop the call.

What a stage looks like in the repo

Each stage is a pull request that changes tooling.json and .swytchcode/integrations/policies.json together. The policy file can block, hold, modify arguments, or redact a response. Block wins over approval. A blocked call exits 6 and is not sent. An approval wait exits 7.

swy policy validate
swy exec <canonical_id from swy list methods> --dry-run

The ID is copied from swy list methods. Dry run does not send and does not count as a live command. Policy as code is the review of that diff.

Do not stage by editing the prompt alone. The prompt can ask for a method that is already enabled. The allowlist is the gate. A prompt-only rollout with a full allowlist is the 10 percent cohort problem again.

How you know a stage is done

Pick a signal before you enable the next method. A useful one is boring: the count of calls for that method, the share that were blocked, and whether any argument surprised you. "The demo looked good" is not a signal.

Stop the rollout when a stage shows calls you did not intend. Disable the method, ship that as the next pull request, and read the log before you discuss the prompt. The model will keep asking. The runtime should keep refusing.

Move one method per stage. Validate the policy file, dry-run the new ID, and read the log before you enable the next write.

Related reading

• API governance tools for AI agents. How the allowlist and the policy file split the decision.
• API observability for AI agents. What to look at between stages.
• A security checklist before company data. The questions to settle before the first write.
• Best API observability tools for agent traffic. When the hosted log is the wrong tool for the question.

FAQ

Can I send 10 percent of users to the new agent from Swytchcode?

The allowlist does not split users into a percentage. It enables methods for the workspace. If you need a cohort, build that in the app that shows the chat. Keep the dangerous methods off the list until you mean to run them for whoever can open the agent.

What is the rollback if a write misbehaves?

Remove the method from tooling.json and merge that change. The model can still ask. The call does not run. You do not wait for a model redeploy.

Does approval work on every plan?

Approval on Slack or Telegram starts on Business and Enterprise. Free and Pro can allow or deny. A staged write on Free or Pro is present or absent, not held for a person.

Should every method in the vendor catalog be enabled before launch?

No. Enable the methods you have a policy test for. The rest of the vendor catalog can stay downloaded and unused. swy get downloads a bundle. swy add is what turns a method on.