A chat answers one message at a time. An agent pursues a goal across multiple steps — calling tools, observing results, and adapting. That loop adds power and new ways to fail.
Properties of an agentic setup
- Objective — what "done" means (even if approximated).
- Tools — bounded capabilities (HTTP, DB queries through safe APIs, code execution sandboxes).
- State — conversation history, scratchpad, or structured plan.
- Stop policy — max steps, max cost, or success predicate.
Without a stop policy, loops can burn tokens or hammer APIs indefinitely.
When agents are worth it
Agents help when tasks are multi-step and dynamic — research with sources, multi-file refactors with tests, or IT tickets that need several queries.
They are overkill when a single retrieval + one LLM call suffices, or when deterministic code should run instead of an LLM.
Risks
Each tool call is a potential failure or injection surface. Narrow tools, validate arguments, and cap side effects.
Key takeaways
- Agents = goals + tools + multi-turn control logic — not a bigger prompt alone.
- Add explicit budgets and termination conditions before scaling traffic.
- Prefer the smallest architecture that meets the job — chat, RAG, workflow, then agent.