Foundry Agent Service Is GA: What It Means If You're Already on LangGraph

Most “agent platform” announcements are still demos wearing a product page. Microsoft’s Foundry Agent Service reaching general availability is a narrower, more useful claim: a managed runtime for agents you already built, in whatever framework you already picked, packaged as a container and run in an isolated sandbox that Microsoft operates. If you’re already running LangGraph or CrewAI in production, the interesting question isn’t whether to switch, it’s whether this solves a deployment problem you actually have.

What GA actually covers

Foundry Agent Service has two ways to define an agent: prompt-based agents, configured entirely through prompts and tool settings in the Foundry portal, and hosted agents, which are your own code packaged as a container image, deployed to Microsoft-managed infrastructure. The GA milestone is specifically about hosted agents and includes the managed runtime, per-session sandboxing, the two supported protocols, and observability integration. Routines, a scheduling feature for running any agent on a timer, remain in public preview, so treat that piece as still maturing.

The framing that matters most: hosted agents are explicitly framework-agnostic. Your container can be a LangGraph graph, a CrewAI crew, an agent built on the GitHub Copilot SDK, or Microsoft’s own Agent Framework. The runtime doesn’t care which orchestration library produced the container, it just runs it.

# A hosted agent is just your existing agent code in a container.
# This LangGraph agent doesn't change to deploy here.
FROM python:3.12-slim
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "agent_server.py"]

The sandboxing model

Every session gets its own VM-isolated sandbox with a persistent filesystem, exposed at $HOME and /files. That isolation is worth pausing on, because it’s solving a problem specific to agents rather than typical web services. A stateless API handler doesn’t usually write files to disk, spawn subprocesses, or need its working directory to survive between requests. An agent that writes intermediate results to disk, shells out to a code interpreter, or maintains a working set of files across many turns of a long conversation does need exactly that, and running two such agents in the same shared compute without isolation is a real security and reliability problem, not a hypothetical one.

Scale-to-zero with stateful resume is the other half of this: the sandbox’s filesystem persists even when the compute backing it gets deallocated during idle periods, and a new invocation reattaches to that same persistent state rather than starting cold. That matters economically for agents with bursty, unpredictable usage, since you’re not paying to keep a VM warm just so an agent’s working files stay available between calls.

Two protocols, two state models

Hosted agents can expose one or both of two protocols:

	Responses protocol	Invocations protocol
Primary identifier	Conversation ID	Session ID
Who manages history	The platform, automatically	The client
Compatible with	OpenAI-style stateful chat APIs	Schema-free, pass-through designs
Best fit	Agents that want the platform to carry conversation state	Agents whose framework already owns its own state

If your agent framework (LangGraph’s checkpointing, for instance) already has an opinionated way of managing conversation state, Invocations lets you keep that model and just use the platform as compute. If you’d rather not build state management yourself, Responses hands that off to the platform in an OpenAI-compatible way.

What this changes and what it doesn’t

For a team already committed to a framework like LangGraph, CrewAI, or AutoGen, this announcement is not a reason to reconsider that choice. It’s a new answer to a different question: where does the container that framework produces actually run in production, with what isolation guarantees, and at what operational cost.

That’s a real question worth answering, separate from orchestration framework choice. Teams running agent workloads today often solve sandboxing and session isolation themselves, with hand-rolled container orchestration, a self-managed Kubernetes namespace per session, or (more commonly than anyone likes to admit) a shared compute pool with weaker isolation than a production agent handling file writes and subprocess execution really should have. A managed runtime that handles per-session VM isolation, persistent filesystem, and scale-to-zero out of the box removes a genuine chunk of infrastructure work, if you’re already inside the Azure ecosystem or open to being.

The trade-off to evaluate honestly: you’re taking a dependency on Microsoft’s specific protocol and sandboxing model, and pricing for hosted compute that scales to zero is a different cost shape than a fixed self-managed cluster. For a team already deep in AWS or GCP with existing container orchestration investment, the calculus is different than for a team already standardized on Azure and looking to stop hand-rolling agent sandboxing. Evaluate it as an infrastructure decision on its own merits, not as a signal about which agent framework is winning.

If you’re scoping out a production agent deployment and want a second opinion on whether to build the sandboxing yourself or adopt a managed runtime like this one, that’s exactly the kind of architecture call worth getting an outside read on before you commit engineering months to either path; see our services page for how we approach that kind of assessment.