AI Agent Design Patterns — Guide

AI Agents: Two Reference Families + 5 Practical Architectures

AI agents are rapidly moving from experimental demos to core operational components inside modern organizations. As this shift accelerates, one of the biggest challenges is not the model itself, but conceptual confusion: what exactly is an “AI agent,” how autonomous should it be, and how should it be designed in practice?

Why two reference families exist

The term “AI agent” is used in two complementary ways. Mature teams keep both views because they answer different questions:

How to use this in a session

• Use Family A to set expectations about autonomy (what “level” of agent you actually need).
• Use Family B to teach implementation building blocks (how you achieve reliability, safety, and scalability).
• Then select from the five practical architectures based on task characteristics (single-step vs multi-step, policy grounding, high-stakes quality, parallel expertise).
• Emphasize that real-world systems are usually hybrids: for example, a Planner–Executor agent may also use RAG for grounding and a bounded reflection loop for quality.

References (Industry + Research)

Fast selection guide

Theoretical foundations: Two reference families used in industry

The term “AI agent” is used in two ways. To reduce confusion in your session, it helps to anchor on (A) a classic taxonomy that classifies agents by their decision logic, and (B) modern implementation patterns that show how LLM-based agents are built today.

Family A — Classic agent taxonomy (AI theory)

This family is the most common “textbook” way to describe agents. It classifies agents by how they decide (reactive rules, internal state, goal reasoning, utility optimization, learning).

Figure — Classic Agent Types (Decision Logic)

This visual is a capability ladder (not a product architecture). It explains how agents evolve from purely reactive rules to learning from experience. Use it to set expectations: as you move right, you typically gain adaptability—but also add complexity, data needs, and stronger governance requirements.

Quick mapping to modern LLM systems

Family B — Modern LLM agent patterns (implementation)

This family is the “how to build it” viewpoint used heavily in industry since 2022. It focuses on patterns that make LLMs behave more like systems: tool use, planning, reflection, and multi-agent coordination.

Figure — LLM Agent Patterns (Implementation)

This figure summarizes the four most common building blocks used to implement LLM-based agents in industry. Each block is a reusable capability (tools, planning, reflection, coordination) that can be combined. The center node represents the overall agent runtime (prompts, tool router, memory/state, logging, and guardrails) that hosts these patterns.

Why these two families coexist

• Family A gives language for “agent intelligence level” (decision logic).
• Family B gives patterns for “agent system architecture” (how to implement with LLMs and tools).
• In modern products, we often implement Family A concepts using Family B patterns.

Note: In the next sections, we translate these foundations into five deployable architectures.

Building an AI Agent as a Product: From Idea to Production

Designing an AI agent should be approached as a product development effort, not as a prompt-engineering exercise. Mature organizations treat agents as software products with clear users, workflows, controls, UX, and lifecycle management. Below is a detailed, industry-strong process using a real example: an Excel Reconciliation Agent.

Figure — End-to-end agent product lifecycle

This visual is a high-level map of the product journey: discovery → UX/prototype → architecture → build → evaluation → pilot → deployment → continuous improvement. It frames the agent as a long-lived product with controls, telemetry, and iteration—not a one-off automation.

1) Product Framing & Problem Definition

Start by framing the agent as a product with a clear value proposition. For Excel reconciliation, the problem is not “compare files”—it is: reduce manual reconciliation time, errors, and cognitive load for finance or operations teams.

Figure — Value proposition & scope boundaries

This diagram captures what the agent will do (and will not do), the user persona(s), and measurable outcomes. It prevents “scope creep” and anchors later UX and evaluation design.

2) UX / UI & Interaction Design

Agents must be designed around progressive trust. Users should always understand what the agent is doing, what it is confident about, and where human validation is required.

• File upload with clear supported formats and data privacy messaging
• Step-by-step progress indicators (ingestion, normalization, matching, review)
• Visual diff tables highlighting matches, mismatches, and confidence scores
• Explicit “human-in-the-loop” checkpoints for low-confidence matches

Figure — Progressive trust UX flow

The UX flow makes the agent’s internal stages visible (ingest → normalize → match → review → export), and inserts human checkpoints only where confidence is insufficient.

