Fixed Workflow, Single Agent, or Multi-Agent System: How to Choose a Pattern for a Task

Before choosing an architecture, describe the task

The first decision is not how many agents to build, but what work you want to automate and how you will recognize a correct result. If the goal, inputs, and sequence of steps can be described precisely, a conventional program may be enough. If some decisions depend on the content of each case, it may be useful to delegate part of the selection to a model. If distinct responsibilities need to work with some degree of independence, a composition of agents might be worth considering. These are design possibilities, not rungs on a ladder where every option is necessarily more advanced or better.

To compare alternatives, write a short task brief. Include the goal, expected inputs, known steps, variations that occur in practice, observable output, and consequences of an error. Also note what actions the system may take and which require authorization or human review. This description helps avoid confusing a task with many steps for a task that needs autonomy: a long but stable sequence can be perfectly programmable.

The available sources offer guidance on choosing between a single agent and multiple agents, present design patterns, and compare agents with workflows. The supplied excerpts do not provide comparable measurements of performance, cost, or error rates for these three approaches. The matrix and examples in this guide are therefore a practical analysis framework, not a claim that one pattern generally produces better results.

Pattern 1: Deterministic workflow

In a deterministic workflow, the program specifies the sequence of operations and the conditions that move each stage forward, repeat it, or stop it. The workflow may include calls to a model—for example, to classify text or extract fields—without making the overall system an autonomous agent. The useful distinction is who decides the next step: in a workflow, that decision is specified mainly in code or explicit configuration.

This pattern is often a good fit when tasks have known inputs, relatively stable rules, few meaningful branches, and an output that can be validated with concrete checks. An invoice intake process, for example, might extract data, validate required fields, reconcile amounts, and send cases that fail a rule for review. The sequence can include exceptions, but the team represents them with explicit conditions instead of asking a model to invent a work route for each run.

As a design criterion, one advantage of this approach is that the team can inspect the intended order and tie each decision to a rule or stage. That does not guarantee that the components will work correctly: an extraction can be wrong, and a rule can be poorly defined. The limitation is that an unanticipated variation requires changing the rules, adding branches, or sending the case to a person. If exceptions multiply, maintaining the workflow may become difficult. That does not automatically prove an agent is needed, but it is a reason to review the design.

Tools in a workflow can be limited to the calls specified by the code. Permissions and accessible data depend on how the system is implemented and configured; they do not follow from the pattern’s name. Persistent memory is not an inherent property of a workflow either. The system can retain the state needed to complete a run, but it is useful to distinguish that temporary state from memory reused across tasks.

Pattern 2: Single agent with tools

In a single-agent pattern, the model takes part in choosing the next steps based on the goal, available context, and tools offered to it. The program still defines the framework: the goal communicated to the agent, the available tools, the applicable limits, and when to stop or ask for help. Autonomy does not mean unlimited permission; dynamic action selection must take place within conditions set by the system.

This pattern may be a candidate when cases vary in meaningful ways and a rigid sequence feels unnatural, but the required capabilities fit within a bounded set of tools. Consider internal support requests: a person asks about an issue that may require consulting documentation, checking a service’s status, and drafting a response. Depending on the case, the agent could decide which of those queries it needs. If an action has significant consequences, the system can be limited to preparing a recommendation for a person to approve.

Flexibility brings a different evaluation burden. It is not enough to check a single route; you need to observe which actions the agent chose, what information it used, when it stopped, and whether it requested review in ambiguous cases. A correct final answer by chance does not show that the intermediate sequence was appropriate. It is useful to record relevant decisions proportionately and review both resolved cases and cases the system rejected or escalated.

Tools are central to the operational boundary: they describe available actions, but their effective scope depends on their implementation, authentication, and controls. Do not assume that a natural-language instruction can replace technical access controls. Memory may be absent, limited to the current interaction, or persistent, depending on the product and design. For an initial evaluation, explicitly state what context is retained and test whether it is necessary rather than assuming that more memory improves the result.

Pattern 3: Multi-agent system

A multi-agent system brings together several components with distinct functions that interact to complete a task. Coordination can take different forms: one component may assign work, components may exchange results, or the system may organize a sequence of specialized functions. The label alone does not explain who decides the workflow, what information is shared, or how disagreements are resolved. Those properties need to be specified before the design can be evaluated.

The question that justifies multiple agents is not whether the problem seems large, but whether separating responsibilities offers a verifiable advantage over a single unit of work or an explicit workflow. This option might be investigated if there are distinct tasks, contexts that are better kept separate, or activities that need to produce independent results before synthesis. But dividing the work introduces coordination, context transfer, and more points where inconsistencies can arise. Without measurements for the particular case, you should not claim that the separation improves quality or reduces time.

Consider the invoice again. A hypothetical design could separate document extraction, policy checks, and preparation of a review for a person. Before building it, ask whether those responsibilities are genuinely independent, whether each can be evaluated separately, and whether the combined result is better or easier to inspect than a fixed workflow or a single agent using the same tools. If the answer is no, the extra components may add cost without a demonstrated benefit.

