Your first read-only agent, with no risk at all

Reading time: about 11 minutes

The situation. You have read the agent lessons and you understand how they work. Building one that actually does something in your pharmacy still feels risky, and rightly so.

The way to lose the fear is not to build a small agent: it is to build one that cannot possibly do harm. A read-only agent can get things as wrong as it likes and the worst that happens is an email with something silly in it. That is what makes it the first one to build.

What you need to hand: Having read what an agent is and the tool contract. This case is those two lessons applied to one small, concrete job.

Step by step

Pick a job that can go wrong without consequences

Any job ending in "and tell me" works. None ending in "and order it", "and send it to them" or "and change it" does.

Good first-agent examples: flag products below minimum with the week’s sales next to them; check whether anything new has gone red on the expiry sheet; compare the delivery received against the delivery note and tell you where they disagree; list what has not sold in three weeks.

They all share a shape: read, compare, summarise and send an email. If your job fits that sentence, it is a good first agent.

Safety is not in the prompt: it is in what you do not give it

This is the one thing in this case you really have to understand, and it is what separates a safe agent from one that looks safe.

If you give it a tool that writes and tell it "do not write", you are trusting it to obey. It will almost always obey. Almost.

If you give it no tool that writes, it cannot write however much it wants to, however wrong it gets, however odd an instruction somebody buried in the data it reads. This is not a matter of degree: they are two different situations.

So the design starts with the tool list, and it contains only looking verbs: read_sheet, check_stock, list_sales. And one output: email_the_owner, with the recipient fixed in the code, not as a parameter. If the recipient is a parameter, the agent chooses who it writes to.

Help me design a READ-ONLY agent for a pharmacy.

JOB: <<every day at 7:00, look at the expiry sheet and tell me if
anything new has appeared as EXPIRED or URGENT since yesterday>>

CONSTRAINTS THAT ARE PART OF THE DESIGN:
- The agent CANNOT write, modify or delete anything anywhere.
- Its only output is an email, and the recipient is fixed in the code:
  it is not a parameter it can choose.
- Maximum 8 loop turns. If it runs out, it emails to say it could
  not finish.
- If data is missing, it says so in the email. It does not assume.

GIVE ME, IN THIS ORDER:
1. The list of tools it needs, with each one’s contract: what it takes,
   what it returns, and what happens when it fails.
2. For each tool, whether it READS or WRITES. If any writes, tell me
   why and propose a non-writing alternative.
3. The agent’s instructions (the system prompt).
4. The loop code.
5. A LIST OF 5 WAYS THIS COULD GO WRONG, and what in the design
   prevents each. If one is not prevented, say so plainly.

On point 5 do not reassure me. Find the real failures.

Review the tool list before the code

The code is long and it is the least of it. The tool list is ten lines and that is where all the safety lives.

Read the names one by one. Anything starting with create, update, delete, send, mark, move or save writes, however innocent the name sounds. mark_as_reviewed writes. save_report writes.

If any appear, do not fix them with an instruction: remove them. And if the job genuinely needs one, then this is not your first agent. Swap it for one that does not, and keep this for when you have three running.

And check the email recipient does not appear as a parameter in any call. It is the commonest slip in this design and easy to spot: search the code for your own address and see whether it is written there or travelling inside a variable.
Dry-run it before giving it access to anything

Before connecting it to your real sheet, ask it to run with fake data: an eight-row table you write yourself, with two expired, one urgent and one empty date.

That shows everything that matters: whether it detects what it should, whether the email reads well, and — best of all — how many loop turns it took for something this simple. If it took seven to read eight rows, something is badly framed and you will pay for it daily.

Then feed it an ugly case on purpose: a row with the date written as text. An agent that accepts that row is failing silently, which is exactly what you do not want it doing alone at seven in the morning.
Let it run for a week and watch it every day

For the first seven days, check every email it sends against the sheet. That is not distrust: it is the only way to know whether what you built does what you think.

What to look at is not whether the email is well written — it always is — but whether what it says is true. That what it flags really is red, and that what it does not flag really is not. The second is the important one and almost nobody checks it: an agent that fails to mention something leaves no trace.

If a week goes well, leave it. And set a reminder for a month out with one task: check one whole email against the sheet. That is the difference between having an agent and having an email that arrives.
When to take the next step, and what it is

The next agent is not "one that writes". It is another read-only one, with a different job. And then another. Until you have three running and checked and watching them bores you.

Only then does an agent that writes make sense, and the way to do it is not to grant write access: it is to have it prepare the draft and have you approve it. An agent that leaves the order ready and waits for your "yes" has all the advantages of automation and none of the consequences.

That boundary — writing requires human approval — is what the agents in production lesson takes seriously. This case leaves you right in front of it, with one running and your hand in.

A full example, and what is wrong with it

The step 2 brief — look at the expiry sheet and report anything newly red. This is point 1 and point 5 of what it returned, the two you must read.

What it replies

Tools:

read_sheet(range) → returns the rows. READS.
read_previous_state() → returns what was reported yesterday. READS.
save_state(list) → records what was reported today. WRITES.
send_email(recipient, subject, body) → sends the alert. WRITES (external).

