Advanced Architectural Patterns for Agentic AI Systems

An agent wraps a language model with four parts: the model as reasoning engine (ideally with native tool calling), tools such as APIs and sandboxed code interpreters, planning and control flow (from a fixed graph to an open-ended loop), and memory (short-term working context plus long-term stores). Every pattern below is a different way of arranging these parts.

An agent's context grows with every observation, error and thought, which raises latency and cost and can bury key facts in the middle of a long prompt. The article names five techniques: state projection (give each step only what it needs), pruning and summarizing with a cheaper model, structured scratchpads that can be parsed and dropped, semantic retrieval of past actions, and prompt caching so static instructions are not paid for on every loop.

Anything that is not a read operation, such as dropping a table, authorizing a payment or emailing a client, should be able to pause the agent for a human decision. In a state-graph framework a chosen tool call interrupts the run, the state is saved, a reviewer approves or edits, and the orchestrator resumes from the saved state.

The model alternates between reasoning and acting: it states a thought, calls a tool, reads the observation and repeats until it can answer. It adapts to unpredictable tasks and can recover from tool errors, but a query may need around ten sequential model calls, and long runs can drift or loop on a broken tool. Truncate or summarize large tool outputs and cap iterations. Best for open-ended research, data analysis and debugging; poor for low-latency, user-facing chat.

A chain of specialized agents works like an assembly line, for example researcher, then analyst, then writer, each passing a structured result to the next. Each agent has a narrow prompt, limited tools and a small context, which improves reliability, lowers token use and makes failures easy to locate and checkpoint. The downside is rigidity: sending work back to an earlier stage complicates the graph. Best for well-defined pipelines such as content generation, ETL and staged reviews.

A fast, cheap classifier reads the request, picks one or more downstream pipelines and extracts entities as structured output, after which ordinary code takes over. It gives low latency, bounded and testable behaviour and low cost, but a wrong routing decision sends everything to the wrong place, and mixed requests can produce stitched-together answers. The article also points to small calibrated decision models for this step. Best for multi-tenant chatbots and contact-center automation with well-known request categories.

A supervisor plans the work, delegates sub-tasks to specialist workers (often in parallel), reviews what comes back and either issues new instructions or synthesizes the answer. The supervisor holds global context such as a task ledger, while workers see only their own sub-task and return a result, so tool logs do not pollute the plan. It parallelizes well and scales by adding workers, but orchestration is complex and everything depends on the supervisor's plan. Best for composite problems such as research, financial analysis and large coding tasks.

A generator produces a draft and a critic, either a second model or deterministic checks such as tests or a SQL dry run, lists the flaws that the generator then fixes, until it passes or a retry limit is reached. Keep context small by passing only the task, latest draft and latest critique, not every failed attempt. It raises quality and blocks flawed output, but costs time and tokens, and a critic can invent a flaw and degrade good work. Use fast deterministic checks at intermediate steps and reserve model critics for the final, high-stakes output.

Specialized agents share an environment and collaborate without a central manager, stepping in when a message matches their abilities, handing off tasks and negotiating. To avoid token bloat, agents subscribe to topics and exchange structured messages instead of reading one giant chat. A swarm can route around obstacles and is easy to extend, but its paths are non-deterministic, hard to audit and prone to endless back-and-forth. Best for open-ended research and simulation; prefer sequential or supervisor patterns for strict enterprise automation.

A wrong final answer can come from the wrong tool, bad arguments, ignored output or weak synthesis, so judge the whole path: tool selection accuracy (often with a model as judge), schema compliance, and iteration counts, where a sudden rise suggests looping. Log every thought, action and observation to an observability platform.

Stop infinite loops with iteration caps and an alert when identical tool calls repeat. Prevent brittle parsing with strict structured outputs, wrap tool calls in error handling and return failures to the agent as observations. Control cost by routing routine work to cheap models and saving frontier models for planning, evaluation and final synthesis.

Neighbouring pages on this site.