Before Microsoft Build 2027, How to Validate Foundry Hosted Agents Deployment?

Your Agent deploys successfully, but the first hosted request fails or returns a response with missing context.

Fastest fix: validate the runtime contract, readiness, identity, session behavior, and a real endpoint call; deployment status alone is not acceptance.

This guide is for Python and .NET developers moving a local code-based Agent to Microsoft Foundry Hosted Agents.
Platform engineers can use it to check packaging, readiness, and release status.
If your team is preparing its Agent infrastructure ahead of Microsoft Build 2027, use the steps to test what you have now—not to assume future product changes.

Start with the decision: keep the app local or prepare it for hosting

Microsoft Foundry Hosted Agents can run code-based Agents as containerized applications on hosted infrastructure. The platform supplies hosting and a runtime contract; your team remains responsible for application logic, dependencies, protocol handling, and tests. Check the Microsoft Learn overview of Hosted Agents to confirm the documented hosting model and scope.

That separation matters. “The deployment completed” describes a platform operation. It does not prove that your Agent can handle real requests, maintain the session behavior you expect, or reach its dependencies.

Choose hosted deployment when the application can run within the documented containerized model and you can verify its dependencies and identity in that environment. Keep the app local while you resolve assumptions such as machine-specific files, interactive prompts, or credentials that are not available to the deployed workload. A move to hosted infrastructure does not automatically make those assumptions portable.

Dependencies that often hide until deployment

Before packaging, make an inventory of what the process needs at startup and during a request:

• Configuration values, secret references, and environment-specific settings.
• Files, templates, model assets, or local databases that the code expects to find.
• External services, network destinations, and authentication scopes.
• Background work, long-running operations, or interactive behavior that may not fit the request lifecycle.
• State held in process memory, temporary storage, or test fixtures.
• Python packages or .NET dependencies that must be included in the release artifact.

These are not claims about platform limits. They are application dependencies you should identify before choosing a deployment path. The Microsoft Learn quickstart for deploying your own code is a place to check the documented process for the current setup. Treat its commands and examples as documentation for that workflow, not as proof that your project uses the same SDK version or configuration.

Before deployment: make the local app prove its contract

A local test should check behavior, not merely whether the process starts. The Hosted Agent runtime contract defines the protocol expectations for a hosted application. Compare your implementation with the current contract before testing the deployment package.

First: check requests and responses

Send a representative request through the interface your app will use when hosted. Confirm that the app:

• Accepts the expected request structure.
• Handles required and optional input deliberately.
• Returns a response in the expected format.
• Reports unsupported or invalid input as an understandable error.
• Avoids leaking secrets, internal paths, or sensitive prompt content in its response.

Do not infer contract compliance from a successful call made through a local wrapper. Test the application boundary that the hosted runtime will use. Keep a sample valid request, its expected response, and a sample invalid request with the project. Those become repeatable release checks rather than notes that only one developer can interpret.

Then: test the behavior your app owns

Streaming, session state, and error handling are application behaviors to verify. An SDK or hosting service may support a mechanism, but that does not mean your application uses it correctly.

For streaming, confirm that the client receives the intended incremental output and that the app finishes or reports an error cleanly. For sessions, compare a fresh session with a continued one. Check which context should persist, which context should be reset, and what happens when the client supplies missing or stale session information. For errors, trigger a controlled failure and inspect the response the caller receives.

A passing readiness check shows that the app has reached the runtime’s expected ready state. It does not establish that a valid Agent request succeeds or that the returned session state is correct.

Prepare a small, reproducible test pack

Keep the following together with your release notes:

• The exact project revision and dependency lock information used for the package.
• The request examples and expected results you will use to validate the contract.
• A record of required configuration keys, without copying secret values into the test notes.
• The expected session behavior for a fresh conversation and a continued one.
• A known failure case and the response your caller should receive.

This is especially useful when the person who packaged the Agent is not the person who operates it. If a failure appears later, you can compare the deployed behavior with the same test pack instead of trying to reconstruct the original setup.

Package and release: compare the workflow stages

The current Hosted Agents deployment guide is the reference for the available release workflow and its current terminology. Follow the applicable path in that guide. Avoid copying an old command or SDK example simply because it worked in another project: deployment options, SDK status, and command details can change.

Treat each stage as a separate checkpoint. A package that builds does not prove that the hosted process starts. A release version that becomes available does not prove that the endpoint accepts your intended request. Keep the evidence connected to the release so you can tell which code and configuration you actually tested.

If the interface labels or commands in your notes no longer match the current documentation, stop and reconcile them before releasing. The official debugging guide can help you investigate a failure using the documented debugging workflow. Do not fill gaps in the process with assumed flags or copied SDK calls.

