In this blog post Microsoft Agent Framework Foundry MCP and Aspire in Practice we will look at how these four technologies fit together into a practical enterprise stack for building, connecting, hosting, and operating AI agents.

One pattern I keep running into is that many leaders are seeing agent demos everywhere, but the stack underneath is still fuzzy. The result is predictable: teams mix frameworks, hosting models, connectors, and observability tools without a clear operating model, then wonder why security, support, and delivery all feel harder than they should.

After more than 20 years in enterprise IT, and a lot of hands-on work across Azure, Microsoft 365, AI, and cybersecurity, I have learned that the best architecture conversations start with role clarity. Not every tool needs to do everything. In this stack, each part has a distinct job.

Why these four belong in the same conversation

At a high level, I think about the stack like this. Microsoft Agent Framework is the application layer for agent logic. Microsoft Foundry is the managed platform layer for running and governing agents. MCP is the integration standard that connects agents to tools and data. .NET Aspire is the engineering and operations layer that helps teams compose, observe, and run distributed applications cleanly.

That matters because enterprise AI is rarely just a model problem. It is usually an orchestration problem, an integration problem, and an operational discipline problem all at once.

The stack in plain English

Microsoft Agent Framework

Microsoft Agent Framework is the part you use to build the agent itself. In plain language, it gives developers a structured way to define an agent, connect it to a model, add tools, keep conversation state, and orchestrate multi-step workflows.

What I like about it is that it separates the agent from the model vendor. That matters in real environments, because architecture decisions change when legal, cost, latency, or data boundary requirements change. I do not like betting the whole design on one model endpoint if I can avoid it.

Under the hood, the framework is not just a prompt wrapper. It includes model clients, session state, memory through context providers, middleware, workflow support, and MCP integration. That gives it a more enterprise-friendly shape than the first wave of DIY agent code most teams experimented with in 2023 and 2024.

Microsoft Foundry

Foundry is where the conversation gets operational. If Agent Framework is how you build the brain and behaviour, Foundry Agent Service is how you host, scale, secure, version, and observe that behaviour in a managed platform.

In my experience, this is where many proofs of concept either mature or stall. A good demo can hide a lot of operational debt. Foundry starts to address the less glamorous but more important questions around identity, monitoring, runtime management, and governance.

That is especially relevant for larger organisations in Australia. If your teams are working within Essential Eight-aligned environments, stronger audit expectations, and growing sensitivity around privacy and data handling, the runtime matters as much as the prompt.

MCP

MCP, or Model Context Protocol, is the least flashy part of the stack and one of the most important. I explain it to executives as a standard plug shape for AI tools and context.

Instead of every application inventing its own custom connector pattern, MCP gives you a common way for AI systems to discover and use tools, prompts, and resources. That reduces integration sprawl and makes it more realistic to build once and reuse across different AI clients and runtimes.

The technology behind MCP is straightforward enough to explain. It uses a client and server model with structured messages so an AI host can ask an MCP server what capabilities it exposes, then call those capabilities in a controlled way. In practice, that means less bespoke glue code and a cleaner separation between the agent and the enterprise systems it touches.

.NET Aspire

Aspire is not an agent framework, and I think leaders should be careful not to force it into that role. Aspire is better understood as an opinionated way to build and operate distributed applications with cleaner local orchestration, service discovery, configuration handling, health checks, and observability.

That makes it highly relevant to agent solutions, because most serious agents are distributed applications. They call models, search services, APIs, databases, identity platforms, and message queues. If that estate is messy in development, it usually stays messy in production.

One of the reasons I like Aspire is that it encourages teams to treat observability as part of the app, not an afterthought. For agent-based systems, that is not just a developer convenience. It is critical for troubleshooting cost, latency, tool misuse, and unexpected behaviour.

What is happening under the hood

If I strip the buzzwords away, the core flow looks like this. A user request enters the application. Agent Framework sends that request to a model with instructions and available tools. The model decides whether to answer directly or call a tool. MCP can provide the standard contract for those tool calls. Foundry can host and manage the running agent. Aspire can coordinate the surrounding services and surface telemetry.

