Patterns vs. Techniques

When we say “pattern”, in this course, we are talking about an end-to-end blueprint—a recurring layout of design, checkpoints, and LLM calls that converts raw model intelligence into a reliable workflow. Think of it as the architectural diagram you’d hand a contractor: it doesn’t just say what should be built, it dictates how the pieces interlock, when the conditional checks trigger, and where and how the resources get allocated. If you ignore the blueprint and jump straight into prompting, you’re basically improvising the wiring of a skyscraper. Sure, it might stand for a minute, but load-bearing stress will likely expose every hidden flaw.

Now, here’s the inevitable friction: open five blog posts and you’ll see the same term “pattern” slapped onto everything from a single-step reflection prompt to a sprawling multi-agent ecosystem. That lexical chaos isn’t intentional ambiguity; it’s a symptom of a field evolving faster than its glossary. Researchers often coin terminology in isolation, vendors adopt whichever word markets best, and suddenly, you’ve got “ReAct” championed as both a prompting technique and a pattern depending on whose slide deck you’re staring at. The noise is real, but it’s not fatal, as long as we anchor our definitions to scope and function instead of chasing buzzwords.

So here’s the thing for this course: we will clearly define terms. In this case, techniques are the granular cognitive skills—verbs that the model executes, like reflect, plan, and query. Patterns are the nouns, the orchestrated structures that deploy those verbs in concert to achieve a goal. You will encounter sources that flip or blur those labels, and that’s expected. We’ll show our work, justify each categorization, and—crucially—teach you how to map any external terminology into this framework. The relationship is simple: techniques are the capabilities, and patterns are the System Designs that strategically use those capabilities.

Let’s explore both in detail. You’ll get hands-on experience with each in the lessons that follow.

What are some agentic techniques?

When we label something a technique, we’re zeroing in on a single, reusable cognitive move—one that can be lifted out of any workflow and dropped into another without rewriting the whole blueprint. Blogs and slide decks sometimes promote these moves to “patterns,” but that’s usually a matter of emphasis, not substance. Our rule of thumb is scope: if the behavior can stand alone as a self-contained verb within larger workflows, it is a technique. Patterns operate one layer above, arranging these verbs into a coordinated system.

• Reflection is a textbook case. It’s about getting the model to re-read its own answer, checking for logic slips, and then revising it. This creates a tight feedback loop, a core behavior that inspects, diagnoses, and improves. It ensures the AI continuously refines its outputs, pushing toward a more accurate and robust result. Because the core behavior never changes—inspect, diagnose, improve—we keep it in the techniques bin, even though some papers call an extended reflection loop a “pattern.”

• Tool use defines how the agent accesses external capabilities. The fundamental action of sending a query to an API and interpreting its response is a foundational skill. As the field of AI agents rapidly evolves, Tool Use is no longer just a mere pattern in their design; it has solidified its position as an indispensable core capability. It’s the critical link that empowers agents to move beyond text and truly interact with and act upon the real-world.

• ReAct (Reason + Act) is where the system interleaves its thoughts with its actions. It doesn’t just think everything through at once, nor does it act undetectably. Instead, it generates a “thought” (a step in its reasoning), then performs an “action” based on that thought, and then “observes” the outcome of that action. This observation then feeds back into its next “thought,” creating a continuous, self-correcting loop.

• Planning involves the system independently breaking down a large objective into smaller, manageable steps, then determining the optimal sequence for execution. It hinges on the system dynamically, deciding its course of action. This is useful because it enables the system to tackle intricate tasks that resist single-pass solutions, essentially having it construct a detailed roadmap prior to commencement. Thus, it effectively handles multi-step problems.

• Multi-agent role assignment involves multiple AI agents working together, often with different specialized roles, to solve a complex problem or achieve a shared objective. They communicate and coordinate their efforts.

By keeping these behaviors at the technique level, we preserve their portability. You’ll start by coding each one in isolation; then we’ll layer them into patterns that deliver full, production-ready workflows.

