The weather question reached the specialist. The specialist asked permission. The caller answered yes—and the inner tool never ran. That is the reproduction in issue #4963 in microsoft/agent-framework, a small example of a larger problem: displaying an approval request does not mean the application can resume the work behind it.
A Python change merged on September 21 draws a sharper boundary. When one agent is exposed to another through Agent.as_tool(), unresolved child function approvals now stop that delegated invocation. They do not become approval requests for a parent continuation that cannot safely complete them.
For builders, this changes the architecture question. “Can this agent ask a human?” is incomplete. The application must also know which suspended operation the human’s answer belongs to, how that operation continues, and where its result returns.
A fix that deliberately stops short
The obvious reading of the issue was that subagent approvals needed to work like ordinary tool approvals. The merged contract is narrower. Each delegated invocation receives a child session, allowing its approval middleware to apply immediate rules when the tool call actually occurs. That can cover tools discovered during execution, rather than only a list known when the parent was constructed.
But if a child function approval remains unresolved, the wrapper fails with guidance to use a workflow for interactive or delayed approval. A response containing other kinds of user-input requests preserves those requests while discarding the child approval continuation. This is a specific boundary around function approval, not a blanket ban on children asking for input.
The new comparison sample makes the choice tangible. One inventory specialist may immediately approve a small reservation through a quantity rule. A larger reservation travels through a workflow: the coordinator delegates, the child pauses, a response resumes it, and the result returns to the coordinator.
The sample’s inventory function only returns a string; it is not evidence of a working stock system. Its useful contribution is the return path. A production application would have to implement the real approval interface and persist checkpoints if the wait must survive a restart.
Sharing data must not share a pending yes
There was a second trap behind the visible request. With session propagation enabled, the earlier wrapper shared the parent’s state dictionary by reference. Rejecting an approval in the returned response would not, by itself, keep child approval state out of that shared dictionary.
The merged implementation instead gives the child a filtered state copy. Application-state changes can merge back, but framework approval and invocation-budget keys are excluded. The exclusion also accounts for custom approval-middleware identifiers. If parent and child use overlapping approval identifiers while propagating a session, the call fails before running the child.
That distinction matters when two agents have similarly named tools or custom middleware. A pending permission belongs to a particular execution. Moving the surrounding data should not silently move the authority to continue it.
The regression cases cover immediate child approval, unresolved requests, shared identifier collisions, preservation of parent approval state, and a fresh delegation that must not inherit a custom child approval queue. These are source-level checks of intended behavior. They do not establish general isolation of arbitrary mutable application objects.
The acceptance test comes after the button
The original report describes streaming and non-streaming failures on an earlier release candidate. The new code is merged, but we have not mapped it to a released Python package or independently run the model-backed sample. The finding is about this implementation and its documented contract, not the behavior of every installed Agent Framework application.
Teams using nested tools can now audit each approval boundary: does policy decide within the call, or can a person answer later? For the latter, a harmless workflow test should prove that the answer resumes the intended child and returns its result to the same coordinator. If persistence is required, repeat that test after restoring a checkpoint. The useful next signal is no longer whether an approval card appears. It is whether the right unfinished job can consume the answer.