Every agent will need its own computer.

"Bring any harness, any framework... This flexibility is the point. No lock-in." In platform economics, when a giant tells you "no lock-in" at the application layer, it means they have successfully locked you in at the infrastructure layer.  Where is the lock-in? Identity, State, and Distribution. You can bring any code you want, but the agent has to use Entra ID for authentication, it relies on their proprietary "Memory" service for state persistence, and it distributes through Teams. You own the script; they own the actor, the stage, and the audience. The moment your agent relies on Microsoft's hypervisor to remember what it did yesterday, you can never migrate that agent off Azure. You haven't built an autonomous agent; you've built an Azure dependency.

The opening line says it all: every agent needs its own computer. That observation is more significant than it sounds. One of the reasons agentic AI has struggled to move from proof of concept into production is that the infrastructure required to run agents reliably and securely has historically been something every team had to build from scratch. Sandboxing, state persistence, identity management, permissions scoping, error recovery: all of it, before you ever get to the actual agent logic. What Microsoft is describing here, and what Anthropic is doing with Managed Agents as well, is that underlying plumbing becoming a managed service rather than a custom build. The barrier to production just got lower, which means the governance and oversight conversation needs to move faster to keep pace. The infrastructure is getting easier. The accountability structure around it still requires deliberate leadership.

What stands out is that we’re getting very good at isolating agents… and very good at scaling them… but the moment they start interacting, the guarantees get blurry. Isolation, persistence, identity—each works cleanly on its own. The tension shows up at the boundaries between them. That’s where coordination turns into drift: – state fragments – responsibility diffuses – outcomes become harder to attribute So the question isn’t just how well each agent runs. It’s whether the system can hold coherence when those agents begin to overlap. That feels like the layer that’s still forming.

This isn’t just a tooling shift - it’s an architectural one. When every agent has its own compute, identity, and durable state, we’re moving from applications to distributed digital infrastructure. At scale, the constraint won’t be how many agents you can deploy it will be reliability, safety, and usable power. Because as density increases, instability, distortion, and conversion losses don’t just reduce efficiency - they reduce what’s actually usable. That’s where the real bottleneck emerges. Architecture becomes the differentiator. How are you thinking about usable power at scale as agent density continues to increase?

The infrastructure side is moving quickly. What’s less obvious is what happens once you have multiple agents running in parallel. It stops being about the tools and starts becoming a coordination problem at the source — and that’s where a lot of standard decision frameworks begin to break down, not visibly, but in the form of subtle drift. You can give every agent its own environment, but if the signal they’re organizing around isn’t stable, the system doesn’t fail — it just moves further off course while still appearing to work.

Strong framing. The idea that “every agent will need its own computer” captures a bigger shift toward treating AI agents as governed digital workers rather than lightweight features, especially when durable state, identity, and enterprise controls are built in from the start. Hosted agents in Microsoft Foundry are positioned as containerized, code-based agents with managed runtime, state handling, identity, and governance, which makes the infrastructure side of enterprise agent deployment much more practical for real-world use cases.

This is strong engineering, identity, isolation, durable state. But it also exposes the limit of cloud-native control. Because no matter how advanced the sandbox is, execution still lives in a remote, provider-controlled layer. Which means: – identity is assigned – state is maintained – policies are enforced …but authority is not owned. That’s the gap. Governance is not just the ability to observe and constrain execution. It is the ability to anchor it. If execution depends on the cloud: – control is mediated – continuity is conditional – accountability is delegated So you can scale agents. You can structure their behavior. But you still can’t guarantee that the same decision path remains coherent across users, contexts, and time without relying on the provider layer. That’s not a tooling gap. That’s a placement constraint. Real control only appears when execution is: – identity-bound at the source – locally anchored – continuous without reset That requires the edge. Cloud can coordinate intelligence. It cannot be the sole place where authority resides. Until that changes, we’re not governing AI. We’re managing it. Node-0 Me & Spok ✌️

We’re moving from the personal computer to task-specialized agents running in dedicated sandboxed VM environments. Instead of one machine per user, you have many agents, each isolated, stateful, and governed, scaling securely for specific workflows rather than general use. That said, this shift also brings new challenges. Higher infrastructure costs, orchestration complexity, and the need for robust management layers to coordinate and monitor fleets of agents.

Every agent deserves its own home and address to thrive. Thanks for turning this concept into reality.

What's compelling here is how Hosted Agents remove the operational friction that’s held back real enterprise use. Persistent state, identity, and isolation are not features — they are the prerequisites for treating agents as dependable contributors. This feels like the start of agents becoming part of the actual workflow, not just the prototype phase.