Why the confusion costs more than a word choice
Calling a single prompt an "agent" is not just imprecise, it changes what people expect. A stakeholder who hears "agent" pictures something that runs unattended and makes decisions; what they usually get is a prompt someone still has to trigger, read, and correct by hand — a real gap between the word used and the thing delivered.
The same slippage happens in reverse: teams call a fully mapped, reviewed, human-in-the-loop process a "workflow" right up until someone asks whether it could run itself, and then quietly start treating it as an agent without ever defining the permissions and boundaries that would make that safe.
The cost shows up at budgeting time too. A project scoped as "building an agent" gets priced and reviewed differently — more scrutiny, more governance — than the same work correctly scoped as "improving a workflow with one AI-assisted step." Misnaming the work invites the wrong level of process around it.
A prompt is not a process
A prompt can improve a task, but it does not define ownership, inputs, review, exceptions, or measurement. That is why prompt libraries often fade when they are not connected to real work.
Ask ten people to write "a good prompt for handling refund requests" and you will get ten different instructions, each capturing a bit of judgement that lives in that person's head. None of them define who approves the refund, what happens when the amount is unusual, or how anyone would know if the prompt started producing worse answers.
That is not an argument against prompts. A good prompt is still the fastest way to test whether a task is even suited to a model before investing in the workflow around it — it is just the wrong unit to build a process out of.
A workflow is the operating unit
A workflow shows how work moves through people, tools, decisions, and handoffs. It is the best place to decide where AI should draft, summarise, classify, retrieve, or stop.
Mapping refund handling as a workflow forces those questions into the open: where the request arrives, what information is needed to assess it, who has authority to approve which amounts, and what gets logged. Once that shape exists, you can decide exactly where a model should draft, summarise, or flag — and where a person must decide.
It is also the level at which most SME AI projects should start and, often, stay. A well-mapped workflow with a model drafting one step of it can run for months without anyone needing to grant it more autonomy than that.
A quick test
If you are not sure which of the three you are looking at, ask one question: what happens the first time this goes wrong? A prompt's failure is a bad output someone edits. A workflow's failure is a step someone catches at the next handoff. An agent's failure is an action already taken that now needs to be undone — which is the reason agents deserve the most caution of the three.
An agent needs boundaries
An agent is only useful when the task, permissions, data, and review rules are stable enough to delegate. Until then, assistive automation usually gives teams more confidence and less risk.
For refunds specifically, that usually means a ceiling on the amount an agent can approve unattended, a clear escalation path for anything above it, and a log a person actually reviews. Skip any one of those and you have handed over judgement without the guardrails that made it safe to delegate.
Those boundaries are not a one-time setup either. As volume grows or the product changes, the ceiling that was safe at launch may no longer be — which is why an agent needs a review cadence, not just a review at the start.
None of this is unique to refunds. The same three questions — what is stable, what is reviewable, and what happens if it is wrong — apply to any task a team is considering handing to an agent.
One task, three framings
Take a single refund request through all three framings. As a prompt, it is one instruction: "draft a reply approving this refund." Useful once, forgotten the moment the next unusual case arrives.
As a workflow, it is the full path: the request lands in a queue, gets checked against the order record, is drafted for review below a set amount, and is escalated above it. As an agent, the same workflow runs with defined permissions — approve below the ceiling, escalate above it, log every action — so a person built the boundaries once instead of re-deciding them every time.
None of the three framings is wrong for every situation. A one-off, low-stakes request is well served by a prompt. A recurring, reviewed request deserves a workflow. Only a request with stable rules and enough volume to be worth delegating deserves an agent — in that order, not the reverse.