Designing agent-first platforms: What changes when agents do the work

For many years, applications were created to function in a waiting mode. A user would click, a request would be made, code would execute, and then a response would return. We became very proficient at this entire process. We developed the ability to predict load, adjust resources as needed, implement enterprise-level controls, and maintain operations to ensure critical business systems are always available.

However, this model is now changing. We’re now expected to develop applications that operate continuously, without waiting for anyone.

The underlying infrastructure hasn’t transformed; it’s the software that’s being developed on top of it that has changed. Previously, developers would write code with predetermined steps and clear paths. Now, we are adopting a new approach: creating multi-agent applications that determine their actions during execution. Developers now focus on outlining the outcome desired, allowing the agents to figure out how to achieve it.

These agents function uniquely. When given a goal, an agent breaks it down into manageable steps, writes the necessary code, executes it, reviews the result, and iterates from there. This process occurs in a cycle that operates independently of human intervention. This shift challenges the foundational assumptions of our platforms since applications that respond and agents that take action have vastly different requirements.

The organisations making significant strides today are those that recognised this shift early. They aren’t merely adding AI features to existing systems; they are innovating for an entirely new kind of software.

How to Run a Dependable Agent

Setting up an agent is now relatively straightforward. A team can link an effective model to some tools, anchor it with company data, and develop something practically useful within a week. This progress is why many organisations now have impressive pilot projects.

However, moving from a pilot project to an agent that the business relies on continuously is where the real challenges lie.

An agent that operates continuously for a business must meet the same standards as everything else in production. It requires a distinct identity, with clearly defined permissions to ensure it only accesses what it is permitted to see. Continuous monitoring is essential to track every action taken, evaluate whether results are correct, and identify any drift that may emerge weeks post-launch. Robust guardrails must be enforced during operation, and the agent must adhere to the same security and compliance standards as the entire system; no exceptions can be made.

Accomplishing all this is not the team’s responsibility; that’s what an agent platform is for. Microsoft Foundry is where agents are developed, rooted in enterprise knowledge, equipped with a distinguished identity via Entra Agent ID, and monitored for performance once they are up and running. The Foundry Control Plane manages the agent but does not dictate the environment in which it performs its tasks. That is a separate consideration entirely.

Where the Execution Takes Place

Once an agent starts performing tasks instead of merely answering questions, it must run code. Whether it’s cloning a repository, installing a package, or performing analyses using real-time data, it requires a dedicated runtime environment. Typically, it adopts the runtime of the host application because this is more straightforward.

However, using shared infrastructure means every workload is impacted by every other one, creating potential risks. Granting broad access can provide utility but also allows an autonomous process too much reach. Conversely, overly restricting it can hinder the agent from fulfilling its intended purpose. Many teams find themselves caught in this dilemma, leading to the stalling of promising agents before they ever get to production.

The solution is not to restrict the agent’s capabilities; it’s to provide it with a dedicated environment that includes its own identity and execution guardrails.

Azure Container Apps Sandboxes offer this solution. When running, each agent is provided with a completely isolated environment that is created swiftly and disappears once the job is complete. It operates under a controlled identity, can only access approved systems, and never retains any credentials used to gain access. If a task is lengthy, the environment can be paused and resumed with all prior information preserved, allowing the agent to continue seamlessly.

This approach relies on solid engineering principles. Each environment functions within its own hardware-isolated microVM, facilitating strong separation and rapid startup times. Critically, the isolation is inherent to the runtime rather than an added layer, allowing teams to prioritise capability without sacrificing control.

Moreover, nothing is lost in the sandbox. The agent remains under the governance of Foundry, ensuring that all interactions with the sandbox are recorded alongside every other action it undertook.

Emerging Architectural Patterns Across Enterprises

When we combine these elements, a distinct design pattern starts to emerge, and we are beginning to see this repetition across various industries.

Firstly, build and manage your agents on Foundry. Then extend their execution into an isolated sandbox through Azure Container Apps. The agents maintain their identity, permissions, and oversight without change; only the underlying environment shifts. This approach enables organisations to scale from a handful of supervised agents to thousands operating simultaneously, without placing undue risk on security and platform teams.

Real-World Applications of This Model

• Regulated client work at scale. The Digital Gateway Powered by Claude integrates Claude’s functionalities into KPMG’s connected tax platform on Microsoft Azure, giving professionals a secure environment to collaborate with AI. Within this platform, DG Cowork acts as the AI-enabled workspace where professionals can process data, generate content, and tackle complex tasks. Given that client data must be compartmentalised by engagement, the platform is designed with engagement-specific workspaces and control measures. DG Cowork operates on a global scale, with over 30,000 Azure Container Apps Sandboxes functioning concurrently.

• Providing answers to previously unasked questions. Cognite supports industrial operators who often struggle with valuable questions—like which assets are poorly performing and why—because they are time-intensive to investigate. Traditional analysis took days, meaning these inquiries often went unexamined. Cognite Atlas AI makes a change. Each agent receives a supervised workspace based on active customer data in Cognite Data Fusion, transforming what used to be lengthy investigations into traceable answers in mere minutes. Furthermore, for more complex issues, agents can pause and resume investigations without losing context, enabling them to tackle problems over time as an engineer might.

Atlas AI agents, backed by Azure OpenAI models in Microsoft Foundry, needed to execute complex tasks efficiently in Cognite Data Fusion, requiring sandbox environments that keep each user’s agent, environment, and data fully isolated. With Azure Container Apps Sandboxes, we had a prototype ready within hours, and we were conducting customer tests within weeks, as Azure managed the challenging aspects: per-user isolation, egress policies, and quick execution. For our industrial clients, this dramatically reduces the time needed to answer critical questions like ‘Which wells are underperforming and why?’ from days to just minutes.

—Christian Flasshoff, Architect, Atlas AI, Cognite

• A safe learning environment for every student. The Department for Education in South Australia operates EdChat, enabling students to learn through coding and data analysis with AI, covering 60,000 students and over 40,000 staff. This approach hinges on providing each student with their own environment, replete with clear guidelines, which allows them to return and find their work exactly as they left it. Developing this framework in-house meant managing complex code which the department estimates comprised nearly 50,000 lines. Transitioning to Azure Container Apps Sandboxes allows them to offload this burden, creating a user-specific execution model that functions at the scale needed for a school system.

These three diverse organisations share a mutual narrative. None faced limitations based on the capabilities of their models; they were confined by the absence of the right environments to execute their work effectively at scale, using real data, and within sustainable economic parameters.

Our Motivation for Building This

Currently, Microsoft runs over a million sandboxes each day in production, supporting services such as GitHub Copilot, Copilot Studio, Security Copilot, Foundry Agent Service, Azure SRE Agent, and various Azure solutions.

Each sandbox corresponds with a user—the developer awaiting a completed pull request, the analyst racing to identify an alert before their shift ends, or the support team tackling a queue that must be emptied by dawn. Their tasks progress at the speed dictated by this infrastructure. This presents a rigorous challenge that has been upheld at scale for a considerable period.

Our unified architecture underpins both our development tools and our AI platform, and we are excited to offer this structure to you.

The Choice You Face

Every significant platform transformation ultimately comes down to early design decisions made by individuals who anticipated emerging trends.

The teams set to thrive with agent deployment over the next few years are making those foundational choices now. They separate the platform that governs the agent from the environments where it executes tasks, viewing this separation as a fundamental strategy rather than a retrofitting task after piloting.

The agents are ready for deployment; the pivotal question is whether your platform is structured for software that takes action.