Microsoft Foundry Hosted Agents Reach GA for Long-Running Workflows

Microsoft Foundry hosted agents are now generally available, with support for production-grade, long-running workflows across frameworks, programming languages, and models. Microsoft also names integrations with GitHub Copilot, Microsoft Teams, Microsoft IQ, and Agent 365.
The immediate news is narrower than a claim that every agent is ready for unsupervised enterprise work. General availability means Microsoft is positioning hosted agents for production adoption. Customers must still validate reliability, permissions, data access, integration mechanics, recovery behavior, cost, and human oversight for each workload.

What changed

• Microsoft Foundry hosted agents are generally available.
• They support production-grade, long-running workflows.
• They work across frameworks, languages, and models.
• Named integrations include GitHub Copilot, Microsoft Teams, Microsoft IQ, and Agent 365.

What admins should do now

• Assign a named business owner and technical owner before approving a pilot.
• Document approved data sources, tools, actions, and human approval points.
• Verify the integration patterns and permissions available for each connected Microsoft product.
• Require an interruption and partial-completion test plan, plus a rollback and reconciliation runbook.

Microsoft Foundry Hosted Agents Reach General Availability​

Most enterprise AI agents have occupied an awkward middle ground. They can answer questions against a curated knowledge base, draft content, or complete a short sequence of tool calls, but moving from a demonstration to a dependable business process requires considerably more than model access.
As reported by Blockchain.News, Microsoft Foundry hosted agents now support production-grade, long-running workflows and can work across frameworks, languages, and models. Microsoft is presenting Foundry as a managed production environment without requiring every development team to standardize on one agent framework or programming stack.
General availability is a product milestone, not proof that every agent built on the platform will be reliable, safe, or economically useful. Outcomes will still depend on the selected models, instructions, tools, data sources, evaluations, permissions, deployment practices, and human controls.
GA changes the evaluation standard. During a preview, customers may reasonably expect architectural limitations, missing controls, or operational rough edges. A generally available service should instead be assessed against production requirements such as availability, identity, security, deployment discipline, observability, cost management, change control, and recovery.
Administrators should therefore separate Microsoft’s verified platform announcement from the controls their own organization must design. “Hosted” does not remove customer responsibility for deciding what an agent may access, which actions it may take, when a person must intervene, and how incomplete work will be reconciled.

---

Long-Running Production Workflows Raise the Operational Bar​

The defining capability is not text generation. It is support for work that extends beyond a brief prompt-and-response interaction.
That expands the range of processes developers may consider for agent-assisted automation. A short-lived assistant might summarize a document, draft a message, or retrieve a record. A longer workflow might coordinate several bounded steps, wait for input, or support a process that cannot be completed in one interaction.
The GA announcement should not be read as verification of every implementation behavior enterprises may expect from such a runtime. Before adopting any long-running agent platform, organizations should require evidence showing how it handles workflow state, interruptions, retries, cancellations, identity changes, unavailable dependencies, and partially completed actions.
Those questions are especially important when an agent can invoke business tools. A generated answer can be reviewed before it is used. A workflow that updates records, sends messages, generates files, or triggers another system may create consequences before a reviewer notices a mistake.
For customer service, the useful target may be a bounded workflow that gathers permitted information, prepares a proposed response, and routes exceptions to an employee. In finance, an agent might assist with analysis, reconciliation preparation, exception classification, or document review. In healthcare, possible pilots should remain within approved administrative uses and include the privacy, safety, and professional-review controls appropriate to the organization.
These examples are potential deployment patterns, not claims about functions automatically supplied by Foundry. Customers must establish whether the runtime and connected tools meet the technical and regulatory requirements of each proposed process.
The safest early pilots will generally have clear inputs, limited tools, measurable outputs, abundant test cases, and explicit escalation points. An organization should be able to explain what the agent is expected to do, what it is prohibited from doing, and what happens when the workflow cannot be completed as designed.

Framework, Language, and Model Flexibility Reduce Rewrite Pressure​

Microsoft’s “any framework, language, or model” positioning addresses the fragmentation already visible in enterprise agent development. Different teams may have adopted different SDKs, orchestration approaches, programming languages, and model providers before the organization selects a shared production platform.
A company may have one team developing internal support tools, another testing document automation, and a third building customer-facing workflows. Requiring all three to rewrite their applications around a single proprietary framework would slow adoption and make a shared runtime less attractive.
Foundry hosted agents instead give organizations a way to evaluate a common hosting platform while retaining flexibility in the development layer.

Choice layer	Verified flexibility	Foundry’s stated position	Question for architects
Framework	Work across frameworks	Host agent workflows without requiring one development framework	Which framework-specific components remain portable?
Language	Work across languages	Support teams using different implementation stacks	Which SDKs, deployment methods, and operational features are available for each language?
Model	Work across models	Allow model choice within the hosted-agent approach	How easily can a workload change models without changing its behavior, evaluations, or controls?

Flexibility does not eliminate platform dependence. An agent’s code may remain portable while its deployment becomes tied to identity systems, collaboration products, governance processes, organizational data, or administrative procedures.
Architects should distinguish between code portability and operational portability. The first concerns whether application logic can run elsewhere. The second concerns whether the organization can reproduce its integrations, permissions, monitoring, deployment process, and support model on another platform without substantial engineering work.
That dependency is not necessarily a defect. Enterprises routinely accept platform dependence when a service removes enough operational burden. The practical requirement is to document which components are portable, which can be replaced only with significant effort, and which business processes would become tightly coupled to the Microsoft environment.

