Delegate bounded tasks and replan deliberately

Learning objective

Implement orchestrator–subagent delegation with explicit role contracts, task decomposition, bounded spawning, and optional replanning

Core idea

An orchestrator owns the requested outcome while subagents own specific contributions. Delegation works when the orchestrator can state the input, expected result, available capabilities, and acceptance condition for each contribution. The parent validates returned work and decides what happens next.

Bounded spawning limits how much subordinate work the application can create, not only how many model turns one participant takes. Optional replanning changes the task decomposition after evidence shows the initial plan is inadequate. Both controls must preserve the original outcome and authority constraints.

Microsoft Agent Framework provides agent-as-tool composition for call-and-return delegation and Magentic orchestration for a manager that plans and coordinates specialist work. Magentic’s documented experimental types and planning controls require explicit treatment; a dynamic plan is not permission to create unlimited agents.

How it works

Turn a role into a callable contract

Expose callable specialists with .as_tool() in Python or .AsAIFunction() in .NET; see 1.1.3 for the parameters and ownership contract.

The specialist’s instructions define its responsibilities, and its tools define the capabilities exposed to it. Keep the callable description aligned with those instructions. An orchestrator cannot route accurately when a tool promises legal approval but the inner agent is only configured to extract contract clauses.

Define required inputs, returned artifacts, supporting evidence, and valid failure outcomes. See 1.1.3 for ownership contracts and 2.1.1 for role prompts and schemas. Enforce those contracts before dispatch and after return.

For example, a cost-estimation subtask receives a design revision and approved assumptions. Its return includes an estimate, unresolved assumptions, and the revision evaluated. Those fields are application-defined. The orchestrator rejects a result tied to a different revision instead of combining it with the active plan.

Decompose work into accepted contributions

Split tasks by outcomes and dependencies. See 2.4.1 and 2.4.2 for sequential gates and parallel collection.

Give each dispatch a task identity and an acceptance predicate. The parent should know whether a result completes a planned contribution, exposes a missing input, or creates a need for another task. A subagent’s prose suggestion to create more agents is evidence for the parent to evaluate, not an automatically executed spawning command.

Distinguish a fixed roster from runtime creation. MagenticBuilder(participants=[researcher_agent, coder_agent], manager_agent=...) configures the participating specialists. Its manager selects among them and can call agents repeatedly in different orders. This is dynamic coordination of a supplied team, not a documented unlimited agent-creation facility.

Enforce the spawning budget outside the prompt

A bounded delegation design specifies maximum active children, total child tasks, and permitted nesting depth. Those are separate controls: limiting simultaneous work does not stop the orchestrator from creating an endless succession of children. A depth cap does not limit a very wide first generation.

Implement the budget in an application-owned dispatch gate, using a custom executor or function tool wrapper. Before dispatch, the gate checks the parent task, allowed role registry, remaining total budget, active-work count, and depth. Only an accepted dispatch invokes the specialist. Return a structured budget-exhausted outcome when the request cannot fit.

These counters and outcomes are application policy, not Magentic parameter names or Microsoft service quotas. For example, an application might allow two active children, six child tasks in total, and one subordinate level. Print those chosen values in the task contract and enforce them in code; do not describe them as framework defaults.

The gate must reserve a slot before execution and release active capacity when that child finishes. Total-created accounting remains consumed after completion. Repeated attempts and replanned work must use the same parent budget rather than resetting it under a different description.

If you permit subagents to delegate, route their requests through the same gate. A parent-only counter that children can bypass does not bound the work tree. For a simpler design, give children no spawning capability and let them return requests for additional work to the orchestrator.

Replan through a controlled manager

Magentic orchestration uses a manager to plan, select participants, assess progress, and synthesize a final answer. The documentation’s .NET sample marks Magentic types experimental with warning identifier MAAIW001. Evaluate this mechanism with that status explicitly represented in your engineering decision.

Magentic bounds coordination with Python max_round_count, max_stall_count, and max_reset_count (.NET: WithMaxRounds(), WithMaxStalls(), and WithMaxResets()) and supports plan review; see 1.1.5 for those mechanisms. None limits child count or nesting depth.

