Microsoft makes Azure AI Foundry Agent Service generally available

Source record: Foundry Agent Service reached general availability

On May 29, 2025, Microsoft announced the general availability of Azure AI Foundry Agent Service in a post about software-company tooling introduced around Microsoft Build. The post described Azure AI Foundry as a unified platform of models, tools, and services, and said a unified API and SDK accompanied the Agent Service milestone. Microsoft described the service as a way for developers to orchestrate multi-agent workflows from their existing development environments.

General availability is a product lifecycle stage for the service. It gives teams a clearer vendor release record for the capability announced in May 2025. It does not replace application design decisions about models, instructions, data, tool access, evaluation, incident response, or the authority required for external effects. Those decisions remain part of every system built on a managed agent platform.

A unified platform still has separate ownership layers

A managed agent service can provide useful lifecycle components such as model access, tool integration, identity, observability, and hosting. The application team still owns the task contract: what the agent receives, which source records it may retrieve, which tools it may call, who can change its configuration, and how the team evaluates its output. Write these choices down as versioned application state rather than leaving them implicit in a portal configuration.

Ownership becomes especially important in multi-agent workflows. Each agent should have a named role, input schema, output schema, permitted tools, and handoff condition. A coordinator can route a task, but it should not hide which component produced a claim or requested an action. Clear interfaces make it possible to replace an agent, change a model, or investigate a failure without treating the entire workflow as one opaque unit.

Hypothetical example: triage a service incident

Imagine a hypothetical internal incident-triage workflow. One agent summarizes an alert from a monitored service, another retrieves approved runbook passages, and a third assembles a draft incident note. Each receives structured inputs and returns a typed result with citations. The workflow can create a draft in an incident workspace, while the on-call engineer remains the owner of diagnosis, escalation, and any corrective action.

If the monitoring data is missing, the runbook is outdated, or two agents disagree, the coordinator records the conflict and routes the task to the on-call engineer. It does not invent a resolution or call a remediation tool. This example shows the practical value of an orchestrated system: it gathers and structures evidence quickly while preserving the human decision point and the record needed for a later review.

Architecture: version the workflow around stable contracts

Treat an agent workflow as a versioned graph. Store the agent definitions, model selections, tool allowlists, input and output schemas, routing rules, evaluation fixtures, and release notes together. Every execution should identify the workflow version and the component versions it used. This allows a team to compare a changed result with the configuration that produced it, rather than guessing whether the cause was a model, tool, prompt, routing rule, or source-data update.

Design handoffs so they carry only the information needed by the next component. A research agent can pass a claim set and citations to a writer, while the writer does not receive credentials or broad access to the underlying data store. A state-changing tool should receive a validated execution request rather than unconstrained conversational text. This creates small, testable boundaries across a workflow that may otherwise look like one continuous agent session.

Failure modes: orchestration can multiply ambiguity

Multi-agent systems can amplify errors when one component presents a guess as established context for another. They can loop when a task is repeatedly delegated without a terminal condition, or race when multiple components try to update shared state. Tool calls can succeed after a coordinator has timed out, creating an outcome that differs from the workflow's visible status. These are distributed-systems concerns that need explicit state and recovery design.

Test duplicate delivery, expired credentials, model timeout, conflicting agent results, malformed handoffs, tool denial, and a partial external action. Define terminal states for completed, failed, cancelled, approval-required, and unknown outcomes. A trace should show the order of decisions and the inputs that justified each transition. This evidence helps a team diagnose a failure without assuming that an agent's final message reflects the actual state of every connected system.

Evaluation checklist: release a workflow with operational evidence

Evaluate the complete workflow against representative tasks, including normal execution, incomplete evidence, invalid handoffs, tool failures, and reviewer rejection. Check factual support, schema conformance, tool-use policy, latency, cost, and the clarity of the resulting audit trail. Use fixed fixtures for repeatable cases and record the versions of models, agents, tools, and policies. A platform capability becomes useful when its behavior can be measured against the work it is meant to perform.

For a first production use, select a bounded workflow with a named owner, rollback plan, monitoring, and a safe manual fallback. Set thresholds for intervention, completion quality, unexpected tool calls, and unresolved outcomes. Review the system whenever a model, connector, agent definition, or routing policy changes. This establishes a release discipline that uses the managed platform's features while keeping the application's responsibilities explicit and reviewable.

Related capabilities

• SI infrastructure development