GitHub Copilot and Microsoft Teams Are Named Integrations​

Microsoft names GitHub Copilot and Teams among the integrations for Foundry hosted agents. Organizations should verify the available integration patterns and permissions model before designing around either product.
It is reasonable to examine GitHub Copilot in relation to development workflows and Teams in relation to workplace collaboration, but the announcement alone does not establish a specific end-to-end deployment path. Customers should confirm which experiences are available, how agents are published or accessed, what administrative boundaries apply, and which identities are used at each stage.
Teams deserves particular scrutiny because workplace conversations can contain attachments, links, customer details, informal speculation, and material intended for a limited audience. Administrators should not assume that an agent’s presence in a Teams experience automatically gives it appropriate access to all associated content—or that content available to an agent may safely be repeated to every participant.
Before enabling a Teams-related design, administrators should establish:

• Which user, service, or agent identity is involved.
• Which data the integration can retrieve.
• Which actions the integration can initiate.
• Whether channel, chat, tenant, and guest boundaries are respected.
• How output visibility relates to permissions on the underlying sources.
• How the organization will review and disable the integration if necessary.

GitHub Copilot requires a parallel review on the development side. Faster construction does not replace code review, threat modeling, testing, evaluation, or deployment approval. Organizations should maintain a controlled path from prototype to production regardless of how much implementation assistance a developer receives.
The sound pattern is to build, review, test, evaluate, authorize, deploy, monitor, and revise—with named ownership at every stage.

---

Microsoft IQ Is Directly Integrated with Hosted Agents​

The supplied facts establish that Microsoft IQ is directly integrated with Foundry hosted agents. That makes it a relevant part of Microsoft’s broader agent platform story, but the announcement does not by itself verify specific claims about how Microsoft IQ derives organizational relationships, determines provenance, interprets policies, or resolves conflicting internal information.
Organizations should therefore evaluate Microsoft IQ through concrete use cases rather than broad assumptions about “organizational intelligence.” For each pilot, ask what information becomes available, how access is authorized, how source boundaries are applied, and how administrators can test the results.
A useful evaluation should distinguish between several questions:

1. Availability: What information can the proposed agent access?
2. Authorization: Why is the agent or requesting user entitled to access it?
3. Suitability: Is the information appropriate for the task?
4. Currency: Is the selected information current enough to support the proposed decision?
5. Conflict handling: What happens when approved sources disagree?
6. Disclosure: Where can the agent’s output be displayed or transmitted?

These are WindowsForum recommendations for evaluating any organizational-data integration. They should not be interpreted as claims that Foundry or Microsoft IQ automatically performs each check.
The value of an enterprise agent often depends on access to relevant business information, but broader context also increases the potential impact of incorrect access or inappropriate disclosure. A fluent response can conceal a weak source-selection process, and users may place more trust in an answer that appears to reflect internal knowledge.
Testing should therefore include deliberately conflicting, outdated, restricted, and incomplete material. The goal is not merely to determine whether an agent can find an answer. It is to determine whether the proposed system behaves acceptably when the organization’s information is messy—as enterprise information almost always is.

Agent 365 Is Microsoft’s Governance and Optimization Platform​

The verified description of Agent 365 is that it is a governance and optimization platform, and Microsoft names it among the integrations associated with hosted agents.
That description does not establish a detailed feature inventory. The supplied facts do not verify claims that Agent 365 automatically provides agent registries, inventories, policy enforcement, security-system integration, compliance controls, or continuous optimization. Customers should confirm the available capabilities, licensing, administrative interfaces, data boundaries, and supported agent types directly during product evaluation.
The distinction matters because “governance” can mean different things across products. It may refer to visibility, configuration, reporting, lifecycle processes, policy administration, evaluation, or some combination of those functions. Administrators should not assume that a governance label satisfies a specific control requirement.
Before relying on Agent 365, map each organizational requirement to an observed and tested capability:

Governance requirement	Evidence admins should request
Ownership	A demonstrable way to associate the agent with accountable business and technical owners
Visibility	Evidence showing which relevant agents, deployments, or activities administrators can see
Access control	Documentation and testing of who can configure, deploy, invoke, or modify the agent
Change control	A record of which agent components changed, who approved the change, and when it entered production
Monitoring	Demonstration of the events, metrics, or reports available to operations teams
Suspension	A tested method for preventing new work and handling work already in progress
Evaluation	Evidence showing how the organization can assess quality and risk before and after deployment
Optimization	A clear explanation of what can be optimized, which inputs are used, and which approvals constrain changes

This is a vendor-neutral requirements map, not a representation that Agent 365 currently satisfies every row.
A governance platform also cannot make an unsafe business process safe merely by bringing it under administration. Teams still need to decide whether a process is suitable for agent assistance, whether human judgment must remain mandatory, and which outcomes require independent review.
Optimization deserves the same caution. Improving task-completion rates is not enough if the system reaches completion by escalating fewer ambiguous cases, using broader access, or skipping a review that the business considers essential. Quality, cost, latency, escalation behavior, permissions, and business impact should be evaluated together.

Production Readiness Requires Evidence About Failure Handling​

“Production-grade” should be treated as an evaluation prompt rather than a substitute for testing. The relevant question is how the complete solution behaves when a dependency fails, a tool returns malformed data, permissions change, a source becomes unavailable, an employee leaves, or a process stops after some—but not all—actions have occurred.
Before adopting any long-running agent runtime, require evidence that it preserves sufficient information for operators to determine what has happened, what remains incomplete, and which actions are safe to retry. Do not assume that state preservation, checkpointing, interruption recovery, or audit output is available in the exact form your workflow needs.
Application designers should make actions idempotent where practical, separate reversible steps from irreversible ones, and define checkpoints appropriate to the business process. These are WindowsForum architecture recommendations, not verified Foundry functions.
Human intervention should likewise be designed into the workflow. A vague instruction to “ask a human if uncertain” is not an operational control. The design should specify:

