AI Agent Architecture | 30 Days of AI Agents, Day 2

Yesterday we defined an AI agent as a goal-driven system that thinks, acts, and observes in a loop. Today we turn that definition into a blueprint: the components of agent architecture, how they connect, and what a reasonable stack looks like. If Day 1 was the "what", this is the "how it is put together".

Save this sheet. The rest of this note walks through it section by section.

What Agent Architecture Means

Agent architecture is the blueprint that defines how an agent thinks, plans, uses tools, and reaches a goal. The key idea on the sheet is worth memorizing:

Agent = Brain + Memory + Tools + Planner + Executor, working together in a loop to perceive, reason, act, and learn.

Architecture matters because agents fail in boring ways. They lose context, call the wrong tool, retry forever, or return confident nonsense. Almost every one of those failures traces back to a missing or blurry component, not to the model being "not smart enough".

The Six Core Components

Component	What it does	Details
Brain (LLM)	Understands the request and reasons about next steps	GPT-4o, Claude, Llama 3, Gemini
Memory	Stores and recalls information	Short-term session history, long-term store in a vector DB or Redis
Tools	Interact with external systems	APIs, search, code, databases, calculators, web
Planner	Breaks goals into steps and strategy	Task decomposition, chain of thought, ReAct, plan-and-execute
Executor	Takes action and runs the steps	Runs code, calls APIs, queries databases, triggers workflows
Evaluator	Checks results and decides what happens next	Validates output, handles errors, decides to retry or stop

The evaluator is the one teams skip, and it is the one that separates a demo from a system. Without it, the agent has no principled way to say "this is good enough" or "this is wrong, try again".

The Architecture Flow

User input (goal)
  -> Perceive and understand (LLM)
  -> Retrieve context (memory)
  -> Plan (planner)
  -> Take action (executor + tools)
  -> Evaluate result (evaluator)
       -> goal achieved?  no  -> back to perceive, with new context
                          yes -> final output to the user

Two details matter here. First, memory is read before planning, so the plan reflects what the agent already knows. Second, the "goal achieved?" check is explicit. It should be a real function with criteria, not the model's vibe.

A good evaluator starts cheap and deterministic, then escalates:

def evaluate(output: dict) -> tuple[bool, str]:
    # 1. Cheap structural checks first
    if not output.get("answer"):
        return False, "empty answer"
    if not output.get("sources"):
        return False, "no sources cited"
    # 2. Business rules
    if len(output["answer"]) > 4000:
        return False, "answer too long for the channel"
    # 3. Only then, optionally, an LLM-as-judge check for quality
    return True, "ok"

The reason string goes back into the loop as feedback, so the next attempt knows what to fix.

The High-Level Diagram

On the sheet, the user talks to an agent interface, not directly to the model. That interface is where you put authentication, rate limits, input validation, and logging. Inside the agent, the brain talks to memory, the planner hands steps to the executor, the executor uses tools, and the evaluator checks the outcome before anything goes back to the user.

Keeping these as separate modules pays off quickly. You can swap the model without touching tools, replace the vector store without touching the planner, and test the executor without paying for LLM calls.

Agent vs Traditional Software

Feature	AI agent	Traditional software
Goal	Goal-driven	Rule-driven
Adaptability	Adapts to new inputs	Fixed rules
Decision making	Autonomous	Pre-programmed
Tool use	Dynamic, as needed	Static, built in
Uncertainty	Handles ambiguity gracefully	Struggles with unknowns
Scalability	High with the right architecture	Limited by design

In practice the best agents are both. A deterministic shell (interface, tools, validation, permissions) wraps a probabilistic core (the model). Treat the model like a talented new hire: you let it decide, but you do not give it the production database password.

An Example Stack

Layer	Common options	Notes
LLM	OpenAI GPT-4o, Claude, Llama 3	Pick per task; a smaller model often handles routing
Memory	Pinecone, Weaviate, Redis	Postgres with pgvector is a solid default if you already run Postgres
Orchestration	LangChain, LangGraph, CrewAI	Covered on Days 9, 10, and 14
Tools	SerpAPI, GitHub, SQL databases, n8n	Wrap each one with input validation
Frameworks	AutoGen, OpenAI Agents SDK	Useful for multi-agent conversations and handoffs
Deployment	Docker, Kubernetes, managed cloud	Agents are long-running jobs; plan for timeouts and queues

You do not need every layer on day one. A model API, a Postgres table for memory, and three well-described tools will take you surprisingly far.

Design Principles and Patterns

The principles that hold up in real builds:

• Goal-oriented. Every run has a clear definition of done.
• Modular. Components talk through small interfaces.
• Memory-aware. The agent knows what to remember and what to forget.
• Observable. Every thought, tool call, and result is logged with a run ID.
• Bounded. Step limits, cost limits, and timeouts on every loop.
• Secure. Least-privilege credentials per tool.

And the patterns you will meet later in the series: ReAct (reason, act, observe), plan-and-execute (plan everything first, then run), reflection (critique and revise), multi-agent, and hierarchical (a manager agent delegating to workers).

Key Takeaways

• Agent architecture is a loop of think, plan, act, evaluate, repeat.
• Six components: brain, memory, tools, planner, executor, evaluator.
• The evaluator is what turns a demo into a system. Make "goal achieved" an explicit check.
• Wrap the probabilistic model in a deterministic shell of validation and permissions.
• Start with a small stack and iterate; modular design lets you swap parts later.

FAQs

Do I need a separate planner component?

Not always. For short tasks, the model can plan inline with ReAct-style reasoning. Add an explicit planning step when tasks have many steps or when you need to show or approve the plan before execution.

What should the evaluator check first?

Structure and rules: required fields, valid formats, citations present, limits respected. These are cheap and reliable. Use an LLM judge only for qualities that code cannot check.

Can one model play every role?

Yes, and many agents do. Splitting roles across models is an optimization, usually a small fast model for routing and a stronger one for reasoning.

Up Next

Day 3 is Prompt vs Workflow vs AI Agent: three levels of autonomy, when each one is the right tool, and why the cheapest level that solves the problem usually wins. It is the decision you should make before writing any agent code. If you want help designing an agent architecture for your own use case, reach out.