What an AI agent actually is
"AI agent" gets used loosely enough to mean almost anything. The concrete, buildable definition is narrower and more mechanical than the marketing version — an LLM, a set of callable tools, and a loop.
3 min read
The narrow, buildable definition
That loop — "let the model decide, step by step, whether it needs more information or needs to take an action before it can answer" — is the actual mechanical difference between a chatbot that just talks and an agent that can do things. Everything else people mean by "AI agent" (autonomy, planning, memory, personality) is built on top of this same loop; the loop itself is the part worth understanding cold before any of the fancier framing.
Tools: functions the model can ask to have run
A tool, from the model's side, is just a described function: a name, a natural-language description of what it does, and a schema for its arguments. The model never actually executes anything — it emits a structured request ("call get_available_slots with { date: '2026-06-10' }"), and the application's own code is what actually runs that function and returns a result back into the conversation.
This is the mechanism that lets an agent answer with facts it was never trained on and couldn't possibly know — today's actual appointment availability, a specific customer's specific order status — by handing it the ability to ask for that information mid-conversation, rather than trying to bake it into the model itself.
Why streaming is the expected default, not a nice-to-have
Generating a response token-by-token takes real, human-perceptible time — often several seconds for a substantive answer. Streaming means sending each token to the client as soon as it's generated, rather than waiting for the entire response to finish and sending it all at once. The mechanism is typically Server-Sent Events (SSE): a long-lived HTTP response the server keeps writing chunks into, that the browser reads incrementally.
Users have been trained by every major chat product to expect the second experience — the visible "typing" effect isn't decorative, it's what makes a multi-second response feel responsive instead of frozen. A non-streaming agent endpoint is a noticeably worse product experience for the exact same underlying model and latency.
A genuinely stateless agent is a legitimate, simpler starting point
Not every agent needs conversation memory, tools, or persistence. A simple product-info chat widget — no login, no history kept between page loads, answering purely from context stuffed into the system prompt (product descriptions, FAQ content) — is a real, complete agent in the narrow sense above, just one where the loop typically never needs to call a tool at all. It's worth building or recognizing this simpler shape first, before reaching for tools, persisted sessions, or write actions, all covered in later lessons in this domain.
Further reading
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What is the actual mechanical loop that distinguishes an agent from a plain single-shot chat completion?
2. A model emits a tool call for get_available_slots with a specific date. What actually looks up the real availability data?
3. Why does a non-streaming agent endpoint feel like a worse product experience than a streaming one, even with identical underlying latency?
4. A simple product-info chat widget answers questions purely from FAQ content stuffed into its system prompt, with no tools and no saved history between visits. Is this a legitimate agent?