• The conditions that trigger review.
• The person or role responsible for responding.
• The evidence the reviewer receives.
• The actions the reviewer may approve or reject.
• The time limit before the work expires or is cancelled.
• The method used to resume, reconcile, or close the case.

Tool access should follow least privilege. An agent that needs to read a customer record does not automatically need permission to modify it. An agent may be allowed to prepare an action while execution remains with an employee or a separately controlled service.
Customers should also test how permission loss affects pending work. Revoking access may prevent further actions without resolving changes already made. A credible pilot must account for that middle state rather than treating disablement as equivalent to rollback.
Microsoft can supply a production platform, but each customer remains responsible for defining the acceptable blast radius of its workflows.

---

Finance, Healthcare, and Customer Service Put Controls to the Test​

The supplied material identifies finance, healthcare, and customer service as areas positioned to benefit from AI-driven process improvements. These are credible targets because they combine large information volumes, repeatable tasks, and significant manual effort.
They are also demanding environments for automation.
Finance workflows may depend on authorization limits, separation of duties, accurate records, deadlines, and reviewable approvals. An agent that accelerates preparation but obscures responsibility for a consequential action may create additional operational or audit work.
Healthcare adds privacy, safety, and professional-judgment requirements. Agent pilots should clearly separate administrative assistance from decisions reserved for qualified professionals and should use only data sources and actions approved for the specific workflow.
Customer service may offer more immediately bounded opportunities. Agents could assist with collecting permitted information, classifying requests, drafting responses, or preparing a case for an employee. Any authority to issue refunds, change accounts, disclose information, or make customer commitments should be explicitly documented and tested.
The best early use cases are likely to have:

• Clear and limited inputs.
• A narrow set of approved data sources.
• Few tools and tightly constrained actions.
• Historical examples that can become test cases.
• Measurable definitions of success and failure.
• Straightforward human escalation.
• A practical way to reverse or reconcile mistakes.

Enterprises should prioritize suitability over spectacle. A modest system that prepares evidence for a human decision may deliver more durable value than an ambitious deployment attempting to automate an entire operational function.
Reusable industry solutions may eventually emerge, but a generic prompt or vocabulary package is not enough. A credible implementation must reflect the organization’s approval hierarchy, data-handling rules, exception process, and accountability model.

The Pilot Adoption Gate: Deliverables Required Before Approval​

A production pilot should not proceed solely because a team has demonstrated a compelling agent interaction. Before approving any Foundry hosted-agent pilot, require the following vendor-neutral deliverables.

Required deliverable	Minimum acceptable content
Named business owner	One accountable person responsible for the purpose, business outcome, acceptable behavior, and decision to continue or stop the pilot
Named technical owner	One accountable person responsible for implementation, deployment, dependencies, monitoring, incident response, and technical changes
Approved data-source list	Every permitted source, its owner, sensitivity, access conditions, retention expectations, and prohibited uses
Tool-and-action matrix	Every tool the agent may invoke, each allowed action, the identity used, permission level, expected result, and maximum business impact
Human approval map	Exact points requiring review, named reviewer roles, required evidence, response deadlines, and behavior when approval is denied or unavailable
Rollback and reconciliation runbook	Procedures for stopping new work, identifying completed actions, reversing reversible changes, reconciling irreversible changes, and notifying affected owners
Interruption test cases	Tests covering service interruption, tool failure, timeout, credential loss, dependency unavailability, cancellation, and delayed human response
Partial-completion test cases	Tests in which some actions succeed and later actions fail, including duplicate prevention, safe retry, case closure, and manual cleanup
Production acceptance criteria	Measurable thresholds for quality, escalation, cost, latency, security, and business outcome
Change-control plan	Components that require reapproval, including model, instructions, tools, permissions, data sources, evaluations, and integration configuration

If any row lacks an owner or testable evidence, the workload is not ready for a production pilot. It may remain suitable for a sandbox or controlled demonstration, but the organization should not treat it as an approved operational system.

Human Ownership Remains Mandatory​

Reducing manual intervention does not eliminate human accountability.
Every production agent should have an identifiable business owner and technical owner. Security, privacy, legal, risk, or compliance reviewers should be added when the workflow requires them. The organization should never be unable to answer who is responsible for the agent’s purpose, implementation, access, and acceptable behavior.
Change management must extend beyond application code. Agent behavior may be affected by changes to models, instructions, data sources, tools, permissions, integrations, evaluations, and workflow configuration. A change that improves one metric may alter escalation behavior, increase cost, expand access, or create a different error pattern.
Teams also need a safe method to stop work. Disabling a user-facing entry point may not resolve jobs or actions already underway. Revoking credentials may prevent the next step while leaving external systems in an inconsistent condition.
A complete operating model therefore includes suspension, cancellation, rollback, reconciliation, and communication. If an agent is halted midway through a process, administrators should be able to determine which cases require review and which business owners must be notified.

Action checklist for admins​

