Advanced AI Agents & Multi-Agent Architectures

A single LLM call answers a question. An agent plans, uses tools, remembers, and acts toward a goal. This tutorial takes you from single agents to systems where multiple specialized agents collaborate — the architecture behind serious production AI workflows.

Table of Contents

• What Makes an Agent
• The Agent Loop
• Tool Use and Function Calling
• Memory: Short-Term and Long-Term
• Planning and Reasoning Strategies
• Guardrails and Error Recovery
• Why Multi-Agent Architectures
• Multi-Agent Patterns
• Communication Between Agents
• Handoffs and Orchestration
• Evaluating Agent Systems

What Makes an Agent

An agent is an LLM wrapped in a loop with three capabilities:

1. Tools — it can act (call APIs, run code, query databases).
2. Memory — it retains context across steps.
3. Planning — it decides what to do next based on results so far.

Agent = LLM + Tools + Loop + Memory

A chatbot without tools is not an agent. The difference is autonomy: an agent chooses its own sequence of actions.

The Agent Loop

Every agent framework — LangGraph, OpenAI Assistants, CrewAI, smolagents — is a variation of this loop:

def run_agent(goal: str, max_steps: int = 15):
    messages = [{"role": "user", "content": goal}]
    for step in range(max_steps):
        response = llm.chat(messages, tools=TOOLS)
        if response.tool_calls:
            results = [execute_tool(tc) for tc in response.tool_calls]
            messages.append(tool_result(results))
        else:
            return response.content      # final answer
    raise AgentBudgetExceeded(max_steps)

The explanation: the model either requests a tool call (and the loop feeds the result back) or produces a final answer. max_steps is a hard budget — without it, a confused agent can loop forever and burn money.

Tool Use and Function Calling

Tools are functions the model can request, described by JSON schemas.

TOOLS = [
    {
        "type": "function",
        "function": {
            "name": "get_order_status",
            "description": "Get the shipping status of a customer order by order ID.",
            "parameters": {
                "type": "object",
                "properties": {
                    "order_id": {"type": "string", "description": "e.g. ORD-8842"}
                },
                "required": ["order_id"],
            },
        },
    }
]

def execute_tool(call):
    if call.name == "get_order_status":
        return db.query("SELECT status FROM orders WHERE id = %s", call.args["order_id"])
    raise UnknownTool(call.name)

The explanation: the model never runs code — it requests a tool. Your code validates inputs, executes, and returns a string result. Tool descriptions are prompts: a vague description means the model calls the wrong tool.

Tool design rules:

• Fewer, well-named tools beat many overlapping ones.
• Return errors as readable text — the model can recover from an error message, not from a stack trace.
• Make tools idempotent when possible.

Memory: Short-Term and Long-Term

• Short-term (working memory): the conversation history in the context window. Manage it with truncation or summarization.
• Long-term: persistent facts stored outside the model, usually in a vector database, retrieved when relevant.

def compact_history(messages, keep_last=10):
    if len(messages) <= keep_last:
        return messages
    summary = llm.chat([{
        "role": "user",
        "content": f"Summarize the key facts and decisions:\n{render(messages[:-keep_last])}"
    }])
    return [summary] + messages[-keep_last:]

The explanation: old turns are compressed into a summary so the agent keeps essential context without blowing the context window.

Planning and Reasoning Strategies

ReAct trace example:
Thought: I need the order status before I can refund.
Action:  get_order_status("ORD-8842")
Observation: status = "delivered"
Thought: Delivered, so refund policy allows it. I need the payment ID.
Action:  get_payment_id("ORD-8842")
Observation: pay_771
Action:  refund("pay_771", amount=49.99)

Guardrails and Error Recovery

Agents fail in specific ways: loops, hallucinated tool arguments, and destructive actions. Defend in layers:

