Agentic Design Patterns
This is an original, engineering-focused learning path. It does not reproduce any book, repository chapter, or attachment. Instead, it organizes architecture selection, state, authorization, recovery, and evaluation into seven verifiable lessons and one offline project.
Content boundary
External articles, papers, and specifications are used only for fact checking and further reading. This project writes and organizes the lessons independently, links to sources, and does not copy third-party bodies or attachments into the site.
Scope alongside Agent Core
Agent Core teaches the state loop, context, planning, checkpoints, approval, and runtime control. This course asks how to combine those capabilities—and when not to add an Agent at all.
What you will learn
- Choose the lowest-complexity solution among ordinary code, deterministic workflows, single Agents, and multi-Agent systems.
- Design routing, parallelism, joins, reflection, and planning with explicit stopping conditions.
- Separate the responsibilities of tools, memory, business state, and protocol capabilities.
- Keep high-risk actions behind authorization and human approval.
- Verify recovery with checkpoints, idempotent receipts, error classification, and environmental outcomes.
- Evaluate systems with task success, cost, latency, safety-violation, and human-takeover rates.
Prerequisites
- Basic Python functions, JSON state, and HTTP requests are enough.
- Agent Core and Tool Calling and Function Calling are recommended.
- No Agent framework knowledge is required.
Learning sequence
| Order | Lesson | What you can do afterward |
|---|---|---|
| 1 | Pattern Selection and Minimal Architecture | Decide whether an Agent is needed and draw the smallest state boundary |
| 2 | Routing, Parallelism, and Joining | Compose common deterministic structures and handle partial failure and conflict |
| 3 | Reflection, Planning, and Stopping Conditions | Give dynamic iteration feedback, a budget, and an exit |
| 4 | Tools, Memory, and State Boundaries | Assign external actions, long-lived information, and business state correctly |
| 5 | Human Approval and Safety Boundaries | Keep irreversible actions behind explicit authorization |
| 6 | Failure Recovery, Evaluation, and Observability | Prove reliability with traces, receipts, and environmental outcomes |
| 7 | Project: Recoverable Task Workflow | Run and verify a key-free recoverable state machine |
Boundary between patterns and protocols
| Problem | Start with | The application still owns |
|---|---|---|
| In-process or owned-backend capability | Tool Calling | Principal, object-level authorization, approval, idempotency, and receipt |
| Standardized tool, resource, and context connection | MCP | Mapping protocol capability to business policy and validating results |
| Collaboration between independent Agent applications | A2A | Delegation scope, remote-task access, approval, and outcome acceptance |
Protocols provide interoperability; they do not grant business authority automatically. Multiple protocols can coexist, but they are worth adding only when a boundary genuinely crosses processes, products, or organizations.
Hands-on project
The course project lives in beginner-route/examples/:
resilient_workflow.py: a recoverable task workflow that uses only the Python standard library.test_resilient_workflow.py: verifies strict checkpoints, parallel joins without shared writes, approval binding, classified retry, idempotent receipts, and recovery after a post-commit crash.
Mastery standard
- I can explain why a task should use ordinary code, a workflow, one Agent, or multiple Agents.
- I can write maximum steps, completion criteria, failure criteria, and human-takeover conditions.
- I can distinguish a retryable fault, a business rejection, and an exception requiring human handling.
- I can design an offline replay set with quality, cost, latency, and safety thresholds.
- I can prove that approval binds the current action and repeated recovery does not repeat a side effect.
- I can inspect both the trace and final environmental state rather than trusting an Agent’s text claim alone.