That separation is healthy. It means you can evolve the agent logic without rebuilding the whole platform, or change the hosting and operational model without rewriting every integration.

It also helps with a basic architectural truth. If a task is deterministic, use normal software. If a task is open-ended, language-driven, or requires adaptive tool use, an agent may be the right fit. I still see too many teams applying agent patterns to work that should have stayed as a workflow or API.

A reference pattern I would actually use

For a greenfield enterprise project, I would usually think about the stack in four layers.

• Experience layer – Teams, web app, internal portal, or line-of-business UI.
• Agent layer – Microsoft Agent Framework for agent logic, routing, memory, and workflows.
• Integration layer – MCP servers for approved tools and enterprise context, plus selected direct APIs where MCP is not yet the best fit.
• Platform layer – Foundry for managed agent operations and Aspire for application composition, dependencies, and observability.

This pattern works well when you want flexibility without chaos. It also gives architecture teams a cleaner way to assign ownership. Developers can own agent behaviour. Platform teams can own hosting, telemetry, and guardrails. Security teams can focus on identity, data access, and tool boundaries.

A small example

I would still start small. First get a single agent working with one model, one or two tools, and proper telemetry. Then expand only when the operating model is clear.

// Simplified Agent Framework example
var agent = new AzureOpenAIClient(new Uri(endpoint), credential)
 .GetChatClient("gpt-4o-mini")
 .AsAIAgent(instructions: "You help staff answer internal policy questions clearly.");

var result = await agent.RunAsync("Summarise our device onboarding policy in plain English.");
Console.WriteLine(result);

The code is not the main point. The real design question is what happens next. Where does policy content come from, who approves tool access, how is the conversation logged, what identities are used, and how do you trace a bad answer back to the model, retrieval source, or tool call.

If I am using Aspire around that solution, I want the surrounding services defined together. That might include the web app, the API, the search component, storage, and telemetry plumbing.

// Simplified Aspire AppHost idea
var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.PolicyApi>("policy-api");
var web = builder.AddProject<Projects.Portal>("portal")
 .WithReference(api);

builder.Build().Run();

This is where Aspire earns its place. It gives the team a cleaner development experience and a more consistent view of dependencies, configuration, and health before the solution becomes a production incident.

Three lessons I would stress to leaders

• Do not confuse a framework with a platform. Agent Framework helps you build agent behaviour. Foundry helps you run and govern it. Those are related but different concerns.
• Standardise integrations early. MCP can reduce long-term connector sprawl, but only if you treat it as an architecture standard rather than another experiment.
• Obsess over observability from day one. Agent systems fail in subtle ways. You need traces, logs, metrics, and runtime visibility before executives depend on the output.

Where leaders get into trouble

The most common mistake I see is over-automation before trust is earned. Teams wire an agent into too many tools too quickly, then discover that the hardest part is not generation. It is permissioning, auditability, exception handling, and recovery when the model behaves unexpectedly.

The second mistake is assuming the stack itself solves governance. It does not. Good technology can give you identity controls, network isolation, content filtering, and monitoring, but an organisation still needs clear policy on who can publish agents, what data they can reach, and when a human must stay in the loop.

My takeaway

From where I sit in Melbourne, working with organisations in Australia and beyond, this stack feels like one of the more credible ways Microsoft is bringing order to enterprise AI. Agent Framework gives structure to agent development, Foundry brings managed operations, MCP offers a common integration language, and Aspire helps engineering teams keep the whole application estate understandable.

The bigger question for leaders is not whether agents are real anymore. It is whether their organisation can build them with enough clarity, control, and operational discipline that they remain useful after the first wave of excitement passes.

• From Demo to Production with Microsoft Agent Framework for Architects
• MCP A2A OpenTelemetry and OAuth Every Architect Must Track in 2026
• Enterprise AI Agents Need Standards Before They Need Scale in 2026
• Why Real-World Agent Architecture Needs More Than Just a Model
• Why Agent Legibility Will Matter More Than Better Prompting for CIOs