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