Choose the least complex execution model

Learning objective

Distinguish deterministic automation, single-agent systems, and multi-agent workflows

Core idea

Choose an execution model by where decisions belong. Deterministic automation follows application-defined rules. A single agent uses a model to choose actions within a tool boundary. A multi-agent workflow coordinates distinct agents and their outputs. More model calls don’t automatically make a system multi-agent, and more agents don’t automatically make it more capable.

For an architect, autonomy is a placement decision. Keep exact rules and authorization in code. Introduce model judgment where varied language, uncertain evidence, or task decomposition requires it. Introduce multiple agents when specialization, separate permissions, or coordination provides a measurable advantage over one agent. Microsoft’s architecture guidance recommends the lowest complexity that reliably meets the requirements.

How it works

Identify who chooses the next step

In deterministic automation, the application defines the path and conditions. An invoice job can parse a known input, calculate tax by a rule, compare amounts, and route exceptions through explicit branches. Every next step follows the program rather than a model’s proposed plan.

A direct model call can sit inside that fixed path. For example, a pipeline always summarizes a submitted document and then validates the returned fields. The model output can vary, but the application still decides the order of operations. Microsoft’s architecture guidance treats a direct model call as a separate, less complex option from an agent with tools.

This distinction prevents a false binary between “no AI” and “agent.” A deterministic control flow can contain a nondeterministic text transformation. Describe both separately: who chooses the next operation, and whether the operation’s result is repeatable. Fixing temperature doesn’t establish deterministic workflow behavior or a correct business decision.

Use one agent for dynamic tool choice

A single agent uses one decision-making context to select among available tools and interpret observations. It can perform multiple model calls and tool invocations before producing its result. One order-support agent might look up an order, inspect shipping information, and ask for missing details without involving another agent.

The tool loop in 0.4 is the defining behavior: the model proposes a next action, the application authorizes execution, and the observation informs the next decision. Tool count and loop count don’t determine agent count. An agent with five tools remains one agent if one context owns the task’s decisions.

Use this arrangement when a coherent instruction set and bounded tool set can handle varied requests within one domain. The Azure OpenAI function-calling mechanism is tools with tool_choice: "auto" for model-selected calls. The executor remains application code, so dynamic choice doesn’t require unrestricted authority.

A single agent still needs termination, validation, and failure handling. Iteration limits prevent endless tool selection. Tool permissions determine which side effects are possible. If the task requires a fixed calculation or mandatory policy gate, implement that part in code rather than asking the agent to honor it from memory.

Introduce multiple agents for a concrete boundary

Multi-agent orchestration coordinates specialized decision-making participants. Each can have its own instructions, model choice, knowledge, and tool boundary. The orchestrator determines how work is distributed, which context crosses a boundary, and how results become the final outcome.

Microsoft identifies reasons to consider multiple agents: cross-domain work, distinct security boundaries, parallel specialization, or a single agent that cannot reliably manage its prompt and tools. State which reason applies. Naming the same model “researcher” and “writer” doesn’t itself establish an advantage; the two roles need distinct work and an observable result contract.

Separating prompts also doesn’t enforce a security boundary by itself. Assign the actual tool executor or identity only the permissions required by its role. A reviewer with a read-only task shouldn’t gain write authority because another participant can make changes. The orchestration architecture and the application permission model must agree.

Distinguish fixed routing from dynamic delegation

A multi-agent workflow can have deterministic orchestration. Microsoft’s sequential pattern invokes agents in a predefined linear order, and each consumes the previous stage’s output. The next agent is chosen by the workflow, not by an agent. Variable generated content doesn’t make that routing dynamic.

Concurrent orchestration fans work out to independent agents and then aggregates results when the task requires it. Parallelism fits independent analyses; it doesn’t remove dependencies between stages. Decide how to merge results and handle a missing or failed participant before claiming the workflow is complete.

