Agentic Systems and Design Patterns: Topology choices and two core agent patterns explained

# Agentic systems in practice

Agentic systems go beyond single-turn chatbots. They plan, act, observe results, and iterate until a goal is achieved. Two decisions shape every production agentic system: the overall topology (how agents are organized) and the internal design patterns (how an agent reasons, calls tools, and handles errors).

Topology: single-agent vs multi-agent

A single agent owns the entire loop. It accepts the user query, keeps short-term context and long-term memory, picks tools to call, observes results, and returns the final output. This approach is straightforward to implement, easier to debug, and tends to have lower latency for focused tasks. Teams commonly start here.

Limitations appear when tasks are long-horizon or require markedly different skills. Context windows fill up. Specialized knowledge becomes hard to isolate. A single failure mode can take down the whole flow.

A multi-agent architecture adds a meta-agent or orchestrator that decomposes goals and delegates work to specialists (for example, retrieval, search, coding, or critic agents). Each specialist may have its own tools and memory. Results are aggregated by an LLM synthesizer. Shared or private memory and dedicated servers can support collaboration.

Benefits: specialization, parallelism, and higher reliability through division of labor.

Core design patterns (what agents do internally)

Topology decides organization. Design patterns decide an agent's internal thinking and action style. The article identifies six dominant patterns used in production. Two are described in the supplied text and are summarized below.

ReACT (Reason + Act)

ReACT interleaves three explicit steps in a tight loop:

• Thought: verbalized reasoning about current state, knowns, unknowns, and which single action will close the largest gap.
• Action: a concrete tool call with specific arguments.
• Observation: the tool result is injected back into context so the next thought is grounded in reality.

This loop repeats until the agent judges the task complete. ReACT bridges pure chain-of-thought reasoning (which is blind to external tools) and blind tool calling (which is planless). It is the default architecture in many tool-using systems and coding assistants.

Engineering concerns to manage when using ReACT:

• Prevent infinite loops by enforcing a hard iteration limit.
• Control context growth because each thought and observation consumes tokens and can bloat prompts.

CodeAct

CodeAct uses executable code as the agent's primary action. Instead of issuing a single discrete tool call, the agent generates code (commonly Python) that can:

• Contain control flow and branching.
• Invoke multiple tools or APIs within one action.
• Perform data transformations and filtering.
• Implement error handling and retries.

This pattern appears in advanced coding and automation products. It enables complex, multi-step tasks to be expressed and executed more reliably than a sequence of single tool calls.

Practical guidance

• Start simple with a single-agent ReACT implementation for focused tasks. It's easier to iterate and debug.
• Use iteration limits and token-management strategies up front to avoid runaway loops and costs.
• Move to multi-agent architectures when the problem requires specialization or long-horizon planning that exceeds a single agent's context window.

The original piece maps these topology choices and patterns to real products and production trade-offs. Understanding both layers—how agents are organized and how they reason—helps teams build more reliable, scalable agentic systems.