3) Agent Capability & Architecture Design

Decompose the agent into deterministic and non-deterministic components. This separation is critical for reliability and explainability. In reconciliation, the math and file IO are deterministic; the ambiguity resolution is where the LLM helps most.

• Deterministic layer: file parsing, schema detection, normalization, calculations
• Agentic layer: interpreting column semantics, resolving ambiguities, explaining differences
• Design patterns used: Tool-Using Agent + Planner–Executor + Reflection

Figure — Deterministic vs agentic responsibilities

This diagram is an extract of the full system: it shows which subproblems must be deterministic (parsing/calculation), which are agentic (semantic mapping/ambiguity resolution), and where checkpoints and logging live.

4) Development Process (Industry-Strong Model)

Use a hybrid approach: Agile product development for iterative delivery and stakeholder feedback, plus AI evaluation loops for reliability. Build the deterministic backbone first, then add agent intelligence.

Figure — Agile delivery + AI evaluation loops

This diagram shows the dual-track loop: product increments ship frequently, while evaluation gates protect quality. It helps teams avoid “demo-only agents” by enforcing measurable progress and stability.

5) Testing & Validation Strategy

Testing an agent goes beyond unit tests. You must validate behavior, robustness, and trust—especially because input variability is the norm in Excel-based processes.

Figure — Evaluation matrix and confidence thresholds

This figure is an extract of a full evaluation program: golden datasets define expected outcomes, confidence bands drive UX gates (auto-accept vs review), and audits compare agent decisions to expert baselines.

6) Pilot, Demos & Stakeholder Validation

Pilots should be run with real users and real data, but under controlled conditions. Strong pilots focus on evidence: accuracy, time saved, trust, and operational readiness.

• Shadow mode: agent produces results without executing final actions
• Side-by-side: manual vs agent-assisted reconciliation (time + error metrics)
• Executive demos: outcome-first storytelling with traceability (what, why, evidence)

Figure — Pilot design: shadow → assisted → controlled automation

This visual shows a staged adoption path: start in shadow mode, move to assisted mode with human approvals, and only then automate low-risk actions. It increases safety and stakeholder confidence.

7) Deployment & Operations

Production deployment requires operational discipline. Agents must be observable and governable. Treat prompts, tool schemas, and workflows as versioned artifacts.

Figure — Production readiness: observability, governance, cost

This diagram is an extract of a full ops model: telemetry captures tool traces and outcomes, governance controls versions and permissions, and runtime monitoring detects drift, cost spikes, or abnormal behavior.

8) Continuous Improvement & Product Evolution

Successful agents are never “done.” They evolve based on user feedback, new data patterns, and changing business rules. Build feedback and learning loops into the product from day one.

Figure — Feedback → evaluation → iteration loop

This visual shows how product feedback becomes measurable improvements: feedback labels enrich evaluation sets, regressions are caught early, and the agent’s behavior evolves safely through versioned releases.

1) Tool-Using Reactive Agent (Reflex + Tools)

A fast agent that interprets a request and calls tools immediately (minimal long-horizon planning). Best for operational tasks and high-volume execution.

Figure — Reactive + Tools

This is a minimal viable agent loop: the agent routes intent and immediately calls one or more tools, then validates the results before responding. The diagram is an extract—in production you also add authentication, rate limits, audit logs, and permissions. The Safety Gate represents policy checks and/or confirmation before any write action (create/update/delete).

Core components

• Intent/router + entity extraction
• Tool catalog with strict schemas
• Deterministic validators for outputs
• Write-action confirmations & least privilege
• Audit logging of tool traces

Real-world examples

• IT Ops: restart a service, verify health checks, record outcome in a ticket.
• Customer Support: fetch last invoice from billing API and initiate resend workflow.
• Finance Ops: pull daily spend from DW and flag anomalies with rule checks.

2) RAG + Tool Agent (Context-Grounded Action Agent)

Adds retrieval (policies, SOPs, docs) before acting—so outputs are grounded and defensible. Ideal for compliance-heavy environments.

Figure — Retrieval Grounding + Tools

