Agentic design patterns are recurring shapes for building systems where a model decides what to do next rather than following a fixed script. Most published catalogues list around twenty. In production, a handful do the work, and each one implies infrastructure that the pattern diagram never shows: a runtime, persistence, permissions, and somewhere to look when it goes wrong.
The patterns themselves are not complicated, and the literature explains them well. What gets skipped is the operational half, so this covers the patterns briefly and then the parts that decide whether the thing survives a week of real use.
Table of contents
- Tool use, the pattern everything else rests on
- Reflection, planning, and knowing which you need
- Multi-agent, and why it usually is not the answer
- Memory, and the distinction that matters
- What the patterns do not tell you
- How this fits the rest of the stack
- FAQ
Tool use, the pattern everything else rests on
The model is given a set of callable functions with described parameters, decides which to call, receives the result, and continues. Everything else in the agentic vocabulary is a variation on this loop.
The design work is in the tool boundary rather than the prompt. Tools that are too granular force the model through long chains where each step can go wrong. Tools that are too broad hide the decision inside your code, which is often what you actually want.
- Describe each tool for a reader who has no other context. The description is the interface.
- Make failures informative. A tool returning a clear reason lets the model correct; one returning a stack trace does not.
- Validate arguments before executing. The model will eventually pass something impossible, and that must be a rejection rather than a crash.
- Make anything with side effects idempotent, or take a key. Retries happen, and a duplicated payment is a worse outcome than a failed one.
The unglamorous observation: most agent reliability problems are tool design problems. A model that keeps picking the wrong tool is usually being shown two tools whose descriptions do not clearly distinguish them.
Reflection, planning, and knowing which you need
Reflection means the output is critiqued, by the same model or another, and revised. It measurably improves quality on tasks where errors are recognisable after the fact, such as code that fails a test or a document that omits a required section.
It does nothing for tasks where the model cannot tell good from bad, and it doubles or triples cost and latency on every request. So apply it selectively, ideally gated on a real signal: run the tests, and reflect only if they fail.
Planning means decomposing a goal into steps before executing any of them. Useful when steps have dependencies and a wrong early choice is expensive to unwind.
The trap is planning things that do not need it. A two-step task with a generated plan is slower, costs more, and introduces a new failure mode where the plan itself is wrong and the executor follows it faithfully off a cliff. Fixed workflows beat generated plans whenever the sequence is actually known.
The honest heuristic: if you can write the steps down, write them down. Reserve planning for genuinely open-ended tasks, which are rarer in production systems than in demonstrations.
Multi-agent, and why it usually is not the answer
The pattern that gets the most attention and delivers the least. Several specialised agents, each with a role, coordinating through a supervisor or by passing messages.
It is genuinely appropriate in narrow circumstances: when subtasks are truly independent and can run in parallel, when different steps need different tool permissions, or when one component must not see data another handles.
Everywhere else it multiplies the failure modes. Every handoff is a place for context to be lost or garbled, cost scales with the number of participants, latency is the sum of the chain, and debugging means reconstructing a conversation across several logs to find where the misunderstanding started.
The pattern that actually works most often is boring: one agent, a well-chosen set of tools, and ordinary code orchestrating the parts that do not need a model. Reach for multiple agents when you can name the specific thing a single one cannot do.
The related pattern worth more attention is human in the loop. An agent that pauses for approval before an irreversible action is the difference between a useful assistant and an incident. It also implies durable state, since the run must survive the wait.
Memory, and the distinction that matters
Memory in agent systems means three different things that get conflated.
Working memory is the current conversation, held in the context window, gone when the run ends. Retrieval is fetching relevant documents at query time, which is not memory at all but is usually filed under it. Persistent memory is state deliberately written and read across sessions, so the agent recalls a preference from last week.
The first is free and bounded. The second is a search problem, and its quality depends on chunking and retrieval far more than on the model. The third is a database with an access pattern, and it needs the same care as any other database: a schema, a way to correct wrong entries, and a retention policy.
The mistake is treating persistent memory as a feature you switch on. An agent that remembers everything accumulates contradictions and stale facts, and confidently acts on them. Deciding what is worth remembering, and what expires, is design work rather than configuration.
What the patterns do not tell you
Every diagram in every catalogue shows boxes and arrows. None of them shows the parts that decide whether the system stays up.
- A runtime. The agent needs a process that stays running, reachable at a URL other systems can call, that restarts when it dies.
- Persistence. Runs that pause for approval, or resume after a failure, need durable state. A conversation held in process memory does not survive a deploy.
- Secrets. API keys for every tool, held somewhere that is not the repository and not baked into an image.
- A permission boundary. Which endpoints, which domains, which credentials, which data. An agent with a shell tool and no boundary is a remote code execution vulnerability with good intentions.
- Observability. When an agent does something strange, you need the full trace: prompts, tool calls, arguments, results. Without it, debugging is guesswork.
- Cost controls. A loop that retries without a ceiling is a bill. Cap iterations, cap spend, and alert on both.
That list is the same list any backend service needs, plus tracing and spend limits. Which is the real point: an agent is a backend service whose control flow happens to be decided by a model, and it needs the same operational foundation as one.
Treating it as something categorically new is how teams end up with a prototype that impresses in a demo and cannot be deployed, because nobody built the half that has nothing to do with the model.
How this fits the rest of the stack
The half that no pattern catalogue covers is the runtime: somewhere the agent can run, a database it can write state to, environment variables holding its tool credentials, and logs showing what it actually did. Those are ordinary infrastructure line items, and costing them early is what makes the difference between a prototype and something you can operate. The RunxBuild hosting calculator shows the service, managed database, and storage side by side.
Useful related references:
- MCP Server Design for a Digital Goods Storefront
- Cloud Management Platforms: The Tools and Patterns
- Cloud Data Integration: Tools, Patterns, and When to Use Each
- Services on RunxBuild
FAQ
What are agentic design patterns?
Recurring architectural shapes for systems where a model decides what to do next: tool use, reflection, planning, multi-agent coordination, memory, and human-in-the-loop approval. Each describes control flow, not the infrastructure it requires.
Do I need multiple agents?
Usually not. Multiple agents help when subtasks are genuinely independent, need different permissions, or must not see each other’s data. Otherwise they multiply failure modes, cost, and latency. One agent with good tools plus ordinary orchestration code is the stronger default.
When is reflection worth the cost?
When errors are detectable after the fact, such as code that fails tests. Gate it on a real signal rather than running it on every request, since it multiplies cost and latency and does nothing when the model cannot distinguish good output from bad.
What infrastructure does an AI agent need?
The same as any backend service, plus two additions: a runtime, durable state, secret storage, and a permission boundary, then full tracing of prompts and tool calls, and hard limits on iterations and spend.
What is the most common cause of unreliable agents?
Tool design. Descriptions that do not clearly distinguish one tool from another, failures that return stack traces instead of reasons, and side-effecting tools that are not idempotent under retry.