There is nothing magical about an agent. It is a planner, a set of tools, some memory and a scheduler, and each of those is an engineering problem you can reason about.
The first two parts of this series covered what an agent is and how it differs from plain generative AI. This one opens the box. I'll go through the parts an agentic system is made of, the main architectures used to wire them together, and the design choices that decide whether the result works outside a demo.
Planning: the core of every agent
Every agent has a planner somewhere: a component that takes a vague goal ("prepare the monthly report") and turns it into concrete steps in a sensible order. Most systems do this through hierarchical task decomposition. The goal is split into subgoals, and those are split again until each piece is small enough to execute directly.
How the planner chooses between possible steps varies:
- Heuristics. Hand-written or learned scoring rules that rank candidate actions when searching every option would cost too much.
- Symbolic planning. Classical planners working over an explicit model of the available actions. STRIPS is the classic representation; PDDL is the standard language for describing planning domains and problems.
- Probabilistic planning. Markov decision processes (MDPs), or their partially observable variant (POMDPs), for situations where the outcome of an action is uncertain.
- LLM-based planning. A language model reads the instruction and writes the plan itself, usually as a list of steps or tool calls.
In practice the last option dominates because it copes with messy natural-language goals. More and more systems pair it with a symbolic layer, though: the language model interprets the request, and a stricter component checks that the resulting plan can actually be executed.
Agent architectures you'll meet in practice
BDI: beliefs, desires, intentions
BDI comes out of research on rational agents from the late 1980s and 1990s and is loosely modelled on how people reason about what to do. The agent holds beliefs (what it knows about the world), desires (outcomes it would like) and intentions (the goals it has committed to and is actively pursuing). Its most useful property is reconsideration. When new information changes the agent's beliefs, it can drop or revise an intention instead of blindly finishing a plan that no longer makes sense.
ReAct: reasoning and acting in turns
ReAct was introduced by Yao et al. in ReAct: Synergizing Reasoning and Acting in Language Models (Princeton and Google, 2022). Rather than planning everything up front, the model takes turns: it writes a short reasoning step, takes an action such as a search or an API call, reads the result, and reasons again. Because the reasoning is written out, you can follow why the agent did what it did, and it adapts naturally when a tool returns something unexpected. The price is that every observation goes back into the prompt, so long tasks burn through a lot of tokens.
ReWOO: plan first, observe later
ReWOO, proposed by Xu et al. in ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models (2023), goes after that cost. A planner writes the whole chain of reasoning, including every tool call it will need, before any tool runs, with placeholders for results it doesn't have yet. Workers then execute those calls, and a solver fills the results into the chain and produces the answer. Since the model isn't re-prompted after each observation, token use drops sharply; the authors report roughly five times fewer tokens on a multi-step question-answering benchmark. What you give up is flexibility. If an early result changes the picture, a ReWOO plan can't react the way ReAct can.
Multi-agent systems
Frameworks such as AutoGen, CrewAI and CAMEL spread the work across several agents with different roles: one plans, one executes, one reviews. They talk through messages or a shared memory, and the workflow often looks like a small team, with a manager agent handing tasks to specialists. Splitting the work this way keeps each agent's prompt and toolset small, which makes the individual pieces easier to test. It also introduces a new way to fail: agents talking past each other, or going round in circles over the same disagreement.
Tool use: acting on the world
A planner that can't act is just a text generator. The tool layer is what lets an agent fetch live data, send an email, book a meeting or kick off a CI/CD pipeline. Most of it is built on function calling: the model gets a typed schema for each tool and chooses which one to call, with which arguments. Frameworks like LangChain and Semantic Kernel wrap this up, and when a task needs real computation rather than a fixed endpoint, a sandboxed code interpreter takes over.
The calling is the easy part. The real engineering happens just before a call runs. A tool call is a side effect on a real system, so its arguments have to be validated against the schema rather than trusted, execution has to be sandboxed, and the action has to be checked against what this particular agent is allowed to do. Skip any of the three and a mistake stops being a wrong answer. It becomes a wrong action that has already happened.
Memory: from stateless prompts to agents that remember
Memory is what separates an agent from a stateless prompt, and it is rarely just one thing:
- Short-term memory holds the state of the task in progress.
- Long-term memory keeps what should outlive a session, such as user preferences and facts the system has picked up.
- Episodic memory records past decisions together with how they turned out. Teams often skip it and regret it later, because it is the only thing a reflection step can actually learn from.
Where each kind of memory lives should follow from how it is read. Semantic search over unstructured history belongs in a vector database such as Pinecone, Weaviate or Qdrant. Relationships you need to walk through (who reports to whom, which service depends on which) fit a graph database like Neo4j. Small, short-lived session state is well served by Redis. When this split is wrong the symptom is easy to miss: the agent still sounds fluent, but over a long workflow it slowly loses track of what it was doing.
Orchestration: where agents turn into distributed systems
As soon as several steps or several agents are involved, you are building a distributed system, and the usual rules apply. A task runner such as Airflow, or the agent executor that comes with LangChain, gives you a place for retries, timeouts and a durable record of what ran. Routing sends each step to the agent that specialises in it. Feedback loops grade an output before it is committed, and a supervisor agent watches the others instead of doing the work itself. None of this is new: it is a scheduler, a load balancer, a health check and a supervisor tree under different names.
Real stacks usually combine three things: a framework, a model endpoint and somewhere to keep state. In large companies a common combination is LangChain with Azure OpenAI and Cosmos DB, mostly because the compliance questions have already been answered for it. For developer tools, AutoGen with ordinary Python tooling is popular. For business automation across SaaS products, CrewAI with a vector store and an integration platform such as Zapier is typical, since most of the difficulty there lies in the integrations rather than in the reasoning.
Four properties that matter in production
- Interruptibility. A long-running agent needs a point where a person can stop it, and that point has to be designed in, not bolted on later as a kill switch.
- Explainability. The decision trace must be readable afterwards. "The model decided to" is not an explanation anyone can act on.
- Observability. Logs, dashboards and tracing matter even more than usual, because the control flow is only decided at runtime.
- Scalability. Keep agent processes stateless and the state in shared storage, so a process can be replaced without losing what the agent knew.
What comes next
Most near-term progress will be consolidation rather than invention. Memory is still split between symbolic stores and vector indexes, and a single query that can reach both is an obvious missing piece. Planners today keep rediscovering strategies they have already worked out, so caching and reusing plans that worked is probably worth more than a bigger model. Further out, marketplaces where agents trade capabilities and agents that repair their own failures at runtime are both plausible, but neither is anywhere near something I would trust in production yet.
Next in the series: the main types of agentic AI, and a step-by-step path to building your first agent.
