| 1 | # 01_cover |
| 2 | |
| 3 | Welcome everyone to this session on Building Effective Agents. This presentation distills key insights from Anthropic's engineering team, drawing from their experience working with dozens of teams building LLM agents across industries. |
| 4 | |
| 5 | The central thesis is compelling: the most successful implementations aren't using complex frameworks. They're building with simple, composable patterns. |
| 6 | |
| 7 | [Pause] |
| 8 | |
| 9 | Let's explore what those patterns look like and when to use them. |
| 10 | |
| 11 | Key points: ① Anthropic's field-tested agent patterns ② Simplicity beats complexity ③ Practical implementation guidance |
| 12 | Duration: 1.5 minutes |
| 13 | |
| 14 | --- |
| 15 | |
| 16 | # 02_what_are_agents |
| 17 | |
| 18 | [Transition] Before diving into patterns, we need to establish a shared vocabulary. |
| 19 | |
| 20 | Anthropic draws an important architectural distinction between two types of agentic systems. On the left, we have Workflows — systems where LLMs and tools follow predefined code paths. Think of these as choreographed sequences. On the right, Agents — systems where the LLM itself decides what to do next, dynamically directing its own processes. |
| 21 | |
| 22 | [Pause] |
| 23 | |
| 24 | The key takeaway here is that both are "agentic systems." It's a spectrum, not a binary — and the right choice depends on your specific use case. |
| 25 | |
| 26 | Key points: ① Workflows = predefined orchestration ② Agents = autonomous tool-using LLMs ③ Both are valid — spectrum matters more than label |
| 27 | Duration: 1.5 minutes |
| 28 | |
| 29 | --- |
| 30 | |
| 31 | # 03_when_to_use_agents |
| 32 | |
| 33 | [Transition] So when should you reach for these more complex patterns? |
| 34 | |
| 35 | The answer starts on the left: most of the time, you should start with single LLM calls optimized with retrieval and in-context examples. This covers the vast majority of applications. |
| 36 | |
| 37 | When you do need more, workflows give you predictability for well-defined tasks, while agents shine when flexibility and model-driven decisions are needed at scale. |
| 38 | |
| 39 | [Interactive] Think about your current project — where does it fall on this complexity spectrum? |
| 40 | |
| 41 | And a crucial piece of advice about frameworks: start with raw LLM APIs. Many patterns need just a few lines of code. If you do use a framework, make sure you understand what's happening underneath. |
| 42 | |
| 43 | Key points: ① Start simple — single LLM calls first ② Workflows for defined tasks, agents for flexibility ③ Understand your frameworks |
| 44 | Duration: 2 minutes |
| 45 | |
| 46 | --- |
| 47 | |
| 48 | # 04_augmented_llm |
| 49 | |
| 50 | [Transition] Every agentic system starts from the same building block: the augmented LLM. |
| 51 | |
| 52 | This diagram shows the foundational unit. You take a base LLM and enhance it with three capabilities: retrieval for accessing relevant information, tools for taking actions in the world, and memory for retaining context across interactions. |
| 53 | |
| 54 | [Pause] |
| 55 | |
| 56 | Two things matter most in implementation: tailor these capabilities to your specific use case, and ensure they provide well-documented interfaces. Anthropic's Model Context Protocol — MCP — is one approach to standardizing third-party tool integration. |
| 57 | |
| 58 | Key points: ① LLM + retrieval + tools + memory ② Tailor capabilities to use case ③ MCP for standardized integration |
| 59 | Duration: 1.5 minutes |
| 60 | |
| 61 | --- |
| 62 | |
| 63 | # 05_prompt_chaining |
| 64 | |
| 65 | [Transition] Now let's look at the first workflow pattern: Prompt Chaining. |
| 66 | |
| 67 | The diagram shows the core idea — decompose a task into sequential steps. Each LLM call processes the output of the previous one, with optional "gate" checks at intermediate points to ensure quality. |
| 68 | |
| 69 | The key trade-off is latency for accuracy. By making each individual LLM call a simpler, more focused task, you get better overall results. |
| 70 | |
| 71 | Two concrete examples: generating marketing copy then translating it, or writing a document outline, checking it meets criteria, then writing the full document. |
| 72 | |
| 73 | Key points: ① Sequential LLM calls with gate checks ② Trade latency for accuracy ③ Works when tasks decompose into fixed subtasks |
| 74 | Duration: 1.5 minutes |
| 75 | |
| 76 | --- |
| 77 | |
| 78 | # 06_routing |
| 79 | |
| 80 | [Transition] The second pattern is Routing — classifying inputs to direct them to specialized handlers. |
| 81 | |
| 82 | Routing lets you build more specialized prompts without cross-contamination. Optimizing for one type of input won't hurt performance on others. |
| 83 | |
| 84 | Think of customer service: general questions, refund requests, and technical support each flow to different downstream processes with tailored prompts and tools. Or model selection — easy questions go to smaller, cost-efficient models like Haiku, while complex ones route to more capable models like Sonnet. |
| 85 | |
| 86 | Key points: ① Classify input → specialized followup ② Separation of concerns ③ Prevents cross-optimization interference |
| 87 | Duration: 1.5 minutes |
| 88 | |
| 89 | --- |
| 90 | |
| 91 | # 07_parallelization |
| 92 | |
| 93 | [Transition] The third pattern is Parallelization, which comes in two flavors. |
| 94 | |
| 95 | Sectioning breaks a task into independent subtasks that run simultaneously — like having one model process queries while another screens for inappropriate content. These tend to perform better than asking a single LLM call to do both. |
| 96 | |
| 97 | Voting runs the same task multiple times for diverse perspectives — like having several different prompts review code for vulnerabilities, flagging issues independently. |
| 98 | |
| 99 | [Pause] |
| 100 | |
| 101 | Both approaches boost confidence through multiple perspectives. |
| 102 | |
| 103 | Key points: ① Sectioning = independent parallel subtasks ② Voting = multiple perspectives on same task ③ Better than single-call for complex multi-concern tasks |
| 104 | Duration: 2 minutes |
| 105 | |
| 106 | --- |
| 107 | |
| 108 | # 08_orchestrator_workers |
| 109 | |
| 110 | [Transition] The Orchestrator-Workers pattern looks similar to parallelization, but has one crucial difference. |
| 111 | |
| 112 | Here, a central LLM dynamically decides what subtasks are needed, delegates them to worker LLMs, and synthesizes the results. The subtasks aren't predetermined — they emerge from the input. |
| 113 | |
| 114 | This is ideal for coding products that modify multiple files, where the orchestrator determines which files need changes based on the task description. Or search tasks that need to gather and analyze information from multiple sources. |
| 115 | |
| 116 | Key points: ① Central LLM dynamically breaks down tasks ② Key difference: subtasks not pre-defined ③ Ideal for unpredictable, complex workflows |
| 117 | Duration: 1.5 minutes |
| 118 | |
| 119 | --- |
| 120 | |
| 121 | # 09_evaluator_optimizer |
| 122 | |
| 123 | [Transition] The last workflow pattern is the Evaluator-Optimizer — essentially an iterative refinement loop. |
| 124 | |
| 125 | One LLM generates a response; another evaluates it and provides feedback. This cycle continues until the output meets quality standards. It's analogous to how a human writer iterates through drafts. |
| 126 | |
| 127 | There are two clear signs this pattern fits: first, human feedback demonstrably improves LLM responses; second, the LLM can provide that same kind of feedback. If both are true, you have a strong candidate. |
| 128 | |
| 129 | Key points: ① Generate-evaluate feedback loop ② Two fitness signals to look for ③ Analogous to human iterative writing |
| 130 | Duration: 1.5 minutes |
| 131 | |
| 132 | --- |
| 133 | |
| 134 | # 10_agents |
| 135 | |
| 136 | [Transition] Now we arrive at fully autonomous agents — the most flexible and powerful pattern. |
| 137 | |
| 138 | Agents emerge as LLMs mature across five key capabilities: understanding complex inputs, reasoning and planning, reliable tool use, error recovery, and knowing when to pause for human checkpoints. |
| 139 | |
| 140 | [Pause] |
| 141 | |
| 142 | Here's the surprising part — agent implementation is often straightforward. They're typically just LLMs using tools in a feedback loop. But this simplicity comes with trade-offs: higher costs and potential for compounding errors. Extensive testing in sandboxed environments, with appropriate guardrails, is essential. |
| 143 | |
| 144 | Key points: ① Five key LLM capabilities enable agents ② Implementation = LLMs using tools in a loop ③ Higher costs + compounding errors require guardrails |
| 145 | Duration: 2 minutes |
| 146 | |
| 147 | --- |
| 148 | |
| 149 | # 11_agents_in_practice |
| 150 | |
| 151 | [Transition] Let's look at two domains where agents have proven particularly valuable. |
| 152 | |
| 153 | Customer support is a natural fit — conversations require both dialogue and action. Tools pull customer data, handle refunds, and access knowledge bases. Some companies are so confident in their agents that they charge only for successful resolutions. |
| 154 | |
| 155 | Coding agents have shown remarkable potential. The key advantage: code is verifiable through automated tests, creating a natural feedback loop. Anthropic's own agent solves real GitHub issues from pull request descriptions alone. |
| 156 | |
| 157 | One fascinating insight from their experience: they spent more time optimizing their tools than the overall prompt — a testament to how important ACI design is. |
| 158 | |
| 159 | Key points: ① Customer support: natural conversation + actions ② Coding agents: verifiable + iterable ③ Tool optimization > prompt optimization |
| 160 | Duration: 2 minutes |
| 161 | |
| 162 | --- |
| 163 | |
| 164 | # 12_summary |
| 165 | |
| 166 | [Transition] Let's close with three principles to take away. |
| 167 | |
| 168 | First, simplicity. Build the right system for your needs, not the most sophisticated one you can imagine. |
| 169 | |
| 170 | Second, transparency. Let your users see the agent's reasoning — it builds trust and aids debugging. |
| 171 | |
| 172 | Third, invest in ACI design — your agent-computer interface. Think of it as HCI for machines. Good tool documentation and testing pays dividends. |
| 173 | |
| 174 | [Pause] |
| 175 | |
| 176 | The progression is clear: start simple, optimize with evaluation, and add agentic systems only when simpler solutions genuinely fall short. Thank you. |
| 177 | |
| 178 | Key points: ① Simplicity in design ② Transparency in planning ③ ACI through tool documentation and testing |
| 179 | Duration: 2 minutes |
| 180 |