An architecture review can absorb an entire release catalogue and still end without a decision. Build 2026 adds choices across agent development, hosting, tools, memory, and grounding. The useful question for an enterprise team is which change removes an observed obstacle in its own workload.

I would start with one accepted business task and trace where it fails today. Is the problem finding authoritative information, choosing an appropriate tool, recovering interrupted work, or proving that the result is correct? Each answer leads to a different investment.

Separate available capabilities from announced direction

The June 2 Foundry Build recap distinguishes stable developer components from preview services and future milestones. In particular, it describes Foundry Toolkit for VS Code as GA, memory and Toolboxes as preview, and hosted-agent GA as expected in early July. An expected date is a planning input, not a delivered production guarantee.

The Agent Service announcement presents a build, deploy, and operate approach. That is a useful way to organize responsibility, but it should not turn into a requirement to replace every component at once. Retain working parts of the application unless a change has a measurable benefit.

For each proposed capability, record the required feature, release status, deployment constraints, dependency owner, and acceptance evidence. A broad platform label cannot answer whether a specific preview integration is suitable for the application’s operating requirements.

Use the business bottleneck to choose a pilot

Consider a hypothetical equipment manufacturer whose support engineers prepare maintenance recommendations. The assistant currently retrieves manuals, checks equipment records, and drafts an explanation for an engineer. It struggles when manuals disagree and when an interrupted diagnostic sequence resumes.

If retrieval is the dominant failure, assess the grounding path first. Preserve document versions and test whether the correct evidence reaches the model. A richer agent runtime will not repair an index containing superseded maintenance instructions.

If failures arise after tool calls or restarts, assess orchestration and state recovery. If the assistant consistently knows the relevant information but omits required steps, procedural guidance or memory may deserve a controlled experiment.

This prioritization keeps the pilot small enough to interpret. Changing retrieval, memory, prompts, models, and hosting together can improve a score while leaving the team unable to explain why.

Read early memory results as research signals

The June 2 Agent Service post reports early Tau-bench absolute success-rate gains of 7–14 percentage points with procedural memory at near-baseline cost. This is Microsoft’s reported benchmark observation. It is not an enterprise-wide productivity estimate or a promise for the manufacturer’s support tasks.

The separate June 3 memory article reports about a 5% improvement in its STATE-Bench and Tau-Bench evaluations. It does not establish that this is the same configuration, denominator, or improvement measure as the earlier range. The two statements should not be combined into a single expected benefit.

That distinction matters in a business case. Use an external finding to justify testing a hypothesis, then measure the application under its own tasks, tools, and failure conditions. Approval for broad rollout should depend on that second result.

Define a comparison that can settle the decision

Freeze a baseline configuration and a representative task set. Include ordinary cases, ambiguous manuals, unavailable equipment records, and requests that should be escalated. Assign reviewers who understand the operational policy rather than asking a model to decide every question of correctness.

Compare the proposed capability against the baseline with equivalent input data and access. Keep failed and escalated tasks in the report. If an experiment excludes hard tasks, label that restriction and do not generalize the result to the whole service queue.

Measure accepted recommendations, missed mandatory checks, unsupported claims, elapsed resolution time, and cost per accepted result. Add a recovery test if the pilot changes runtime behavior. A successful happy-path demonstration cannot settle whether interrupted work is safe.

Make observability part of the pilot budget

The Build observability announcement distinguishes the tracing and evaluation foundation from new preview extensions, including multi-turn evaluation and trace replay. Record the specific surfaces used in the pilot and confirm their maturity separately.

My recommendation is to correlate each business task with model calls, retrieval, external actions, and the final review outcome. Capture enough configuration information to reproduce a failure, while keeping sensitive content out of routine telemetry unless it is deliberately required and controlled.

Include evaluation and human review in the cost calculation. A cheaper inference path can be more expensive overall if it causes additional review or repeat work. The business owner should see those costs alongside the quality result.

Keep the release decision reversible

A new dependency should have a fallback. For grounding, retain a known-good source configuration. For a model, retain the prior deployment while testing compatibility. For a workflow change, define how unfinished tasks are identified and completed without duplicate action.

Give the pilot an explicit exit condition. Examples include a material correctness improvement on a priority task class, a reduction in total handling effort, or recovery that meets an agreed operational objective. These are proposed acceptance categories, not claimed product outcomes.

If the experiment is inconclusive, keep the existing production path and revise the test. A release announcement does not create an obligation to adopt the feature immediately.

Put ownership beside each investment

The data owner should approve source quality and freshness. The application team should own workflow correctness. The platform team should own deployment and telemetry. Security and identity teams should verify access boundaries. The business sponsor should decide what improvement justifies the operating cost.

Ask each owner what evidence would make them comfortable with a wider release. Resolve incompatible expectations before the pilot starts. Otherwise a technically successful experiment can reach review with no agreed definition of production readiness.

For the next planning cycle, fund one constrained experiment with a baseline, accountable owners, and a rollback path. Foundry’s broader platform creates more ways to improve an application. The discipline is choosing the capability that addresses a demonstrated problem and proving its value before expanding.

References

Microsoft: Foundry Build Edition, June 2, 2026

Microsoft: Build and run agents at scale, June 2, 2026

Microsoft: Memory reliability and management, June 3, 2026

Microsoft: Observability and agent ROI, June 3, 2026

