A dependency upgrade passes compilation and the agent answers a test question. The release reaches production, where a browser client fails to load, a background response resumes incorrectly, or telemetry costs change. The package installed successfully; the application contract still changed.
Foundry upgrades deserve the same release discipline as database clients and application frameworks, with an additional check for changes in model behaviour. Evaluate compatibility and task quality together, while keeping their causes distinguishable.
Upgrade a recorded configuration
Microsoft’s September roundup, published October 15 documents language-specific SDK changes rather than one universal upgrade path. For example, it identifies JavaScript browser-bundling fixes in version 2.7.1 and a .NET Projects line that remained beta. A stable package in one language does not establish equivalent feature maturity in another.
The same roundup calls out runtime defaults, including 100% default Azure Monitor trace sampling in AgentServer Core’s discussed release. That is a configuration detail, not a performance statistic. Review it against expected traffic, privacy requirements, and telemetry budget before rollout.
Create a baseline record containing package versions, runtime image, protocol, model deployment, prompts, tools, retrieval configuration, and policies. Include indirect dependencies and the deployment configuration used by the running service. A lockfile alone may not capture all of them.
Change one major dimension at a time where practical. If the immediate goal is to fix a client issue, hold the model configuration constant. If the goal is to compare a model, retain the known-good SDK path. This makes failures easier to attribute.
Test the interfaces the application actually uses
Build a compatibility matrix around real application paths: authentication, resource creation, streaming, tool invocation, structured output, file handling, and cancellation. Do not require every possible feature to pass if the application does not use it.
Run the client in its actual environment. A server-side test does not establish that browser bundling works. A local interactive credential does not establish that the deployed workload identity has the intended permission.
Inspect stream handling as a protocol, not just a text result. Confirm event order, partial output, tool events, final status, and error handling. A user interface that shows generated text but misses a terminal failure can misrepresent an unfinished operation as completed.
The September Agent Framework article explains that recovery can replay interrupted steps and that external effects still require idempotency. Verify the application’s write behaviour after interruption. Recovery support should not become a reason to remove reconciliation logic.
For a hypothetical procurement assistant, test a timeout after submitting a purchase request. The recovered agent should query the existing operation and return its confirmed state. Creating a duplicate request is a compatibility failure even if the new SDK handles reconnection exactly as documented.
Evaluate the business behaviour separately
Microsoft’s model lifecycle guide recommends comparing candidate configurations against workload-specific baselines. Use the same source snapshot, task inputs, and evaluation criteria for the candidate and current release.
Include representative ordinary work, known incidents, ambiguous requests, and cases that require refusal or escalation. Review correctness, evidence, policy compliance, tool arguments, and final business state. Keep important task classes separate in the report.
The Model Router evaluation guide provides a useful quality, cost, and latency comparison approach. If the application uses routing, record the selected-model distribution where available. Otherwise a change in routing behaviour can look like an SDK effect.
For model-based judging, retain the evaluator configuration and calibrate it against domain review. A change in evaluator behaviour should not silently redefine the release gate. Deterministic checks should handle schema validity, authorization boundaries, and verifiable transaction state.
Do not interpret a small clean test as proof that rare failures disappeared. As an illustrative calculation, if 300 independent, representative trials show zero occurrences of a particular failure, the one-sided 95% binomial upper bound is approximately 0.994%: one minus 0.05 raised to the power of one divided by 300. This is a statistical illustration, not a measured Foundry result.
The assumptions matter. Closely related prompts are not necessarily independent, and a convenient test set may not represent production. Use the calculation to explain uncertainty, not to assign a misleading assurance percentage to the whole application.
Stage the release around observable outcomes
Start in a non-production environment with synthetic or permitted test data. Verify migrations and configuration changes before sending production requests.
Use shadow evaluation only where its access and data handling are authorized. Keep side-effecting tools disabled or replaced with controlled test equivalents. A shadow run must not submit a second purchase request or send duplicate communication.
For a limited live rollout, monitor accepted tasks, review corrections, latency, tool failures, repeated actions, and total cost. Compare with the baseline over a meaningful task mix rather than using only request volume.
Set stop conditions before deployment. A wrong-authority action, repeated external write, or critical task regression may justify immediate containment even if average quality improved. The business owner should define those priorities with the application team.
Make rollback include unfinished work
Keep the prior application configuration available while evaluating the candidate. Confirm that required model deployments and supporting resources remain usable under the intended rollback plan.
Identify how active sessions, persisted state, and unfinished background work behave across versions. A prior runtime may not understand state written by the candidate. Resolve that compatibility question before relying on rollback during an incident.
Separate restoring a version from repairing business effects. Reverting code does not cancel an order or retract a message. Use the operation log to reconcile tasks that crossed the release boundary.
The release record should explain the reason for upgrading, evidence of compatibility, quality and cost results, remaining limitations, and the recovery plan. Assign an owner to the decision and a date to revisit temporary exceptions.
A useful upgrade delivers a specific improvement without losing control of the application’s behaviour. Newer versions create opportunities. Reproducible tests, staged exposure, and business-state verification determine whether the change belongs in production.
References
Microsoft: September Foundry roundup, October 15, 2026
Microsoft: Agent Framework interactive and resilient execution updates, September 24, 2026
