Split business goals into bounded work

Learning objective

Decompose goals into bounded workflows, agents, subagents, and tools.

Core idea

For an architect designing an agentic system, decomposition starts with an observable business outcome. A goal such as “resolve a disputed invoice” is too broad to be a tool contract. Break it into bounded units that produce evidence, decisions, or controlled changes, then choose which units need reasoning.

A workflow owns the sequence and allowed outcomes. An agent interprets an uncertain task and selects actions within a scope. A subagent is an agent acting under another agent’s delegated responsibility. A tool exposes an operation through an interface. These are different boundaries, even when the same codebase implements them.

Microsoft’s Azure Architecture Center recommends the lowest complexity that reliably meets requirements: a direct model call, a single agent with tools, or multiagent orchestration. Splitting every business noun into an agent adds coordination without necessarily improving the result. Add a specialist when its separate knowledge, instructions, tools, or responsibility solve a real limitation.

How it works

Define the outcome before the participants

Write the goal as a deliverable with acceptance evidence. For invoice resolution, require an identified invoice, an explanation supported by records, a proposed disposition, and a recorded outcome. Distinguish “recommend a credit” from “issue a credit.” The first produces a proposal; the second changes a financial system.

Define unsuccessful outcomes too. Missing records, conflicting evidence, and rejected authorization are meaningful results, rather than instructions to keep trying. A bounded unit specifies what it receives, what it produces, and when it must stop or return control.

Use business dependencies to identify workflow stages. Retrieve the invoice before checking its amounts. Obtain authorization before executing a credit. Do not let model-selected ordering accidentally become the business process. See 1.1.2 for the boundary between deterministic control and autonomous reasoning.

Map units to workflow executors

Microsoft Agent Framework represents graph workflows through executors and edges. An executor receives an input, performs work, and emits output. It can contain custom logic, such as transforming data or calling an API, or an AI agent. A workflow therefore does not imply that every step is a model call.

In Python, WorkflowBuilder connects executors through add_edge(). Conditional edges route according to message content. add_fan_in_edges() joins outputs from multiple workers into an aggregator; .NET uses AddFanInBarrierEdge(sources: [...], target: ...). These identifiers describe control and data flow; they do not automatically establish business acceptance of the values traveling along the edges.

Make each executor’s output useful to its consumer. A retrieval executor might produce an invoice record and provenance. A reasoning executor might produce a dispute category with supporting evidence. A validation executor checks whether the proposal satisfies the application contract before any side effect is reachable.

Parallelize only independent work. Invoice retrieval and customer correspondence retrieval can run separately if neither needs the other’s result. Calculating an adjustment from a verified invoice depends on that verification. A fan-in point should specify what happens when one branch provides no usable evidence, rather than treating a partial collection as complete.

Separate agents from their tools

A tool boundary describes an operation, its arguments, and its result. Use it for a record lookup, calculation, or controlled write. The agent chooses whether and how to call available tools; the implementation remains responsible for checking inputs and enforcing the operation’s rules.

Agent Framework’s tool documentation distinguishes local function tools from hosted tools whose behavior depends on the provider. Do not assume a tool’s placement, approval behavior, or availability from its name. For this logical design, an application-owned function tool gives you an explicit operation to validate and govern.

An agent can also appear as a tool. Python’s .as_tool() converts an agent into a function tool for another agent; .NET uses .AsAIFunction(). This is appropriate when a specialist reasons over a bounded subtask and returns a result to the primary agent. The specialist is a subagent in this design, rather than an ordinary deterministic calculation disguised as an agent.

Preserve ownership across the decomposition

Give the workflow owner responsibility for the final business outcome. Give each specialist responsibility for its delegated result. Give each tool implementation responsibility for its operation’s allowed behavior. A successful specialist response does not mean the overall workflow succeeded.

Record these boundaries in the logical architecture, not only in prompts. If the evidence agent can also issue credits, its scope has expanded from gathering evidence to changing money. Separate those capabilities so the architecture can enforce the intended decision boundary. See 1.1.3 for delegation contracts and 1.1.6 for approval placement.

Key distinctions and trade-offs

Workflow versus agent: The workflow defines allowable coordination. The agent provides reasoning inside that coordination. A fixed workflow can include nondeterministic agent steps without surrendering its required business order.

Subagent versus tool: A subagent reasons about a delegated task. A function tool performs an exposed operation. Agent-as-tool composition makes their invocation surfaces similar, but their internal behavior and result assurance differ.

Specialization versus fragmentation: Separate specialists can reduce prompt complexity and tool overload. Too many narrow agents increase messages, latency, and failure points. Combine units that share one coherent responsibility unless a separate boundary earns its cost.

Parallelism versus dependency: Concurrent evidence gathering can shorten elapsed time. Dependent decisions still require an explicit join and validation. More concurrent agents do not remove the need for one accepted outcome.

Architecture / decision scenario

A distributor asks a system to resolve invoice disputes. You define a workflow whose outcomes are a validated resolution proposal, a completed authorized credit, or an escalation with missing evidence. Those outcomes bound the original goal.

A deterministic executor identifies the invoice and rejects malformed identifiers. Two retrieval tools obtain invoice records and correspondence. A dispute agent interprets the correspondence. It calls a pricing specialist through .as_tool() when the dispute requires interpreting negotiated terms; the primary agent retains responsibility for the combined proposal.

A calculation tool computes the adjustment from validated inputs. The workflow joins the evidence and proposal, checks required fields, and routes unresolved conflicts to a person. Issuing a credit is a separate function tool behind approval, rather than another capability on the evidence agent.

This decomposition uses a workflow for business order, an agent for uncertain interpretation, a subagent for specialized reasoning, and tools for bounded operations. If negotiated-term interpretation proves unnecessary, replace that specialist with deterministic logic instead of preserving an agent merely because the diagram already contains one.

Common exam traps

• Creating an agent for every step, including exact arithmetic and input validation.
• Treating a tool-call result as proof that the business goal is complete.
• Delegating a whole goal without defining the specialist’s return contract.
• Running dependent decisions concurrently because the framework supports fan-out.
• Giving an evidence-gathering agent mutation tools that exceed its responsibility.

What to remember

Decompose by outcomes and ownership before choosing agents. Use executors and edges for workflow boundaries, reasoning agents for uncertainty, agent-as-tool composition for bounded specialist delegation, and tools for explicit operations. Every unit needs an accepted result and a way to return failure without expanding its scope.

Knowledge check

References

• Microsoft, AI agent orchestration patterns
• Microsoft, Workflow concepts
• Microsoft, Workflows — Executors
• Microsoft, Workflows — Edges
• Microsoft, Tools overview