Azure AI Foundry Agent Service: Building Production-Grade AI Agents with Managed Memory and A2A Protocol

Microsoft shipped more agent infrastructure in the December 2025 to January 2026 window than the previous six months combined. If you blinked, you missed three rebrandings and a fundamental shift in how Azure positions its agent platform.

The short version: Azure AI Foundry became Microsoft Foundry (cross-cloud, not Azure-only), the SDK consolidated into a single azure-ai-projects v2 package, managed long-term memory entered public preview (free during preview), and A2A protocol tooling launched for cross-framework orchestration. Production observability — monitoring, evaluations, cost tracking — is now GA.

If you are building AI agents on Azure, this changes your architecture options significantly. Here is what actually matters and what is still marketing.

What Changed

1. Managed Long-Term Memory (Public Preview)

The headline feature. Foundry Agent Service now provides persistent, managed memory for agents — no external vector database required.

from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

client = AIProjectClient(
    endpoint="https://your-project.cognitiveservices.azure.com/",
    credential=DefaultAzureCredential()
)

# Create an agent with managed memory
agent = client.agents.create_agent(
    name="invoice-processor",
    model="gpt-4o",
    instructions="Process invoices and remember vendor payment patterns.",
    # Managed memory — agent remembers across sessions
    enable_long_term_memory=True
)

# The agent can now recall information from past interactions
response = client.agents.create_run(
    thread_id=thread.id,
    agent_id=agent.id,
    messages=[{"role": "user", "content": "What were the last 3 invoices from Contoso?"}]
)

What this replaces: Previously, you needed to build your own memory layer — typically Azure AI Search (vector store) + custom embedding pipeline + session management. Managed memory eliminates this for standard use cases.

When to use managed memory vs. external vector stores:

Factor Managed Memory External Vector Store
Setup complexity Zero config Full pipeline setup
Data control Microsoft-managed You control the data
Custom embedding models No Yes
Query flexibility Basic recall Advanced filtering, hybrid search
Compliance requirements May not meet data residency Full compliance control
Cost at scale Free during preview, TBD after Predictable (AI Search pricing)

My recommendation: Start with managed memory for prototyping and non-sensitive data. Move to Azure AI Search or Cosmos DB vector search when you need data residency guarantees, custom embeddings, or advanced query patterns.

2. SDK Consolidation (azure-ai-projects v2)

Microsoft consolidated four SDKs into one:

Before (v1):
  azure-ai-ml          → Model management
  azure-ai-resources   → Project management  
  azure-ai-openai      → OpenAI endpoints
  azure-ai-inference   → Inference APIs

After (v2):
  azure-ai-projects    → Everything

Migration is straightforward but not automatic:

pip install azure-ai-projects --upgrade

# v1 pattern (deprecated)
from azure.ai.ml import MLClient
from azure.ai.resources import AIProjectClient as ResourceClient

# v2 pattern (current)
from azure.ai.projects import AIProjectClient

The main breaking change: authentication patterns unified under DefaultAzureCredential. If you were using API keys directly, you need to switch.

3. A2A Protocol Support

Foundry agents can now advertise AgentCards and participate in A2A-orchestrated workflows. This is the interoperability play — your Foundry agents can collaborate with LangGraph agents, AutoGen agents, or any A2A-compatible system.

# Foundry agent with A2A enabled
agent = client.agents.create_agent(
    name="data-analyst",
    model="gpt-4o",
    instructions="Analyze data and return structured insights.",
    a2a_enabled=True  # Automatically exposes AgentCard
)

# The agent is now discoverable at:
# https://your-project.cognitiveservices.azure.com/.well-known/agent.json

4. Production Observability (GA)

The monitoring dashboard now tracks: - Token usage per agent run - Cost attribution by agent and thread - Latency distributions (P50, P95, P99) - Evaluation metrics (groundedness, relevance, coherence) - Tool call traces end-to-end

This is the feature that makes Foundry viable for production. Without observability, you are flying blind. With it, you can justify agent deployment to finance and compliance teams.

Managed vs Self-Hosted: The Real Decision

The question I get most often: "Should I use Foundry's managed agent runtime, or build my own with LangGraph/AutoGen/custom?"

