“Let’s build an agent for that.”

That’s a common reaction to almost any problem right now. If there’s a repetitive task, someone suggests wrapping a language model in an “agent” and letting it handle everything end to end.

But an agent is only one option. You can build an agent to automate a task. You can build a normal program. Or you can simply add the functionality to the tools people already use.

The real question is: when should you build an agent, when should you build a regular program, and when should you just extend the existing tool?

Imagine a simple, old-fashioned proofreading workflow. You sit and write a document in a basic text editor. There is no built-in spellcheck, no grammar help, no automatic feedback. When the document is ready to go to print, you print it out on paper. You send this printout to a colleague for proofreading. The colleague reads the document, underlines spelling mistakes, marks typos and other errors, and writes corrections in the margins. Then you get the paper back and sit down at your computer again. You go through the marked-up pages and manually correct the original document in the text editor.

This is a separate, clearly defined step: first you write, then you print, then someone else proofreads, then you correct.

A naive “agent” approach would be to replace the colleague with a language model agent, but keep the rest of the workflow more or less the same. You still write in the same simple text editor. When you are done, you print the document or export it to a file. You send this to a system that scans or reads the document. The agent runs through the text, finds spelling mistakes and other errors, and produces a new, corrected version, maybe with underlines and suggested fixes. You then print or download this corrected version and use it to update your original document.

On paper, this sounds modern: the human colleague is replaced with an automated agent. In reality, it keeps a lot of unnecessary steps. You still print or export. You still send the document somewhere else. You still jump between different tools and representations of the same text. You have built a separate system around the work instead of improving the place where the work actually happens: the text editor.

The smarter solution is the one the world discovered quite quickly for text processing: build spellcheck into the editor itself. Instead of a separate proofreading step, the editor underlines spelling mistakes as you type. You get suggestions directly in the tool where you write. You fix errors immediately, without printing, scanning, or sending anything to a colleague or an agent. Spellcheck is not its own system; it is part of the work tool.

This is the core idea: not everything that can be automated needs an agent. Often, the right move is to bring the functionality into the tool where the user already works, instead of wrapping the old workflow in something that looks clever from the outside.

You might choose an agent when the task really does span multiple tools and systems over time, and there is no obvious main place to put the functionality. You might choose a normal program when it is a separate job with clear input and output. But when the task is tightly connected to what the user is already doing in one tool—like proofreading while writing—the natural place for that functionality is inside that tool, as part of the workflow, not as a separate agent.