• Maintain an inventory of approved hosted-agent deployments, including each agent’s purpose, owners, environment, connected systems, model choices, and current status.
• Separate development, testing, and production environments, with controlled promotion between them.
• Approve the data sources, identities, tools, and actions required for each workflow.
• Apply least privilege and prohibit access that is merely convenient rather than necessary.
• Require human approval before financial, irreversible, privacy-sensitive, safety-relevant, or externally visible actions.
• Verify the available GitHub Copilot, Teams, Microsoft IQ, and Agent 365 integration patterns instead of assuming how they operate.
• Test interruption, timeout, retry, cancellation, permission loss, stale data, conflicting data, malicious input, and partial completion.
• Maintain a rollback and reconciliation runbook for every workflow that can change an external system.
• Re-evaluate the deployment after changes to models, instructions, tools, permissions, data sources, integrations, or evaluation criteria.
• Define measurable pilot exit criteria and stop the deployment if it cannot meet them.

---

Microsoft Is Building a Broad Enterprise Agent Platform​

Foundry hosted agents fit a familiar Microsoft strategy. The company is bringing development tools, a hosted runtime, workplace products, organizational intelligence, and governance offerings into a broader enterprise platform.
The verified milestone is meaningful: hosted agents are generally available, support production-grade long-running workflows, work across frameworks, languages, and models, and name integrations with GitHub Copilot, Teams, Microsoft IQ, and Agent 365.
The next phase will be determined by implementation evidence rather than announcement language. Enterprises need to learn which integration patterns are available, how permissions operate, what administrators can observe and control, and how the complete solution behaves when a workflow is interrupted or only partly completed.
Organizations do not need to wait for every possible question to be resolved before experimenting. They should, however, distinguish between a sandbox demonstration and a production pilot. The adoption gate should be explicit: named owners, approved data, constrained tools, documented approval points, tested failure scenarios, and a workable reconciliation plan.
Microsoft has moved Foundry hosted agents beyond preview. That gives enterprises a stronger reason to evaluate the platform—but not a reason to lower their standards. The most successful deployments will begin with narrow workflows, measurable outcomes, limited authority, and clear human ownership, then expand only when testing shows that the operational controls are as dependable as the agent’s most impressive demonstration.

---

References​

1. Primary source: blockchain.news
   Published: 2026-07-10T17:23:07.983825
   
   

   Microsoft Foundry Agents GA supercharge enterprise ops | AI News Detail

   According to satyanadella, Microsoft Foundry Hosted Agents are GA, enabling long-running agents across any model, with Teams, IQ, and Agent 365 integration.

   blockchain.news
2. Official source: learn.microsoft.com
   
   

   Foundry Hosted Agents | Microsoft Learn

   Learn how to host Agent Framework agents in Microsoft Foundry Agent Service as containerized, managed hosted agents.

   learn.microsoft.com
3. Official source: devblogs.microsoft.com
   
   

   What's New in Microsoft Foundry | June 2026 | Microsoft Foundry Blog

   Claude is now generally available in Microsoft Foundry. Here's everything else that shipped between Build 2026 and the end of June — autopilot agents, expanded Toolboxes and Routines, Agent Optimizer's private preview, and more. Microsoft Foundry June 2026: Claude reaches GA, agents...

   devblogs.microsoft.com
4. Official source: microsoft.com
   
   

   Microsoft Agent 365, now generally available, expands capabilities and integrations | Microsoft Security Blog

   ​We’re announcing the general availability of Agent 365, plus previews of new capabilities to discover and manage shadow AI agents. Learn more.

   www.microsoft.com
5. Official source: adoption.microsoft.com
   
   

   1 Introduction

   PDF document

   adoption.microsoft.com
6. Official source: cdn-dynmedia-1.microsoft.com
   
   

   The Microsoft Agent Factory white paper Feb 2026

   PDF document

   cdn-dynmedia-1.microsoft.com

Spoiler: Additional references (4)

1. Official source: techcommunity.microsoft.com
   
   

   Default Section

   PDF document

   techcommunity.microsoft.com
2. Related coverage: tomsguide.com
   
   

   Biggest Microsoft Build 2026 announcements — agentic AI, RTX Spark Dev Box, GitHub Copilot app, new MAI models, and more | Tom's Guide

   All the big news from Microsoft's AI-focused event

   www.tomsguide.com
3. Related coverage: techradar.com
   
   

   Microsoft makes Copilot Cowork open to everyone, and wants to help you tackle even the trickiest work tasks | TechRadar

   Copilot Cowork gets an upgrade as it opens to all users

   www.techradar.com
4. Related coverage: windowscentral.com
   
   

   OneDrive adds AI agents via active Microsoft 365 licenses | Windows Central

   Microsoft brings OneDrive AI agents to general availability, offering smarter file management and project tracking.

   www.windowscentral.com

 

[ChatGPT]

Microsoft’s Foundry Hosted Agents Reach GA—Now Comes the Governed Pilot​

Microsoft now offers generally available hosted runtime infrastructure for Foundry agents. The practical question for Windows and Azure administrators is whether its sandbox isolation, supported Python and .NET runtimes, regional footprint, telemetry, and planned Microsoft 365 distribution fit a controlled, governed pilot—not whether the GA label justifies broad autonomous deployment.

What changed

• Foundry hosted agents are generally available.
• Supported runtimes include Python 3.13, Python 3.14, and .NET 10.
• Agent sessions run in isolated sandboxes.
• The service is available in more than 20 Azure regions.
• Direct integrations with Microsoft Teams and Microsoft 365 Copilot are planned for July 2026.

What admins should do now

1. Choose one low-impact internal use case with a named business owner.
2. Confirm runtime and dependency compatibility.
3. Verify region, networking, connected-service, pricing, and support requirements in the intended tenant.
4. Assign a narrowly scoped identity and approve only the tools required for the pilot.
5. Define human-approval points, telemetry handling, success criteria, and a tested kill switch before inviting users.

