How to roll an enterprise agent from reads to writes

Security sends the agent project back with one line: the design lets a model update customer records on day one. The team had planned a big-bang connect of six systems because the demo needed all of them. The review does not care about the demo. It cares about which call can be undone.

This post is a rollout sequence ordered by reversibility. Reads first. Low-value writes next. Money, deletes, and identity last, and only with a person in the loop.

Start where a mistake expires on its own

A read that returns a ticket, a balance, or a file the user could already open is the first slice. If the model misreads it, the damage is a wrong sentence in chat. You correct the sentence. You do not file a restore ticket.

Put only those methods in tooling.json. Leave every write out, even the ones the demo used. swy get can download the whole bundle. swy add is the decision. A method you did not add cannot run.

Use IDs you can point at. The docs examples include github.issues.create and github.repo.star. A first release can allow a read you copied from swy list methods and leave both writes out. A later release can add github.issues.create with a test. Leave github.repo.star out until you actually want the agent to star a repository. The sequence is the decision. The provider is only where the IDs came from.

Run the agent on that list until the questions people ask match the methods you enabled. If they keep asking for writes, that is a finding, not a reason to enable the write the same day. Write down the ask. It belongs in the next stage, with a policy.

API compliance for agent integrations is the packet security will ask for before stage two. The checklist before company data is the shorter pass you do before the first read of anything sensitive.

Add writes you can reverse without a war room

A low-value write is one you can undo with another call or by hand in a few minutes. A draft comment. A tag on a test record. An internal note that does not email a customer. Sequence those after reads have been dull for a week.

Each write gets a test in .swytchcode/integrations/policies.json. Block the arguments you will not accept. A comment that mentions an outside email domain is a different risk from a comment on an internal ticket. Encode that. swy policy validate runs the tests. Do not enable the method in the same change that introduces an untested rule.

Give the read week a date when you will open the log, not a date when you hope to feel done. If that week shows a call to a method you thought was off, stop. Fix the allowlist before any write merges. A quiet log is the permission for the next ID. A surprising log revokes it.

There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs. The rollout does not include pasting provider keys into the agent host.

Hold the calls you cannot take back

Refunds, deletes, permission changes, and anything that tells a customer a fact should wait for a person. Human approval on Slack or Telegram starts on Business and Enterprise. The call does not run while it waits. If nobody answers within 48 hours, it expires. A late yes does not send it.

Free and Pro cannot hold a call. On those plans, keep irreversible methods off the allowlist. Deny is the staged state. Turning the method on later is a deliberate release, not a prompt tweak.

Block still wins when both rules could match. A policy that denies a refund over a cap will stop the call even if another rule would have asked for approval. Exit code 6 means the provider never saw it. Exit code 7 means it is waiting.

Tell security the sequence in one page

Reviewers stall projects that say "the agent can use the CRM." They move projects that say which methods are on, which are next, and which stay off until approval exists. Give them the method IDs from swy list methods, the policy tests, and the week you expect to add the first write.

Do not promise a date for refunds in the same plan as the read-only launch. Those are different releases. The read-only launch can ship while the refund method is still absent from tooling.json.

Ship the read-only list. Add one reversible write when the reads have been quiet. Keep irreversible methods off until approval is real on the plan you pay for.

Related reading

• Policy as code for agent calls. The file that makes the sequence reviewable.
• API governance tools for AI agents. Where an allowlist sits next to a gateway.
• Log every API call an agent makes. How you show the read-only week actually stayed read-only.
• API observability for AI agents. What to watch when the first write turns on.

FAQ

Can the demo include a write if production starts read-only?

Keep the demo on the same allowlist as production, or label it as a different project with its own tooling.json. A demo that enables writes on a shared file is a production launch.

What counts as reversible?

You can undo it with a second call or a short manual edit, and a customer never saw it. If undoing it needs a backup restore or a legal note, it is not in the early write stage.

Who is allowed to add the next method?

The same review as any other production change. The diff is tooling.json plus the policy test. A person who can edit the prompt should not be the only person who can enable a write.

What if the model needs a write the list does not have?

It fails closed. That is the point of the sequence. Capture the request, decide if the write is reversible, and add it in a later pull request with a test.