Agent Building Blocks & Design Patterns
Learn the core building blocks of agents, memory types, ReAct loops, multi-agent collaboration, 30 must-know terms, and A2A/AG-UI protocols.
Formulate task objective
Task: Fetch active users and generate database summary report.
Agent Loop
This diagram shows the reasoning-action cycle at the core of every AI agent. The agent receives a user goal, plans a sequence of steps, decides which action or tool to invoke, acts, then observes the result. Observations feed back into memory (short-term scratchpad or long-term store), which informs the next planning step. This loop repeats until the agent determines the goal is satisfied. Understanding this cycle explains why agent reliability is hard — errors compound across iterations — and why memory and tool design are the two highest-leverage engineering decisions in any agentic system.
Agent Loop
▶📚 Prerequisites(2)
🎓 Learning objectives
- •Understand Agent components and the 30 Must-Know Agentic AI Terms (Agent, Environment, Action, Observation, Goal, etc.)
- •Implement a ReAct (Thought-Action-Observation) loop from scratch
- •Describe multi-agent patterns, Agent-to-Agent (A2A) and Agent-User (AG-UI) protocols
What is it?
AI Agents are LLM-powered systems that take sequences of actions to accomplish goals, rather than responding to a single prompt. An agent perceives its environment through tool outputs, reasons about what to do next, takes actions (tool calls), and iterates until the task is complete. The key difference from a plain LLM call: agents have a feedback loop — outputs inform the next input.
Why it exists
Single LLM calls are stateless and cannot handle tasks requiring multiple steps, external data lookup, or real-world actions. Agents emerged to bridge the gap between "LLM as Q&A engine" and "LLM as autonomous worker." A task like "research competitor pricing and draft a report" requires 10–20 sequential steps — only an agent can orchestrate this.
Problem it solves
Complex, multi-step tasks that require accessing external systems: searching the web, querying databases, writing/reading files, calling APIs, executing code, and iterating based on results. Agents bring LLM reasoning to automation pipelines that would otherwise require hard-coded logic for every possible path.
Intuition
A plain LLM call is like consulting an expert once: you describe the problem, they give you their best one-shot answer, conversation over. An agent is like hiring that expert as a contractor: you give them a goal, they autonomously research, ask clarifying questions, make tool calls, and hand you a completed deliverable. The LLM is the brain; tools are the hands.
If you come from Java/Spring Boot: an agent is like a long-running @Async service method with a workflow engine. The LLM is the workflow orchestrator deciding the next step; tool calls are service method invocations (HTTP clients, DB queries, file I/O). The agent loop is the workflow state machine.
If you come from React/Frontend: an agent is like useReducer with async side effects. State = conversation history + tool results. Actions = tool calls. Reducer = LLM deciding next action. The loop keeps dispatching actions until a terminal state (task complete or error).
Analogy
An AI agent is like a skilled project manager with a team of specialists. The PM (LLM) does not do the execution work — they think, plan, and delegate. When they need market data, they ask the research analyst tool. When they need a document drafted, they call the writing tool. When they need a calculation, they call the math tool. They synthesize all results into a final deliverable, iterating as needed.
Technical explanation
The ReAct (Reasoning + Acting) pattern is the most widely used agent architecture:
Loop: while not done:
- LLM receives: [system prompt] + [conversation history] + [available tools as JSON schema]
- LLM outputs either: a. Tool call: {"name": "search", "input": {"query": "GPT-4 pricing 2024"}} b. Final answer: direct text response (task complete)
- If tool call: execute tool → append result to history → go to 1
- If final answer: return to user
Tool specification (OpenAI/Anthropic format): { "name": "search_web", "description": "Search the internet for current information", "input_schema": { "type": "object", "properties": {"query": {"type": "string", "description": "Search query"}}, "required": ["query"] } }
Context management is critical: each loop iteration adds messages to context. A complex task might require 20 iterations × 500 tokens = 10K tokens before answering. With GPT-4 at $10/1M input tokens, a complex agent task costs $0.10 just in context re-reading.
Multi-agent patterns: orchestrator agents delegate to specialized sub-agents. Example: ResearchAgent calls WebSearchAgent and DataAnalysisAgent in parallel, then synthesizes results. LangGraph and CrewAI implement graph-based multi-agent coordination.
Architecture
Single-agent architecture (ReAct):
[User Goal] ↓ [Agent Loop] ↓ LLM (with tool schemas in context) ↓ Tool call decision ↓ (if tool call) Tool executor ↓ Tool result → append to history ↓ (loop back) LLM reasons over result ↓ (if final answer) Return to user
Multi-agent (orchestrator pattern): User → Orchestrator LLM ↓ delegates subtasks ┌──────┼──────────┐ SubAgent1 SubAgent2 SubAgent3 (search) (code) (analysis) ↓ Orchestrator synthesizes → User
Workflow
- Define tools: write Python functions or API wrappers; annotate with docstrings used as tool descriptions
- Convert to tool schema: Anthropic/OpenAI SDKs auto-generate JSON schema from type annotations
- Initialize agent loop: system prompt defines agent persona, capabilities, and constraints
- First LLM call: send user goal + tool schemas → model decides first action
- Execute tool: call the function with model-provided arguments → capture output
- Append to history: add tool call + result as assistant/tool messages
- Repeat: send full history to LLM → next decision (tool or final answer)
- Termination: model outputs text without tool use (done) OR max_iterations reached
- Context pruning (long tasks): summarize older history to stay within context window
Example
import anthropic
client = anthropic.Anthropic()
def search_web(query: str) -> str: # In reality, call a search API return f"Search results for {query}: [simulated results]"
tools = [{"name": "search_web", "description": "Search the web", "input_schema": {"type": "object", "properties": {"query": {"type": "string"}}, "required": ["query"]}}]
messages = [{"role": "user", "content": "What is the current price of Anthropic Claude API?"}]
while True: response = client.messages.create(model="claude-opus-4-5", max_tokens=1024, tools=tools, messages=messages)
if response.stop_reason == "end_turn": # Agent is done
print(response.content[0].text)
break
# Process tool calls
for block in response.content:
if block.type == "tool_use":
result = search_web(**block.input)
messages.append({"role": "assistant", "content": response.content})
messages.append({"role": "user", "content":
[{"type": "tool_result", "tool_use_id": block.id, "content": result}]})
Real-world usage
Devin (Cognition AI): autonomous software engineering agent. Reads codebases, plans changes, writes code, runs tests, debugs failures, and opens pull requests — completing full engineering tasks from a single instruction.
OpenAI Operator: web-browsing agent that can fill forms, make purchases, and navigate websites on behalf of users. Uses computer-use tool calls to interact with browser screenshots.
Anthropic Claude with computer use: API that lets Claude see and interact with desktop applications — used for automated QA testing, data entry automation, and legacy system integration where APIs do not exist.
Trade-offs
Autonomy vs reliability: more autonomous agents (fewer human checkpoints) complete tasks faster but make more unrecoverable mistakes. Always add human-in-the-loop checkpoints for irreversible actions (sending emails, making purchases, deleting data).
Context growth: each agent iteration adds tokens to context. At 20 iterations with 1K tokens each, you have used 20K tokens before generating the final answer. Design tools to return concise outputs, and prune context aggressively.
Cost predictability: a single user request can trigger 5–50 LLM calls depending on task complexity. Without max_iterations limits, a runaway agent can cost $10+ on a single task. Always set iteration limits and cost budgets.
Visual explanation
Stateful ReAct Loop Architecture: [User Goal] ──> [Planning / Memory State] ▲ │ │ ▼ [Observation] <─ [LLM: Thought] ──> [LLM: Action (Tool Call)] │ │ │ ▼ └────────────────────────────── [Tool Execution]
Advantages
- —
Solves highly complex open-ended tasks that single prompts cannot
- —
Iterates and self-corrects based on tool error messages
- —
Can delegate to specialized subagents for parallelism
Disadvantages
- —
Difficult to test and predict behavior — non-deterministic execution paths
- —
Can get stuck in infinite execution loops, racking up high token costs
- —
Hard to debug: need full thought/action/observation traces to diagnose failures
Common mistakes
- —
No max_iterations limit. An agent trying to find information that does not exist will loop indefinitely, calling tools repeatedly. Always set a hard limit (typically 10–25 iterations) and return a "could not complete" message when reached.
- —
Tool descriptions that are too vague. If your search tool description says "search for things", the LLM will misuse it. Write descriptions like a contract: specify what the tool does, what inputs it expects, what it returns, and when NOT to use it.
- —
Giving agents irreversible capabilities without confirmation. If an agent can send emails or delete records, a misunderstanding of the task can cause real-world damage. Require explicit human confirmation before any write operation to external systems.
- —
Not handling tool errors in the agent loop. Tools fail — APIs return 429s, databases time out, files are missing. If your agent loop crashes on a tool error, the whole task fails. Wrap tool calls in try/except and return structured error messages the LLM can reason about.
- —
Using a single huge agent instead of specialized sub-agents. An agent managing a 50-tool toolkit makes poor decisions — the tool selection problem becomes overwhelming. Split into specialized agents (SearchAgent, CodeAgent, WritingAgent) coordinated by an orchestrator.
🎤 Interview questions
How do you handle rate-limiting and token quotas when deploying multi-agent systems composed of multiple active loops?
Walk through the design of the Agent-User Interaction (AG-UI) protocol. How does it handle streaming tool call executions?
📂 Subtopics
5 Agentic AI Design Patterns
The five foundational patterns for how agents refine and improve their behavior — Reflection, Tool Use, ReAct, Planning, and Multi-Agent — and how they combine.
~20 min
Agent vs LLM vs RAG (Mental Model)
The brain/food/decision-maker analogy distinguishing what an LLM, RAG, and an Agent each contribute to a system, and why an Agent needs both of the others.
~10 min
The 6 Building Blocks of AI Agents
Role-playing, Focus, Tools, Cooperation, Guardrails, and Memory — six design principles that make AI agents more reliable, intelligent, and useful in real-world applications.
~20 min