After release: verify identity, readiness, calls, and sessions

Run the same test pack against the deployed endpoint. Check more than the happy path. A successful request proves that one route worked under one set of conditions; it does not cover failure responses, identity boundaries, or session continuity.

Deployment acceptance checklist

• [ ] The release status is recorded, and it corresponds to the intended project revision.
• [ ] The hosted process reaches the readiness state expected by the current documentation.
• [ ] A valid request receives the expected response through the deployed endpoint.
• [ ] An invalid or unsupported request produces a controlled failure.
• [ ] The deployed identity can access the services the application actually requires.
• [ ] A fresh session behaves as designed.
• [ ] A continued session preserves or resets context as intended.
• [ ] Logs help you distinguish startup, request, dependency, and application errors.
• [ ] The team knows which release to restore if the acceptance checks fail.

Use separate tests for the readiness mechanism and the application endpoint. A passing readiness signal is not a substitute for a real request, and a successful request is not a substitute for checking the process state after startup. Confirm identity by testing an operation that requires the intended access. Do not treat the presence of a configured identity as proof that the target service authorizes it.

For observability, record which request was tested, whether it succeeded, and where you found the relevant diagnostic evidence. Microsoft documents hosted logging in its guide to monitoring Hosted Agent logs and provides a separate Agent tracing setup guide. These pages describe platform guidance; your team still needs to decide which application events and failure categories are useful to track.

First-week review: expand the pilot only when evidence supports it

During the first week after release, review failures and changes against a baseline from your acceptance tests. The measures below are operational signals for your team to define. They are not Microsoft performance targets or platform service-level promises.

Track failed calls by category: request rejected, app error, dependency access denied, timeout, or unexpected response. Note whether a retry occurred and whether it changed the outcome. Review session anomalies separately from ordinary request failures. Record each release change beside the observations so that a new failure can be compared with the version that introduced it.

Use these decision rules:

• Continue the pilot if valid calls, controlled failures, identity checks, and session tests match the expected results, and the team can find relevant logs.
• Pause expansion if readiness passes but application calls fail, if identity access is inconsistent, or if sessions behave differently from the documented application design.
• Roll back or restore the previous known release if a change causes a new failure that blocks a required workflow and the team cannot resolve it with a configuration correction.

These are team operating decisions, not automatic platform actions. Define who can approve a rollback, where the known-good release is recorded, and which test must pass before you resume expansion. If you need a general view of Hashvps services while comparing remote resource options, use the Hashvps service overview; it does not replace Foundry-specific deployment documentation.

FAQ: resolve the remaining deployment checks

What should you inspect before moving a local Agent into the hosted runtime?

Check dependencies, configuration, and protocol behavior before packaging. Make sure the app does not rely on a file, credential, or interactive step that exists only on a developer’s machine. Run valid, invalid, streaming, and session-related tests as applicable. Then compare the app boundary with the current runtime contract. This separates code problems from packaging or hosting problems.

How do you verify health checks and the request protocol independently?

Use one check to confirm the hosted process reaches the documented ready state, then send a real request through the documented contract. Save the response from each check. If readiness succeeds but a request fails, investigate request handling, identity, and dependencies rather than assuming that the health mechanism covers application behavior. The current contract and deployment guide should govern the exact implementation details.

What proves that session state is behaving correctly after deployment?

Test a new session and a continued session against the deployed endpoint. State what context should persist and what should not, then compare the actual responses with that expectation. Also inspect relevant application logs. A successful response by itself does not prove that conversation state was retained, isolated, or reset correctly; those outcomes depend on your application design and the way it handles session information.

Where should you look first when deployment or invocation fails?

Identify the earliest stage that failed: packaging, release creation, hosted startup, readiness, identity, or endpoint invocation. Use the deployment status and hosted logs to narrow the stage, then compare the request and response with the current runtime contract. Check external access and credentials separately. Before changing commands or SDK calls, confirm that the documentation you are following matches your selected deployment workflow.

Choose the right remote resource for the job

If your current approach is to keep an Agent test environment on a developer’s machine, it can create practical problems: the environment may not be available when teammates need it, local configuration can differ between people, and machine-bound credentials or files can make failures hard to reproduce. A remote Mac can be a better fit when you need a separately accessible development or test machine for Mac-specific build and validation work.

That does not make Mac rental a replacement for Microsoft Foundry Hosted Agents in production. Use Foundry for the hosted Agent deployment you are validating; consider Hashvps when you specifically need remote Mac resources for development or testing. First complete the checklist above, then compare the available options in the Hashvps package details if a remote Mac environment fits your workflow.