AI use cases: assistant or agent?
Before you call anything an agent, name its three parts: instructions (what it is for, and its boundaries), knowledge (the grounding it answers from), and at least one action (a system it actually reads from or writes to). If you can name all three, you have an agent use case. If you can name the first two but no action, you have an assistant, which is a valid and much smaller build. If you can’t name the knowledge and at least one action, you don’t have a use case yet. You have a demo.
That naming exercise takes ten minutes, and it is worth doing before anyone estimates anything, because the two labels describe builds that differ in almost everything that costs money.
The three parts
Section titled “The three parts”| Part | The question | What a real answer looks like |
|---|---|---|
| Instructions | What is this for, and what is it explicitly not for? | A written role and boundary, not “it helps with support” |
| Knowledge | Which system or documents hold the ground truth? | A named system with a named access owner |
| Actions | What does it read from or write to, beyond a chat window? | A named API, database, or application, with the permission it needs |
Instructions alone are easy; everyone has those by the second meeting. Knowledge is where the first ideas die: if nobody can point at the system that holds the truth, the model will fill the gap with fluent guesses, and a guessing system is not an early version of the right system. Actions are where the word “agent” is earned or lost. An agent, by definition, acts. If your candidate never touches a system, calling it an agent inflates the scope you’re about to price.
No action: you have an assistant
Section titled “No action: you have an assistant”An assistant answers questions from grounded knowledge. A support team asking “what does our warranty cover for water damage?” against the actual policy documents. A sales engineer querying past proposals. Nothing is written anywhere; a human reads the answer and acts on it themselves.
This is not a consolation prize. Assistant use cases are often the right first build precisely because of what they lack:
- No write path means the worst failure is a wrong answer a human can catch, not a wrong booking a human has to reverse.
- No system integration means the build is mostly retrieval and grounding work, not API plumbing, permissions, and error handling.
- Governance is one review step, not an audit trail with rollback.
The honest trade: an assistant only removes the looking-things-up part of the work. The human still performs every action, so the ceiling on saved effort is lower. That is fine. Smaller value at much smaller cost and risk is frequently the better ratio, and it produces the grounding layer a later agent would need anyway.
Knowledge plus action: now it’s an agent
Section titled “Knowledge plus action: now it’s an agent”An agent completes a loop on its own: it reads state from a system, decides, and writes a result back. Consider invoice intake. An assistant version answers “which cost center does this supplier usually book to?” An agent version reads the incoming invoice from the mailbox, matches it against open purchase orders in the ERP, and creates a posting proposal in the accounting system for a human to approve.
The moment that write path exists, three things change at once:
- Scope. You are now integrating with a production system, which means authentication, permissions, malformed input, retries, and what happens when the target system is down. The model is a fraction of the build.
- Cost. Every action needs a defined failure mode, and every failure mode is designed, built, and tested. This is honest engineering effort, not a mark-up.
- Risk. A wrong answer wastes minutes. A wrong write creates state that someone has to find and undo. That is why the action list belongs in the instructions as an explicit boundary: what it may touch, and everything else is off limits.
None of this argues against agents. It argues against pricing an agent while imagining an assistant.
Can’t name knowledge and an action? That’s a demo
Section titled “Can’t name knowledge and an action? That’s a demo”There is a third category, and it fills most “AI opportunity” workshops: an impressive interaction with no named ground truth and no named system. It answers from whatever the model already believes, and it acts on nothing. Demos have a real job, building conviction, and they do it well. But a demo converts to a use case only when someone names the knowledge source and at least one action, and that step is organizational work (who owns the data, who grants access) far more than it is technical work. Until it happens, no scoping estimate means anything.
This page deliberately treats the agent as a checklist of parts. For what an agent is underneath, a model in a loop with its own context, tools, and role, read What is an agent? in Foundations.
Name it, then size it
Section titled “Name it, then size it”Say “assistant” when there is no action and enjoy the smaller build. Say “agent” when there is one and budget for what the write path really costs. Say “demo” when you can’t name the parts, and go do the naming before anyone estimates anything. Once something genuinely is an agent, the next question is not what it can do, but how much of it runs without a human in the loop. That is a ladder, not a switch.