Handoff orchestration transfers control when the active agent recognizes that another specialist should handle the task. That introduces a model-selected routing decision and the risk of repeated transfers. These patterns have different control owners even when all are described as multi-agent. Detailed pattern selection belongs to the architecture objectives; this lesson establishes the distinction. In sequential orchestration the workflow chooses the next agent; in handoff, the active agent does.

Use workflow primitives for explicit control

Microsoft Agent Framework workflows connect agents and functions through explicit execution paths. In the .NET graph API, WorkflowBuilder connects typed executors through edges and conditions. The documented direct-edge operation is AddEdge(sourceExecutor, targetExecutor). The Python graph API uses WorkflowBuilder and add_edge instead. Keep language-specific identifiers separate.

Executors perform work; edges route messages. An executor needn’t be an agent. In .NET, a deterministic executor can implement a [MessageHandler] and return a transformed value, or send a message through IWorkflowContext.SendMessageAsync. That lets you combine rule-based stages with agent stages without granting the model control of every transition.

The framework documents direct, conditional, switch-case, fan-out, and fan-in edges. Choose those mechanisms when application conditions should own routing. Use agent orchestration when model judgment should choose the participant. A workflow exposed through an agent interface remains internally structured; its outward interface doesn’t reveal whether its inner stages are deterministic or autonomous.

Scope framework choices to their language. The overview marks Agent Framework for Go as public preview, and the Workflow concepts page identifies Python’s functional workflow API as experimental. The .NET graph examples here don’t imply that every language exposes the same APIs or feature status.

Key distinctions and trade-offs

Model call versus agent: A fixed summarization call can solve a task without a dynamic action loop. An agent decides which allowed action to take next.

Single agent versus multiple agents: Several tools or repeated calls don’t establish multiple agents. Multiple specialized participants require coordination and context exchange.

Fixed workflow versus fixed output: A sequential graph can route deterministically while its agent outputs vary. Describe the control flow independently of generated content.

One agent is easier to trace and coordinate. Several agents can isolate responsibilities or perform independent work concurrently, but add message passing, repeated context, aggregation, and partial-failure handling. Compare complete accepted outcomes, not the number of impressive intermediate responses.

Architecture / decision scenario

A claims platform needs exact eligibility calculations, free-text customer support, and a disputed-claim review across legal and medical evidence. Use deterministic automation for eligibility rules and required approval gates. Those conditions have known inputs and explicit decisions; model judgment would add uncertainty without adding needed capability.

Use one bounded support agent for varied questions and authorized status lookups. Its tools catalog and tool_choice: "auto" provide dynamic selection, while runtime limits and permissions bound execution. A fixed one-pass summary inside this flow doesn’t become a separate agent merely because it is another inference request.

For disputed claims, evaluate separate legal and medical agents with distinct evidence and read-only tool boundaries. If their reviews are independent, run them concurrently and validate both result contracts before aggregation. If one depends on the other’s result, connect them sequentially instead. Keep the final eligibility calculation and mandatory approval in deterministic executors.

The acceptance measure is whether the coordinated workflow improves complete review quality enough to justify extra latency, tokens, and failure handling. If one agent meets the same target with the required permissions, retain that simpler design. If a specialist fails, the orchestrator returns an incomplete or escalated review rather than treating another specialist’s answer as a substitute.

Common exam traps

• Calling every model-backed pipeline an agent.
• Counting tools or inference requests as agents.
• Assuming multi-agent implies model-selected routing.
• Confusing deterministic routing with deterministic generated output.
• Treating separate prompts as enforced permission isolation.
• Adding parallel agents where the work has sequential dependencies.

What to remember

Locate control ownership before selecting a framework. Use rules for exact decisions, one agent for bounded dynamic tool use, and coordinated agents for justified specialization. Explicit workflows can mix deterministic functions and agent stages; more autonomy is a cost that the task must justify.

Knowledge check

References

• Microsoft, AI agent orchestration patterns
• Microsoft, Function calling
• Microsoft, Microsoft Agent Framework overview
• Microsoft, Workflow capabilities
• Microsoft, Workflow edges
• Microsoft, Workflow executors
• Microsoft, Workflow concepts