Read-Only First

Every new integration an agent touches should start in read-only mode. Not because writes are hard, but because trust is earned in one direction and destroyed in the other.

Here's the pattern in practice. An operations agent at a logistics company got access to the fleet-scheduling API. The obvious move was full CRUD from day one — the agent was supposed to manage schedules, after all. Instead, the team shipped it with read scope only. For two weeks the agent could see everything and change nothing. Its job during that window: propose changes in plain language, in a channel where a human could compare the proposal against reality.

That window caught three bugs that would have been incidents. The agent misread a timezone field and would have shifted an entire depot's schedule by five hours. It treated a soft-deleted route as active. And it double-counted a recurring maintenance block because the API returned it once per occurrence, not once per rule. None of these were model failures in the dramatic sense — they were ordinary misunderstandings of an unfamiliar data source. Read-only mode turned each one into a code review comment instead of a 2 a.m. page.

The deeper reason this works: an agent's first contact with a new system is when its mental model is worst. It hasn't seen the edge cases. It doesn't know which fields lie, which timestamps are UTC-except-when-they-aren't, which "status" values are vestigial. Granting write access at the moment of maximum ignorance is exactly backwards. You want the permission curve to lag the competence curve, not lead it.

There's an organizational benefit too. Read-only launches are easy to approve. Nobody schedules a meeting to debate whether the agent can look at the billing system. So the integration ships weeks earlier, the agent starts building context immediately, and by the time you request write access you arrive with evidence: here are forty proposals it made, here's the accuracy rate, here are the two it got wrong and why. That conversation approves itself.

The graduation path should be explicit, not vibes-based. Define it up front: N proposals reviewed, error rate below X, at least one edge case encountered and handled correctly. Then widen the scope one verb at a time — create before update, update before delete. Deletes might stay human-gated forever, and that's fine. Some doors don't need to open.

The anti-pattern is symmetric access: whatever the agent can read, it can write. That's how service accounts get provisioned when nobody is thinking, because it's one line shorter in the config. Resist it. The read/write boundary is the cheapest safety mechanism you will ever deploy — it costs nothing at runtime, requires no clever prompting, and fails closed by construction.

Start blind to nothing, empowered to nothing. Watch, propose, earn. The agents that operate real systems for years all walked this path; the ones that skipped it usually made the incident report that explains why the next one didn't.

Permission design like this is one of fourteen patterns explored in depth in the book: Ops by Agent — worth a look if you're deciding what your agent should be allowed to touch next.