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