Agentic Systems and Design Patterns

Over the last two years, the industry has moved from simple chatbots and retrieval-augmented generation pipelines to something fundamentally more powerful: agentic systems. These systems do not just answer questions; they plan, act, observe the consequences of their actions, and keep iterating until a goal is achieved. Whether it is Cursor writing and debugging code, Perplexity performing multi-step research, Manus executing complex tasks through code, or Gemini Deep Research producing long-form investigative reports, the underlying architecture is agentic.

At the heart of every agentic system lie 2 critical design decisions. 

1. The first is the overall topology: should the system be a single agent that owns the entire problem, or a multi-agent system where specialized agents collaborate under an orchestrator?
2.  The second is the choice of internal design patterns that govern how the agent reasons, selects tools, handles errors, and improves its own output. 

Get these decisions right, and the system becomes reliable, scalable, and genuinely useful. Get them wrong, and you end up with brittle loops, runaway costs, or agents that hallucinate tool calls.

This article provides a clear, production-oriented map of both layers. Let us examine single-agent versus multi-agent architectures, then walk through the six design patterns that dominate real-world systems today. Each pattern is illustrated with a diagram and explained with concrete examples drawn from products already in production.

1. Agentic Systems Topology

Every agentic system falls into one of two broad categories.

Single Agent System

In a single-agent architecture, one agent owns the complete loop. It receives the user query, maintains both short-term context and long-term memory, decides which tools or MCP servers to call, observes the results, and eventually produces the final output. This design is simple to implement, easy to debug, and has lower latency for focused tasks. It is the natural starting point for most teams.

The main limitations appear when the problem becomes long-horizon or requires genuinely different skills. Context windows fill up, specialized knowledge is hard to isolate, and a single failure mode can bring the entire system down.

Multi-Agent System

A multi-agent system introduces a meta-agent (or orchestrator) that decomposes the high-level goal and delegates work to specialized agents, for example, a data-retrieval agent, a search agent, a coding agent, or a critic. Each specialist may have its own tools and memory. Results flow back to an aggregator LLM that synthesizes the final answer. Shared or private memory and MCP servers support the collaboration.

The advantages are specialization, parallelism, and higher reliability through division of labor. The costs are coordination overhead, higher token consumption, and more complex failure modes (handoff errors, inconsistent state, cascading retries). Most production systems begin as single-agent and only move to multi-agent when the benefits clearly outweigh the complexity.

2. Core Design Patterns

Topology decides how agents are organized. Design patterns decide how each agent thinks and acts. The six patterns below appear, often in combination, in virtually every serious agentic product shipping today.

ReACT Agent (Reason + Act)

The foundational pattern used by the majority of tool-using agents.

The agent interleaves three explicit steps in a tight loop:

1. Thought: verbalized reasoning about the current state, what is known, what is still missing, and which single action would close the biggest gap.
2. Action: a concrete tool call with specific arguments.
3. Observation: the tool result is injected back into the context so the next thought is grounded in reality.

This loop continues until the agent decides the task is complete. Pure chain-of-thought reasoning is blind to the external world; pure tool calling is planless and reactive. ReAct fuses the two and remains the default architecture in LangGraph, LlamaIndex, the OpenAI Agents SDK, Claude’s tool-use agents, and most coding assistants.

The main engineering concerns are infinite loops (always set a hard iteration limit) and context growth (every thought and observation consumes tokens).

CodeAct Agent

Used by Manus, OpenHands, and an increasing number of advanced coding and automation systems.

Instead of emitting one discrete tool call per turn, the agent writes executable code (usually Python) as its primary action space. That code can contain control flow, multiple tool invocations, data transformations, filtering, and error handling — all in a single execution step. The sandbox runs the code and returns stdout, stderr, or artifacts. If something fails, the agent can observe the error and revise the code, achieving a form of self-debugging.

CodeAct collapses what would have been many ReAct steps into one more expressive action. It also leverages the full power of existing software libraries. The trade-off is the need for a secure, well-instrumented execution environment.

Self-Reflection

Critical for reliability and high-stakes outputs.

