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
   
   Loading…

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

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

   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