Why your first AI agent should be read-only

Every client who asks for an agent wants it to do something. Fix the ticket, update the record, restart the service. That is the whole appeal, and it is also the reason most first attempts get quietly shelved.

We now open almost every agentic engagement the same way: build it read-only first, run it for a few weeks, and only then decide what it is allowed to touch.

This is not caution for its own sake. It is the fastest path to a write-capable agent you actually trust.

You do not yet know what it will get wrong

Before an agent runs against your real systems, your model of its failure modes is imagination. After two weeks of it reading your real data, you have a list.

That list is almost never what teams predict. The agent rarely fails in the dramatic ways people fear. It fails because your log format changed last quarter, or because two services share a name, or because a field that is nullable in the schema is never null in practice except for one legacy customer.

None of that shows up in testing. All of it shows up in a week of read-only operation, and every item on the list is a permission you now know how to scope.

Read-only agents are already useful

The framing that a non-acting agent is a demo is wrong. An agent that reads across five systems and tells you what it found is doing the part of the job that eats the most human time.

Triage, correlation, summarisation, first-pass diagnosis. On an incident, the mechanical work of pulling logs, checking the deploy diff, and reading three dashboards is most of the first ten minutes. An agent that hands you that context and a proposed action, for you to run, captures most of the value with none of the risk.

Plenty of clients stop here and are happy. That is a legitimate outcome, not a failed project.

Proposals are training data for your permission model

While it is read-only, have the agent propose the action it would have taken, and record it.

After a few hundred proposals you can go through them and sort them into three piles: I would have approved this instantly, I would have wanted to look first, and absolutely not. Those three piles are your risk tiers, derived from evidence instead of guesswork.

That is a far better foundation than a workshop where everyone speculates about what the agent should be allowed to do.

Then widen, narrowly

When you do grant write access, grant it one tool at a time, starting with the most reversible one. Creating a draft. Adding a comment. Opening a ticket.

Each expansion is a small decision backed by real data about how the agent behaves in that specific situation. Compare that to the alternative, which is granting broad access on day one, watching something go wrong, and revoking everything in a panic. Teams that do the second thing usually do not get a second attempt, because trust in the whole idea is spent.

Slow is not the opposite of ambitious here. It is how the ambitious version survives contact with production.