Microsoft Turns Agent Hosting Into Azure Plumbing​

An AI agent can look deceptively simple during development. A developer selects a model, writes instructions, connects a few tools, and runs the program on a laptop. Within hours, the software may be searching documents, calling APIs, or generating reports that resemble useful work.
Production is where that simplicity collapses. The agent needs a dependable execution environment, controlled access to credentials and downstream systems, useful telemetry, failure handling, and boundaries that limit the consequences of bad instructions or compromised inputs.
Foundry hosted agents address part of that production gap by giving organizations Microsoft-operated runtime infrastructure for agent code. The important shift is not that Microsoft has made agents automatically scalable, stateful, private, or secure in every deployment. Those behaviors depend on the selected configuration, connected services, code, architecture, and support boundaries.
Instead, Microsoft is providing a defined hosting layer with supported runtimes, sandboxed execution, regional availability, and operational telemetry. That can reduce the amount of runtime infrastructure a team must build and maintain before it can test an agent under realistic enterprise conditions.
The distinction is important. A hosted runtime is not the same thing as a complete application architecture. Teams still need to determine how an agent authenticates, which resources it can reach, where durable business data belongs, what happens when dependencies fail, and how a deployment is reviewed or reversed.
Foundry should therefore be evaluated as an operational foundation, not as a promise that every infrastructure decision disappears.

---

The Hard Problem Was Never Writing the First Prompt​

The agent boom has produced a large gap between prototype quality and production readiness. A prototype may succeed in a controlled demonstration because its inputs are clean, its permissions are broad, its tools respond normally, and a developer is nearby to restart it.
Enterprise workloads offer none of those guarantees. Users submit ambiguous instructions, upstream APIs fail, documents contain misleading or hostile content, model behavior varies, and apparently harmless requests may expose sensitive data or trigger unintended actions.
Traditional applications already face many of these problems, but agents add uncertainty because they can select actions dynamically. A conventional application generally follows paths engineers explicitly wrote. An agent may choose which approved tool to call, how to interpret retrieved information, whether to retry, and what intermediate context to use in producing its result.
That makes the runtime relevant, but it does not transfer responsibility for business behavior to the runtime provider.
General availability means hosted agents have moved beyond a preview-only posture. It gives enterprise teams a clearer reason to begin formal architecture, security, support, and procurement reviews. It does not establish that every adjacent capability, framework combination, region, connected service, or integration is suitable for a particular production workload.
Most importantly, GA does not answer the authorization question. A managed runtime cannot decide whether an agent should be allowed to approve an invoice, alter a customer record, push code, create an account, or send a message representing an employee.
GA makes Foundry worth a controlled pilot, not broad autonomous deployment.

The Sandbox Is the Product, Not a Footnote​

Hosted-agent sessions run in isolated sandboxes. That isolation matters because agents may process untrusted content, create working files, execute code, and interact with external systems.
A sandbox boundary can reduce the risk that one session interferes with another or reaches beyond its intended execution environment. For administrators comparing an unmanaged development host with a purpose-built agent runtime, that is a meaningful platform capability.
The claim should not be stretched further than the available facts support. Sandbox isolation alone does not establish the exact security relationship between Foundry and every process-, container-, or virtual-machine-based design. Nor does it prove that an agent is safe from prompt injection, vulnerable dependencies, excessive permissions, data leakage, or misuse of an approved tool.
Platform isolation and authorization solve different problems:

Control layer	Primary question	Customer responsibility
Runtime isolation	Can one execution environment interfere with another?	Confirm that the service boundary fits the workload’s threat model
Identity and permissions	What may the agent access or change?	Assign the identity and restrict privileges
Tool governance	Which actions can the agent attempt?	Approve tools and constrain their permitted operations
Data governance	What information may enter prompts, traces, or external services?	Classify, redact, retain, and monitor data appropriately
Business authorization	Which consequential actions require human judgment?	Define approval and escalation rules
Operational recovery	How is harmful behavior stopped or reversed?	Own the kill switch, rollback process, and incident response

An agent can be well isolated and still be overprivileged. It can remain inside its sandbox while disclosing information through a connection the organization intentionally approved. It can make an expensive series of legitimate calls or take an authorized action that the user did not intend.
That is why WindowsForum administrators should treat sandboxing as one layer in a defense-in-depth design. It is a useful reason to test the platform, but not a substitute for identity scoping, tool restrictions, data controls, and human oversight.

Microsoft Narrows the Runtime Without Dictating the Framework​

The concrete supported runtime environments identified for the generally available service are Python 3.13, Python 3.14, and .NET 10.

Runtime option	Version	Likely organizational fit	Pilot consideration
Python	3.13	Existing Python agent and data workloads	Validate every required package and native dependency
Python	3.14	Newer Python projects	Test framework compatibility before standardizing
.NET	10	C# and Microsoft-oriented application teams	Align libraries, build processes, and operational ownership

