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

Yao and colleagues: τ-bench, 2024

A procurement agent can read a supplier proposal, compare it with purchasing policy, and prepare a response. The hard question arrives when it starts writing files and calling business systems: whose data can it access, whose authority does it use, and what happens if a session fails halfway through? Those decisions belong in the architecture before a promising demonstration becomes a production pilot.

Microsoft’s April 22 hosted-agent announcement addressed part of that problem with a refreshed public-preview runtime: separate VM-isolated session sandboxes, persistent files across suspension, and compute that scales down when idle. It also described dedicated agent identities and support for different frameworks. These were launch capabilities, not evidence that a particular enterprise application had passed its own production acceptance tests.

Read the April release status precisely

The accompanying developer announcement distinguished stable Microsoft Agent Framework 1.0 and generally available Foundry Toolkit for VS Code from preview hosted agents, memory, and Toolboxes. It also separated the GA tracing foundation from preview hosted-agent tracing and custom evaluators. An SDK release and a managed service release are separate decisions; neither should substitute for checking the feature your application actually uses.

The April Toolbox announcement described reusable tool bundles exposed through an MCP-compatible endpoint. Its launch table emphasized Build and Consume, while broader Discover and Govern pillars were marked coming soon. My recommendation is to record each required control and its evidence individually. A platform’s governance direction is useful context; an implemented and verified control is what a release decision needs.

An illustrative procurement workflow

Consider a hypothetical manufacturer whose buyers review supplier quotes. This is a design example, not a customer implementation or a measured result. The initial agent reads an approved proposal, retrieves the current purchasing policy, identifies missing terms, and prepares a recommendation. A buyer approves the recommendation before a separate application submits any change to the purchasing system.

Keep the first pilot narrow: one business unit, one document type, a defined set of suppliers, and read access to a small collection of current policies. Exclude payment execution and supplier bank-detail updates from the initial tool set. A smaller action surface makes failures easier to interpret and gives the team a practical baseline for deciding whether additional autonomy is useful.

Separate the runtime boundary from the business boundary

Session isolation helps protect execution state. It does not establish which purchasing records the caller may see. I would require the application to derive the session’s business scope from authenticated identity, then enforce the same scope in every retrieval and API call. User-written text must never choose the tenant, buyer identity, or permission boundary.

Decision	Recommended pilot implementation	Evidence to retain
Session scope	Separate working directories and session identifiers by authenticated business scope.	A negative test where one buyer requests another buyer’s material.
Tool access	Expose narrow operations such as reading a quote or preparing a change request.	Tool schemas, authorization decisions, and rejected calls.
Approval	Bind approval to the exact supplier, record, proposed change, and version.	Approved payload plus the approving user’s identity.
Recovery	Use a unique operation key for external writes and reconcile uncertain outcomes.	An interrupted run that resumes without duplicate submissions.

These are proposed application controls, not claims that Foundry automatically implements this whole design. Define who owns each control: the identity team, platform team, application team, or business owner. If a control has no owner and no observable outcome, it is difficult to operate when the agent encounters an unusual request.

Treat files and tool calls as part of the transaction

A generated recommendation may contain outdated facts even when its file survives a restart. Record the policy version, source identifiers, retrieval time, and proposed transaction with the draft. Before the approved write executes, recheck that the purchasing record has not changed. If it has, return the proposal for review instead of applying approval to a different business situation.

Handle uncertain API results explicitly. A timeout can mean the request never arrived, or that the system completed it without returning a response. The agent should not resolve that ambiguity by repeatedly submitting the write. A reconciliation operation that checks the operation key and business record is more useful than a confident explanation of what probably happened.

Measure a complete task

For this pilot, I would measure the elapsed time from quote receipt to an accepted buyer recommendation, including review and correction. Add the percentage of recommendations accepted without material edits, policy violations missed, inappropriate disclosures, and interrupted runs recovered successfully. Token usage is an operating input; an accepted, correctly scoped recommendation is the business output.

Calculate cost per accepted recommendation using model calls, retrieval, active runtime, storage, monitoring, and human correction. Compare the result with a manual baseline on equivalent quotes. Keep difficult cases in the denominator, including declined and escalated requests. Otherwise, an attractive average can hide an agent that helps only when the work was already easy.

A practical release gate

My suggested sequence is to replay representative historical quotes with sensitive details removed, then test malicious instructions embedded in documents, expired sessions, permission changes, unavailable tools, and interruption after approval. Run a supervised pilot only after those cases have clear outcomes. Broader access should depend on observed quality and recoverability, not the size of the model or the smoothness of a demo.

The architectural value of a managed runtime is the opportunity to spend more attention on business correctness. Use that opportunity to define who can act, what approval authorizes, how interrupted work is reconciled, and what a successful task costs. Those decisions make the pilot useful to both the engineering team and the purchasing leader.

References

Microsoft: refreshed hosted agents, April 22, 2026
Microsoft: local-to-production developer journey, April 22, 2026
Microsoft: Toolbox launch scope, April 22, 2026

When an enterprise assistant makes the same decision incorrectly, fine-tuning can look like the obvious next investment. First identify the failure. Did the model lack the current policy? Did the tool return incomplete data? Was the expected decision ambiguous? Or did the model repeatedly choose the wrong action despite having the evidence and instructions? Each diagnosis points to a different intervention.

