AI Agents & Multi-Agent Systems: From Loops to Orchestration

An agent is an LLM that can act — plan, call tools, observe results, and keep going until a goal is met. Move from single-turn prompts to a loop that decides what to do next, and you've built an agent. This tutorial covers the agent loop, then how multiple agents can collaborate as a team.

Table of Contents

• What Is an AI Agent?
• Agent vs. Prompt vs. Workflow
• The Agent Loop
• Memory and State
• Building a Simple Agent
• What Are Multi-Agent Systems?
• Patterns for Multi-Agent Collaboration
• When Multi-Agent Is the Wrong Call

What Is an AI Agent?

An agent is a model wrapped in a loop where it can take actions. It doesn't just answer — it decides to look something up, call a tool, then decide again based on what it found, repeating until it reaches a goal or gives up.

The key difference from a plain prompt: the model drives the next step. You hand it a goal and a set of tools; it chooses how to get there.

Agent vs. Prompt vs. Workflow

These get confused, so let's separate them:

• Prompt — one model call, one answer. No tools, no loop.
• Workflow — a fixed, pre-scripted sequence of steps (do A, then B, then C) with or without a model. The path is decided by you.
• Agent — the model decides the path at runtime, choosing tools and steps dynamically.

Prompt:    "Summarize this."                    -> one answer
Workflow:  extract -> classify -> summarize     -> fixed path you wrote
Agent:     goal + tools; model picks the steps  -> flexible, unpredictable path

Why it matters: workflows are predictable and safe; agents are flexible and powerful. Choose based on how much you trust the model to steer.

The Agent Loop

Every agent runs some version of this loop:

1. Receive the goal (and what's happened so far).
2. Decide the next action — answer, or call a tool.
3. If a tool call: run it, append the result, go back to step 2.
4. If it answers (or hits a stop condition): return.

Loop:
  model -> "calls lookup_order(8821)"
  run it -> result
  model -> "calls get_shipment_status(tracking)"
  run it -> result
  model -> "Your order ships tomorrow."
  stop.

Explanation: the agent keeps calling tools until it has enough information to answer. Each iteration adds to the message history, so the model remembers what it already found.

Memory and State

Agents need to remember across steps. That memory lives in the message history you resend every iteration (the API is stateless). Longer-lived memory can also live outside the prompt.

• Working memory — the conversation so far, sent each turn. Holds recent tool results and decisions.
• Long-term memory — stored elsewhere (a file, a database) and re-read when relevant. For remembering a customer across sessions.

Working memory (per loop):  request + tool calls + results + reasoning
Long-term memory (across):  notes written to disk, recalled next session

Best Practice: Keep only what the agent needs in the prompt. A history that grows forever bloats cost and confuses the model — trim or summarize old steps.

Building a Simple Agent

A minimal agent is the tool-calling loop from Tutorial 5, wrapped so the model can call tools multiple times until it's ready to answer.

def run_agent(goal):
    messages = [{"role": "user", "content": goal}]
    while True:
        resp = client.messages.create(model="claude-sonnet-5",
                                      max_tokens=300, tools=tools, messages=messages)
        # Did the model answer, or ask to call a tool?
        if not any(b.type == "tool_use" for b in resp.content):
            return resp.content[0].text
        # Run every requested tool and append results, then loop again.
        messages.append({"role": "assistant", "content": resp.content})
        for block in resp.content:
            if block.type == "tool_use":
                result = run_tool(block.name, block.input)
                messages.append({"role": "user",
                                 "content": [{"type": "tool_result",
                                              "tool_use_id": block.id,
                                              "content": str(result)}]})

Explanation: the while loop keeps calling the model. If the reply contains a tool call, the code runs it and feeds the result back, then loops. The loop exits only when the model returns a plain text answer.

Note: Add a safety cap (if steps > 10: break) so a stuck agent can't loop forever, spending money.

What Are Multi-Agent Systems?

A multi-agent system is several agents working together, each with a specialty or role, coordinating on a larger task that one agent handles poorly. Think of a team instead of a single worker.

Why they exist: one agent doing everything gets muddled. Splitting roles — a researcher, a writer, a reviewer — lets each focus and improves quality and oversight.

Patterns for Multi-Agent Collaboration

Three common ways agents organize:

• Orchestrator pattern — one "manager" agent decides which specialist agents to call and in what order.
• Pipeline pattern — each agent hands its output to the next (extract → summarize → write report).
• Debate/review pattern — one agent produces, another critiques, and they iterate.

Orchestrator:
   Coordinator
     ├─ researcher agent  -> gathers data
     ├─ analyst agent     -> interprets it
     └─ writer agent      -> drafts the report

Review:
   writer produces draft -> reviewer flags issues -> writer revises

Explanation: the orchestrator routes work to specialists; the review pattern uses a second opinion to catch errors. Both trade extra cost and latency for better, more reliable output.

Best Practice: Prefer one capable agent with good tools over a complex team unless the task genuinely needs division of labor. Multi-agent adds cost, latency, and failure modes.

When Multi-Agent Is the Wrong Call

Multi-agent is a heavy hammer. Avoid it when:

• A single agent suffices — most tasks, honestly.
• Steps are fixed and known — that's a workflow, and a workflow is cheaper and more reliable than letting agents improvise.
• Correctness beats flexibility — you want a deterministic path, not model-driven choices.
• Cost or latency matter — each agent is more tokens and more time.

"Summarize a PDF"              -> one agent, or even one prompt
"Research + draft + fact-check a report" -> consider a team

Common Mistake: building a multi-agent system for a job a single prompt does fine. Complexity is a tax you pay for flexibility — don't pay it without reason.