What are some common agentic patterns?

If a technique is a single instrument, a pattern is the full score—entrances, reprises, tempo changes, and the conductor’s cues. A pattern spells out control flow: it specifies when to invoke which skills, how many cycles to run, where to branch, and what to do if limits are reached. In short, patterns give you a predictable, end-to-end pathway from user intent to final answer—robust enough to reuse across projects and tweak without rewriting the entire symphony. A pattern in this course earns the “pattern” label because it satisfies three criteria:

1. Multi-technique choreography: More than one skill working in concert.

2. Reusable control structure: The same scaffold can solve many tasks with minimal edits.

3. Explicit quality or resource guardrails: Not just “do X,” but “do X under these constraints.”

We will look at the following five flagship patterns in this course:

• Prompt chaining: This pattern involves a linear sequence where a complex objective is processed through ordered stages, each handled by a dedicated agent. The output from one agent serves as the input for the next (e.g., a “drafting agent” passes to a “critique agent”, which then passes to a “polishing agent”). Gates positioned between these agents can perform rejection, revision, or short-circuiting actions based on criteria.

• Routing: Operating as an intelligent switchboard, this pattern classifies an incoming request and then dispatches it to the most suitable specialist agent. This specialist agent could be tailored with a specific prompt, linked to a retrieval module, or be a fine-tuned sub-agent, ensuring the request reaches the most competent handler.

• Parallelization: This pattern follows a divide-and-aggregate approach, where a workload is distributed across multiple independent agents for simultaneous execution. The results generated by these parallel agents are then consolidated through aggregation. The pattern’s definition lies in its governing structure, including the rules for fanning out tasks, the policies for merging results, and the logic for breaking ties, distinguishing it from merely initiating multiple calls.

• Orchestrator–worker model: This represents a command-and-delegate structure. A top-level orchestrator agent decomposes a complex goal into smaller subtasks, assigns these subtasks to specialized worker agents, and then synthesizes the individual outputs provided by those workers.

• Evaluator–optimizer loop: This pattern embodies continuous improvement through an iterative process. One agent generates a draft or solution, while a separate evaluator agent scores or critiques it. This pair of agents then iterates and refines the output until a predefined score threshold is achieved or an allocated budget ceiling is met.

How do techniques power flexible patterns?

Each of these architectures serves as a reusable playbook: you can swap in different techniques, adjust thresholds, or aim it at a new but related problem, and it still works. That’s why we use the word pattern for them: they’re strategic blueprints, not just isolated tactics.

Techniques are modular, allowing them to be swapped within patterns without altering the core structure. This means you can easily tailor aspects like precision, speed, or cost. For example, you can replace complex reflection with a faster scorer in an evaluator-optimizer loop, or add a creative ReAct step to a prompt chain. This inherent composability transforms a few fundamental skills into an expansive design space, a concept we’ll frequently highlight as we connect techniques to patterns in upcoming lessons.

Think of the techniques listed as the “usual suspects” you’ll spot in real-world code; they’re not prerequisites, just the skills that most commonly power each pattern’s control flow. The following table will help you map this out:

A pattern can work with fewer techniques or additional ones, depending on the task, budget, and design choices. In the lessons that follow, we’ll call out these junction points often, highlighting which technique powers which stage of every pattern we build.

Is this the final word?

The AI agent landscape is constantly evolving, with new techniques and terminology emerging weekly. This dynamic environment, while exciting, makes building lasting systems challenging. Our distinction between techniques and patterns isn’t an absolute truth, but a pragmatic framework designed to navigate this complexity.

Boundaries and patterns will undoubtedly evolve with new techniques and capabilities. Yet, the core distinction between individual cognitive skills and the orchestrated workflows deploying them, remains durable. This framework offers a mental model to cut through the noise, empowering you to critically assess new patterns for genuine novelty or reusability. The field’s continuous evolution is its nature; with clear thinking and foundational understanding, you’ll be well-equipped to adapt and contribute to its next chapter.