Treat each replan’s proposed task list as input to the dispatch gate. Compare every proposed task with accepted artifacts, tasks still running, and the remaining total budget. A changed description does not make an already completed contribution missing again. If the plan invalidates an artifact’s assumptions, record why a replacement is needed and charge that replacement against the same parent’s budget.

Validate the role and required capabilities before admitting each replacement or additional task. The gate checks the application-owned allowed-role registry and depth for that parent. A plan requesting a specialist outside the registry returns an unsupported-role outcome; it does not dynamically expand the participant roster or tool permissions.

Separate plan admission from immediate execution. A replan can fit the remaining total budget while proposing more simultaneous work than active capacity permits. Queue admitted tasks and reserve active slots only as capacity becomes available. Reject or escalate a plan that cannot complete its required contributions within the remaining total budget rather than launching a convenient subset and calling the plan accepted. Planned, replanned and child-requested work all pass the same dispatch gate before they hold an active slot.

If four of six permitted child tasks already exist, three replacement tasks exceed the two remaining total slots. Available active capacity does not change that decision. Reduce the proposal without losing required coverage or return a budget-exhausted outcome.

Use fixed delegation when the decomposition is known and stable. Choose Magentic when the path requires discovery and adaptation. Microsoft warns that performance outside the original Magentic-One design is untested; validate your specialist team rather than assuming a flexible manager guarantees useful planning.

Isolate manager state for each parent

For Python manager state, the documentation warns against sharing an explicit stateful manager across concurrent or interleaved workflows. Use manager_factory for isolated manager state per workflow. Mixing progress ledgers across parent tasks can corrupt both task selection and termination decisions.

The terminal Python Magentic output is the manager’s synthesized AgentResponse. Validate that synthesis against the accepted child artifacts and the remaining unresolved work. Reaching the manager’s final answer is an execution outcome; the application’s acceptance contract still determines whether the requested result is complete.

Key distinctions and trade-offs

Delegation versus spawning: Calling a configured specialist delegates work. Creating or scheduling additional children changes the size of the work tree and requires a budget gate.

Round limits versus child limits: Magentic coordination limits bound its planning loop. Application counters bound active, total, and nested subordinate work.

Replanning versus changing the goal: A replan changes how the original outcome is pursued. It does not authorize a broader scope, wider permissions, or a fresh budget.

Fixed decomposition is easier to inspect; dynamic planning adapts to discoveries but adds coordination cost and repeated-work risk. Keep acceptance and budget checks deterministic.

Architecture / decision scenario

A migration assistant owns one application assessment. Its configured subagents analyze dependencies, propose a target design, and estimate migration effort. Each contract names inputs, required artifacts, excluded actions, and a return status. The parent validates design revisions before accepting estimates.

The service chooses an application budget of two active children, six total child tasks, and one subordinate level. A dispatch executor checks and reserves those counters. Children cannot create peers directly; they return missing-work requests to the parent. A completed child frees active capacity without restoring total task budget.

For uncertain dependencies, the team evaluates experimental Magentic coordination with explicit round, stall, and reset limits. If research reveals an incompatible assumption, the manager replans. That plan still passes through the original dispatch budget and cannot introduce an unapproved role.

Plan review is enabled explicitly. A human can revise the proposed tasks, and manager state is isolated with manager_factory. When limits prevent the remaining analysis, the parent returns an incomplete assessment naming the unresolved dependency rather than calling budget exhaustion a successful migration plan.

Common exam traps

• Treating a role description as a validated return contract.
• Confusing repeated calls to supplied participants with unlimited agent creation.
• Using round limits as substitutes for active, total, or depth budgets.
• Resetting the task budget whenever the manager replans.
• Admitting a replan because active slots remain when the total task budget is exhausted.
• Sharing a stateful manager across independent concurrent tasks.

What to remember

Delegate through explicit callable and result contracts, and keep outcome ownership with the parent. Enforce spawning in a dispatch gate. Magentic supports experimental planning and bounded replanning, but its coordination controls do not replace child-task budgets or final acceptance checks.

Knowledge check

References

• Microsoft, Tools overview
• Microsoft, Magentic orchestration
• Microsoft, Executors