5 Agentic AI Design Patterns Explained with Python Examples

Think about how a good final-year student in Indore writes a project report. She doesn't type it in one go and submit.

She writes a draft, rereads it and fixes weak paragraphs. She checks numbers with a calculator and looks up references in the library database. When a result looks odd, she investigates and adjusts. Before starting, she outlines the chapters and their order. And for the big project, she splits work with three teammates.

Each of those habits solves a different problem: quality, facts, uncertainty, scale and specialisation. Agent builders have names for them.

What are agentic AI design patterns?

The draft-and-reread habit is the reflection pattern. Using the calculator and library is tool use. Investigating and adjusting step by step is ReAct. Outlining chapters first is planning. Splitting work with teammates is the multi-agent pattern.

Agentic AI design patterns are reusable ways of structuring LLM calls, tools and loops so that a model can improve its output, use external information, handle multi-step goals and share work, instead of answering in a single pass.

They are patterns, not products. You can implement each one in plain Python, as the ReAct loop in the agents overview showed, or use a framework that packages them. Knowing the patterns helps you read any framework's documentation faster.

Each pattern is a different shape of loop or flow around the same LLM.

Pattern 1: Reflection, the model reviews its own work

In reflection, one call generates an answer and a second call critiques it against clear criteria. If the critique finds problems, the feedback goes back to the generator for another attempt. The loop ends when the critic is satisfied or a round limit is reached.

It works because models are often better at spotting a problem than at avoiding it in the first draft. A critic that checks "is it under 30 words?" or "does the code pass these tests?" catches mistakes the generator missed.

The best critics are partly or fully deterministic. Word counts, required keywords, unit tests and JSON validation never get tired or lenient. Use an LLM as critic only for qualities that code cannot check, such as tone.

Reflection is a loop between a generator and a critic, with a hard cap on rounds.

Here is a reflection loop for a WhatsApp promo message for a sweet shop in Sarafa. The "generator" applies a fix for each issue the critic reports, standing in for an LLM that reads feedback.

def critic(msg):
    issues = []
    if len(msg.split()) > 25: issues.append("too long")
    if "Rs" not in msg: issues.append("no price")
    if any(w.isupper() and len(w) > 3 for w in msg.split()): issues.append("shouting caps")
    return issues

def generator(msg, issues):
    if "too long" in issues:
        msg = " ".join(msg.split()[:18]) + "."
    if "shouting caps" in issues:
        msg = " ".join(w.capitalize() if w.isupper() and len(w) > 3 else w for w in msg.split())
    if "no price" in issues:
        msg += " Kaju katli at Rs 900 per kg."
    return msg

draft = ("HUGE Diwali offer at our Sarafa shop! Fresh kaju katli, motichoor laddoo and "
         "soan papdi made every morning with pure ghee, come early because stocks finish fast")
for round_no in range(1, 4):                      # hard cap on rounds
    issues = critic(draft)
    print(f"Round {round_no}: {len(draft.split())} words, issues={issues}")
    if not issues:
        break
    draft = generator(draft, issues)
print("Final:", draft)

Run it and you will see the message pass in the second round. Real systems use the same structure for code that must pass tests or for SQL that must run without errors.

Patterns 2 and 3: Tool use and ReAct

Tool use

Tool use lets the model request a function call instead of answering from memory: search a database, run Python, call a weather API. Your program executes the call and returns the result to the model.

This is the pattern that turns a model's guess into a fact. Ask a plain model for the current price of gold in Indore and it will invent one. Give it a price tool and it will look it up. The details of defining tools are in tools and function calling for agents.

ReAct

ReAct (reason plus act) combines reflection and tool use in a loop. The model writes a short thought, picks a tool, reads the observation and thinks again, repeating until it can answer.

The value is adaptivity. If a search returns nothing, the next thought can rephrase the query. ReAct is the default loop in many agent frameworks, and you can build the full version, including parsing the model's text output, in a ReAct agent from scratch.

Pattern 4: Planning, decide the steps before acting

ReAct decides one step at a time. That is flexible, but on long tasks it can wander or repeat work. The planning pattern asks the model to write the whole plan first: the steps, their order and which steps depend on others. Then the program executes the plan.

Plans with dependencies have a useful side effect. Steps that don't depend on each other can run at the same time, and if a step fails, you know exactly which later steps are blocked.

Python's standard library has a helper for exactly this. Below, a plan for organising a college coding workshop is ordered with graphlib, and each batch of steps that can run in parallel is printed together.

from graphlib import TopologicalSorter

# step -> steps it depends on (what an LLM planner might return as JSON)
plan = {
    "book seminar hall": [],
    "confirm speaker": [],
    "design poster": ["confirm speaker"],
    "open registrations": ["book seminar hall", "design poster"],
    "send reminders": ["open registrations"],
    "arrange snacks": ["book seminar hall"],
}

ts = TopologicalSorter(plan)
ts.prepare()
stage = 1
while ts.is_active():
    ready = sorted(ts.get_ready())
    print(f"Stage {stage}: run together -> {ready}")
    ts.done(*ready)
    stage += 1

Six steps finish in four stages instead of six, because independent work runs side by side. In a real agent, the LLM writes the plan dictionary, your code validates it, and each step becomes a ReAct run or a single tool call. If a step fails, the agent re-plans only the blocked part.

Pattern 5: Multi-agent collaboration

The multi-agent pattern gives different agents different roles, each with its own prompt and tools. A researcher gathers facts, a writer drafts, a reviewer checks. A coordinator, or a fixed sequence, passes work between them.

It helps when one prompt would otherwise have to hold too many instructions and tools, or when you want separate permissions. The writer does not need database access, and the researcher does not need the email tool.

The cost is coordination. Every handoff is extra model calls and another place where context can be lost. Common structures, such as sequential, parallel, router and hierarchical teams, are compared in multi-agent system patterns.

Which agentic design pattern should you use?

Match the pattern to the failure you actually see, not to what sounds advanced.

The patterns combine naturally. A typical research assistant plans the sections, runs a ReAct loop with search tools for each one, and finishes with a reflection pass that checks citations. The five levels of agentic AI shows how much control each combination hands to the model.

Common mistakes with agentic design patterns

• Reflection without real criteria. "Make it better" leads to endless rewording. Give the critic checkable rules.
• No round limit. Reflection and ReAct loops must have a cap, or a stubborn failure becomes an expensive one.
• Planning without validation. An LLM-written plan can reference tools that don't exist or contain circular dependencies. Check it before executing; graphlib raises an error on cycles.
• Jumping straight to multi-agent. Five agents debugging each other is harder than one agent with good tools. Add agents only when a single one clearly struggles.
• Judging a pattern on one example. Measure success rate and cost on a fixed set of 20 or more tasks before and after adding a pattern.

Key takeaways

• Five patterns: reflection, tool use, ReAct, planning and multi-agent.
• Reflection improves quality, tool use adds facts and actions, ReAct adapts step by step.
• Planning orders long tasks and exposes parallel work; multi-agent splits roles and permissions.
• Prefer deterministic critics and validated plans, and always cap loops.
• Choose patterns by the failure you observe, then measure the change.