For decades, applications have been designed to wait. A user clicks, a request arrives, code runs, a response goes back. And we got very good at this.
We learned to forecast traffic, scale on demand, wrap everything in enterprise controls, and run it all with the operational discipline that keeps critical business systems available around the clock. That model is being turned on its head, and being asked to serve apps that continuously act, and wait for no one. What changed is not the infrastructure underneath, but the software being written on top of it.
The work we used to capture as deterministic code, where every branch was defined in advance and every step was known before the first line ran, is now being rewritten as multi-agent applications that work out the steps at runtime. A developer used to encode the path, and now a developer describes the outcome and lets a set of agents reason their way toward it.
Agents work differently. Given an outcome, an agent reasons through the problem, breaks it into steps, writes code to solve it, runs that code, looks at the result, and goes again. The work happens in a loop that no human is standing inside.
That change puts pressure on assumptions our platforms were built on, because an application that responds and an agent that acts need very different things underneath them. The organizations pulling ahead right now are the ones who understood this early. They are not simply adding AI to what they already have.
They are designing for a different kind of software. What it takes to run an agent you can depend on Getting an agent working is no longer the hard part. A team can connect a capable model to a few tools, ground it in company data, and have something genuinely useful inside a week.
That is real progress, and it is why so many organizations now have a pilot that impressed the room. The distance between that pilot and an agent the business depends on around the clock is where the real challenge is. An agent operating continuously on behalf of a company gets held to the same bar as everything else in production.
It needs its own identity, with permissions scoped to what it is allowed to see. It needs to be watched while it works, so a team can trace every step it took, evaluate whether the outcome was right, and catch the drift that shows up quietly weeks after launch. It needs guardrails that are enforced at runtime.
And it has to clear the same security and compliance standards as the rest of the estate. No one is going to grant an agent an exemption. None of that is work a team should be doing for itself.
That is the job of an agent platform. Microsoft Foundry is where agents are built, grounded in enterprise knowledge, given a first-class identity through Entra Agent ID , and traced and evaluated once they are live. The Foundry Control Plane governs the agent, but it does not dictate where the agent’s work actually runs.
That is a separate decision, and a separate layer. Get started with Microsoft Foundry Where the work actually runs The moment an agent stops answering questions and starts completing tasks, it has to execute code. It clones a repository.
It installs a package. It runs an analysis against live data and calls into a system of record. That execution needs a runtime environment.
In most cases, it simply inherits the one the host application is already running on, because that is the path of least resistance. Run the agent on shared infrastructure and every workload inherits the blast radius of every other one. Give it broad access so it can be useful and you have handed an autonomous process far more reach than you intended.
Lock it down until it is safe and the agent can no longer do the job you built it for. Teams get stuck in this trade-off, and it is where most promising agents usually stall before they reach production. The answer is not to limit what the agent can do.
It is to give it a dedicated environment, with its own identity and guardrails for execution. Azure Container Apps Sandboxes provides exactly that. Every agent execution gets a fully isolated environment of its own, created in seconds and gone when the work is finished.
It runs as an identity you control, can access only the systems you have allowed it to reach, and never stores the credentials it uses to get there. And when a task spans hours or days, the environment can be paused and resumed with its full working context intact, so the agent picks up precisely where it left off. There is real engineering behind this.
Each environment runs inside its own hardware-isolated microVM, which is what makes strong separation and sub-second startup possible at the same time. But the mechanism is not the point. Isolation is built into the runtime rather than wrapped around it, so teams stop choosing between a capable agent and a controlled one.
Nothing disappears into the sandbox. The agent is still governed by Foundry, so what it sent into the sandbox and what came back stay on the record with every other step it took. The architecture pattern emerging across the enterprise Put the two together and a clear design pattern appears, one we are now seeing repeatedly across industries.
Build and govern the agent on Foundry. Extend its execution into an isolated sandbox on Azure Container Apps . The agent keeps its identity, its permissions, and its oversight.
The agent does not change when its work moves. Only the ground it runs on does. The work it performs happens in an environment that is purpose-built for agent tasks with ultra-fast executions, scoped to what it needs, and dissolved afterward.
This is what allows an organization to move from a handful of supervised agents to thousands running concurrently, without asking security and platform teams to accept risk they should never be asked to accept. What this looks like in practice Regulated client work, delivered at scale.
Originally published at azure.microsoft.com
