Why Your First AI Feature Should Be Read-Only

The pattern I see most often in AI product reviews: a team gets excited about what the model can do, ships a feature that can create, update, or delete something real, and then spends the next quarter explaining a weird edge case to legal.

The pattern I recommend instead: ship a read-only feature first. Always.

The Asymmetry

LLMs fail in two shapes. They produce wrong answers, and they produce confident wrong actions. Those failures have very different blast radii.

┌───────────────────────────────────────────────────────────┐
│           Failure Mode Asymmetry                           │
├───────────────────────────────────────────────────────────┤
│                                                            │
│   Read-only feature fails:                                 │
│     → User sees a wrong answer                             │
│     → User asks again, or reads the source, or shrugs      │
│     → You fix the prompt / retrieval                       │
│     → Blast radius: one conversation                       │
│                                                            │
│   Write feature fails:                                     │
│     → Agent updates the wrong record                       │
│     → Email sends to the wrong list                        │
│     → Refund issues for 10x the amount                     │
│     → Blast radius: everyone downstream, plus compliance   │
│                                                            │
└───────────────────────────────────────────────────────────┘

A wrong answer is embarrassing. A wrong action is a ticket, a rollback, a customer email, sometimes a regulator. You can absorb wrong answers during the "is this useful?" phase of a product. You cannot absorb wrong actions.

Starting read-only buys you the evaluation data you need — without risking the thing the company actually cares about.

What "Read-Only" Actually Means

Read-only is not just "the tool doesn't have a DELETE in it." It's a design stance that applies at every layer:

• Data layer: the credentials your AI holds cannot mutate anything. Use a separate DB user with SELECT grants only.
• API layer: the tools you expose return data, not side effects. No POST, PATCH, or DELETE wrappers.
• Infra layer: rate limits are per-query, not per-mutation, because there are no mutations.
• Social layer: the feature is marketed as "ask" or "look up," not "do." User expectations set the blast radius.

The Four Questions Before Write Access

Eventually you want to let the AI do things. Before any tool graduates from read to write, I ask four questions. If the answer to any of them is "not yet," the tool stays read-only.

1. Is it reversible?

Can a human undo this action inside of five minutes, without engineering support? Adding a note to a record: yes. Sending an email: no. Processing a refund: depends on how your finance system works.

Irreversible tools need a human-in-the-loop step permanently, not just during the pilot.

2. Is it logged?

Every write needs a structured audit record before it happens, including the prompt that triggered it, the tool call arguments, the user who was in the loop, and the outcome. If the log schema doesn't exist, the tool doesn't ship.

3. Is it approved?

Who, specifically, clicked the button that caused this action? "The agent decided" is not an approver. During the first months of write access, the answer should always be a named human — even if the UI makes approval a single tap.

4. Is it rate-limited?

Not just globally, but per-user and per-tool. The worst AI incidents I've seen were not one bad action — they were one bad action repeated 8,000 times in a loop before anyone noticed. Rate limits turn disasters into anomalies.

What You Lose By Starting Read-Only

Almost nothing. You ship later by a couple of weeks, and you tell your most ambitious stakeholder that the agent can't yet take actions in the system of record. In exchange, you get:

• Real usage data that tells you which actions users actually wanted the AI to take.
• A retrieval quality baseline that you can point to when something regresses.
• An audit trail pattern already wired up, which is the hard part of the write phase anyway.
• A team — including legal and security — that trusts the rollout cadence.

Every one of those is worth more than the two weeks.

The Graduation Path

When I graduate a tool from read to write, it goes through three gates:

1. Describe-only: the agent can describe the action it would take, but cannot execute it. A human clicks to confirm. Logs capture both the description and the decision.
2. Execute-with-approval: the agent executes after a named human approves in the UI. Rate limits and audit logs are live. Runs for at least two weeks.
3. Autonomous within bounds: the agent executes without approval, but only for actions under a specified risk threshold — small dollar amounts, low-impact records, reversible operations. Higher-risk actions stay in gate 2 indefinitely.

Most tools live happily in gate 2 forever. That is not a failure. That is a well-designed product.

The boring version of AI — the one that helps without surprising anyone — is the one that ships, stays up, and keeps growing. Start read-only. Earn the write access.