Enterprise AI agent projects are moving beyond proofs of concept, and the runtime choice now has real operational consequences. In a new Microsoft Mechanics short, Microsoft outlines three broad ways to run agents: no-code or low-code agents, hosted container agents in Microsoft Foundry, and custom container-hosted agents that run outside Foundry.
Why the runtime choice matters
For IT and cloud teams, the decision is less about whether an agent can be built and more about who owns orchestration, governance, security, telemetry, and day-two operations. The more control you take over the runtime, the more responsibility you also take for networking, identity, observability, scaling, and policy enforcement.
Three options Microsoft highlights
No-code and low-code agents are suited to teams that want speed and managed platform capabilities. Microsoft points to Copilot Studio and Microsoft Foundry Agent Service for prompt agents and workflows that can use managed orchestration, evaluation, telemetry, MCP tools, knowledge grounding, and scoped observability.
Hosted container agents in Microsoft Foundry are code-based agents that still benefit from platform-managed services. This model is useful when developers need custom code while still relying on Foundry for conversation history, identity and access control, private connectivity, telemetry, tracing, and centrally applied governance.
Custom container-hosted agents run externally, such as in Azure Container Apps, Azure Kubernetes Service, or non-Azure environments like Amazon EKS. This approach can maximize portability and control, but it shifts more of the operational burden to the engineering and platform teams.
Practical takeaways for cloud teams
Start by matching the runtime to the workload's risk and complexity. A departmental assistant with standard workflows may fit a low-code model. A production agent that requires custom logic, private networking, and consistent enterprise guardrails may be a better fit for hosted containers in Foundry. A highly specialized platform requirement or multi-cloud deployment may justify a custom container approach.
The important operational question is not only where the agent runs, but where governance is enforced. Microsoft specifically calls out controls such as content filtering, prompt injection protection, copyright safeguards, tracing, and fleet-level telemetry. Those capabilities should be part of the architecture review before an agent becomes business-critical.
Bottom line
Microsoft's framing is a useful reminder that enterprise AI agents need a runtime strategy, not just a development experience. Choose the simplest model that still meets your requirements for control, extensibility, security, observability, and operational ownership.
Source: Microsoft Mechanics on YouTube