{"slug": "design-patterns-of-agentic-ai", "title": "Design Patterns of Agentic AI", "summary": "A developer's blog post identifies seven recurring design patterns in agentic AI, including ReAct, planner-executor, reflection, tool use, and orchestrator-worker, arguing that these patterns underlie most autonomous agent systems. The post emphasizes the importance of naming these patterns to understand and build agentic AI effectively.", "body_md": "Here's a confession: the first \"agent\" I built was basically a while loop with a prompt stapled to it. It called a function, read the result, and called another function. I thought I'd invented something. Turns out I'd just rediscovered ReAct, badly, three years after everyone else.\n\nThat's the funny thing about agentic AI right now. Underneath all the hype and the funding rounds and the \"autonomous agent\" landing pages, there are maybe seven recurring patterns doing all the real work. Once you can name them, you start seeing them everywhere: in LangChain's docs, in Claude Code's architecture, in that one open-source repo you starred and never opened again. Let's name them properly.\n\nThis is the pattern everything else is built on top of. The model reasons about what it knows, picks a tool, fires it off, reads the result, and does it again. It's less \"master plan\" and more \"detective walking around a crime scene picking up clues one at a time.\"\n\n```\nThought: I need the current weather to answer this.\nAction: call_weather_api(city=\"Berlin\")\nObservation: 18°C, cloudy\nThought: Now I can answer.\n```\n\nThe elegant part is that the model never has to commit to a full plan up front. It gets to change its mind after every observation, which is exactly what you want when the world keeps surprising you mid-task.\n\n**Reach for it when** the next step genuinely depends on what you just learned, not on what you guessed at the start.\n\nInstead of one model doing the thinking and the doing at once, you split the job. A planner breaks the goal into steps. An executor actually runs them.\n\nIt sounds like bureaucracy, and honestly, it kind of is, in the good way. Bureaucracy exists so you can inspect decisions before they turn into actions. With this pattern, you can look at the plan, catch the dumb idea before it becomes a dumb API call, and swap out executors without touching the planning logic at all.\n\n**Reach for it when** \"refactor this module\" needs to become locate, analyze, edit, verify, and you want to see that breakdown before anything runs.\n\nGenerate an answer. Have a second pass, sometimes the same model wearing a different hat, critique it against the original goal. Revise. Repeat until the critique passes or you run out of patience (or budget).\n\n``` php\nDraft -> Critique -> Revise -> (loop until it's good or the budget runs dry)\n```\n\nThis genuinely makes outputs better, especially for code and writing. The catch is that an unbounded reflection loop is just an expensive way to spin your wheels, so you need a hard stopping condition, not vibes.\n\n**Reach for it when** quality beats speed, and you have some cheap way to check the work: tests passing, a rubric, a second opinion.\n\nThis isn't really a pattern so much as the foundation everything else sits on. Give the model a menu of actions with clear names and clear inputs, and let it decide what to order.\n\nThe part people get wrong isn't the model side, it's the API design side. One giant `do_everything`\n\ntool and the model can't compose anything interesting. Fifty tiny tools and it burns half its turns just chaining trivial calls together. Good tool design is just good API design: single responsibility, obvious naming, predictable shapes coming back.\n\nOne coordinator breaks a big job into independent chunks, hands them off to specialized workers (separate agents, or the same agent wearing different hats), and stitches the results back together.\n\n```\nOrchestrator\n |- Worker A: research topic X\n |- Worker B: research topic Y\n `- Aggregator: synthesize A + B into a final answer\n```\n\nThis is the engine behind most \"deep research\" style products you've seen demoed. The win is parallelism: workers run at the same time instead of one after another. The cost is coordination complexity, which is really just latency traded for headaches.\n\n**Reach for it when** the subtasks are genuinely independent and the final synthesis step is well defined, not an afterthought.\n\nShort-term memory is a scratchpad for the current task. Long-term memory survives across sessions, pulled from a vector store, a file, a database, whatever you've got.\n\nThe hard part was never storage. It's retrieval discipline: knowing what's worth keeping, what's gone stale, and how to stop old context from crowding out what actually matters right now. A memory system that hoards everything is just a slower, pricier context window wearing a trench coat.\n\n**Reach for it when** the agent needs continuity: a coding assistant that remembers your team's conventions, a support bot that remembers what the customer already told it last week.\n\nBefore anything irreversible happens, sending an email, deploying code, spending real money, the agent stops and waits for a nod from an actual person.\n\nThis isn't the system admitting it can't be trusted. It's a deliberate line drawn in the sand: read freely, reason freely, but earn permission before you touch anything external. Nearly every serious production agent framework draws that line in roughly the same place.\n\nNobody ships just one of these. Real systems stack them.\n\nA coding agent might run ReAct for its inner tool loop, add Reflection to sanity-check a diff before proposing it, then stop at a human-in-the-loop checkpoint before anything actually gets committed. A research agent might plan with Planner and Executor, fan out the legwork with Orchestrator and Workers, and lean on memory so it isn't re-fetching the same five sources every twenty minutes.\n\nNone of this is exotic. It's separation of concerns, single responsibility, and checkpoints before side effects, the same principles you'd apply to any distributed system. The only twist is that one of your \"services\" occasionally hallucinates. Design for that, and the rest is just software architecture wearing a new coat.\n\n*Which of these have you actually shipped, and which one bit you when you tried?*", "url": "https://wpnews.pro/news/design-patterns-of-agentic-ai", "canonical_source": "https://dev.to/zeeshanhshaheen/design-patterns-of-agentic-ai-334c", "published_at": "2026-08-29 17:01:32+00:00", "updated_at": "2026-08-29 17:18:43.110507+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-research", "developer-tools"], "entities": ["LangChain", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/design-patterns-of-agentic-ai", "markdown": "https://wpnews.pro/news/design-patterns-of-agentic-ai.md", "text": "https://wpnews.pro/news/design-patterns-of-agentic-ai.txt", "jsonld": "https://wpnews.pro/news/design-patterns-of-agentic-ai.jsonld"}}