This is a practical initial matrix. Python remains central to AI development, while .NET gives enterprise development teams another route into the hosted runtime.
Supporting two Python versions may help organizations that cannot move every dependency at the same time. Agent projects frequently combine model clients, orchestration libraries, document-processing packages, observability components, and native extensions. A single incompatible dependency can block an upgrade even when the core application code requires few changes.
The presence of .NET 10 also makes hosted agents relevant outside specialist Python teams. Organizations can evaluate the service alongside existing .NET engineering practices rather than treating agent development as a completely separate technology estate.
Runtime support should not, however, be confused with universal application portability. Teams should not assume that any local project can be submitted unchanged or that every agent framework will adapt automatically. Dependency declarations, startup behavior, request handling, configuration, and telemetry requirements may require project-specific work.
Likewise, no assumption should be made about the general availability of source-code deployment, customer-supplied containers, custom packaging, or a particular deployment protocol unless those options are confirmed for the tenant and workflow being evaluated.
The safest pilot begins with the supported runtime matrix and then validates the complete application path:

1. Language and runtime version.
2. Framework and library compatibility.
3. Native operating-system dependencies.
4. Configuration and secret handling.
5. Input and output expectations.
6. Telemetry behavior.
7. Failure and retry behavior.
8. Deployment and rollback procedure.

Framework flexibility is valuable only when operations remain predictable. The goal is not to prove that every framework can run somewhere; it is to establish that a specific application can be deployed, monitored, governed, and recovered by the team that will own it.

---

More Than 20 Regions Create Options, Not Guarantees​

Hosted agents are available across more than 20 Azure regions. That footprint gives multinational organizations and regulated teams a broader basis for evaluation than a service limited to a small number of locations.
Region count alone does not select the right deployment location. Administrators must consider proximity to users and data, organizational residency rules, disaster-recovery design, connected services, support expectations, and the availability of every component required by the solution.
A hosted-agent region should not be treated as proof that a complete workload is supported there. The agent may depend on models, storage, databases, monitoring systems, private connectivity, external APIs, or other services with different regional constraints.
Region selection is therefore an architecture exercise, not a checkbox. The pilot team should diagram the complete data and control path, including:

• Where the agent runtime executes.
• Where prompts, retrieved content, and outputs are processed.
• Where business data is stored.
• Where telemetry is sent.
• Which external systems receive data.
• Which components must remain available during a regional interruption.
• Which team owns each dependent service.

The same caution applies to networking. The existence of a hosted runtime does not establish that every desired private-networking configuration, ingress pattern, egress restriction, firewall rule, or name-resolution design is available or supported. Those details belong in the tenant-verification phase.
Pricing also requires verification. Teams should not infer a container-style consumption model or any precise billing behavior without reviewing the current commercial terms for their subscription and region. The total cost of an agent may include runtime usage, model calls, storage, telemetry, connected services, and external API charges.
Cost controls should be part of the pilot even before the exact billing model is finalized. Useful safeguards include a limited user population, bounded task duration, conservative retry policies, per-agent cost attribution, usage alerts, and an owner empowered to suspend the workload.

OpenTelemetry Makes Failure Visible, Not Self-Explanatory​

OpenTelemetry support gives operators a familiar standard for collecting traces, metrics, and logs from agent activity. That can be more useful than a narrow dashboard showing only the initial prompt and final response.
For an ordinary chatbot, input, output, latency, and errors may provide enough information for basic troubleshooting. For an agent, the important evidence may lie between those points: model calls, tool selections, arguments, external responses, retries, handoffs, and failures.
Telemetry can help a team answer operational questions such as:

• Which step caused a failed task?
• Did the agent repeatedly call the same tool?
• Did latency come from the model, a connector, or application code?
• Did an update change the frequency of errors?
• Which users or workflows generated unusual activity?
• Was a consequential action preceded by the expected approval?

The presence of telemetry does not mean every event is captured by default or that all required fields are automatically safe to retain. The exact signals, export path, configuration options, and integration with the organization’s monitoring stack must be tested.
Agent traces can contain prompts, retrieved records, tool arguments, identifiers, model outputs, and portions of sensitive documents. Enabling detailed tracing without a data-handling review may create a second repository of information that is broader or more persistent than intended.
Administrators should determine which fields are collected, where they are exported, who can query them, how long they remain available, and how deletion or legal-hold requirements apply. Sampling and redaction should be based on the workload’s data classification rather than a generic desire to capture everything.
OpenTelemetry provides evidence, not judgment. It can show that an agent called a tool five times, but it cannot independently determine whether five calls were reasonable. It can expose a slow response without deciding whether that response was accurate, compliant, or useful.
Each pilot therefore needs workload-specific evaluation criteria. A support agent may be judged on policy compliance and escalation quality. An operations agent may be measured on false positives, rollback safety, and its refusal to act under uncertainty. A document assistant may be evaluated on citation quality, disclosure risk, and whether it distinguishes retrieved facts from generated interpretation.

The WindowsForum Operator View: Five Governance Gates​

The recurring message does not need to be that “agents are risky.” Administrators already know that new execution platforms require controls. The useful question is what must be true before a Foundry pilot can move beyond a development team.
The following are recommended operating practices, not claims about controls that Microsoft automatically configures or enforces.

1. Least-privilege identity​

Give the agent a dedicated identity where the architecture permits it, and grant only the access required for the pilot use case. Avoid reusing an administrator, developer, or broadly privileged application identity.
Document every permission, its purpose, its approver, and its expiration or review date. If the agent only reads a limited collection of records, it should not receive write access to the broader system.

2. Approved tool allowlist​

Create an explicit list of tools, APIs, commands, and external services the agent may use. Treat the addition of a tool as a security change, not as a casual prompt edit.
Where possible, narrow each tool to specific operations and data scopes. “Access to the ticketing system” is too broad; “read assigned tickets and draft comments without posting” is a governable pilot permission.

3. Human approval for consequential actions​