class GuardedAgent:
    MAX_COST = 2.00          # dollars
    BLOCKED = ["delete_all", "drop_table"]

    def execute_tool(self, call):
        if call.name in self.BLOCKED:
            return Refusal("This tool requires human approval.")
        if self.total_cost + est(call) > self.MAX_COST:
            return Refusal("Budget exceeded — stopping.")
        return self.sandbox.run(call)

Key guardrails:

• Step and cost budgets — always.
• Sandboxing — run code tools in containers with no network or scoped credentials.
• Human-in-the-loop — pause for approval on irreversible actions (payments, deletions, emails).
• Structured output validation — validate tool arguments against the schema before executing.

Why Multi-Agent Architectures

One agent doing everything hits limits: the context window fills, the system prompt becomes contradictory, and a single failure loses all work.

Multi-agent systems split work across specialized agents, each with:

• A narrow role and focused system prompt
• Only the tools it needs
• Its own context window

Benefits: better accuracy per task, parallelism, and failure isolation. Costs: more complexity, more latency, and new failure modes (agents talking past each other). Use multi-agent only when single-agent + tools genuinely isn't enough.

Multi-Agent Patterns

1. Supervisor (Orchestrator–Workers)

A router agent delegates to workers and aggregates results.

           ┌─→ Research Agent
Supervisor ├─→ Writer Agent
           └─→ Reviewer Agent

Best when tasks decompose cleanly and you need central control.

2. Pipeline (Sequential)

Each agent transforms the output of the previous one: extract → summarize → format. Simple, debuggable, deterministic.

3. Debate / Critique

A generator agent and a critic agent iterate until the critic passes the output. Great for code review and analysis quality.

draft = writer_agent.run(task)
for _ in range(3):
    critique = critic_agent.run(draft)
    if critique.verdict == "approve":
        break
    draft = writer_agent.run(f"Improve based on: {critique.issues}")

4. Hierarchical

Teams of agents, each with its own sub-supervisor. For large workflows; adds coordination overhead.

Communication Between Agents

Agents share state through a common structure, not free-form chat.

from dataclasses import dataclass, field

@dataclass
class SharedState:
    goal: str
    facts: dict = field(default_factory=dict)     # validated outputs
    artifacts: dict = field(default_factory=dict) # documents, code
    messages: list = field(default_factory=list)  # audit trail

def researcher(state: SharedState) -> SharedState:
    state.facts["competitor_pricing"] = fetch_pricing()
    return state

def writer(state: SharedState) -> SharedState:
    state.artifacts["report"] = llm.write(state.facts)
    return state

The explanation: the researcher writes structured facts into shared state; the writer reads them. Each agent sees only what it needs, and the messages list gives you a full audit trail for debugging.

Handoffs and Orchestration

In customer-facing systems, agents hand conversations to each other:

def triage_agent(state):
    intent = classify(state.last_message)
    if intent == "billing":
        return Handoff(to="billing_agent", context=state)
    if intent == "technical":
        return Handoff(to="tech_agent", context=state)
    return Handoff(to="human", reason="unknown intent")

Orchestration rules:

• Handoffs transfer state, not just control — the next agent needs context.
• Always keep an escalation path to a human.
• Track which agent handled each turn for evaluation and debugging.

Frameworks worth knowing: LangGraph (graph-based state machines), OpenAI Agents SDK (handoffs), CrewAI (role-based crews), AutoGen (conversational agents).

Evaluating Agent Systems

Agents are non-deterministic, so test differently:

• Trajectory evaluation — did the agent take sensible steps and call the right tools?
• Outcome evaluation — did the final answer solve the task?
• Cost and latency per run — a correct answer that costs $5 isn't a success.

def evaluate_run(trace, expected):
    scores = {
        "correct_tools": set(trace.tool_calls) == expected.tools,
        "final_answer": llm.grade(trace.final_answer, expected.answer),
        "steps_under_budget": len(trace.steps) <= 15,
        "cost": trace.cost_usd,
    }
    return scores

The explanation: run this over a fixed test set on every change. Regression in tool choice or cost is as important as regression in answer quality.