"Agent" is doing too much work
The word "agent" now covers almost anything. A single chat prompt gets called an agent. A cron job with an LLM in the middle gets called an agent. So does a system that plans, calls ten tools, and retries on failure.
Strip the branding and most useful agents share the same small shape: something happens, the system gathers what it needs, does the work, and puts the result where a human or another system will see it. Four steps: trigger, data, action, deliver. If you can name each step for your use case, you can build it. If you can't, you don't have an agent yet, you have a vague hope.
The loop: trigger, data, action, deliver
Here it is as plain pseudocode:
on trigger: # a webhook, a cron, a new row, a message
context = gather() # read files, query APIs, pull the record
result = act(context) # the LLM call, tool use, or computation
deliver(result) # Slack, a PR, a DB write, an email
Every reliable agent I've shipped fits this. The interesting engineering is almost never in the LLM call. It lives in the other three steps: making the trigger fire at the right time, feeding the model exactly the data it needs and nothing more, and delivering somewhere that fails loudly when it breaks.
A concrete example: "summarize new support tickets and flag the angry ones."
- Trigger: a new row in the tickets table.
- Data: the ticket text plus the customer's plan and last three tickets.
- Action: classify sentiment, write a one-line summary.
- Deliver: post to a Slack channel, add a label in the helpdesk.
No planning loop, no autonomy. It runs, and it's useful.
When a prompt is enough
Most tasks don't need an agent. They need a good prompt you run yourself.
Use a plain prompt when the task is one-shot, you're already at the keyboard, and you can eyeball the output. Rewriting an email, drafting a SQL query, explaining a stack trace: opening a chat and pasting context is faster than any pipeline you'd build, and you catch mistakes on the spot.
Building an agent has a real cost: a trigger to maintain, credentials to store, error handling, logging, and a new thing that can page you at 2am. That cost is worth paying only when the task repeats and the human in the loop is the bottleneck.
When it's worth building
Build the agent when three things are true:
- It repeats. Same shape, many times a day or week. One-offs never earn back the setup.
- The trigger is real, not you remembering. If a system event can start it (a webhook, a schedule, a file landing), it's a candidate. If the only trigger is "when I feel like it," keep it a prompt.
- You can define "done." You know what good output looks like well enough to check it, automatically or at a glance.
If any of these is missing, you're building a toy that will quietly rot.
Keeping it reliable
The gap between a demo and something you trust is almost all error handling.
Narrow the job. One agent, one task. "Read the invoice, extract totals, write a row" beats "handle all our finance ops." Small scope means you can actually verify it.
Make deliver idempotent. Triggers fire twice. Retries happen. If your agent posts to Slack or writes a row, make a repeat run safe: check for an existing result, use an idempotency key, upsert instead of insert.
Constrain the action. Give the model tools with tight signatures instead of free-form shell access. A function that takes a ticket ID and a label is auditable. "Run any command" is not.
Log the whole loop. Store the trigger payload, the data you gathered, the model's output, and what you delivered. When it misbehaves you want to replay the exact run, not guess.
Fail loud. A silent agent that stopped working is worse than no agent, because you stopped doing the task by hand and nobody noticed. Alert on zero runs, not just on errors.
Where this is weaker
This loop is honest about its limits. It fits tasks with a clear trigger and a checkable output. It does not fit open-ended research, long autonomous planning, or anything where "done" is fuzzy and a wrong action is expensive. Multi-step agents that plan and self-correct are real and sometimes worth it, but they are much harder to keep reliable, and most teams reach for them long before they need to. If you can collapse a problem into trigger, data, action, deliver, do that first. Add autonomy only when the simple loop provably can't do the job.
Start with one task
Pick the single most annoying repetitive thing you did this week. Write down its four steps. If you can fill in all four, you have your first agent, and it'll probably take an afternoon, not a sprint. Ship that one. You build reliability on small loops, not by bolting it onto a big one.
I write about turning AI from a chat toy into a working tool. I help build AGINE Academy, a game-based academy for learning Claude by real practice. It is an independent product and is not affiliated with Anthropic.
Top comments (0)