Choose Foundry when: - Your team is Microsoft-centric (Azure, Entra ID, Microsoft 365) - You need compliance certifications out of the box (SOC 2, ISO 27001, HIPAA) - Managed memory is sufficient for your recall requirements - You want cost tracking and observability without building infrastructure - Your agents are relatively straightforward (tool calls, conversation, memory)

Choose self-hosted when: - You need full control over the model (fine-tuned, self-hosted, non-Azure) - Your agent architecture is complex (multi-agent with custom routing) - You need custom memory implementations (graph RAG, hierarchical memory) - Data residency requires specific infrastructure not available in Foundry regions - You are already invested in a framework (LangGraph, AutoGen, custom)

The hybrid approach — which I recommend for most enterprise deployments — uses Foundry for model hosting and observability while keeping custom orchestration:

Custom Orchestrator (LangGraph / Hermes / custom)
    │
    ├── Model calls → Azure AI Foundry (hosted models)
    ├── Observability → Foundry monitoring (cost, latency, evals)
    ├── Tool access → MCP servers (custom + Foundry-hosted)
    └── Agent communication → A2A protocol (Foundry agents participate)

This gives you the best of both: Azure's model hosting and monitoring without being locked into Foundry's orchestration model.

SDK Migration Checklist

If you are on the v1 SDK, here is the migration path:

# 1. Install v2
pip install azure-ai-projects --upgrade

# 2. Update imports
# Find all: from azure.ai.ml import / from azure.ai.resources import
# Replace with: from azure.ai.projects import AIProjectClient

# 3. Update authentication
# Old: MLClient(subscription_id, resource_group, workspace)
# New: AIProjectClient(endpoint, credential=DefaultAzureCredential())

# 4. Update agent creation calls
# Check azure-ai-projects SDK reference for parameter changes

# 5. Test locally before deploying
az login
python -m pytest tests/test_agents.py -v

Cost Considerations

Foundry pricing during the preview period is aggressive:

  • Managed memory: Free during preview
  • Agent runs: Billed per token (model-dependent)
  • Observability: Free during preview
  • A2A protocol: Free (open standard)

Post-preview, expect managed memory to be priced per GB-month (similar to Azure AI Search). For a typical agent handling 1,000 conversations/day with 50 tokens of memory per conversation, that is roughly 1.5M tokens/month of memory — likely $5-15/month based on current storage pricing.

The real cost driver is model inference, not memory or orchestration. A GPT-4o agent handling complex multi-turn conversations costs roughly $0.15-0.50 per 1K conversations depending on message length.

What I Would Do Differently

After building agents on both Foundry and custom infrastructure:

  1. Start with Foundry for the first agent. The managed runtime eliminates infrastructure overhead and lets you validate the business case. Migrate to custom orchestration only when you hit a specific limitation.
  2. Use managed memory for prototyping, external vector stores for production. The managed memory preview is excellent for getting started, but data residency and compliance requirements will eventually force you to externalize.
  3. Invest in MCP servers early. Whether you use Foundry or custom orchestration, standardizing tool access via MCP pays dividends when you add new agents or tools.
  4. Do not skip observability. Foundry's monitoring dashboard is the easiest path to production-grade observability. Even if you run custom orchestration, forward traces to Application Insights and use Foundry's evaluation tools.

Key Takeaways

  1. Microsoft Foundry (formerly Azure AI Foundry) is now the unified agent platform. The SDK consolidation, managed memory, and A2A support make it the most complete managed agent runtime on Azure.
  2. Managed memory eliminates the vector store setup tax. Use it for prototyping and non-sensitive workloads. Externalize for compliance and advanced query needs.
  3. A2A support means Foundry agents are interoperable. Your Foundry agents can collaborate with LangGraph, AutoGen, or any A2A-compatible agent without custom bridges.
  4. The hybrid approach is usually right. Use Foundry for model hosting and observability; keep custom orchestration for complex workflows. Do not force your architecture into Foundry's orchestration model unless it fits.
  5. Production observability (GA) is the real game-changer. Cost tracking, latency monitoring, and evaluation metrics make agent deployment justifiable to stakeholders who need numbers, not demos.

Resources