Do you really need an AI agent?

Choose one job that returns every week. It might be sorting enquiries, checking invoices, or pulling the same facts from a stack of files. Name the input, the output, and the moment where a wrong answer reaches another person.

If the job is still "make the business smarter," there is no job to hand over yet. You have a vague project, and vague projects are where expensive promises grow.

The useful question is smaller. Does the job need somebody to read what arrives and choose the next step? Or does it follow a fixed path every time?

I use one line before I let a tool touch work. If I can take the result back, it can run. If another person, their money, or their record feels the result, it waits for me.

Writing a draft into a local folder is usually reversible. A weekly list of missing details is reversible. A message in an unsent drafts folder is still reversible because you can read it and remove it.

Sending the message is different. Moving money, deleting a file, and changing a booking also need an approval step that is visible before the action happens.

I kept the test deliberately boring. A practice folder held 6 fictional enquiries and a response guide. The job was to refresh one local action list, show which items need a person, and leave the input files alone.

In Claude Code Desktop, I saved that as a local routine. I ran it once by hand, then a later scheduled run appeared without another Run now click. It needed one-time permission to replace the existing report. After that approval, it completed.

The raw scheduled report was useful, and it was not clean enough to trust without reading. It counted the days before a course incorrectly and added a few actions that the practice files did not support. I kept that raw output, checked it against the guide, and wrote a corrected report beside it. That is the part many demos leave out.

For the plain route, I copied the same 6 fictional enquiries and response guide into a small fixed script. The copied practice files stayed the same for both routes. The script wrote the same local report filename. It has no instruction to send a message, change a booking, or edit an input file.

This test shows a useful boundary. A scheduled agent can handle a report that needs it to read the current case, while a fixed automation can handle a report whose cases and rules are already known.

My recorded routine needed permission before it replaced its existing output. I only observed one scheduled firing, so I do not treat it as evidence of unattended work over time. The saved routine records its model and effort setting, but no dollar cost reading. The fixed script used no paid API, model, cloud service, or network request in its recorded run. That proves zero external service charge for that run, not zero electricity, computer time, or maintenance work.

Claude Code's current documentation makes another difference clear. A local Desktop task runs on the machine and needs the app open and the computer awake. A cloud Routine can run when the computer is off, but that is a different setup with its own access decisions.

Use ordinary automation when the job follows fixed rules and the input stays predictable. A calendar reminder, a spreadsheet formula, or a short script can be the honest answer. You do not need a model to rename a file the same way every time.

Use an agent when the same job arrives in many shapes and somebody normally has to read, compare, or decide what matters next. The agent earns its place when it reduces that reading while leaving the irreversible part for you.

Pay a builder when they can name your real exceptions and the approval boundary. They are not selling a word when they can show what the tool reads, what it writes, what it will never do alone, and where you inspect it.

Leave the project alone until the repeated job has a name. A tool cannot repair a process before that work has been named.