Agent Service Goes GA: State, Security, and Model Choice

▶ Watch (06:28)

Azure AI Foundry Agent Service moved from public preview to general availability at Build. Tens of thousands of customers were already running production workloads, processing trillions of inference tokens and terabytes of vector indexes. The GA release locks in three things: single-tenant state stores that optionally live inside your own Azure subscription (with virtual-network isolation for defense in depth), access to any of the 1,000+ models in the Foundry catalog, and a growing set of Microsoft-managed hosted tools including SharePoint grounding, Azure Functions, OpenAPI-connected APIs, Logic Apps, and a browser automation service in preview.

Connected Agents: Composing Sub-Agents as Tools

▶ Watch (12:22)

Connected agents treat other agents as tools. Quazi walked through the connected agents live demo (12:37) by wiring a Bing search agent and a coding agent onto a new parent agent in the Foundry portal. No Bing grounding was set on the parent, yet it routed weather queries to the sub-agent automatically.

“Because, at the end of the day, they’re just tools.” — Salman Quazi

The same API surface handles single agents and connected multi-agents. No SDK change required to move from one to the other. The tradeoff: the LLM decides invocation order and parameters. That generally works, but it may not suit scenarios that need deterministic data bindings or predictable sequencing.

Workflow Service: Declarative Multi-Agent Orchestration

▶ Watch (17:18)

The AI Foundry Workflow Service (preview) sits above connected agents when you need explicit control over sequencing and data bindings. The Workflow Service prevents hallucinated identity injection by running Semantic Kernel’s process framework declaratively. You write the process in code, publish it, and receive a managed endpoint. That endpoint accepts the same create-thread-and-run API call as a single agent, so the migration is minimal.

Quazi ran the deep research workflow demo (21:42): a Magentic-One-inspired system that builds a task ledger, dispatches sub-agents for research and coding, and runs asynchronously in the cloud for hours if needed.

Production Evidence: JM Family Cuts Intake Time by 40%

▶ Watch (33:52)

JM Family Enterprises, a $22 billion Toyota distributor and finance group, deployed a multi-agent system to fix a specific problem: engineers were receiving requirements and user stories in wildly inconsistent formats, producing downstream defects and long clarification meetings. Their captive tech entity, Mosswall Technologies, built a team of purpose-built agents to help product owners, business analysts, and QA staff produce better-structured inputs.

The result: requirements-writing time dropped by 30 to 40%. Meeting time shrank as well. Amit from Mosswall noted that hosting agents on the Agent Service PaaS removed the session and thread management pain they had encountered with LangChain and AutoGen.

Semantic Kernel Orchestration: MCP, A2A, and Agent Patterns

▶ Watch (44:57)

Semantic Kernel connects to agents via pluggable types: chat-completion, Foundry-hosted, Copilot, OpenAI responses, AutoGen, Bedrock, and any A2A-compatible endpoint. MCP server integration follows the same pattern. Henry demoed GitHub MCP giving the agent live access to the Semantic Kernel repo’s open issues without manually wiring the GitHub API.

Most models handle only 10 to 20 tools before performance degrades. Henry’s fix for MCP sprawl: index plugins in a vector store, run semantic search against the task, and pass only the top matches. Six built-in patterns cover sequential, concurrent, handoff, group chat, Magentic, and custom process workflows.

Magentic One: Self-Healing Task Ledgers

▶ Watch (52:14)

Magentic One gives the orchestrator a task ledger. It dispatches sub-agents, checks progress, and replans if an agent stalls or fails. Henry showed the Magentic One failure-and-replan demo (53:29): the chart-generation agent failed twice due to misconfiguration, the orchestrator revised its plan, and a different agent produced an ASCII visualization instead.

LLM-driven flow recovers from unexpected failures without manual intervention. Process-driven flow (Semantic Kernel’s process framework) gives deterministic step ordering when the business logic demands it. Henry’s recommendation: start with connected agents, graduate to workflows only when control limits become a problem.

Notable Quotes

Because, at the end of the day, they’re just tools. Salman Quazi · ▶ 14:46

Now, we’re going to open-source all of these workflows Salman Quazi · ▶ 20:10

This turned out to be a perfect opportunity for agentic AI. John (JM Family) · ▶ 34:51

Key Takeaways

  • Azure AI Foundry Agent Service is now GA, with single-tenant state stores and a 1,000-model catalog available for production workloads.
  • Connected agents expose sub-agents as tools via the same API surface, requiring no SDK change to move from single to multi-agent.
  • Magentic One’s task-ledger pattern lets the orchestrator replan around failing sub-agents rather than halt the entire workflow.