Foundry Agent Service vs. DNotifier

Part of a series on running AI workflows across model providers — this one compares Microsoft's agent platform to DNotifier without pretending only one can be right.

Microsoft's Foundry Agent Service — the platform that replaced the Assistants API, covered two articles back — is a real, capable agent-building product, not a stopgap. It deserves an honest comparison rather than a dismissal, the same way this series has compared DNotifier against Bedrock AgentCore and against Perplexity's own agent capabilities in earlier batches. Both can build production agents. They're solving the problem from different starting points.

What Foundry Agent Service actually is

Foundry Agent Service is Microsoft's native agent-building layer inside the broader Foundry consolidation covered in Azure AI Foundry vs. Azure OpenAI — a platform for defining agents with tools, memory, and orchestration, built specifically around Azure's own model catalog and Azure's own infrastructure. It's positioned, in Microsoft's own framing, as "an agent platform with models, tools, workflows, and observability," not merely a chat completions endpoint with extra steps.

For a team already committed to Azure — using Azure's identity system, Azure's networking, Azure's compliance and data-residency guarantees — building agents natively inside Foundry Agent Service means those things come for free, integrated at the platform level rather than bolted on.

A genuinely capable agent platform, built to be inseparable from the rest of Azure.

Where DNotifier's approach differs

DNotifier's defineAgent() and Workflow abstractions solve a different problem: building agents that can call Azure AI, OpenAI, Claude, Gemini, and other providers through one consistent interface, without committing the application's architecture to any single cloud's agent runtime. The same Workflow that includes an Azure-backed agent for one step can include a Claude-backed agent for the next, with ctx.state carrying context between them regardless of which provider is behind each step.

This isn't a claim that DNotifier's orchestration is more sophisticated than Foundry Agent Service's — for teams fully committed to Azure, Foundry's native integration with Azure's identity, networking, and compliance tooling is a real, earned advantage DNotifier doesn't try to replicate. The difference is what each one optimizes for: Foundry Agent Service optimizes for going deep on Azure. DNotifier optimizes for staying flexible across providers.

Two different bets about what matters more — going deep on one platform, or staying portable across several.

They can coexist

These aren't mutually exclusive choices in practice. A Foundry-hosted agent, built to take advantage of Azure-native features a specific step genuinely needs, can be one step inside a broader DNotifier workflow that also includes steps calling other providers directly. Nothing about using DNotifier requires abandoning Foundry Agent Service where it's the right tool for a specific piece of the system — the same coexistence pattern this series described for Bedrock AgentCore.

A use case that shows this in practice

A healthcare-adjacent team needed one specific agent step — patient-intake document processing — to run inside their existing Azure compliance boundary, using Foundry Agent Service's native integration with their Azure-based identity and data-residency controls, which were already audited and approved for that specific data. The rest of their application — a multi-step workflow that also called Claude for drafting patient-facing summaries and a separate provider for translation — ran through DNotifier's Workflow orchestration, with the Foundry-hosted intake step invoked as one step in that broader flow. Neither system replaced the other; each handled the part it was actually built for.

The honest tradeoff

Choosing Foundry Agent Service natively for everything means accepting deeper commitment to Azure specifically — a reasonable choice for a team that has already decided Azure is its cloud, and wants agent-level tooling that assumes and rewards that commitment. Choosing DNotifier's orchestration layer for the parts of a system that don't need Azure-specific depth keeps those parts portable if provider needs change later, at the cost of not getting Foundry's most Azure-native integrations for free in those parts.

Neither is the objectively correct choice in general — it depends on how tied to Azure a given team, and a given part of their system, actually is or wants to be.

Frequently asked questions

Can a DNotifier workflow call an agent built in Foundry Agent Service as one of its steps?

Yes, conceptually — a Foundry-hosted agent can be invoked from a DNotifier workflow step the same way any Azure AI deployment can, with DNotifier handling the surrounding orchestration.

Is Foundry Agent Service a requirement for using Azure AI models through DNotifier?

No — the basic provider: "azure_ai" integration covered in Azure AI on DNotifier: Setup Guide works directly against Azure AI deployments without requiring Foundry Agent Service specifically.

Does DNotifier plan to replicate Foundry Agent Service's Azure-native features?

That's outside the scope of what this article can verify — the comparison here is about what each platform is built to optimize for today, not roadmap speculation.

Is it wasteful to use both systems in the same overall application?

Not inherently — using each where its strengths actually apply, as in the use case above, is a reasonable architecture rather than a compromise.

The Bottom Line

Next in this series: two different ways to authenticate against Azure AI, and when each one is actually the better choice.

Read part nine: Entra ID vs. API Keys on Azure. Explore dnotifier.com.