Aspire ties Microsoft Agent Framework into one app graph

Aspire now runs a multi-agent ski resort app as one graph with chat, voice, and specialist services.

Aspire 13.4 arrives with a very practical message: distributed agents are easier to ship when the whole system lives in one AppHost. In Microsoft’s AlpineAI demo, that means chat, voice, specialist agents, Foundry resources, and the Cosmos emulator all start together.

The demo is built around a ski resort concierge, but the architecture matters more than the theme. It mixes Aspire, Microsoft Agent Framework, Microsoft Foundry, Cosmos DB Emulator, and agent-to-agent calls in a way that feels close to a real production system.

One AppHost now describes the whole system

The biggest idea in the post is simple: the AppHost is no longer just a place to start services. It becomes the source of truth for the app graph, including model deployments, prompt agents, hosted agents, Python services, Go services, .NET projects, and the infrastructure they depend on.

Microsoft’s sample uses that graph to wire up a frontend, a data generator, a chat advisor, a voice advisor, and multiple specialist agents. Aspire then starts them in the right order, connects references, and exposes the dependencies so you can inspect what is actually running.

That matters because agentic apps get messy fast. Once you add live telemetry, voice input, tool calls, and several specialized models, the old “start the API and hope for the best” routine stops working. Aspire gives the team a single place to declare the system shape.

• Foundry account and project hold the agent resources.
• Model deployments split normal chat from realtime voice.
• App references connect agents to data and other services.
• Azure Container Apps placement keeps the runtime story explicit.

Microsoft shows this split clearly in the sample code. A Foundry project can host a prompt agent with web search, while a separate app can expose custom code as a hosted agent. Those are different execution models, but Aspire keeps them in the same application definition.

The advisor is the orchestration layer

The chat advisor is the brain of the ski resort experience. It receives the user request, decides which specialist agents matter, calls only those agents, then combines the answers into one response. That is a much cleaner pattern than making one giant model guess everything at once.

Tommaso Stocchi, the author of the post, describes the sample as a realistic concierge that can answer guest questions, reason over live resort telemetry, route requests to specialist agents, search the web for general ski knowledge, and support both chat and voice experiences.

“The important part is not that the demo is about skiing. The important part is how Aspire turns a complex multi-agent system into one application graph you can run, observe, and publish.”

That quote gets to the heart of the article. The ski theme is just a readable wrapper around a harder engineering problem: how do you keep a distributed agent system understandable once it grows beyond a single model call?

The answer in this demo is to make the advisor the only thing the user talks to, then treat specialists as tools. Weather, lift traffic, safety, ski coaching, and web-backed research each own a narrow job. The advisor picks the right ones based on the request.

• Weather agent handles current conditions and forecasts.
• Lift traffic agent answers wait times and lift status.
• Safety agent deals with closures and slope risk.
• Ski coach agent turns skill level into recommendations.
• Ski researcher answers general ski questions with web search.

Voice adds another service path, not another app

The voice advisor follows the same idea, but with a different transport and runtime. It is a .NET WebSocket service that connects browser audio to Azure AI Voice Live, uses a realtime model deployment, and talks to the same specialist network as the chat advisor.

That is a strong design choice. Teams often build separate “voice” and “chat” systems, then spend months reconciling behavior differences. Here, the user experience changes, but the underlying specialist network stays shared.

Microsoft also keeps the realtime and normal chat models separate in Foundry. In the sample, one deployment is used for standard conversation, while another is reserved for realtime voice. That split makes sense if you care about latency, streaming behavior, and prompt tuning.

For developers, the practical win is operational. Aspire can start the frontend, the voice service, the advisor, and the data generator together, so you do not need a hand-built launch script with hidden assumptions.

Real numbers make the architecture easier to compare

The post includes enough concrete data to show how much is being coordinated. There are two advisor entry points, two model deployments, and five specialist tools behind the chat advisor. That is already a lot of moving parts for a demo.

Here is the useful comparison: the advisor is a single MAF agent, but it fans out to five tools. The voice advisor is a separate service path, but it still depends on the same Foundry project and the same live resort data. The data generator is another service again, written in Go, feeding telemetry into the system.

That mix is the point. Aspire is not trying to hide the fact that the app spans multiple languages and runtimes. It makes that fact visible and manageable.

• Go powers the data generator.
• Python powers the weather, safety, and ski coach agents.
• .NET powers the advisor, lift traffic agent, and voice service.
• A2A lets specialist agents expose capabilities as tools.

There is also an observability angle that should matter to anyone building agent systems. The post shows OpenTelemetry wired into the advisor, with a switch for sensitive data. That is a serious signal: Microsoft expects developers to trace agent behavior, not just run it.

When the advisor chooses between weather, lift traffic, safety, and ski coaching, the trace should explain why. Without that, debugging becomes guesswork, especially when a model call chains into several other calls.

Why this sample matters beyond ski resorts

AlpineAI is a demo, but the architecture maps to a lot of real products. Any support assistant, field operations dashboard, travel planner, or internal IT agent could end up with the same shape: one orchestrator, several narrow specialists, a live data source, and a separate voice path.

The article also shows a healthy boundary between platform-managed and app-managed behavior. Foundry handles hosted prompt agents and model resources. Custom code handles domain logic, orchestration, and services that need their own dependencies. Aspire keeps both under one roof without pretending they are the same thing.

That split is what makes the sample worth studying. It avoids the trap of stuffing every task into one model prompt, and it avoids the other trap of scattering agent pieces across separate repos with no shared operational model.

If Microsoft keeps pushing Aspire in this direction, the next interesting question is less about whether agents can talk to each other and more about how large a graph teams are willing to maintain before they need stronger policy, testing, and trace analysis. For now, this sample gives a concrete answer: start with one graph, keep the specialists narrow, and make the advisor the only public entry point.