Visibility into interactions matters: you should be able to reconstruct what information each component received, what result it produced, and how that result was used later. This helps investigate failures, although it does not eliminate the possibility of failures. Permissions, tools, and memory are assigned through implementation; the architecture does not resolve them automatically. Functional separation may help define responsibilities, but only if access and data exchanges are designed and verified explicitly.

A shared comparison and decision matrix

To compare patterns fairly, first hold the task, set of cases, and success criteria constant. For the invoice example, that means using representative documents, the same accounting rules, and a shared definition of correct extraction, appropriate routing, and an acceptable record. The comparison would not be useful if one pattern received more context, tools, or human intervention than another without that difference being documented.

The table below does not assign universal scores. It summarizes questions the team can answer using evidence from its process, tests, and measurements. For example, “high variability” should mean that observable differences change the steps needed, not simply that the team does not yet understand the process. Likewise, “easy to check” requires a test or acceptance criterion, not just a subjective impression.

Tools, permissions, memory, and oversight

These elements are not determined automatically by choosing one pattern or another. A pattern changes where decisions are made and how many components take part; the actual scope depends on connected tools, how access is controlled, what data is supplied, and the review logic. For that reason, an architecture should not be described as “safe” or “controlled” solely because it is a workflow or because it consists of multiple agents.

For tools, document each available action, its effect, and who can invoke it. Distinguish read operations from actions that modify data, send messages, or create other external effects. In a workflow, the program itself may invoke each tool at a planned point. In an agent, the model may select a tool from those allowed. In a multi-agent system, clarify which components have access to which tools and how you verify that a transferred output cannot trigger an unauthorized action.

For memory and context, specify what is retained during a run and what, if anything, is reused in another. Record why that information is retained and test its effect with cases. Additional memory may help preserve necessary information, but it may also introduce stale or irrelevant context. Treat this as a design risk to test, not as an inevitable outcome.

Human oversight needs a concrete purpose. It may confirm actions, resolve exceptions, verify results, or stop the process. A review that comes too late may not prevent the effect it was intended to control; reviewing every step may make automation unnecessary. Define review points according to the impact of an error, and measure how many cases are reviewed, how much work review requires, and what disagreements arise.

Initial evaluation: measure before increasing autonomy

A useful pilot does not begin with a demonstration designed to make everything go right. It begins with a set of cases that reflects intended use: common cases, known boundary cases, incomplete documents, ambiguous inputs, and exceptions that require the system to stop. Keep a baseline for the current process so results can be compared, and record the conditions of each test. If you change instructions, tools, or rules, note the change so you do not attribute an effect to the architecture when it may have come from something else.

Evaluate the outcome and the path separately. Outcome questions include: Were the data extracted correctly? Was an authorized route chosen? Was the need for review detected? Was the system prevented from completing an action with insufficient information? Process questions include: What intermediate decisions were made? Which tools were used? Was relevant information consulted? Did the system stop when it should have? For agents and multi-agent systems, these records help show whether an acceptable answer was produced by an appropriate route.

Define in advance the criteria for continuing, narrowing, or stopping the test. If the most serious errors happen when an action is selected, you may need to restrict tools or return that decision to the code. If cases cannot be evaluated consistently, first improve the definition of success. If human reviewers frequently correct the same type of result, the system may need an explicit rule, better inputs, or a validation stage—not necessarily more agents.

When not to use an agent—or when to reduce autonomy

Not using an agent may be the right decision when a known routine can be handled with conventional code, when rules are stable and verifiable, or when there is no reliable way to check the result. Keeping a person in the loop may also be preferable when the cost of a mistake is high and actions cannot easily be reversed. In those cases, automation can be limited to preparing data, summarizing information, or proposing a route without executing it.

Return to a fixed workflow, or limit the agent to one stage, if action selection offers no benefit you can measure, if the agent uses unnecessary tools, if exceptions can now be represented with clear rules, or if it is difficult to reconstruct how a decision was made. When components in a multi-agent system disagree, consider whether separation is actually helping: an explicit route with validations may be easier to test for that case, although the team needs to check this.

If you are evaluating an agent composition, start with separate functions that have defined inputs, outputs, and acceptance criteria. Do not divide a task into many abstract roles based on intuition. First test a simple version, observe where it fails, and expand only when you have identified a problem that separation could address. The advice to start with the simplest pattern that fits also appears in one of the supplied secondary sources; here it is presented as a design heuristic to validate for the specific use case, not as a universal law.

A final checklist for documenting the choice

An architectural decision is more useful when it can be revisited after observing the system in real conditions. Document the problem you are trying to solve, the alternatives you compared, and the evidence that led to the decision. You do not need to assume the choice is permanent: if case variability, consequences of errors, or available tools change, the appropriate pattern may change too.

For further comparison of single agents and multiple agents, consult the Microsoft Learn guide identified in the source material. For a comparison of agents and workflows, the UiPath documentation may be useful, keeping in mind that it is vendor documentation. The Microsoft Learn and Google Cloud design-pattern pages offer architectural guidance; evaluate their recommendations against your team’s needs and constraints. These references do not replace your own tests or prove performance outcomes for a particular task.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.