Start here if Agentic AI is new to you.

This chapter assumes nothing. By the end, you will know what an agent is, what makes a system "agentic", what tools and memory are doing, and you will have walked through the lifecycle of a single agent answering one question. The rest of the manual will then make sense.

What is an "agent", really?

An LLM by itself is a function: text in, text out. It has no memory between calls, no ability to take action, no way to look things up. It just predicts the next token.

An agent wraps an LLM in a loop and gives it three things it lacks: the ability to use tools, the ability to remember across turns, and the ability to decide what to do next. That loop, perceive, decide, act, observe, repeat, is what makes a system "agentic".

The three things every agent does, in order

{
  "action": "call_tool",
  "tool": "search_web",
  "args": { "query": "agentic AI orchestration patterns" }
}

{
  "action": "final_answer",
  "text": "Based on the search results, the four main patterns are..."
}

A complete tiny agent in Python

Here is the smallest honest agent. Roughly 30 lines. Read it top to bottom. The patterns you will see in production systems are elaborations of this.

def tiny_agent(goal, llm, tools, max_steps=10):
    """A minimal agent. Loops until the LLM says 'done' or budget runs out."""
    history = [{"role": "system", "content": f"You are an agent. Goal: {goal}"}]

    for step in range(max_steps):
        # 1. PERCEIVE: build the prompt from history
        decision = llm(history, available_tools=list(tools.keys()))

        # 2. DECIDE: did the model finish or call a tool?
        if decision["action"] == "final_answer":
            return decision["text"]

        if decision["action"] == "call_tool":
            tool_name = decision["tool"]
            args = decision["args"]

            # 3. ACT: run the tool, observe the result
            if tool_name not in tools:
                result = f"Error: tool '{tool_name}' is not available"
            else:
                try:
                    result = tools[tool_name](**args)
                except Exception as e:
                    result = f"Tool error: {e}"

            # Append the tool call AND its result to history (this is memory)
            history.append({"role": "assistant", "content": f"calling {tool_name}({args})"})
            history.append({"role": "tool", "content": str(result)})

    return "Agent stopped: max steps reached without final answer"

Three things to internalize from this code. First, history is everything: it is the only memory the agent has within one task. Second, the loop has a hard upper bound (max_steps): without this, a confused agent loops forever. Third, tool errors are caught and fed back: the agent gets the chance to recover instead of crashing.

From one agent to many: why orchestration?

A single agent is enough for narrow, well-scoped tasks. But three things break when you push it harder:

• Context bloat: as the loop grows, history balloons. The model gets confused, slow, and expensive. There is a hard ceiling around 100k to 200k tokens before quality drops sharply.
• Skill spread: the same prompt cannot make a model great at researching, writing, coding, and reviewing. Specialization beats generalization.
• Failure correlation: a single agent's blind spots are the system's blind spots. No one is checking its work.

Multi-agent systems address all three: shorter contexts per agent, specialization by role, and cross-agent verification. That is what the rest of this manual covers.

The conceptual map: what we will cover

Each chapter answers one question. Use this as a roadmap.

Recommended next steps

• Build the tiny agent above with one real LLM and one real tool (web search, a calculator, anything). Watch the history grow. Break it on purpose: remove the max_steps cap, see what happens.
• Then read Chapter 2 (Architecture). The seven-layer architecture will map directly onto what you just built, and you will see what your minimal version was missing.
• Pick a real problem you care about. Decide single vs multi, sketch the agents on paper, and only then start coding. The thinking matters more than the framework.
• One scope note before you go. Almost every agent in this manual is the call-and-response kind: a function that takes a prompt and returns an answer. That is one valid kind of agent, and the kind nearly all production systems ship today. Chapter 24 names a different kind, the one almost nobody is building yet, that watches continuous streams instead of answering questions. If after building tiny agents you find yourself wondering why every example feels like a chatbot under the hood, that chapter will tell you what is missing.