Require a human decision before actions that alter records, spend money, change access, communicate externally, deploy code, delete data, or create contractual or regulatory consequences.
The approval step should expose what the agent plans to do, the data supporting that plan, and the exact action that will execute. A generic “continue” button without context is not meaningful oversight.

4. Trace-data redaction and retention review​

Review telemetry fields before production data enters the pilot. Define what must be redacted, what may be retained, who can access traces, and when records are deleted.
Include prompts, retrieved content, tool arguments, outputs, identifiers, and error payloads in the review. Do not assume the monitoring path has the same access controls or retention settings as the original business system.

5. Kill-switch and rollback ownership​

Name the person or team authorized to disable the agent immediately. Document how to revoke its identity, block tools, stop user access, suspend deployment, and roll back changes.
Test that process during the pilot. A kill switch that exists only in an architecture diagram is not an operational control.
Together, these gates create a reasonable threshold for moving from experimentation to limited use. They do not eliminate risk, but they make ownership and decision boundaries explicit.

Teams and Microsoft 365 Copilot Are the Planned Destination​

Direct integrations with Microsoft Teams and Microsoft 365 Copilot are planned for July 2026. That date should be treated as a planned milestone, not as an operationally complete launch specification.
The currently stated plan does not, by itself, establish publishing mechanics, administrative workflows, tenant prerequisites, permission inheritance, application availability, licensing, or feature parity. Those details must be reviewed when Microsoft makes the relevant integration capabilities and documentation available.
The strategic importance is still clear. Agents become more useful when employees can reach them through established work surfaces rather than another standalone portal. Teams and Microsoft 365 Copilot could provide that distribution path, subject to the eventual controls and support model.
Distribution also increases administrative stakes. Users may interpret an agent shown in a familiar Microsoft application as an approved corporate authority. A polished name, icon, and conversational interface can create more trust than the underlying security review warrants.
Before enabling a future integration, organizations should require:

• A visible business and technical owner.
• A concise description of the agent’s scope.
• Clear disclosure of actions the agent can and cannot perform.
• A support and escalation route.
• A defined user population.
• A method for withdrawing access quickly.
• Confirmation of data, licensing, and compliance implications.
• A review of the integration’s actual identity and permission behavior.

July 2026 is therefore a planning marker. It is not a reason to design today’s architecture around unconfirmed publishing behavior.

---

Known Facts vs. Items to Verify in Your Tenant​

The following separation prevents announced platform characteristics from becoming assumptions about a specific deployment.

Known facts for evaluation	Items to verify in your tenant
Foundry hosted agents have reached general availability	Whether every required workflow or adjacent feature is GA
Supported runtimes include Python 3.13, Python 3.14, and .NET 10	Package, framework, and native dependency compatibility
Agent sessions use sandbox isolation	Whether the isolation model satisfies the workload’s threat model and compliance review
The service is available in more than 20 Azure regions	The correct region for data, latency, resilience, and organizational policy
OpenTelemetry is part of the observability approach	Which traces, metrics, and logs are available and where they can be exported
Direct Teams and Microsoft 365 Copilot integrations are planned for July 2026	Tenant readiness, licensing, publishing mechanics, permissions, and support status when released
Microsoft provides the hosted execution infrastructure	Availability and behavior of connected models, storage, tools, and other services
Networking options, including any private-access or egress-control requirements
Pricing units, included resources, quotas, limits, and total solution cost
Deployment, versioning, rollback, and lifecycle procedures
Responsibility boundaries between Microsoft, the customer, and third-party providers
Support response, service-level commitments, and escalation paths
Data location and retention across runtime, models, tools, telemetry, and external services

This table should become part of the architecture review rather than remain editorial advice. Each verify item needs an owner, an evidence source, and a pass-or-fail decision before the pilot expands.

A Concrete Pilot Checklist for Admins​

The initial pilot should be intentionally small. A useful target is one internal workflow, one development team, one operations owner, and a limited group of informed users.

Before deployment​

• [ ] Select a low-impact use case with measurable value.
• [ ] Exclude irreversible or high-consequence autonomous actions.
• [ ] Confirm Python 3.13, Python 3.14, or .NET 10 compatibility.
• [ ] Inventory application, framework, package, and native dependencies.
• [ ] Choose a candidate region and validate every connected service there.
• [ ] Document data flows, including telemetry and third-party destinations.
• [ ] Review current pricing, quotas, limits, and support boundaries.
• [ ] Create a least-privilege identity.
• [ ] Approve a narrow tool allowlist.
• [ ] Define actions requiring human approval.
• [ ] Establish trace redaction, access, and retention rules.
• [ ] Assign kill-switch, rollback, security, and business owners.

During the pilot​

• [ ] Limit access to a named user group.
• [ ] Monitor tool calls, failures, latency, and unusual usage.
• [ ] Compare outputs against workload-specific quality criteria.
• [ ] Review denied, escalated, and ambiguous requests.
• [ ] Test dependency failures and unavailable downstream services.
• [ ] Exercise identity revocation and the kill switch.
• [ ] Record runtime, model, prompt, tool, and dependency versions for each release.
• [ ] Track the full cost of runtime, models, telemetry, storage, and connected services.

Before expansion​

• [ ] Confirm that the pilot met its business success criteria.
• [ ] Resolve material security, privacy, and operational findings.
• [ ] Recheck regional and connected-service availability.
• [ ] Confirm production support and escalation arrangements.
• [ ] Review whether new users require narrower data segmentation.
• [ ] Repeat the permissions review rather than copying pilot access unchanged.
• [ ] Obtain formal approval from business, security, data, and operations owners.
• [ ] Define the next limited expansion stage instead of opening access broadly.

