Microsoft’s Foundry and Agent Framework documentation, alongside Shiv Ojha’s Azure AI stack reference, point to the same enterprise pattern: production agents need orchestration, tools, memory, evaluation, deployment and operational controls, not just access to a model API.
Microsoft is presenting enterprise AI agents as managed software systems that require orchestration, tools, memory and operational controls around the model, according to its Foundry and Agent Framework documentation.
In “The Complete Azure AI Stack: 9 Layers, 40+ Services, One Reference,” software architect Shiv Ojha describes production AI on Azure as a nine-layer architecture rather than a single model endpoint. Ojha’s reference places model services as one layer in a broader system that also includes agent orchestration, application frameworks, memory, state, security, observability and deployment concerns.
That framing is useful for enterprise teams because it separates a model call from a production agent. A prompt sent to a model can produce an answer or choose a tool. An enterprise agent, by contrast, must usually authenticate users, apply access controls, connect to approved systems, preserve relevant context, handle failures and produce logs that can be reviewed after deployment.
Ojha’s article is not an official Microsoft architecture document. However, its central argument aligns with Microsoft’s own product materials for Microsoft Foundry and Microsoft Agent Framework.
Microsoft Learn describes Microsoft Foundry as an enterprise AI platform for building, evaluating, deploying and operating AI applications and agents. Microsoft says Foundry supports multi-agent orchestration, model building, evaluation, deployment and operational controls.
The Foundry documentation also points to a large tool catalog, with more than 1,400 tools available for developers. That detail highlights a practical distinction in agent design: many enterprise use cases depend on whether an agent can retrieve governed business context and call authorized tools, not only on which model generates the next response.
Microsoft Learn also describes memory and operational management as part of the Foundry environment. Those capabilities help move an AI application beyond stateless chat interactions toward systems that can maintain context, apply policies and be monitored in production.
Microsoft’s Developer Blogs announcement for Microsoft Agent Framework version 1.0 describes the framework as supporting multi-agent orchestration, multiple model providers and interoperability through standards including Agent2Agent and Model Context Protocol.
Visual Studio Magazine’s report on the same release says Agent Framework 1.0 includes memory and context providers, graph-based workflows, multiple orchestration patterns and connectors for OpenAI, Claude, Amazon Bedrock, Gemini and Ollama. Those features reinforce the same architectural direction: production agents need routing, state, workflow control and connectors in addition to model inference.
The multi-provider support is also notable. Microsoft’s Agent Framework materials do not present enterprise agent development as a single-model pattern. Instead, the framework is described as a layer that can connect applications to different model providers while managing orchestration above them.
Across Ojha’s Azure reference, Microsoft Learn’s Foundry documentation, Microsoft’s Agent Framework announcement and Visual Studio Magazine’s coverage, the common theme is that enterprise agents are being packaged as integrated application systems.
A model remains central to these systems. It can generate language, reason over instructions and select actions. But the surrounding layers determine whether the agent can operate inside an organization: identity, permissions, memory, retrieval, approved tools, evaluation, deployment and monitoring all affect reliability and governance.
For teams building on Azure, Microsoft Foundry and Microsoft Agent Framework show how Microsoft is organizing those surrounding layers. The message is increasingly clear: enterprise AI architecture is no longer just a question of which model to call. It is a question of what software stack is needed to run agents safely and reliably.
Microsoft is presenting enterprise AI agents as managed software systems that require orchestration, tools, memory and operational controls around the model, according to its Foundry and Agent Framework documentation.
Ojha’s reference places model services as one layer in a broader system that also includes agent orchestration, application frameworks, memory, state, security, observability and deployment concerns.
That framing is useful for enterprise teams because it separates a model call from a production agent.
Continue reading
