Michael Ryan: Choosing Agent Patterns by Control Flow and Context

Design patterns give developers reusable ways to think about agent systems, but they are incomplete recipes: each must be adapted to its environment. Ryan introduces patterns for workflows, agent reasoning and context management, then examines the Pi harness.

Asked which patterns might remain stable, Ryan points to the persistent reasoning-and-acting loop and growing use of MCP to structure tools. The field is still new, he says, and its conventions continue to evolve.

The practical distinction between a workflow and an agent is where control flow sits. A workflow’s program specifies the orchestration, even when it includes branches and loops; an agent lets the model choose its next tool or action from what it observes.

A coded workflow tends to be more predictable and easier to evaluate, while an agent is more flexible but harder to debug and optimize. Classifying a support ticket, retrieving a policy and drafting a response can be a workflow; investigating and resolving the issue may call for an agent.

Ryan emphasizes that a workflow can still branch, route and loop. The distinction is not whether a system uses a language model, but whether program logic or the model decides the next step.

Ryan presents five workflow patterns: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. Real systems often combine them rather than choosing just one.

Prompt chaining decomposes a task into calls and can insert a gate between steps. Extracting calendar events from email and then choosing an emoji is simpler to reason about than one large prompt, although successive model calls usually increase latency.

Routing classifies an input and sends it to an appropriate model or downstream workflow. A simple math question could go to a smaller model while a frontier problem goes to a more capable one, trading quality against cost and time.

The routing example distinguishes a small model for easy questions from a larger one for difficult problems. The initial classifier is effectively a switch that chooses a downstream path.

Parallelization can split independent work or run the same task several times and vote. A safety classifier can run while a response is generated; alternatively, several answers to a math problem can be aggregated. A ten-item judging rubric could also be evaluated concurrently.

In the orchestrator-workers pattern, the system dynamically decides which subtasks and how many workers are needed. That differs from a fixed parallel branch. A complex software project might be split into interface, color picker and other components.

An evaluator-optimizer loop generates an answer, evaluates it and sends feedback for revision. Ryan says it helps when quality can be articulated and the evaluator can reliably judge it. If the target is a human preference that a model cannot assess well, human feedback may be more suitable.

STORM illustrates composition. Given a topic such as the 2024 Hualien earthquake, it researches sources and produces a cited, Wikipedia-style article. The overall work is structured enough to implement as a workflow, but more involved than a single model call.

STORM surveys related articles and identifies perspectives such as residents, politicians and seismologists. For each perspective it generates questions, searches for answers and builds a conversation; a separate branch directly drafts an outline, which the research helps refine.

The number of perspectives can be generated dynamically, making that portion resemble orchestrator-workers. The question-answer loop resembles evaluation and iteration; calls are chained within each branch, while the direct and research branches run in parallel.

The system can search the internet. Ryan says the research branch seeks broader, more diverse coverage than directly generating an outline. Its conversation length is bounded by a configured maximum, though the model can also indicate it is finished.

Ryan says the research conversations aim to expose perspectives that a direct outline could miss. Their length is a design parameter, and the system can impose a maximum.

When comparing multi-agent systems, Ryan recommends defining the metrics first, such as cost and accuracy. More agents can improve accuracy while costing more; a larger supervisor could review smaller workers, but he does not claim STORM uses that extra loop.

An evaluator could be a stronger model checking a smaller worker, but Ryan cautions that such additional loops add expense. The right comparison depends on the budget and the quality metric.

Ryan says the reported STORM results show greater similarity to human-written articles and higher model-graded scores for interest, organization, relevance and coverage than the shown baselines. Those results motivate collecting multiple perspectives rather than relying only on a direct draft.

Archon takes a different approach: search for a workflow architecture. Its inputs include a target benchmark, an inference budget, available models and components such as generators and verifiers. Candidate architectures are tested and iteratively optimized.

The building blocks have separate roles. A generator proposes an answer; a fuser combines candidates; a critic describes strengths and weaknesses; a ranker orders answers; a verifier reasons about and can correct one. Test generation and evaluation add explicit criteria.

An Archon verifier first reasons about a candidate and then can regenerate a corrected answer. Its test components can express criteria such as concision or adequate explanation.

The paper uses prompted, off-the-shelf models for those roles. Ryan cautions that ranking depends on context: a model may handle a few candidates well but struggle to rank a thousand. The architecture must also obtain completed answers from its generators.

One searched math pipeline samples multiple answers from different models, critiques and ranks them, fuses groups, verifies them and fuses again. Diversity matters: if all candidates are identical, the value of generating many alternatives collapses.

The pipeline’s final fuser is itself a selected model; its job is to combine already ranked candidates, not necessarily just outputs from the same model family.

Ryan is not recommending this particular pipeline as the default way to solve math. It illustrates how a search can optimize a workflow for a setting; the paper reports that, at sufficient token budgets, discovered architectures beat a then-frontier math baseline in its experiments.

An agent repeatedly calls a model, interacts with an environment, receives feedback and decides whether to stop. Designing the agent means choosing how it reasons, takes action and handles the resulting observations.

