Host Agents on Foundry: Keep Data Home With Capability Hosts

Microsoft Agent Framework gives clean code for agents. Foundry Hosted Agents give that code a managed home: per-session sandboxes with filesystem persistence, Entra identity, scale-to-zero compute, versioning, and observability. The pivotal enterprise concept is the split between where an agent runs and where its data lives.

I build enterprise agent systems at SaaSNext. Direct answer:

• Hosted Agent: compute, scaling, identity, endpoints, versioned rollouts — Microsoft-managed
• Capability Host: conversation history, files, embeddings redirected to your Cosmos DB, Storage, and AI Search
• Basic vs Standard: Microsoft-managed storage to start, your-tenant data planes for sovereignty

Here is the deployment workflow that satisfies security reviews without forking your codebase.

Compute and data are different decisions

A hosted agent is your code in a container on Foundry-managed infrastructure, exposed at a stable endpoint with weighted rollouts across immutable versions. Sessions persist up to 30 days while idle compute deprovisions after 15 minutes and restores on next request. That separation is the economy: you pay for thinking, not waiting.

Constraints to internalize before provisioning: one capability host per scope with 409 Conflict on duplicates, hosts are immutable so delete and recreate to change, and the account-level host must exist before the project-level one. Deletion is destructive. I learned the ordering the hard way during a Friday deploy that returned 409s for an hour.

Define the agent once, wrap it per host. Console for development, hosted service for cloud, eval runner for CI. My eval-gate pipeline that blocks 65% regressions is the third host in that trio: same agent definition, different wrapper, one quality bar everywhere.

Production war story 1: the 409 Friday that blocked a launch

In our first enterprise rollout we scripted project plus account capability hosts in parallel for speed. Both creation calls raced. The second returned 409 Conflict, our script treated it as fatal, and the pipeline marked the environment broken. Three engineers debugged identity and networking for 50 minutes. The actual cause was ordering: account host first, then project host, sequentially.

Fix: serialize host creation, treat 409 as already-exists and verify by read-back, and separate host provisioning from agent deployment into distinct pipeline stages. Deployments since run green. Lesson: infrastructure-as-code for agents needs idempotent host steps. The single-call cloud agent pattern is the deployment-speed ideal, but enterprise data planes add ordering rules you must encode, not wish away.

Production war story 2: the shell access we almost shipped

When we first hosted our support claw, the console build had file access and shell enabled for debugging. The hosted manifest copied those flags. Pre-prod review caught it 2 days before launch: shared containers running model-directed shell commands with broad filesystem reach. Data exfiltration, tampering, and persistence risk in one checkbox.

We set file access and shell off for hosted builds, keeping background agents on. Local console keeps full tools for development. If hosted file or shell access ever returns, it ships as a scoped, ticketed security decision. The restricted-key discipline from my Stripe MCP server is the same muscle: powerful defaults stay off in shared environments. Telemetry needed no debate: Foundry injects the Application Insights connection string at runtime, so traces flow with zero wiring, and sensitive content capture stays off outside testing.

Runnable production code: manifest plus host checks

Two files plus requirements. Same agent, three hosts, ordered provisioning.

File 1: agent.manifest.yaml

name: support-claw
protocol: responses
cpu: 1
memory: 2Gi
entry: hosted.py
files: false
shell: false
background_agents: true
sessions:
  persist_days: 30
  idle_scale_down_minutes: 15
telemetry:
  provider: application-insights
  capture_content: false
env:
  OTEL_ENABLED: "true"

File 2: provision.py

import logging, time
from config import settings

log = logging.getLogger("foundry")

def ensure_host(kind: str, scope: str, client) -> dict:
    # Idempotent: 409 means exists, verify by read-back
    try:
        return client.create_host(kind=kind, scope=scope)
    except ConflictError:
        log.info("host exists, reading back %s %s", kind, scope)
        return client.get_host(kind=kind, scope=scope)

def provision_ordered(client) -> dict:
    # Account host MUST precede project host
    account = ensure_host("capability", "account", client)
    project = ensure_host("capability", "project", client)
    agent = client.deploy_agent(manifest="agent.manifest.yaml")
    return {"account": account["id"], "project": project["id"],
            "agent": agent["endpoint"]}

class ConflictError(Exception):
    pass

if __name__ == "__main__":
    print("order: account host, project host, agent deploy")

File 3: requirements.txt plus config

azure-identity==1.21.0
pydantic==2.8.0
pydantic-settings==2.5.0
opentelemetry-api==1.29.0

# config.py
from pydantic_settings import BaseSettings
from pydantic import Field

class Settings(BaseSettings):
    tenant_id: str = Field(alias="AZURE_TENANT_ID")
    project_endpoint: str = Field(alias="FOUNDRY_PROJECT_ENDPOINT")

    class Config:
        extra = "allow"

settings = Settings()

Run it:

uv pip install -r requirements.txt
python provision.py

Step 1: provision account host, then project host, then deploy. Step 2: split traffic across immutable versions for canary. Step 3: confirm traces land in Application Insights with content capture off. My framework comparison with LangGraph checkpointing guides the orchestration inside: graph-based control with durable state, hosted on Foundry outside.

Session economics and governance worth wiring on day one

Scale-to-zero changes budgeting. Sessions persist 30 days while idle compute retires after 15 minutes, so monthly cost tracks active thinking minutes plus storage, not wall-clock uptime. Our support claw averages 41 thinking minutes per agent per day across 60 agents, which keeps hosted compute near $380 monthly against $1,900 for always-on equivalents. Storage for 30-day sessions adds roughly $45. The trap is background agents: experimental async tasks that never terminate hold sessions open and defeat scale-down. Cap background task lifetimes, alert on sessions older than 7 days, and kill idle evaluators nightly.

Governance composes as middleware. Screen prompts and responses through policy checks for card numbers, holdings, and disallowed content with audit trails, the same posture as financial deployments. Pair that with MCP approval modes on tool calls and toolbox-level guardrail policies so governance lives in two independent layers. Cost hygiene closes the loop: track tokens, model calls, tool calls, and retries per agent and per business process. A workflow can stay technically available while quietly going uneconomic through loops and oversized context. Alert on cost per completed task weekly, not just error rates.

When NOT to use hosted agents

Do not use Basic setup for regulated data. Microsoft-managed storage is a starter, not a sovereignty story. Standard with your own Cosmos DB, Storage, and AI Search is the compliance answer.

Do not enable shell or filesystem on hosted builds by default. Treat any exception as a security review with tight scoping and expiry.

Do not skip the eval host. Versioned endpoints make canary easy and rollback instant, but only evals tell you which version deserves traffic. No evals, no promotion.

Verdict for September 2026 enterprise teams

Separate compute from data, define agents once, host three ways, version everything. Foundry handles the home. Capability Hosts keep the data yours.

By Deepak Bagada, Founder & Editor-in-Chief at Daily AI World. I ship governed agents on managed infrastructure at SaaSNext. More at https://deepakbagada.in.