This diagram highlights how an agent becomes defensible: it retrieves evidence (policies/SOPs/docs), composes an answer or plan grounded in that evidence, and then performs tool actions with traceability. It is an extract of a full RAG system: in practice you also include chunking/indexing, relevance thresholds, source allowlists, freshness/version rules, and citation capture so outputs can be audited.

Core components

• Retriever (search/vector) + chunking strategy
• Citation/evidence tracker
• Tool layer (tickets, approvals, systems)
• Source allowlists and version/freshness rules
• Fallback: “not found” with escalation path

Real-world examples

• HR: remote work policy answer grounded in official policy sections + approval request.
• Security: draft an exception request referencing control requirements + open a ticket.
• Enablement: step-by-step calibration guidance from the latest SOP.

3) Planner–Executor Agent (Goal-Directed)

Separates planning from execution. The planner builds a structured roadmap; the executor runs steps with checkpoints and re-planning triggers. Best for multi-step work and program-like tasks.

Figure — Planner → Executor with Checkpoints

This figure shows a two-layer control model: the Planner produces a structured Plan (often JSON), and the Executor runs steps with tool calls under checkpoints. The checkpoints (Validate → Update State → Re-plan) are where reliability is gained: errors, missing inputs, or constraint violations trigger a re-plan rather than silent failure. The Rollback branch indicates controlled reversal for risky writes.

Core components

• Plan schema (JSON): steps, inputs/outputs, validation, rollback
• State store: step results + decisions
• Execution controller: timeouts, retries, kill-switch
• Re-planning triggers: missing data, tool error, constraint violation

Real-world examples

• Cloud migration: inventory → dependency map → cutover plan → execute → validate → post-mortem.
• Data incident: detect → isolate scope → test fix → deploy → verify → RCA.
• Procurement automation: requirements → shortlist → compliance → approvals → contract drafting.

4) Reflect–Critique–Revise Agent (Quality Gate / Self-Review)

Adds a structured critique loop to improve quality and reduce errors. The critic can be the same model or a second “reviewer” agent. Best when output quality and risk are high.

Figure — Draft → Critique → Revise

This diagram represents a quality gate pattern. The Critic applies a rubric (accuracy, completeness, safety, constraints, tone) to a draft, and only then allows revision and finalization. It is an extract of the wider system: in real deployments you typically add scoring thresholds, deterministic checks (e.g., schema validation), and bounded iteration (Max 2 rounds) to control cost and avoid infinite loops.

Core components

• Draft generator
• Critic rubric (accuracy, completeness, safety, tone, constraints)
• Revision step
• Stop conditions (max rounds, threshold score)

Real-world examples

• Leadership memo: draft → critic checks assumptions and missing decisions → revise with clarity.
• Security response: propose controls → critic aligns to framework → revise with measurable actions.
• Executive email: tone/clarity critic → revise for concise ask + next steps.

5) Supervisor + Specialist Multi-Agent (Orchestrated MAS)

A supervisor decomposes work and delegates to specialized agents (researcher, analyst, verifier, writer, tool-operator). Best for complex work requiring parallel expertise and modularity.

Figure — Supervisor Orchestration

This is a coordination architecture: a Supervisor decomposes work, assigns it to specialists with narrow roles (research, analysis, verification, writing, tool ops), and then synthesizes the final answer. The Shared Memory hub represents a common workspace for artifacts (citations, intermediate notes, plans). The diagram is an extract—production systems also define schemas, arbitration rules, and timeouts to prevent drift or circular collaboration.

Core components

• Supervisor with delegation policy
• Specialists with narrow scopes + output schemas
• Shared memory (“blackboard”) for artifacts
• Aggregator: conflict resolution + final output
• Timeouts and bounded collaboration

Real-world examples

• Vendor due diligence: security agent + finance agent + legal agent → supervisor synthesizes risks.
• Architecture: target architecture agent + risk agent + exec summary agent → unified proposal.
• AI governance: policy agent + controls agent + training agent → operational program output.

Live A/B Quiz — Agent Design Decisions

Use this interactive A/B quiz during class to discuss trade-offs. After each choice, the page reveals the recommended option and the rationale (patterns + agent type).