# Agentic Systems Are Just Patterns

## Single Agent Patterns

### Tool Use Pattern

An LLM by itself can only produce tokens. It can't query a database, hit an API, run code, or check today's weather. The tool use pattern closes that gap by giving the model a structured way to say "I want to call function X with these arguments" and having the surrounding system actually execute that call and feed the result back in.

How it works, step by step

1.  **Tool definitions are given to the model (JSON Schema) -** ame, description, and a schema for expected inputs.This happens in the system prompt or a dedicated `tools` parameter.
    
2.  **The model decides whether a tool is needed** based on the user's request and the tool descriptions.
    
3.  **The model emits a structured tool call** instead of (or alongside) natural language e.g. `{"tool": "get_weather", "input": {"city": "Bangalore"}}`.
    
4.  **The orchestrating code (not the model) executes the actual function** hits the API, runs the query, etc.
    
5.  **The result is returned to the model as a new message** (a "tool result").
    
6.  **The model incorporates that result into its next response** either calling another tool or answering the user.
    

This is fundamentally a loop: think → act → observe → think again.

### ReAct Pattern

**ReAct** (Reason + Act) is the pattern that interleaves the model's reasoning with tool calls, step by step, rather than doing all the thinking up front or calling a tool exactly once. It's essentially Tool Use pattern extended into a loop with explicit reasoning traces at each step.

Instead of "think once, then answer" or "call one tool, then answer," ReAct has the model alternate between:

*   **Thought**: reason in natural language about what it knows and what it needs next
    
*   **Action**: call a tool based on that reasoning
    
*   **Observation**: read the tool's result
    
*   **Thought**: reason again, incorporating the new observation
    
*   ... repeat until it has enough to answer
    
*   Final answer
    

This loop is what lets an agent handle multi-step problems where the next action genuinely depends on what the previous action returned, you can't know what to search for next until you see what the first search turned up.

### Plan & Execute Pattern

**Plan & Execute** splits agentic work into two distinct phases: first produce a full multi-step plan, then work through it rather than deciding one step at a time the way ReAct does. It trades ReAct's adaptability for more efficient, more predictable execution.

1.  **Plan**: a (usually more capable) model looks at the whole task and decomposes it into an ordered list of discrete steps upfront before any tool has been called or any information gathered.
    
2.  **Execute**: same agent executes the plan in the given steps involving tool calls etc.
    

Incorporated in multi agent systems as well with a dedicated planner agent and execution agent

### Agentic RAG Pattern

**Agentic RAG** takes the standard retrieve-then-generate pipeline and gives the model control over the retrieval itself instead of a fixed "always retrieve once, then answer" flow, the model decides *whether* to retrieve, *what* to retrieve, *how many times*, and whether the results are actually good enough to answer with.

```plaintext
Standard RAG (fixed pipeline):
Query → Embed → Retrieve top-k → Stuff into context → Generate answer (one shot, no judgment calls)

Agentic RAG (model-in-the-loop):
Query → Model reasons: "do I even need retrieval for this?"
→ If yes: Model decides what to search, calls retrieval asa tool
→ Model evaluates:"are these chunks actually relevant/sufficient?"                    → If not: reformulate query, retrieve again, or try a                               different source
→ Repeat until confident → Generate answer
```

## Multi Agent Patterns

### Sequential Execution

agents run one after another in a fixed order, each one's output becoming the next one's input - a pipeline, not a negotiation.

```plaintext
Task → Agent A → Agent B → Agent C → Final Output
       (draft)   (review)  (format)
```

###   
Parallel Execution

runs multiple agents at the same time on independent pieces of a task, then combines their outputs - a fan-out/fan-in shape.

```plaintext
                ┌─→ Agent A (source 1) ─┐
Task ─ split ──┼─→ Agent B (source 2) ─┼── merge → Final Output
                └─→ Agent C (source 3) ─┘
```

### Router Pattern

The **Router pattern** (also called Router-based orchestration or Dynamic Routing) puts a single decision-maker in front of a set of specialist agents, and sends each incoming task to whichever one fits, instead of running everyone in a fixed sequence or in parallel by default.

```plaintext
                          ┌─→ Agent A (billing questions)
Task → Router (classify) ─┼─→ Agent B (technical support)
                          └─→ Agent C (account changes)
```

### Orchestrator Worker Pattern ( Manager Worker Pattern )

The **Orchestrator-Worker pattern** (also called Manager-Worker or Hierarchical orchestration) puts a central agent in charge of a task from start to finish - it doesn't just dispatch once like Router, it keeps control, breaking the task into subtasks, assigning them to workers, checking their results, and deciding what happens next.

![](https://cdn.hashnode.com/uploads/covers/639ca8d6052fc36d4a8f42ec/43395382-6a70-4307-80ac-3c391c129f0c.png align="center")