Session 7· 06· 10 min

Real-World Architecture Examples

What you'll learn
  • Map 6 real applications to the patterns you have learned
  • See how architecture choices follow from constraints
  • Understand why our BookingAgent capstone uses a single agent

Theory is only useful when you can apply it. This lesson walks through six real applications and explains why each one maps to a specific architectural pattern. By the end, you will see these patterns everywhere.

Application-to-pattern map

 PatternWhy this pattern?
Customer support botHandoffsConversational flow: triage then specialist then billing
RAG pipelineRouting workflowClassify query type, route to right retriever
Code assistantSingle agentOne domain, focused tools (read/write/run)
Data processing pipelineOrchestrator-WorkerBreak into subtasks, process in parallel
BookingAgent (capstone)Single agent5-8 tools, one domain, no need to split
Enterprise multi-dept botSubagents (supervisor)HR, finance, IT — each a separate team and agent

Deep dive: Customer support bot

The classic handoff architecture. A triage agent classifies the issue, asks clarifying questions, then hands off to the appropriate specialist with full conversation context. The specialist resolves the issue and may hand off to a billing agent if payment is involved.

Customer support: Handoff chain
Triage agent
Classify & gather info
Handoff
Pass context
Specialist agent
Resolve issue
Handoff
If billing needed
Billing agent
Process payment

Why handoffs instead of a router? Because the conversation is sequential and stateful — the specialist needs to know what the triage agent already discussed. A router would lose that context.

Deep dive: Data processing pipeline

An orchestrator examines a dataset, identifies what processing each partition needs (cleaning, transformation, validation), dispatches workers in parallel, and then aggregates the results.

Data pipeline: Orchestrator-Worker
Orchestrator
Analyze & plan
Workers (parallel)
Clean / Transform / Validate
Orchestrator
Aggregate & verify

Deep dive: Enterprise multi-department bot

A supervisor agent sits at the front. When an employee asks an HR question, the supervisor delegates to the HR subagent. A finance question goes to the finance subagent. Each department's team develops and maintains their own agent independently.

Supervisor
Central coordinator
  • Routes to the right department
  • Synthesizes cross-department answers
  • Maintains conversation state
  • Owned by the platform team
HR Agent
Department specialist
  • PTO policies, benefits, onboarding
  • Connected to HR database tools
  • Owned by the HR team
  • Deployed independently
Finance Agent
Department specialist
  • Expense reports, budgets, invoices
  • Connected to finance tools
  • Owned by the finance team
  • Deployed independently
Why is BookingAgent a single agent?
Our capstone BookingAgent has 5-8 tools (search flights, book hotel, check availability, etc.) in a single domain (travel). It handles one user at a time in a conversational flow. There is no team-ownership split and no need for parallel execution. A single agent with good tools is the right call — and that is exactly what the decision framework from lesson 05 would tell you.

Check your understanding

Knowledge Check
A startup is building a code review bot that reads PRs, checks style, runs tests, and writes review comments. All tools are in one domain (code). Which architecture?
Knowledge Check
A large e-commerce company has separate teams for product search, order management, and returns. They want a unified chatbot. Which pattern?
Ready for the hands-on?
You now have the complete conceptual toolkit: patterns, performance data, a decision framework, and real-world examples. In Session 8 you will actually build these patterns with LangChain code — starting with a single ReAct agent and progressing through handoffs and subagents.