What Makes an Agent an Agent
From static text to continuous action
Here's the thing, when you call an LLM with a prompt, you get back some text and that's it. The model doesn't perceive anything, can't take action, and can't reflect on whether its response actually worked. It's a brilliant text generator, but it's fundamentally passive.
An agent is different. Agents are autonomous systems that operate in continuous loops, they perceive their environment (maybe reading your CRM data or monitoring a file system), reason about what to do next, execute actions through tool calls, observe the results, and adjust their approach. This perceive-reason-act-reflect cycle is what separates agents from simple LLM calls.
From what I've seen in production systems, the distinction matters. An agent handling a customer inquiry doesn't just draft a response, it searches your knowledge base, checks account status in Salesforce, evaluates escalation criteria, routes the ticket, and logs every step. It's doing work, not just generating text.

Check your understanding
You're building a system to process customer support tickets. Which of the following would qualify as a true agent rather than just an LLM wrapper?
The ReAct pattern: thinking and acting in lockstep
The breakthrough that made modern agents practical came from Shunyu Yao's 2022 ReAct paper. The idea is elegant: interleave chain-of-thought reasoning (Thought) with tool actions (Action) and environmental observations (Observation). Instead of planning everything upfront or acting blindly, the agent reasons one step at a time, acts, sees what happens, and decides what to do next.
Let's say you're building a sales lead qualification agent. It thinks 'I need to find recent conversations from healthcare vertical', searches your CRM, observes the results, then thinks 'Three accounts match, let me check their engagement scores', fetches that data, observes again, and finally segments them. Each thought informs the next action; each observation updates the agent's understanding.
The pattern is adaptive and works beautifully for exploratory tasks. Chi Wang and Qingyun Wu built AutoGen (now AG2) around this loop, and it's the foundation for most production agent systems in 2026. One catch: ReAct can be expensive, every reasoning step burns tokens, and sometimes it gets stuck in local optimization loops when it lacks foresight.
ReAct in the wild: CTF cybersecurity agents
A ReAct agent tackling Capture the Flag cybersecurity challenges with GPT-4o hit 83% task completion, not bad. But when researchers added a planning step before the ReAct loop (the hybrid ReAct&Plan approach), success jumped to 95%. The upfront plan gave the agent strategic direction, and the ReAct loop gave it the flexibility to adapt when things didn't go as expected.Check your understanding
Planning strategies: when to think ahead
Not every task benefits from step-by-step reasoning. Plan-and-Execute separates strategic planning from tactical execution. A Planner agent decomposes your goal into an ordered list of steps (without calling any tools), and an Executor agent, typically a ReAct loop, runs those steps in sequence.
This pattern shines in structured workflows. IBM's multi-agent RAG system uses a planner to break down complex pharmaceutical research queries, then hands off to a research assistant and report generator. Novo Nordisk's drug discovery agents follow the same architecture. The planner provides foresight; the executor provides adaptability.
In practice, most production systems use hybrid planning (what researchers call ReAct&Plan). Generate a rough plan upfront, then execute step-by-step with the freedom to deviate based on real-time feedback. Denny Zhou's LATS (Language Agent Tree Search) work takes this further, exploring multiple reasoning paths in parallel, evaluating and pruning branches, but that's overkill for most business workflows. For high-stakes, complex problems, though, Tree-of-Thought can be worth the overhead.
Check your understanding
Match each planning strategy to the scenario where it works best.
Tool calling: the I/O layer that makes agents real
Here's where the rubber meets the road. Tool calling is what transforms an LLM from a text generator into an active agent. The agent decides it needs to search your CRM, so it generates a structured function call with parameters, search_crm(vertical='healthcare', last_contact_days=30), and your system executes that call, returning results the agent can reason about.
The LLM reasoning part is actually the easy part. The hard part is the engineering infrastructure: authentication, error handling, schema validation, API rate limits, retries, secure execution. In 2026, tools like AG2 and newer frameworks handle a lot of this plumbing, but you still need to design your tool interfaces carefully. Good tool design means clear descriptions, well-typed parameters, and meaningful return values.
One pattern I've seen work well: Salesforce account creation workflows where the agent chains tools. It calls the Salesforce API to create an Account, parses the response to get the AccountID, then uses that ID to create a Task and assign ownership. State management across tool calls, remembering what happened and passing context forward, is where a lot of naive implementations fall apart.
Autonomy has a failure mode
More autonomy is not always better. Agents can get stuck in loops, make expensive API calls repeatedly, or confidently do the wrong thing. Production systems need guardrails: iteration caps, human-in-the-loop checkpoints for high-stakes actions, confidence thresholds for automatic execution. Balance autonomy with reliability.Memory and state: what agents remember
A single-turn agent is barely an agent at all. Production agents need memory, they have to remember what they've tried, what worked, what the user said three steps ago, and what the overall goal is. This breaks down into a few layers.
Short-term memory is your agent's working context, the conversation history, the current plan, intermediate results. Long-term memory often lives in a vector database: past interactions, learned user preferences, successful tool call patterns. State checkpointing lets you pause and resume multi-step tasks, critical for workflows that span hours or days.
AG2's 2026 Beta architecture introduced event-driven pub/sub patterns where agents publish state changes to named streams and subscribe to relevant events. This decouples agent state from conversation flow and makes it much easier to build stateful, production-scale systems. If you're building anything beyond a demo, think hard about how you'll persist and retrieve state, it's not glamorous, but it's the difference between a cool prototype and something you can actually deploy.
The cognitive architecture is the real product
Agents are not just LLMs with better prompts. You're building a complete cognitive architecture: perception (reading from APIs, databases, files), reasoning (ReAct or planning loops), action (tool execution with error handling), and reflection (evaluating outcomes and adjusting). The LLM is just one piece. The architecture is what you ship.Key takeaways
- Agents operate in continuous perceive-reason-act-reflect loops; LLMs are passive text generators that stop after one response.
- ReAct interleaves reasoning with action and observation, making agents adaptive, but it can be expensive and myopic without planning.
- Plan-and-Execute separates strategic planning from execution; hybrid approaches (ReAct&Plan) combine foresight with adaptability for most production workflows.
- Tool calling is the I/O layer that makes agents real, the engineering challenge is authentication, error handling, and state management, not LLM reasoning.
- Production agents need memory (short-term context, long-term vector stores, state checkpointing) and guardrails (iteration caps, confidence thresholds, human-in-the-loop) to be reliable.
Your product check-in
Apply “What Makes an Agent an Agent” to a product or workflow you know. What would you try, what could go wrong, and what evidence would help you decide?