Exam-style
A logistics company sends a nightly summary to its depot managers. The job takes yesterday's bookings, calculates three figures (total deliveries, average delivery window, and the percentage completed on time), formats them into a short report with a plain-English covering paragraph, and emails it at 06:00. The steps have not changed in two years and nobody expects them to. A team proposes building it as an AI agent with tools for the database, the calculations and the mailer. What should be built?
Reveal the answer
B. A fixed workflow orchestration: query the bookings, compute the three figures in code, call a foundation model once to write the covering paragraph, and email the result
Every step of this job is known before the job starts, and that settles it. Ordinary workflow orchestration runs the four steps in the order somebody wrote down: a scheduled query, three calculations in code, one model call to turn the figures into a readable paragraph, one send. The cost per night is fixed because the number of model calls is fixed. The arithmetic is exact because a database and a few lines of code did it rather than a language model. When a figure looks wrong at 06:30, the run is reconstructable step by step. The model is used for the one part of the job that needs language, and nothing else.
AI agents exist for the opposite situation. An agent is a foundation model given a goal, a catalogue of tools it may call, and a record of what it has already done. Then it is put in a loop, choosing the next tool from what the last one returned. That tool usage and that choosing are what let an agent finish multi-step tasks whose steps nobody could write down in advance: a customer request that turns into a negotiation, an investigation that goes wherever the last answer points. Amazon Bedrock AgentCore is the managed home for exactly that, supplying the runtime, the gateway that exposes existing APIs as tools, memory and traces. It is the right service for an agent and it does not make this job an agent-shaped job. Handed a fixed sequence, the loop still runs. It burns model calls deciding what a schedule already decided, and it can produce a different step order tonight than it did last night. The nights it costs three calls and the nights it costs twelve bill differently for identical work. Two agents double the loops and add the coordination between them, which is more of the same expense with nothing gained.
The single long prompt fails on two counts. A night of bookings pasted into the context window is a large input-token bill for a calculation a SUM would have done, and the arithmetic is being asked of the least reliable component available. More basic than that, a model call returns text. It cannot send an email. Something outside the prompt has to take the action, and once that something exists it is the workflow.
Retrieval Augmented Generation misreads what kind of job this is. RAG is for finding relevant passages in a body of documents when nobody knows in advance which passages matter. Last night’s bookings are a known set of rows retrieved by a query with a date in it. There is nothing to search.
The test to carry into this scenario: an agent is worth building when the sequence of steps is not knowable in advance, and costs more than it returns when it is.
Q. A nightly report pulls yesterday’s bookings, works out three fixed figures, writes them up and emails them at 06:00. The steps have not changed in two years. Build it as an agent?
A. No. Build it as ordinary workflow orchestration: a scheduled query, the three calculations in code, one model call for the covering paragraph, one send.
Why? AI agents are for multi-step tasks whose steps nobody can write down before the request arrives. The loop and the tool usage decide what happens next from what the last step returned. Amazon Bedrock AgentCore is the managed place to run one, with a runtime, a gateway that turns existing APIs into tools, memory and traces. Point it at a job whose steps were settled two years ago and the loop deliberates over a decision already made, at a bill that changes night to night. A fixed sequence costs the same every run, gets the arithmetic exactly right because code and a database did it, and can be walked through line by line when a figure looks wrong. One long prompt with the bookings pasted in pays input tokens for a SUM and still cannot send the email, since a model call returns text and nothing else. Retrieval Augmented Generation answers a different need again, finding the relevant passages in a corpus when nobody knows which ones matter; a date-filtered query over last night’s rows is not a search problem.