A returning customer says, “Use my usual delivery arrangement.” Remembering the preference could save a conversation. Remembering a previous customer’s arrangement could create a privacy incident. Remembering an outdated instruction could send an order to the wrong place.

Long-term memory makes an AI assistant more useful only when the application can distinguish a preference, a current fact, an old fact, and an authorization decision. The first implementation task is to define what each category means for the business.

Start with the feature that exists

Microsoft introduced memory in Foundry Agent Service in public preview in November 2025. The announcement describes extracting and retrieving user information and conversation summaries across interactions. That offers a managed foundation for continuity, with preview terms that teams need to evaluate before adopting it.

Keep the scope of that announcement clear. This design uses the documented memory concept and application controls; it does not assume that every retention, correction, or identity requirement is automatically solved by enabling memory.

The broader Agent Framework architecture provides orchestration and session building blocks. A workflow checkpoint, a conversation history, and a remembered customer preference serve different purposes. Treating them as one unstructured store makes retention and testing unnecessarily difficult.

The research argues for explicit evaluation

LongMemEval, introduced in 2024, uses 500 curated questions to examine long-term conversational memory. Its abstract reports an approximately 30% accuracy drop across sustained interactions in evaluated commercial assistants and long-context models. The benchmark tests extraction, cross-session reasoning, time, updates, and abstention. These findings describe its tested systems and conditions, not Foundry performance.

The older Lost in the Middle study also found that access to a long context did not ensure reliable use of relevant information, particularly when its position changed. A larger input window is therefore an option to evaluate, not proof that a memory problem has disappeared.

For an enterprise architect, the implication is practical. Test what the assistant recalls, when the remembered fact was true, and when it should decline to answer. Storage success alone is a weak acceptance criterion.

Separate business records from conversational memory

Imagine a hypothetical distributor using a support agent for repeat customers. The order-management system owns shipping addresses and account permissions. The memory layer might retain a preference for concise status summaries or a usual delivery-time discussion. It should not become an alternative system of record for the customer’s authorized receiving address.

For a new order, retrieve the current address from the authoritative system and ask for confirmation when the workflow requires it. The remembered preference can make the conversation smoother without bypassing the transaction’s normal validation.

This distinction also helps with data quality. If a customer says an address changed, the assistant can propose the appropriate account-update process. It should not silently write a conflicting address into memory and later present that as verified operational data.

Bind scope to authenticated identity

Derive memory scope from the application’s authenticated tenant and user identifiers. Never allow a natural-language request such as “use the profile for user123” to select a different person’s memory.

Decide how shared accounts work before launching. An account-level purchasing preference may be visible to a team, while a person’s accessibility preference should remain personal. Those are different scopes with different access rules.

Test isolation at retrieval and update boundaries. A successful test proves both that another user’s facts stay hidden and that the current user cannot overwrite them indirectly. Include tenant changes, reassigned accounts, and recycled application identifiers in the test plan.

Preserve origin and time

A useful memory item needs enough provenance to explain why it exists. My recommended record includes its source interaction, time recorded, applicable scope, fact type, and any validity period. Avoid retaining sensitive raw conversation content merely because it is convenient.

Represent corrections explicitly. If a customer first prefers phone calls and later requests email, retrieval should prioritize the current preference while respecting the chosen retention policy. A vague summary containing both statements leaves the model to guess which one governs.

Some memories should expire because the business meaning expires. A travel preference for a particular week is not a lifelong customer attribute. Where the chosen preview interface lacks a required lifecycle control, implement that control in the application or postpone that memory category.

Let users correct the assistant

Provide a practical way to inspect or challenge remembered information. “That is no longer correct” should trigger a defined correction path. The agent should acknowledge the change without promising deletion across every system unless the application has completed that operation.

Deletion needs its own verification. Check that removed information no longer appears through direct lookup, semantic retrieval, derived summaries, or copied application caches within the scope you control. Document any separately retained audit record and its purpose.

A support team also needs a way to investigate a disputed memory without unrestricted access to private conversations. Use narrowly scoped diagnostics and log metadata rather than exposing all remembered content by default.

Build a memory-specific test set

Create multi-session cases with known facts, deliberate corrections, similar customers, and questions with no answer in the history. Include temporal questions such as which instruction applied before a change.

Compare memory enabled and disabled on the same task set. Score correct recall, stale-fact use, unsupported recall, cross-user exposure, and appropriate abstention separately. An overall average can hide a serious isolation defect behind better preference recall.

Keep the retrieved memory items with the evaluation evidence when permitted. That lets engineers distinguish extraction failure from retrieval failure and reasoning failure. Changing the model when the wrong memory was retrieved may make the symptoms harder to reproduce.

Decide whether continuity is worth its cost

Measure avoided clarification turns and successful task completion alongside retrieval latency, storage, model calls, correction effort, and privacy operations. Use the business task as the denominator rather than the number of memories stored.

A sensible pilot begins with low-risk preferences in one authenticated application. Expand the scope after demonstrating useful recall, reliable correction, and effective separation between users.

The strongest memory design is selective. It remembers information with a clear purpose, retrieves it within the right identity boundary, and knows when a fresh business record or another question is more reliable.

References

Microsoft: Memory in Foundry Agent Service, November 25, 2025

Microsoft: Agent Framework architecture, February 19, 2026

Wu and colleagues: LongMemEval, 2024

Liu and colleagues: Lost in the Middle, 2023

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.

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.

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