Begin with the problem
Architecture patterns are reusable starting points, not rigid recipes. A pattern helps a team recognize familiar forces and then include only the components the task requires.
requirements → match pattern → remove unnecessary pieces → add risk controls → evaluateWhat you will learn
- Recognize common LLM, RAG, agent, batch, streaming, and document patterns.
- Connect each pattern to its required components and risks.
- Adapt patterns instead of copying enterprise complexity into small problems.
Current production grounding: Google’s Gemini tools documentation distinguishes managed built-in tools from custom functions executed by the application.
These links document current public features and practices. They do not reveal a provider’s private implementation or guarantee that every product uses identical defaults.
1. The Engineering Problem
Modules 21-23 gave you the individual decision frameworks — RAG vs. fine-tuning, workflow vs. agent, weighted priorities. This module assembles the outcomes of those decisions into named, reusable architecture patterns — the vocabulary a real engineering team uses to say “this is a RAG-with-reranking problem” and immediately know what components that implies.
2. The Pattern Catalog
| Pattern | When It Applies | Key Components |
|---|---|---|
| Simple LLM app | Task fits in one prompt, no external knowledge or actions needed | Model call, structured output validation |
| RAG | Task needs current or private knowledge beyond training data | Retrieval, vector DB, context assembly, model call |
| RAG + reranking | Initial retrieval isn’t precise enough at top-k | Retrieval, reranking, context assembly, model call |
| Agent workflow | Task needs dynamic, multi-step reasoning | Agent loop, tools, state management (your Agents course) |
| Agent + tools | Agent needs to observe and act on real systems | Everything above, plus tool schemas and validation (Module 9) |
| Human-in-the-loop | high-risk actions need approval before execution | Everything above, plus an approval gate (your Agents course’s Module 16) |
| Multi-agent | Task benefits from specialized, coordinated roles | Multiple agents, a coordination pattern (your Agents course’s Module 15) |
| Batch AI pipeline | Processing doesn’t need real-time response | Queue, async workers (Module 17), batch model calls |
| Streaming/real-time app | interactive UX matters | Streaming responses (Module 16) |
| Document intelligence | Extracting structured data from unstructured documents | Ingestion (Module 18), structured output (Module 9) |
| Enterprise knowledge assistant | needs RAG plus per-user access control at scale | RAG, access control (Module 13), reranking, citations |
| AI coding assistant | needs code understanding, generation, and multi-step editing | Agent, tools (file read/write, test execution), often multi-agent |
3. Composability — Patterns Combine
"Enterprise knowledge assistant" is not a single, atomic
pattern -- it's RAG + reranking + access control + citations,
COMPOSED.
"AI coding assistant" is agent + tools + (often)
multi-agent, COMPOSED.
Real systems are composed of several of these named
patterns working together -- exactly Module 24 of your Agents
course's "single-agent architectures" theme, now extended across
this entire course's broader engineering vocabulary.4. A Real-World Analogy — The Factory, Once More
A factory's engineers don't design EVERY new product line from
first principles -- they reach for KNOWN, PROVEN sub-assembly
patterns ("this needs a conveyor system," "this needs a quality-
control station") and COMBINE them for the SPECIFIC product.
AI architecture patterns are EXACTLY this same reusable vocabulary
-- naming a REPEATED combination of components so a team can reason
and communicate about it QUICKLY, without re-deriving it from
scratch for every new feature.5. A worked developer example
TechCorp names their features using this module’s pattern catalog, directly speeding up architecture conversations:
| Feature Request | Pattern Match | Components Implied |
|---|---|---|
| “Answer questions from our private policy docs, with per-department access control” | Enterprise knowledge assistant | RAG + access control + reranking + citations |
| “Investigate and propose a fix for a novel billing dispute” | Agent + tools (+ human-in-the-loop for approval) | Agent loop, tools, approval gate |
| “Classify support tickets by urgency” | Simple LLM app, or LLM workflow (Module 22) | Model call, structured output |
| “Nightly batch summarization of yesterday’s support tickets” | Batch AI pipeline | Queue, async workers, batch model calls |
6. How Is This Used in the Industry?
🤖 How Is This Used in the Industry?
Production teams use this pattern vocabulary in design reviews and technical specs — naming a feature’s pattern immediately communicates its component requirements, expected complexity, and relevant modules of prior engineering knowledge to reuse, dramatically speeding up architecture discussions compared to describing every system from first principles each time.
7. Common Mistakes
Incorrect idea: Treating these patterns as rigid templates rather than composable building blocks.
Why it is incorrect: As shown directly in Section 3, real systems combine multiple patterns.
Incorrect idea: Reaching for the “enterprise knowledge assistant” pattern’s full complexity for a task that’s just a simple LLM app.
Why it is incorrect: As shown directly in Module 8’s “least autonomous architecture” principle, match the pattern to actual requirements.
Incorrect idea: Not recognizing when a feature IS a well-known pattern already, and re-deriving its architecture from scratch.
Why it is incorrect: As shown directly in Section 4, this wastes, reusable engineering knowledge.
8. Code — An Architecture Pattern Matcher
What this shows: a working function matching stated task requirements to this module’s named patterns — directly implementing Section 5’s worked developer example as reusable decision logic, the kind of tool a team could use to quickly name a new feature’s architecture.
from dataclasses import dataclass
from enum import Enum
class PatternName(Enum):
SIMPLE_LLM_APP = "simple_llm_app"
RAG = "rag"
RAG_RERANKING = "rag_with_reranking"
AGENT_TOOLS = "agent_with_tools"
ENTERPRISE_KNOWLEDGE = "enterprise_knowledge_assistant"
@dataclass
class ArchitecturePattern:
name: PatternName
when_to_use: str
key_components: list
# Section 2's catalog, made into structured, queryable data
PATTERN_CATALOG = [
ArchitecturePattern(PatternName.SIMPLE_LLM_APP,
"Task fits in one prompt, no external knowledge or actions needed",
["Model call", "Structured output validation"]),
ArchitecturePattern(PatternName.RAG,
"Task needs current or private knowledge beyond training data",
["Retrieval", "Vector DB", "Context assembly", "Model call"]),
ArchitecturePattern(PatternName.RAG_RERANKING,
"RAG's initial retrieval isn't precise enough at top-k",
["Retrieval", "Reranking", "Context assembly", "Model call"]),
ArchitecturePattern(PatternName.AGENT_TOOLS,
"Task needs dynamic, multi-step reasoning with real-world actions",
["Agent loop", "Tools", "State management"]),
ArchitecturePattern(PatternName.ENTERPRISE_KNOWLEDGE,
"needs RAG PLUS per-user access control across a large knowledge base",
["Retrieval", "Access control", "Reranking", "Model call", "Citations"]),
]
def match_pattern(needs_knowledge: bool, needs_precise_retrieval: bool, needs_dynamic_actions: bool,
needs_access_control: bool) -> ArchitecturePattern:
"""Matches task requirements to the appropriate NAMED
architecture pattern (Section 5's worked developer example)."""
if needs_access_control and needs_knowledge:
return next(p for p in PATTERN_CATALOG if p.name == PatternName.ENTERPRISE_KNOWLEDGE)
if needs_dynamic_actions:
return next(p for p in PATTERN_CATALOG if p.name == PatternName.AGENT_TOOLS)
if needs_knowledge and needs_precise_retrieval:
return next(p for p in PATTERN_CATALOG if p.name == PatternName.RAG_RERANKING)
if needs_knowledge:
return next(p for p in PATTERN_CATALOG if p.name == PatternName.RAG)
return next(p for p in PATTERN_CATALOG if p.name == PatternName.SIMPLE_LLM_APP)
# Exactly Section 5's first two real feature requests
result1 = match_pattern(needs_knowledge=True, needs_precise_retrieval=False, needs_dynamic_actions=False, needs_access_control=True)
print(f"[{result1.name.value}] {result1.when_to_use}")
result2 = match_pattern(needs_knowledge=False, needs_precise_retrieval=False, needs_dynamic_actions=True, needs_access_control=False)
print(f"[{result2.name.value}] {result2.when_to_use}")Expected Output:
[enterprise_knowledge_assistant] needs RAG PLUS per-user
access control across a large knowledge base
[agent_with_tools] Task needs dynamic, multi-step
reasoning with real-world actionsWhat this confirms: the function correctly identifies TechCorp’s “per-department access control” request as the enterprise knowledge assistant pattern (not plain RAG) and the “investigate and propose a fix” request as agent+tools — exactly Section 5’s real developer example, made into a working, reusable pattern-matching tool a real team could apply to a new feature request.
9. Production Considerations
- Document which named pattern a feature implements in its design spec — this speeds up onboarding and future architecture reviews
- Revisit pattern choice as requirements evolve — Module 23’s weighted-decision re-evaluation applies here too
10. Trade-offs
- Naming and cataloging patterns adds upfront documentation effort — worthwhile for the communication and reuse speed it provides across a growing engineering team
- Over-fitting a feature into an existing named pattern when it doesn’t match risks forcing unnecessary components — the match should reflect actual requirements, not just convenient categorization
11. Chapter Summary
Named architecture patterns — simple LLM app, RAG, RAG+reranking, agent+tools, human-in-the-loop, multi-agent, enterprise knowledge assistant, and more — are reusable vocabulary for communicating a feature’s component requirements quickly, directly assembling the individual decisions from Modules 21-23 into recognizable, composable building blocks.
Real systems combine multiple patterns rather than fitting one atomic template, and matching a new feature to the correct pattern (or combination) speeds up design conversations and avoids re-deriving architecture from scratch for every new request.
12. Visual Cheat Sheet
Simple LLM App -> RAG -> RAG+Reranking -> Agent+Tools -> Multi-Agent
|
+ Human-in-the-Loop (high-risk)
|
Enterprise Knowledge Assistant
= RAG + Reranking + Access Control + Citations13. Top Takeaways
- Named architecture patterns are reusable vocabulary that speeds up design communication and avoids re-deriving architecture from scratch.
- Real systems compose multiple patterns — “enterprise knowledge assistant” is RAG + reranking + access control + citations, not one atomic thing.
- Matching a feature request to the correct pattern (or combination) directly implies its component requirements.
- These patterns assemble the individual decisions from Modules 21-23 (RAG vs. fine-tuning, workflow vs. agent, weighted priorities) into recognizable building blocks.
- Documenting a feature’s pattern in its design spec speeds up future architecture reviews and onboarding.
14. Interview Questions
Q: 1. Explain why “enterprise knowledge assistant” is described as a composed pattern rather than an atomic one.**
Ans: It combines several distinct patterns and components working together — RAG for knowledge retrieval, reranking for precision at scale, access control for per-user security, and citations for trustworthiness. None of these alone constitutes an “enterprise knowledge assistant” — it’s the specific, combination that defines this named pattern.
- Why it matters: Recognizing composability prevents teams from either under-building (missing a necessary component like access control) or treating the pattern as a rigid, all-or-nothing template.
- Real-world example: Section 5’s TechCorp per-department access control example.
- Common mistake: Building “just RAG” for a request that needs the full enterprise-knowledge-assistant composition, missing access control entirely.
- Interviewer is testing: Whether the candidate understands patterns as composable, not atomic.
- Likely follow-up: “What component would you add if the knowledge assistant also needed to cite its sources reliably?” → Your RAG course’s citation-generation coverage, added as an explicit component to the composition.
Q: 2. How would you use this pattern vocabulary in a design review to speed up an architecture discussion?**
Ans: I would identify which named pattern or combination matches the feature. For example: “This is RAG with reranking,” or “This is an agent with tools and a human approval gate for the high-risk action.”
That name immediately communicates the expected components, complexity, and relevant engineering knowledge. The team can discuss the differences that matter instead of rebuilding the entire architecture vocabulary from scratch.
- Why it matters: This accelerates design reviews and reduces miscommunication about scope and complexity.
- Real-world example: Section 6 — production teams use this exact vocabulary in specs and reviews.
- Common mistake: Describing every new feature’s architecture in exhaustive, from-scratch detail rather than leveraging established pattern vocabulary.
- Interviewer is testing: Whether the candidate can communicate architecture efficiently using shared, established vocabulary.
- Likely follow-up: “What would you do if a feature doesn’t cleanly match any existing pattern?” → Document it as a new pattern if it’s likely to recur, or as a one-off composition if it’s unique to this specific requirement.
15. Scenario-Based Question
Scenario: A new engineer at TechCorp is asked to build a feature that answers questions from company documents, but with results tailored per user’s department access level. They start implementing plain RAG (Module 7) without any access control, since “RAG” was the term used in the initial request.
- Problem Analysis: Section 7’s common mistake — treating “RAG” as the complete pattern when the actual requirement (per- department access) matches the enterprise knowledge assistant composition instead.
- How to Think: The engineer correctly identified ONE component (RAG) but missed that the complete requirement is a composed pattern needing access control as well.
- Investigation: Review the original feature request against Section 2’s full pattern catalog — does “per-department access level” map to a specific, additional component?
- Root Cause: Incomplete pattern matching — recognizing RAG but not recognizing the access-control requirement as implying the fuller enterprise knowledge assistant composition (Section 2, 5).
- Solution: Add Module 13’s access-control layer (filter-then- search, enforced structurally at the data layer) to the existing RAG implementation — completing the correct pattern match rather than shipping plain RAG with a real, unaddressed security gap.
- Trade-offs: Adding access control after initial RAG implementation requires rework — a real, avoidable cost of not matching the complete pattern correctly from the start.
- Production Considerations: This scenario directly demonstrates Section 3’s composability point — correctly recognizing which ADDITIONAL components a feature’s full requirements imply, beyond the most obvious single pattern, is a necessary skill this module’s catalog is designed to support.
16. Next Step
Next: Module 29 — AI Anti-Patterns — closing Level 10: over 50 mistakes and anti-patterns, why each happens, why it’s dangerous, and the correct approach.
- Author
- TechByteByByte Editorial Team
- Reviewed by
- TechByteByByte Admin
- Published
- Last reviewed