Delegate subtasks without losing outcome ownership

Learning objective

Design orchestrator–subagent hierarchies, delegation contracts, and responsibility boundaries.

Core idea

For an architect defining delegation, the first question is who owns the result after a specialist finishes. In an orchestrator–subagent hierarchy, the parent delegates a bounded task, receives the result, and remains responsible for the overall outcome. Delegation distributes work; it does not erase accountability.

Microsoft Agent Framework implements agent-as-tool composition through .as_tool() in Python and .AsAIFunction() in .NET. The parent calls the specialist as a function tool, then continues its own work. This fits a hierarchy where specialists supply findings and the orchestrator integrates and validates them.

Handoff is a different ownership model. The receiving agent takes over the task and conversation. Agent Framework documents handoff as a mesh without a central orchestrator. Choose it for a transfer of responsibility, not merely because your design includes multiple agents.

How it works

Define the hierarchy by decisions

Give the orchestrator the decisions that span specialists: task decomposition, selecting a delegate, integrating evidence, detecting missing results, and deciding whether the overall acceptance criteria are met. Give each subagent a narrower deliverable that it can return without deciding the entire case.

A billing specialist can explain invoice discrepancies. A delivery specialist can determine which shipment events support a delay claim. The orchestrator combines those findings into a response. Neither specialist needs authority to decide the other’s domain or to perform the final financial operation.

Use additional hierarchy levels only when they introduce a coherent responsibility. A parent that merely forwards every message to another parent increases coordination depth without improving ownership. More levels also make budgets harder to account for: one top-level task can produce many specialist invocations.

Publish a delegation contract

Treat the contract as an application interface, not an informal request to “help.” Define the information the delegate receives, the result it must return, and the conditions under which it reports inability to complete the task.

A useful contract includes the following application-owned fields or equivalent structures:

• Task identity and purpose: The case identifier and one requested finding.
• Input scope: The records, evidence, and context the delegate may use.
• Output contract: Required findings, supporting evidence, and unresolved questions.
• Allowed operations: The tools the delegate can invoke and prohibited side effects.
• Execution budget: The application deadline and permitted work for this delegation.
• Return outcomes: Completed finding, missing evidence, conflict, or escalation required.

These are design requirements, not built-in Agent Framework parameter names. Implement them in your request and result types and validate them in application code. A specialist’s confident prose is not an alternative to a return contract.

Agent Framework lets you customize the Python agent tool’s name, description, arg_name, and arg_description through .as_tool(). Use the name and description to explain when the parent should call the delegate. Use the argument contract to constrain the requested subtask. Those descriptions guide selection; they do not enforce data access or validate factual claims.

Keep context and authority separate

Provide the context needed for the finding, rather than automatically copying every case detail to every subagent. The agent-as-tool model leaves overall context management with the parent, which can supply relevant information to the delegate.

Minimizing context also makes responsibility clearer. If the delivery specialist receives the requested shipment evidence and the precise question, its output can be assessed against that scope. If it receives the entire business conversation without a deliverable, it can drift into policy interpretation or final resolution.

Tools should follow the same boundary. Expose read operations to a finding agent and keep mutation operations on a separate execution path. The underlying APIs must still enforce permissions and input rules. A parent cannot make a tool safe merely by telling the delegate not to misuse it.

Decide when ownership actually transfers

Agent Framework’s HandoffBuilder lets Python applications configure allowed transfers with add_handoff(). In .NET, use AgentWorkflowBuilder.CreateHandoffBuilderWith(triageAgent) and WithHandoffs(source, [targets]). By default, participants can hand off to one another. Explicit transfer rules constrain which agent can take over next; they do not turn the mesh into an orchestrator–subagent hierarchy.

The documented handoff implementation only supports Agent participants that support local tool execution. Its routing rules also do not partition conversation history: the documentation distinguishes takeover rules from context synchronization. Do not use a handoff edge as proof of an information-isolation boundary.

Use handoff when a specialist should continue the conversation and own the task. Use agent-as-tool when it should return a finding to the parent. If a human must take responsibility after uncertainty or risk exceeds the system’s scope, define that escalation as a business outcome with a review request, rather than another invisible specialist hop.

Key distinctions and trade-offs

Delegated work versus transferred ownership: Agent-as-tool returns control to the primary agent. Handoff transfers control and task ownership. Similar specialist names do not make the patterns interchangeable. Only agent-as-tool brings control back to the agent that delegated.

Contract guidance versus enforcement: Descriptions tell the model when a delegate is useful. Input validation, restricted tools, and result checks enforce the allowed task. Use both.

Hierarchy versus mesh: A hierarchy provides a clear integration owner. A mesh supports evolving specialist ownership. The choice changes who must detect incomplete work and produce the accepted final outcome.

Context sufficiency versus oversharing: Narrow context can reduce irrelevant evidence and exposure. Too little context can cause repeated clarification. Define required inputs rather than choosing indiscriminately between a full transcript and no transcript.

Architecture / decision scenario

An enterprise support system investigates delayed orders with disputed invoices. The orchestrator owns a case-level response that must reconcile shipment evidence and billing terms. It delegates shipment analysis and invoice analysis through separate agent tools.

Each request identifies the case, the exact question, permitted evidence, and deadline. Each specialist returns a finding with evidence identifiers or an explicit missing-evidence outcome. The shipment specialist has tracking tools; the billing specialist has invoice lookup tools. Neither can issue a credit.

The orchestrator validates both results, requests clarification for a missing invoice, and escalates contradictory findings. It does not report success because one specialist returned a polished answer. The final credit proposal follows the business workflow and approval boundary in 1.1.6.

If the case instead requires a billing specialist to conduct an extended customer conversation and own the remaining resolution, use handoff with explicit allowed transfers. That is a deliberate responsibility change. Retaining agent-as-tool calls while expecting the specialist to own the conversation would leave both context handling and completion ownership ambiguous.

Common exam traps

• Equating agent-as-tool composition with handoff.
• Assuming a specialist’s tool description enforces access restrictions.
• Delegating without a failure result or a bounded return contract.
• Treating custom handoff rules as conversation-history isolation.
• Allowing every hierarchy level to claim the final business outcome.

What to remember

In a hierarchy, the orchestrator retains outcome ownership and subagents return bounded findings. Implement selection guidance with agent tool names and descriptions, and enforce contracts in application code. Use handoff only when you intend control and responsibility to transfer.

Knowledge check

References

• Microsoft, Tools overview
• Microsoft, Workflows orchestrations — Handoff
• Microsoft, AI agent orchestration patterns