Microsoft moved Foundry Agent Service to general availability in July 2026 with hosted sandboxed sessions, Voice Live, Toolboxes, private networking, and enterprise-grade evaluations. For teams shipping mobile apps, n8n automations, and multi-agent orchestration, the interesting part is not that Azure now has a hosted agent runtime. It is that a serious production surface with per-session sandboxes, one managed tool endpoint, and voice-native paths is finally something you can route into from an existing stack without a rewrite.
The July 2026 smol.ai AINews newsletter flagged the Foundry GA alongside the ChatGPT Work launch as the two enterprise agent moves of the month. Where OpenAI shipped a first-party autonomous agent inside a chat surface, Microsoft shipped an infrastructure layer: hosted agents with their own filesystem, memory types, a single Toolboxes endpoint, and Voice Live for real-time speech. At Halmob, most 2026 engagements are a mobile app on top of an n8n automation layer on top of an orchestration layer that routes across vendors. Foundry Agent Service GA is a new lane behind that router, not a new architecture.
The 30-Second Version
What Reached GA in July 2026
Five pieces landed together, and they only look like a bundle of press-release features until you map them onto a real mobile-and-automation stack. Read as a stack, the shape of each lane becomes obvious.
| What went GA | What it does | Impact on mobile and automation teams |
|---|---|---|
| Hosted Agents | Managed runtime with per-session sandbox, dedicated compute, filesystem, and state | You stop hand-rolling worker pools for long-running agents; sessions get real isolation you can point audit at |
| Toolboxes | A single managed endpoint that fronts every tool type with auth, lifecycle, and governance | The dozen MCP and REST connectors you glue together per workflow collapse into one URL and one policy layer |
| Voice Live | Real-time voice paths on top of hosted text agents through the Responses and Invocations protocols | Voice becomes a first-class agent surface for phone-in, call-center, and mobile push-to-talk flows |
| Private networking | VNet-integrated inference and tool calls, no traffic across the public internet | Regulated tenants (finance, health, public sector) can put agents inside the same trust boundary as their own APIs |
| Enterprise-grade evaluations | Built-in eval suites, observability, and Foundry Portal now GA alongside the runtime | The eval, drift-check, and cost dashboard you would have built in-house is now a first-party surface |
The Toolboxes row is the one most teams underrate on launch day. A single managed tool endpoint sounds like a small quality-of-life change until you count the connectors, secrets, and per-tenant auth policies you currently maintain across n8n, your own backend, and each agent framework. Toolboxes moves that surface behind one URL.
Why This Matters for Agent Orchestration
For most of 2025 and early 2026, running production agents meant three unglamorous things: standing up worker pools that survived long-running sessions, wiring MCP or REST tools with per-tenant auth and audit, and building your own evaluation harness because vendors did not ship one. Foundry Agent Service GA does not replace your orchestrator. It moves those three pieces behind one billed surface.
For mobile-first products and n8n-driven automations, that is a good trade. Latency drops when the agent, its tools, and its state live in the same sandbox instead of round-tripping through three services. Failure surface shrinks because one endpoint owns lifecycle, not a fleet of your own containers. And observability moves from "something we hope to add next quarter" to a first-party dashboard on day one.
The Foundry GA story is not that Microsoft caught up on hosted agents. It is that Toolboxes plus Hosted Agents retires the worker pool and the connector shelf you were maintaining anyway.
What still belongs outside Foundry
Even with a production runtime, some pieces stay in your infrastructure. Multi-vendor routing, safety-class checks, tenant isolation policy, long-horizon memory that outlives a single run, cost caps per customer, and the audit trail your compliance team actually reads should not move into Foundry Agent Service. The rule of thumb is the same as with ChatGPT Work: the agent plans and executes one job, your router decides which agent runs which job and where the receipts land.
Foundry Agent Service for Mobile Agents
Mobile is the strictest client for any hosted agent runtime. Battery, network, and background-time budgets are all worse than server-side, and users notice a one-second stall. Foundry GA changes the calculus in three specific places.
Background jobs live in the sandbox, not on the phone
A mobile flow that hands off a long task, then notifies the user when it lands, is the natural fit. Upload finishes on the phone, the mobile app fires an n8n webhook, n8n starts a Foundry hosted session with the goal and connector policy, the agent runs for minutes or hours inside its own sandbox, and a push notification lands when the artifact is ready. The mobile app never blocks on the agent. This is the same shape we described in the Claude Cowork mobile and web background agents post, now with a hosted runtime instead of a bespoke worker pool.
Voice Live as a real mobile surface
Voice Live is not a chatbot with speech bolted on. It is a real-time voice path with an agent behind it, which means the mobile pattern is finally "press to talk, agent thinks and acts, agent talks back" without a bespoke stack. Push-to-talk in the mobile app, socket to Voice Live, hosted agent runs tools through Toolboxes, response streams back as audio and structured events. For customer-support apps, field-service apps, and any product where typing is the wrong input, this collapses a lot of glue.
Foreground taps still route around it
Do not put a hosted-agent session behind a foreground tap. A session that can run for minutes does not fit inside a screen a user is staring at. Use a smaller, faster model behind the tap and hand the long tail to Foundry in the background. That is exactly the pattern in the model-routing layer for mobile AI agents and n8n flows post.
Foundry Agent Service for n8n Automations
n8n stays the trigger, retry, and audit layer. Foundry becomes the runtime for the middle step that used to be a fan-out into six connectors, a wait, and a merge. Keep the boundary honest and each side gets to do what it is good at.
- Point n8n at one Toolboxes URL, not twelve MCP servers. The connector list on the Foundry side moves inside Toolboxes with one policy layer. Your n8n workflows call one endpoint per session, not one per tool.
- Keep n8n as the schedule, webhook, and audit layer. The cron, the retry, the human-in-the-loop gate, and the tenant-facing audit log all stay in n8n. Foundry runs the session. n8n owns the receipts.
- Use Foundry evaluations as your dry-run gate. Before a workflow writes to a customer surface, run the session against Foundry's eval suite first, return the score to an n8n Function node, and gate the write on that score. This lines up with the executor and advisor orchestration pattern, with the advisor now backed by a first-party eval.
- Do not hard-wire Foundry into every AI node. A routing layer in front of n8n still decides per call. That is what keeps the workflow portable when an incident forces a fallback to Claude, Gemini, or an open model. If you already run n8n on Fargate per the n8n ECS Fargate load test post, the same worker pool can front Foundry sessions with almost no shape change.
Cost, Compliance, and the Awkward Parts
The launch story is genuinely useful, but a serious rollout has to answer three questions before it fronts customer traffic.
Private networking is a real feature, not a checkbox
VNet-integrated inference and tool calls are the reason regulated tenants can put an agent inside the same trust boundary as their own APIs. If your product ships into finance, health, or public sector, model the network path end to end before the sales call: which Foundry region, which VNet, which private endpoint per Toolbox, and how the audit trail crosses the boundary. Private networking is not a switch you flip in staging and hope holds in prod.
Data policy and Toolboxes scope
Every entry in a Toolbox is a data path from a customer system into a hosted session. Legal and security will want a written list of which tools are enabled per tenant, which data crosses the boundary, and how retention lines up with GDPR, KVKK, or CCPA obligations. Do not enable a shared Toolbox across tenants by default. Scope Toolboxes per workflow and per customer segment, and log every write from the session to the tool.
Long sessions are cheap tokens and expensive attention
A hosted session that runs for an hour does not fail loudly the way a single API call does. It quietly does the wrong thing for a long time. Cost caps per session, timeouts per phase, and a check-in cadence that catches drift before it writes to a customer surface are all non-negotiable. This is exactly the loop shape we covered in the loop engineering for resilient AI agent loops post, now applied to a first-party runtime.
Do Not Migrate Your Whole Stack
A Practical Rollout in a Real Mobile and n8n Stack
Treat GA as a routing target, not a rewrite. Each step is boring on purpose, because the point is to make the next runtime swap cheap, not to prove architectural purity today.
Step 1: Register Foundry as a routing target
Add Foundry Agent Service as one target inside your existing model-routing layer, with its own quota, timeout, safety class, and network policy. Do not call it directly from the mobile app or from a raw n8n HTTP node. Route through the same layer that already fronts your other agent lanes.
Step 2: Move one background n8n workflow first
Pick a workflow that already runs in the background, has a clear artifact as its output, and touches tools that are easy to move into a single Toolbox. Route the middle step to a Foundry hosted session, keep the trigger, retry, and audit logic in n8n, and measure cost per successful artifact for a week. Not cost per token. Cost per useful outcome.
Step 3: Wire Foundry evaluations as a dry-run gate
Before Foundry writes to any customer-facing surface, run every job through the eval suite first, return the score to an n8n Function node, and let the workflow decide whether to approve, edit, or reject before any write happens. If the eval budget is too tight to run on every call, sample and alert on drift instead of skipping.
Step 4: Move one mobile background job at a time
Pick the highest-friction mobile-triggered background job. Route it to Foundry through n8n, keep the previous multi-step pipeline as an automatic fallback on timeout or shape errors, and measure end-to-end time from mobile trigger to mobile push. Do not batch-migrate every mobile background job.
Step 5: Add Voice Live only after the text path is stable
Voice Live is a great mobile surface, but it multiplies the failure modes: transport, latency, tool timing, and the model at the same time. Ship the text path on Foundry first, prove it survives real traffic for two weeks, then wire push-to-talk on the mobile app through Voice Live for one clearly bounded flow (support triage, field entry, or an intake questionnaire). Do not launch voice as the first Foundry surface a customer meets.
Where This Sits in the Halmob Stack
The pattern maps cleanly onto how we already deliver at Halmob. The mobile app stays a thin client for a real automation layer. The n8n workflows stay declarative and portable. Foundry Agent Service becomes one more runtime behind the routing layer, not a new architecture. For readers coming from earlier posts, this pairs with the ChatGPT Work guide as a second first-party agent lane to route into, and it sits alongside GPT-5.6 Sol Ultra mobile multi-agent orchestration as the pattern for keeping the mobile app snappy while long jobs run on a hosted runtime.
The Bottom Line
Foundry Agent Service GA did not change the shape of agent engineering. It confirmed it. Production hosted agents with per-session sandboxes are a real vendor lane now, Toolboxes retires a shelf of connector glue, Voice Live turns speech into a first-class mobile surface, and enterprise evaluations move a dashboard you would have built in-house behind one bill line. For teams shipping mobile agents and n8n orchestration, the highest-leverage move this quarter is to add Foundry as a new routing target behind an existing router and n8n orchestrator, promote it workflow by workflow, and let cost, latency, and safety logs decide where it belongs. Keep your orchestration layer. Route into Foundry. Do not migrate onto it.
For source material, start with the smol.ai AINews newsletter, the Foundry Agent Service GA announcement on the Microsoft Foundry blog, and the vendor-neutral coverage of the GA and Voice Live public preview. For teams that want Foundry Agent Service wired into a real mobile and n8n product, Halmob builds and operates the routing, orchestration, and automation layers around it.