ReAct interleaves reasoning and actions. In the example, an agent searches for the Apple Remote, learns about Front Row software, refines an ambiguous search and finds that keyboard function keys also control it. Reasoning helps it choose the next search from the previous result.

Ryan notes that the original ReAct paper found simple prompting did not beat every larger-model baseline in its setting, while fine-tuning on reasoning-and-action trajectories improved performance. He observes that agentic post-training is now common.

Reflexion adds experience from earlier attempts. An actor produces a trajectory, an evaluator assesses it, and a reflection is stored for future attempts. In a parenthesis-checking example, test failures expose that counting open and close characters alone does not establish correct ordering.

For the parenthesis example, feedback records why the first solution failed so that a later attempt can check both balance and order. Ryan uses this to explain how reflection becomes reusable experience.

Ryan describes results where adding reflection to prior trajectories improved performance over trajectories alone. But another paper found that prompting capable models to self-correct without external feedback sometimes worsened math and common-sense results. He recommends benchmarking the extra step rather than assuming it helps.

Ryan adds that some of the negative self-correction findings predate newer reasoning models. The useful design question is whether an explicit reflection step improves the particular system being measured.

In response to questions, Ryan says early Reflexion systems used prompts to request reflection. Modern reasoning models may already perform some self-correction, so teams should compare variants against their own evaluations and data.

The CRITIC paper gives a verifier tools to interact with the environment rather than relying on its unaided judgment. Ryan says its reported improvement illustrates why external feedback can be more useful than asking a model to critique itself.

CodeAct expresses actions as executable code. Instead of issuing a separate JSON or text tool call for every country in a phone-price comparison, the model can write a program that loops through countries, calls pricing and conversion functions and selects the minimum.

In the phone-price example, the available functions include exchange rates, tax, product prices and shipping estimates. A program can combine those operations before returning a result to the agent.

The code can perform multiple operations in one turn and the agent can write more code if the result is insufficient. Ryan reports that the paper generally found higher success and fewer turns than text or JSON actions across its tested models.

Plan-then-execute separates deciding the steps from running them. ReWOO first generates a plan with references to earlier outputs, then a worker executes the dependent calls and a final step produces the answer. The model need not choose the next action after every observation.

The ReWOO plan uses placeholders for evidence not yet retrieved. Once the worker obtains a result, it substitutes that result into the next dependent step.

LLMCompiler similarly creates a dependency graph so independent calls can run in parallel, with replanning if verification fails. Ryan says code generation can often express the same idea more flexibly, but planning remains useful for orchestration.

Context engineering determines what the model sees on each call. Ryan says long histories, documents, instructions and tool outputs must be selected carefully: the goals are to keep the context focused while preserving requirements, constraints and progress.

A focused context should include what the current task needs, while continuity means retaining goals, requirements, constraints and progress through changes. Moving earlier text also affects cache reuse.

OpenHands illustrates a persistent event log. User messages, agent actions and tool observations are recorded as events; each model input is reconstructed from that record. The rendered context can change without deleting the underlying history, which also enables monitoring hooks.

For each new model call, the event stream is filtered and converted into messages. The record remains intact even when the rendered view omits or compresses older material.

Memory offloading stores facts outside the immediate context and retrieves them when needed. Ryan uses a personal-assistant example: a birthday and a partner’s name can be saved and recalled later without keeping every past conversation in the model window.

Compaction summarizes older reasoning, actions and observations when a context gets long. A simple implementation summarizes at a fixed threshold; a more elaborate agentic process could retrieve information while compressing, but it adds latency.

Observation masking is an alternative: shorten or remove old tool outputs instead of asking a model to summarize everything. Ryan notes that observations can dominate the token budget, especially when tools return long documents or program output. The full event log can still retain them.

Changing past context can invalidate the model’s key-value cache, so a system might mask observations every several turns rather than constantly. Ryan says the cited study found broadly similar task performance to model summarization, with simpler programmatic masking and no summary-generation wait.

Context isolation delegates a search-heavy task to a subagent with its own window and returns a concise result to the parent. Progressive disclosure is another approach: a skill’s name can be available upfront while its detailed instructions enter context only when needed.

A subagent may fill its own context with documents and searches while returning only a short summary. That prevents the coordinating agent from carrying every intermediate observation.

Ryan distinguishes skills from tools: a skill supplies instructions and context, while a tool takes an action in the environment. Memory, compaction, event logs, masking and isolation can be combined; the system should preserve continuity while avoiding irrelevant context.

Pi is a minimal, extensible agent harness. Ryan says its default enabled tools are read, bash, edit and write; features such as subagents, permission checks, a plan mode and background bash are absent from the base design.

Pi uses a ReAct-style loop, and a bash call can itself run a script, resembling code as action. Its context is stored as a tree that can branch from an earlier point; it also supports skills and compaction, keeping recent turns verbatim while summarizing older ones.

For compaction, Pi summarizes entries before a cutoff and retains later entries verbatim. The next model call receives the system prompt, summary and recent conversation.

Ryan says Pi runs with the permissions of its process and does not prompt before dangerous commands. He sees this as a real safety risk depending on the application. He argues that stronger models can work with simpler harnesses, while weaker ones may need more structure—a trade-off to test.