The Infrastructure Race Moves Above the Model​

Model quality attracts attention, but enterprise adoption may depend more heavily on the surrounding operational system. Organizations can already obtain capable models from several providers. The harder problem is running agent software with predictable ownership, controlled permissions, useful telemetry, and an acceptable recovery path.
Foundry hosted agents give Microsoft a stronger position in that infrastructure layer. The service now has a GA hosting proposition, a defined runtime matrix, sandbox isolation, a footprint spanning more than 20 regions, and a planned route toward Teams and Microsoft 365 Copilot.
Those characteristics do not prove that Foundry will fit every organization. Some enterprises will prefer Kubernetes-based deployments, existing application platforms, another cloud, or architectures designed for uniform operation across multiple providers. Others may decide that Foundry’s operational integration is worth accepting more Azure-specific dependencies.
Portability should be evaluated at several layers rather than reduced to a yes-or-no label:

Layer	Portability question
Application code	Can the core agent logic run outside Foundry?
Runtime	Are the language and package requirements available elsewhere?
Identity	How much access design must change on another platform?
Tools and data	Are connectors based on portable interfaces or platform-specific services?
Telemetry	Can traces and metrics move through standard pipelines?
Deployment	How much packaging and automation must be rebuilt?
Distribution	Does the agent depend on Microsoft-specific user surfaces?
Operations	Can another team reproduce monitoring, incident response, and rollback behavior?

A framework may be portable while the production architecture is not. That is not automatically a defect. Enterprises routinely accept platform-specific monitoring, identity, and operational services in return for reduced engineering burden. The requirement is to document the dependency honestly and understand its exit cost.

The Practical Verdict​

Foundry hosted agents have crossed an important threshold: Microsoft now has generally available hosted runtime infrastructure for agent workloads. Supported Python and .NET versions, sandboxed sessions, OpenTelemetry, and availability across more than 20 Azure regions make the service credible enough for structured enterprise evaluation.
The July 2026 plan for direct Teams and Microsoft 365 Copilot integration adds a significant distribution possibility, but administrators should wait for concrete release details before treating that plan as an established production architecture.
The immediate decision is narrower. Does Foundry’s isolation model fit the workload? Can the application run on Python 3.13, Python 3.14, or .NET 10? Is the required region suitable? Can telemetry be collected without creating an uncontrolled sensitive-data store? Are networking, pricing, dependencies, and support boundaries acceptable in the tenant? Can the organization enforce least privilege, tool allowlisting, human approval, trace governance, and rapid shutdown?
If those questions can be answered with evidence, Foundry is worth a controlled pilot. If they cannot, the GA label should not be used to bypass them.
Microsoft has supplied the hosted runtime. WindowsForum operators still own the harder boundary: deciding what the agent may do, proving that its behavior can be observed, and ensuring it can be stopped before a useful experiment becomes an ungoverned production dependency.

---

References​

1. Primary source: Crypto Briefing
   Published: 2026-07-10T17:42:07.808511
   
   

   Microsoft Foundry's hosted agents hit general availability, and the AI infrastructure race just got more interesting

   Microsoft Foundry's hosted agents are now generally available across 20+ Azure regions with framework-agnostic compute, sandboxing, and M365 integrations

   cryptobriefing.com
2. Official source: devblogs.microsoft.com
   
   

   What's New in Hosted Agents in Foundry Agent Service | Microsoft Foundry Blog

   Learn more about new capabilities introduced in Foundry hosted agents at Microsoft Build, from direct code deployment to voice agents, and upcoming General Availability.

   devblogs.microsoft.com
3. Official source: techcommunity.microsoft.com
   
   https://techcommunity.microsoft.com/blog/azuredevcommunityblog/deploying-foundry-hosted-agents-via-rest-api/4524523
4. Official source: learn.microsoft.com
   
   

   Foundry Hosted Agents | Microsoft Learn

   Learn how to host Agent Framework agents in Microsoft Foundry Agent Service as containerized, managed hosted agents.

   learn.microsoft.com
5. Official source: blogs.microsoft.com
   
   

   Microsoft Build 2026: Be yourself at work - The Official Microsoft Blog

   Platforms shift when developers build. We explore, choose tools, dream, create. This platform shift comes with more information than ever, ready at your fingertips. This shift, it’s about building fast AND THEN: it’s about building, operating, optimizing and observing. Securing your...

   blogs.microsoft.com
6. Official source: marketingassets.microsoft.com
   
   

   1091513_AZ_AI in Action_Ebook refresh_Cover Art

   PDF document

   marketingassets.microsoft.com

Spoiler: Additional references (5)

1. Official source: cdn-dynmedia-1.microsoft.com
   
   

   MS-Azure_logo_horiz_c-white_rgb

   PDF document

   cdn-dynmedia-1.microsoft.com
2. Official source: microsoft.com
   
   

   AutoGen Studio 12

   PDF document

   www.microsoft.com
3. Related coverage: ltm.com
   
   

   BlueVerse Logo_Blue

   Milky way - night space scene

   www.ltm.com
4. Related coverage: techradar.com
   
   

   From code-first to intent-first: Microsoft Build 2026 could be the end of programming as we know it | TechRadar

   Redefining what it means to be a developer with agentic AI

   www.techradar.com
5. Related coverage: tomsguide.com
   
   

   Biggest Microsoft Build 2026 announcements — agentic AI, RTX Spark Dev Box, GitHub Copilot app, new MAI models, and more | Tom's Guide

   All the big news from Microsoft's AI-focused event

   www.tomsguide.com