Module 2: Application & Agent Architectures
Designing an LLM application is not just about picking a model—it’s about picking (and often combining) the right architecture pattern along a spectrum that runs from a single LLM call to fully-autonomous multi-agent swarms.
Architecture Patterns
The following tables provide an overview of common architecture patterns. We distinguish between deterministic workflow patterns and more flexible agentic patterns.
Workflow patterns
These workflows show a deterministic path that is easy to reason about and debug.
Pattern | Essence | When it shines | Typical examples |
---|---|---|---|
Prompt Chaining | Pipe the output of one LLM call straight into the next to decompose a task into fixed steps. | Any job that naturally breaks into a “step 1 → step 2 → step 3” script. | Outline → validate → draft a document; multi-stage data ETL. |
Routing / Handoff | A “router” LLM first classifies the request, then hands it to a specialised prompt / model / agent. | Heterogeneous traffic where different skills or price-points are optimal. | Customer-support triage, tiered model stacks (cheap vs. premium), content-type dispatch. |
Parallelisation | Split independent subtasks or multiple perspectives, run them concurrently, then aggregate. | Latency-sensitive work or problems that benefit from diversity / voting. | RAG with query splits, document section summaries, “best-of-N” idea generation. |
Agentic patterns
These patterns show a model-driven path that is more flexible and can adapt to changing circumstances.
Pattern | Essence | When it shines | Typical examples |
---|---|---|---|
Reflection (Evaluator-Optimiser) | The model critiques its own output and iterates until criteria are met—generation → self-assessment → refine loop. | Quality-critical tasks where first drafts often miss the mark. | Code that compiles & passes tests, self-RAG answer checking, polished writing. |
Tool Use (Function Calling) | The LLM decides to invoke external functions/APIs, receives the results, then writes the final answer. | Anything needing fresh data, side-effects, or capabilities beyond text. | Calendar booking, database look-ups, smart-home control, code execution. |
Planning (Orchestrator-Workers) | A planner LLM dynamically drafts a multi-step plan, delegates subtasks to worker agents, and synthesises the results, re-planning if needed. | Open-ended, multi-phase goals where steps are unknown until you start. | Feature implementation pipelines, research reports, multi-modal creative projects. |
Multi-Agent Collaboration | Multiple agents with distinct roles/personas/toolsets coordinate—via a manager or peer-to-peer—to reach a shared goal. | Complex, multifaceted problems that mirror real-world teams or debates. | Software project teams (PM, coder, tester), debate simulators, collaborative story writing, scientific “lab” agents. |
(Source: Phil Schmid)
How to pick the right pattern
- Start simple. If you can pre-write the steps, a workflow pattern is faster, cheaper, and easier to debug.
- Add autonomy only for uncertainty. Shift to Reflection, Planning, or Multi-Agent once the task demands dynamic decision-making or parallel specialisation.
- Combine patterns pragmatically. Real systems often nest these blocks: e.g., a Planning agent that assigns Tool-Using workers and then reflects on their outputs.
This choice introduces a trade-off between predictability and agency: the higher you climb, the more freedom your system gains, but the harder it becomes to anticipate or constrain every step.
(source: Langchain)