Microsoft’s April 16 update expanded Global Training for o4-mini and introduced GPT-4.1, GPT-4.1-mini, and GPT-4.1-nano as additional model graders. It reported 13 launch regions and planned further expansion. I would treat that list as a dated announcement, not current capacity confirmation. The more important enterprise question is whether the reward used for training represents a decision the business actually wants.

Retrieval, prompting, and training solve different problems

Microsoft’s current fine-tuning overview explains that training changes model weights and does not replace retrieval for fresh information. It distinguishes supervised examples, preference pairs, and grader-based reinforcement signals. For an application team, the useful first step is to match the intervention to the observed failure rather than choosing the most sophisticated customization method.

Observed failure	First intervention I would test	Reason
The answer uses an obsolete policy.	Retrieve a versioned, current policy and check the retrieved evidence.	Training is not a reliable policy-distribution mechanism.
A field is missing or malformed.	Clarify the output contract and validate the response.	A format problem may not require changing model weights.
The agent selects a wrong tool despite adequate context.	Improve tool descriptions and run a controlled baseline before considering RFT.	The action-selection failure needs a measurable test.
Reviewers disagree about the right outcome.	Resolve the rubric with the business owner.	Training on unresolved judgments can amplify inconsistency.

Use the same evaluation cases for your baseline and the proposed improvement. Change one intervention at a time where practical. If better retrieval eliminates the failure, the evidence favors improving retrieval. If a tuned model only appears better after changing the test set, the comparison cannot tell you which intervention helped.

A hypothetical service-dispatch example

Imagine a manufacturer whose assistant recommends whether a reported equipment fault should go to remote troubleshooting, routine dispatch, or urgent human review. The assistant receives a fault report and retrieved service guidance. It proposes a route and cites the supporting rule. This is an illustrative design, not an account of a client engagement.

The business owner must decide what makes that recommendation acceptable. Correctly identifying urgency matters more than writing an elegant explanation. A request with insufficient evidence should escalate. A customer sentence claiming to authorize bypassing the service policy should not change the policy. Those requirements should be explicit before collecting training examples.

Validate the grader as its own system

I would create a separate grader test set containing a correct recommendation, an incorrect recommendation with persuasive wording, a missing-evidence escalation, an invented citation, and malformed output. Ask reviewers to label these cases before running the grader. Then examine where the grader disagrees, including whether it rewards confidence or verbosity instead of correctness.

The current RFT procedure describes the grader as the reward function and requires dataset fields to align with its references. It also supports different grading approaches and separate training and validation files. Check the selected model’s requirements and access before submitting a job. These implementation details must be verified against the current API and packages; older blog examples should not be treated as tested deployment code.

For the dispatch example, my proposed rubric would reject an unauthorized action, require a valid route, verify that the referenced rule exists in the provided evidence, and accept escalation when decisive information is missing. A separate reviewer would inspect explanation usefulness. Keep these scores visible separately so an improved prose score cannot conceal a worse routing decision.

Prevent an apparently successful experiment

Hold out cases by underlying incident or policy family, not merely by randomly separating similar sentences. Near-duplicate fault reports can make the final evaluation look easier than new production work. Include unfamiliar abbreviations, incomplete reports, conflicting evidence, and policies that changed after the training examples were collected.

The model, grader, and reviewer should not all depend on the same unchecked assumption. For an expensive error category, use a business-owned reference and inspect failed examples directly. If the reward increases while reviewers reject more recommendations, pause the experiment and examine the reward definition. A rising training metric is a signal to investigate, not a business acceptance decision.

Global Training needs a separate geography decision

Current training-type guidance distinguishes where training runs from where a trained model is deployed. Global Training can use capacity beyond the resource region. Treat approved training geography and approved inference geography as separate design requirements. Do not infer either from the region displayed on the resource alone.

Microsoft’s data-processing documentation for models sold by Azure describes restrictions on using customer inputs and training data to improve foundation models without permission or instruction, alongside storage and abuse-monitoring behavior. Those commitments are not a promise that every feature has zero retention or identical processing arrangements. Review the applicable model, feature, and deployment type before uploading operational records.

For this hypothetical pilot, I would remove customer identifiers that are unnecessary for learning the routing task, retain policy-version provenance, and give the data owner a documented deletion process. These are recommended project choices. The approved dataset should be reproducible so a later reviewer can determine exactly which examples produced a candidate model.

Make the investment decision with task economics

Compare the baseline and tuned candidate on correct routing, missed urgent incidents, appropriate escalation, reviewer correction time, latency, and total operating cost. Include dataset preparation, expert labeling, grader runs, training, hosting, inference, and maintenance when calculating cost per accepted recommendation. A lower token bill alone does not establish a better investment.

Choose the acceptance thresholds with the service leader before training. If the candidate improves routine routing but increases missed urgent cases, an overall accuracy average is insufficient. Keep the first deployment advisory, inspect disagreements, and expand only when the measured improvement matters to the operation. The objective is a defensible decision process whose quality can be checked after the experiment ends.

References

Microsoft: April 16, 2026 reinforcement fine-tuning update
Microsoft Learn: fine-tuning methods and training types, current guidance
Microsoft Learn: RFT data, graders, and job setup, current guidance
Microsoft Learn: data, privacy, and security for models sold by Azure