Five ways it could go wrong: 1) The sheet is empty → the agent reports zero products. 2) A badly written date → that row is ignored. 3) The email fails → it retries. 4) The sheet has more rows than expected → they are processed anyway. 5) The agent exhausts its turns → it emails to say so.

"The design is safe: the agent cannot modify business data."

And now, what is wrong with that reply:

There is the tool that writes, with an innocent name. save_state sounds like bookkeeping and it is a write. It is honestly declared as WRITES — that part it did well — but the brief said it must not write anything and it put it in anyway, because "report only what is NEW" requires remembering yesterday. The model solved the problem and skipped the constraint without flagging it.
And the right exit is not removing it: it is changing the brief. Remove save_state and the agent tells you the same thing every day, and within a week you switch it off. The good exit is giving up on "only what is new": have it send the whole urgent list each day. It is four lines of email and the agent stops writing anywhere. Worse on paper, and it is your first agent.
The recipient is a PARAMETER in send_email. That means the agent chooses who it writes to. Today it writes to you; the day a row in the sheet contains odd text, it might not. The recipient goes fixed in the code and the tool becomes email_the_owner(subject, body) — two parameters instead of three, and one less thing it can choose.
And point 5 reassured you, which was the forbidden thing. The five "ways it could go wrong" are all operational and none is about safety: it does not mention malicious data, nor what happens if a tool returns something unexpected, nor the save_state it just introduced. And it closes with "the design is safe". The prompt said "do not reassure me" and it did anyway — ask again, pointing at what it missed.

Two design problems and both are in the tool list, which is ten lines. The code was eighty and did not need reading.

That is the lesson: an agent’s safety is reviewed in the tool list, not in the code. If none of them writes, it cannot write — whatever the prompt says, whatever the model reasons, and whatever somebody put in a piece of data.

And if your pharmacy is not like that

If you do not know where to start building it. Start without an agent: the previous case’s script already reads the sheet and sends the email, with no loop and no model. If that is enough, do not build an agent — an agent earns its place when something has to be decided, and "filter by a column" is not deciding.

If you also want a plain-language summary. There the model starts to earn its place: "you have three urgent items and two are from the same supplier" is something a script does not compose. It stays read-only and costs one call a day. That is the first place an agent adds something a script does not.

If the brief has to look at two places at once. There the agent wins too, because the number of turns depends on what it finds. But the risk rises: two sources are two places odd data can enter. Do it once you have three single-source agents running, not as your first.

If somebody else is going to build it for you. Ask for the tool list before anything else and review it yourself with the verb rule. It is ten lines, you do not need to code to read it, and it is where all the safety lives. If they hand you the code without the list, ask for it — not having it written down already says something.

When it does not work first time

It takes many turns for something simple.

Nearly always it is being fed data in pieces and having to ask again. If your tool returns twenty rows at once instead of one per call, the agent resolves in two turns what used to take twenty. Tool design decides the cost more than the prompt does.

The email it sends is confusing.

Give it the exact format in the instructions, with a written example: "one line per product, in this order: product · batch · days · location". Without an explicit format it writes it differently every day, and an alert that keeps changing shape gets read worse each week.

It tells me about things I have already binned.

Because the sheet still has them. It is the price of giving up "only what is new", and the solution is not granting write access: it is you deleting the row when you remove the product. One minute of your time a month against a tool that writes to your data — not a close call.

It works but I do not know if it is telling me the truth.

The check is step 5’s and it has to go both ways: that what it flags really is red, and — what almost nobody checks — that what it does not flag really is not. An agent that stays silent about something leaves no trace, so that side is only checked by looking at the sheet.

Before you use what it gave you

No tool the agent has writes, modifies or deletes anything.
The email recipient is fixed in the code, not a parameter.
There is a turn cap and it reports when it runs out.
You tested it with fake data before connecting it.
You fed it an ugly case on purpose and know what it does with it.
You have a reminder set to check it again in a month.

It slips in a tool that writes. And with a name that does not look like it. mark_as_notified sounds like bookkeeping and is a write to your sheet. That is why you review the tool list before the code, and by name.

It reassures you on point 5. Ask for risks and it tends to list three generic ones and say the design covers them. Read them closely: if none mentions what happens when the data is wrong or a tool fails, it did not really look. Ask again with "do not reassure me".

It takes many turns for something simple. Not a safety failure but it decides whether this pays: every turn costs and grows with what it has accumulated. If it needs seven to read one sheet, the job is badly described or the first call is missing data.

It proposes "improvements" that break read-only. The moment you show it works, it suggests marking the flagged rows, sorting the sheet or moving expired items to another tab. All are writes and all sound like improvements. The default answer for your first three agents is no — and when it becomes yes, it will be with human approval in between.

Now, with your own. Take the expiry sheet from the previous case and build this agent on top of it. It is the easiest job in the world to check — you can look at the sheet and see whether it got it right — and when the first correct email arrives you will understand at once why this deserved four lessons.

← All practical cases Back to the school →

Your first read-only agent, with no risk at all

Step by step

Pick a job that can go wrong without consequences

Safety is not in the prompt: it is in what you do not give it

Review the tool list before the code

Dry-run it before giving it access to anything

Let it run for a week and watch it every day

When to take the next step, and what it is

A full example, and what is wrong with it

And if your pharmacy is not like that

When it does not work first time

Before you use what it gave you