A service agent has diagnosed an incident and prepared a production change. The operations manager opens the approval request after lunch. By then, the deployment has changed, the original session has expired, and another engineer has already resolved part of the problem. What exactly does clicking Approve authorize?
That question belongs in the workflow design. A message asking for permission is only the visible part of approval. The application also needs a durable record of the proposed action, an authenticated decision, and a controlled path from that decision to execution. Otherwise a cautious user interface can sit on top of an unsafe transaction.
A durable pause is an architectural boundary
Microsoft’s February Foundry update describes a pattern combining Azure Durable Functions, Microsoft Agent Framework, and SignalR for workflows that wait for human input. The orchestrator can persist progress while an external approval event is pending. This is an application architecture pattern, rather than a claim that every Foundry agent automatically receives transaction-safe approvals.
The framework’s February release-candidate announcement documents checkpointing and human participation in graph-based workflows. By April, Microsoft had announced Agent Framework 1.0. Those building blocks help coordinate execution. The application still decides which person may approve a particular action and whether the action remains valid when work resumes.
For a production change, I would divide the flow into analysis, proposal, approval, validation, execution, and reconciliation. Each transition needs an explicit state. A conversational response such as “looks good” should become an approval only when the application can associate it with a specific proposal and authorized reviewer.
Measure the final state, not the conversation
The 2024 τ-bench paper evaluated tool-using agents through simulated user conversations, domain policies, and final database state. Its tested agents, including GPT-4o configurations, succeeded on fewer than 50% of tasks; retail reliability across eight trials, measured as pass^8, was below 25%. These are historical benchmark findings, not measurements of current Foundry models.
The useful lesson is methodological: an agent can sound cooperative and still leave the business system wrong. Approval testing should inspect the resulting record, including whether an unauthorized or duplicate change occurred. Testing only the wording of the approval question misses the outcome that matters.
What belongs in the approval record?
Consider a hypothetical service-management agent that proposes increasing capacity for one application. Its proposal should identify the environment, resource, current configuration, intended configuration, estimated financial effect, expiry time, and evidence used to recommend the change. This is an illustrative design, not a report of a client deployment.
Give the proposal an immutable identifier and a version. Store a canonical representation of its executable arguments. The approval decision references that version, rather than a mutable chat message. If the agent revises a target or parameter, require a new decision.
Capture the reviewer’s authenticated identity separately from model-generated text. A model may explain who should approve, but it must not establish that person’s authority. Authorization should be checked against the same identity and policy systems used by the application outside the AI workflow.
Make rejection and expiry ordinary terminal outcomes. Teams often implement the approval branch carefully and leave the other branches ambiguous. An expired request must not become an invitation for the agent to find a different route to execution.
Resume with fresh checks
A persisted workflow can resume correctly from its own perspective while the outside world has changed. Before applying the approved change, retrieve the current resource version and compare it with the proposal’s preconditions. Recheck permissions, policy constraints, and any material financial assumptions.
If those conditions differ, return a revised proposal for review. Do not silently reinterpret the previous approval as permission to achieve the same general goal by different means. The business owner approved one intervention under a particular set of facts.
Separate this validation from the language-model step. Deterministic application code should reject a mismatched resource version or expired approval. An explanatory prompt can help users understand the rejection; it should not be the enforcement mechanism.
Design the uncertain-outcome path
A tool call can time out after the downstream service has accepted a change. Blindly retrying risks a duplicate action. Assign an operation identifier before the write and use downstream idempotency support where available.
Where the target system lacks that support, implement a reconciliation query that checks the business record and operation evidence. Mark uncertain outcomes explicitly. A workflow waiting for reconciliation is more honest and easier to operate than an agent announcing success based on a missing response.
Keep the execution worker separate from proposal generation. Give it only the approved operation and necessary credentials. This limits the chance that unrelated conversation content influences a privileged write during recovery.
Test approval as a complete process
Build cases for approval after a restart, duplicate approval events, rejection followed by a late approval, revoked reviewer access, changed resource state, and timeout after a successful write. Include a hostile instruction inside retrieved incident data that asks the agent to bypass review.
For each case, specify both the expected workflow state and permitted downstream changes. Repeat tests because a single successful conversation does not establish consistent behavior. Preserve the failed cases as regression fixtures after correcting the implementation.
The platform team should own orchestration reliability. The application team should own transaction correctness and reconciliation. The business owner should define approval authority, expiry, and acceptable impact. Put those responsibilities in the runbook so an interrupted workflow has an accountable operator.
Report useful business measures
Track elapsed time from proposal to verified completion, reviewer correction rate, expired approvals, duplicate actions prevented, and unresolved outcomes. Separate time spent waiting for a person from time lost to technical recovery.
For an initial rollout, use a narrow action with a clear reversal procedure and observable final state. Compare the full process with the existing manual workflow, including review and recovery effort. An agent that drafts changes quickly but creates reconciliation work may increase the team’s workload.
The release decision should rest on whether the approved action is executed once, within its intended scope, under valid conditions. Durable orchestration makes the wait manageable. A precise approval contract makes the resulting action trustworthy.
References
Microsoft: February 2026 Foundry update
Microsoft: Agent Framework release candidate, February 19, 2026
Microsoft: Agent Framework 1.0 and the developer journey, April 22, 2026
