Most people who use LLMs every day are not using AI agents. They are using prompts — one question in, one answer out, maybe a follow-up or two. The LLM is a sophisticated search engine with a better sentence completer underneath.
An agent is different. An agent is a system that uses an LLM to decide what to do next, that maintains state between steps, that can call tools, that can run unattended, and that can correct its own course mid-flight based on what it finds.
The gap between prompts and agents is where most early agent projects quietly fail. Not because the LLM is bad. Because the person building the system expected it to work like a better prompt and it does not.
What a prompt does
A prompt is a message you send to an LLM. The LLM responds. You send another prompt. The LLM responds again. Every turn starts fresh — the model sees the conversation history, processes it, and returns text.
There is no memory that persists outside the prompt. There is no decision about what tool to call. There is no state to track progress through a task. The model does what you ask, one step at a time, and then stops.
This is genuinely useful. Writing a paragraph, summarizing a document, explaining a concept — these are prompt tasks. They have clear inputs, clear outputs, and no need for persistent context.
What an agent does differently
An agent adds five things on top of the LLM:
A loop. The agent runs multiple turns without re-prompting from the human. It decides whether it is done or whether it needs another step. The agent loop is the core operating rhythm.
Tool use. The agent can call functions — search the web, read a file, run code, send a message — and use the results of those calls to decide its next step. A prompt cannot do this; it stops at text.
State that persists between turns. The agent writes to memory, updates a working state, or appends to a log. Its next turn starts from that updated state, not from zero. The session is the unit that holds this state.
Orientation toward a goal. A prompt answers a question. An agent works toward an outcome — sometimes over dozens of steps, across hours or days, with checkpoints and corrections along the way.
The ability to delegate. A mature agent system can spawn sub-agents or hand off work to a specialty desk when a task requires a different context or skill set.
The gap in practice
Here is where it goes wrong in practice.
Someone builds a "research agent" by writing a long, detailed prompt: "You are a research assistant. For any topic I give you, search for relevant information, synthesize the key findings, and present a structured summary." They test it. It works. They put it on a schedule to run every morning.
What they have built is not an agent. It is a very detailed prompt that runs on a timer. Each morning it starts cold. It has no memory of what it found on previous mornings. It has no way to correct itself if it produces a hallucination on Tuesday and nobody notices until Friday. It has no way to decide that a topic is too thin to research further, or that a source is unreliable, or that the output should be formatted differently for a different recipient.
These are agent problems, not prompt problems. They require memory, tool use, bounded context, and a loop that evaluates whether the research is good enough before returning it.
The vocabulary trap
"Prompt engineer" and "AI agent builder" are different jobs. They share a foundation — both work with LLMs — but the skills do not fully transfer.
The vocabulary in this space is genuinely messy. People say "agent" to mean "a prompt that runs on a schedule." People say "skill" to mean "a prompt library." People say "memory" to mean "the last 50 messages in the conversation." None of these usages are wrong, exactly, but they are imprecise in ways that make architecture decisions harder.
Triadive's dispatch on the vocabulary tax goes deeper on why this matters for operations.
The honest transition path
If you are coming from prompts and you want to build something that qualifies as an agent:
1. Start with a single agent loop that does one task well, with memory, with tool calls, and with a clear definition of done. 2. Add logging so you can see what the agent decided and why. 3. Test it failing — deliberately give it bad inputs, incomplete context, and edge cases. Prompts fail predictably; agents fail in interesting ways. 4. Only then add a second loop, a second tool, a second agent.
The failure mode is skipping steps 1–3 and going straight to "I will build a team of agents." The result is a system that is twice as complex as a prompt and one-tenth as reliable.
Related terms
An agent runs on an agent loop. A single agent doing one task is a session. A system with one coordinator and multiple specialists is a multi-agent architecture. The coordinator is the CEO agent; the specialists are specialty agents running their own work desks.
For the intermediate-grade version of this topic, see Work Desks and Specialty Agents — what changes in the architecture when you move from one agent to a team.