After generating a first draft (a plan, a piece of code, or an answer), the agent or a dedicated critic LLM  evaluates the output against explicit criteria: correctness, completeness, safety, style, and grounding. If the critique fails, the agent revises using the feedback. The loop continues until the critique passes. Lessons can optionally be written into long-term memory, so the same mistake is less likely in the future.

Self-reflection is the agentic analog of System-2 deliberative thinking. Andrew Ng has repeatedly listed it as one of the four fundamental building blocks of agentic systems (alongside planning, tool use, and multi-agent collaboration). It is especially valuable when the cost of a wrong answer is high.

Tool Use and Agentic RAG

Tool use is the substrate of nearly every modern agent. Cursor is a canonical example: the agent is given a rich set of tools (file system, terminal, search, browser, cloud APIs, MCP servers) and decides at each step which tools to call and with what arguments. The quality of the tool schemas and the system prompt that teaches the model when and how to use them is often as important as the underlying model itself.

Agentic RAG elevates classic retrieval-augmented generation. In a traditional RAG pipeline, the retrieval step is fixed: embed the query, fetch top-k chunks, generate. In agentic RAG, retrieval itself becomes a tool the agent can invoke repeatedly. The agent can rewrite queries, decide which sources to consult (vector database, web search, structured APIs), evaluate intermediate results, and continue retrieving until it judges the context sufficient. Only then does it generate the final grounded answer, usually with citations. Perplexity’s more advanced research modes and modern enterprise agentic RAG frameworks follow this pattern.

Multi-Agent Workflow

A planner or meta-agent receives the high-level goal and decomposes it into sub-tasks. Specialized agents execute those sub-tasks, often in parallel, reading from and writing to shared memory and using tools as needed. An aggregator or synthesizer LLM collects the partial results and produces the final coherent output. Optional critique or reflection loops can be added on top.

This pattern shines on long-horizon, multi-skill problems such as deep research, complex software engineering workflows, or multi-document analysis. Gemini Deep Research is a prominent production example.

3. Choosing and Combining Patterns

In practice, these patterns are almost never used in isolation. Cursor combines heavy tool use with a ReAct-style loop and test-driven reflection. Manus leans on CodeAct. Deep research systems blend multi-agent orchestration, agentic RAG, and reflection. The patterns are composable building blocks rather than mutually exclusive choices.

4. Engineering Principles That Matter Most

Regardless of which patterns you choose, several engineering practices determine whether the system is production-ready:

1. Explicit termination conditions and hard iteration limits prevent runaway loops and cost explosions.
2. High-quality tool schemas and descriptions are often more important than the choice of model. Clear parameter types, realistic examples, and guidance on when to use each tool dramatically improve reliability.
3. Careful memory management decides what stays in the context window versus what is externalized to a vector store or key-value memory.
4. Full observability: Every thought, action, and observation must be logged and inspectable. Without traces, debugging agentic systems is nearly impossible.
5. Cost, safety, and permission guardrails must be enforced at the harness level, not left to the model.
6. End-to-end evaluation that measures real task success (not just next-token accuracy) is essential for continuous improvement.

Closing Thoughts

Agentic systems represent a genuine architectural shift. We are moving from models that merely generate text to systems that can plan, act in the world, observe the consequences, and improve their own behavior. The difference between a fragile demo and a reliable product usually comes down to the quality of the topology and the design patterns chosen.

We have discussed in this article, the following:

Single-agent versus multi-agent structure, ReAct as the workhorse reasoning-and-acting loop, CodeAct for expressive actions, self-reflection for reliability, tool use as the universal substrate, agentic RAG for dynamic knowledge retrieval, and multi-agent workflows for complex collaboration give practitioners a practical decision framework.

Start simple. Begin with a single agent using the ReAct pattern and solid tools. Add self-reflection when accuracy matters. Introduce CodeAct when the logic becomes complex. Move to multi-agent architectures only when specialization and parallelism clearly pay off. Instrument everything. Measure real task success. Iterate.

The systems that follow these principles are already delivering meaningful value in coding assistants, research tools, enterprise automation, and personal AI agents. The patterns themselves will continue to evolve, but the underlying ideas — interleaving reasoning with action, grounding decisions in observation, and composing specialized capabilities — are likely to remain foundational for years to come.