Two different jobs that get called the same thing
“Agentic AI platform” gets used to describe two genuinely different jobs, and most of us, including us at times, aren't careful about separating them.
Job one is building and running an agent. Model access, a runtime that calls tools and reasons through steps, identity so the thing can't do more than it should, observability, infrastructure that doesn't fall over at scale. This is what Foundry does. Foundry Agent Service hit general availability with multi-agent orchestration built in, and Microsoft's Agent Framework and hosted agents reached GA not long after. I'm not going to pretend that's a small thing. It isn't.
Job two is turning “an agent that calls tools” into a process your company will actually trust to run without someone watching it. That's a different kind of problem. It has nothing to do with whether the agent can technically call an API and everything to do with whether it knows a purchase order needs a three-way match before it clears for payment, whether a supplier risk score crossing some threshold gets escalated to an actual named person instead of quietly logged, whether a contract clause that deviates from policy gets routed to legal instead of waved through. And whether all of that gets written down somewhere an auditor can find it a year and a half later, because eventually one will look.
Foundry gives your team the tools to go build that. It doesn't hand it to you finished. And here's the part I'd actually ask you to sit with for a second: I don't think it's supposed to.
Why the platform your team built on didn't build the process for you
Try this question on Microsoft: do they actually want to own your procurement approval hierarchy?
I'd bet not, and not because they can't. Microsoft sells into manufacturing, healthcare, banking, insurance, government, energy, all of it, at once. A shipbuilder's supplier risk policy has nothing in common with a hospital's prior-authorization workflow, which has nothing in common with how a regional bank onboards a new vendor. If Microsoft tried to bake all of that directly into Foundry, they'd stop being a platform and start being an unmanageable stack of vertical products nobody asked them to build.
So their strategy, which I think is the right one for them, is to stay horizontal. Own the models, the runtime, the identity and governance layer, and let partners and internal teams handle the business logic. That's why you can bring your own model into Foundry, your own framework, LangGraph or OpenAI's Agents SDK or Anthropic's SDK or Microsoft's own. It's a foundation meant to be built on top of. Not a finished product.
Which means, if your team has fifty agents running today, what you probably have is fifty separate, hand-built answers to the same underlying question: how do we encode this specific process correctly. Most of that engineering time had nothing to do with the model or the runtime. It went into getting the workflow logic right, over and over, once per agent.
I've seen this play out with more than one team we've talked to this year: an internal platform group ships their tenth or fifteenth agent, and someone finally asks out loud why they're rebuilding the same approval-routing logic, the same PII checks, the same cost tracking, from scratch every time. Usually nobody has a good answer. That's the moment this conversation gets interesting.
Do the arithmetic on it. Going from ten agents to fifty without a shared layer means something like ten to fifty separate implementations of workflow logic, governance, and monitoring. Your engineering and oversight burden scales right alongside your agent count, roughly one to one. Build that layer once and share it, and it doesn't. That's not an abstract architecture preference. It shows up on a headcount plan.
What's actually in that layer
I don't want to leave this vague, because vague is how thought leadership pieces lose credibility. Here's what we mean by the operations layer, concretely, mapped to how an agent actually moves from a prototype to something running in production:
Building it means multi-agent orchestration plus connectors into your models, your data, your existing systems, so nobody's hand-wiring the same integration twice.
Instructing it means your prompts and agent skills live somewhere versioned and centralized, so when a policy changes or a new model comes out, that's a controlled update in one place instead of a scavenger hunt across every agent that touches it.
Protecting it means guardrails that are actually programmable: PII handling, policy checks, which tools an agent is even allowed to call, budget limits, applied the same way everywhere instead of reinvented by whichever team built that particular agent.
Watching it means real tracing, cost, latency, what actually happened on a given run, down to the literal text sent to the model and what came back. Not an estimate. The actual thing.
And proving it means keeping a record good enough to survive a compliance review: what the agent decided, what it based that on, who signed off or overrode it.
That's what we've built. Not a layer on top of your agents so much as the thing that makes each one worth trusting.
The three gaps I keep coming back to
If the infrastructure is already handled, here's what I think is genuinely still missing. Not hand-wavy, specific.
First, the workflow logic itself, already worked out. Not a framework flexible enough that you could eventually build a procurement workflow on it. An actual procurement workflow, approval routing and exception handling and audit trail included, built by people who've done this before and hit the edge cases already. That gap is measured in months of someone's engineering time, not in a feature comparison table.
Second, knowing what a call actually costs you, and why. This one surprised me the first time I dug into it, so I'll be specific rather than round the number off. There's a Microsoft Q&A thread where a developer built an agent whose entire job was to respond “Hi” to any input, and watched it burn somewhere between 2,300 and 2,700 tokens per call (Microsoft Q&A: “Excessive Token Usage for Simple 'Hi' Response,” learn.microsoft.com/en-us/answers). Microsoft's own response in that thread points to background components, default system prompts, memory windows, plugin schemas, tool-handling scaffolding, that get carried into every call whether or not that call actually uses them. That's not a one-off bug report. It's a known pattern, and if your input-token costs already make up most of your bill, which is common once you're running more than a handful of agents, that overhead compounds quietly in a place most teams aren't looking. Being able to see exactly what got sent to the model, every time, is the difference between assuming your costs are under control and actually knowing.
Third, surviving the next model upgrade without a rewrite. Anyone who's lived through a frontier model version bump knows this pain already: prompts you tuned carefully against one model's quirks don't transfer cleanly to the next one. If your fifty agents each have prompts wired directly into their code and tied to a specific model generation, that migration cost comes back every time a new model ships, and at the rate things are moving in 2026, that's every few months, not every couple of years. Version your prompts independently of the model underneath them, and that recurring fire drill turns into a comparison you run once, on your own timeline.
What this means practically
None of this is me telling you to walk away from Foundry. It's closer to the opposite. Foundry is the ground floor, and what's missing sits on top of it, not instead of it.
The actual question isn't Foundry versus something else. It's whether your team wants to keep re-deriving workflow logic, cost visibility, and governance from scratch every time someone stands up a new agent, or whether it makes more sense to start from something that's already solved that part, so your engineers spend their time on the piece of the problem that's actually specific to your business.
If you've already got a real fleet of agents running, this isn't hypothetical for you. You've lived it. My honest pitch is a narrow one: keep the models, keep the runtime, keep the Azure investment you've already made. Add the layer that turns “an agent that can call a tool” into something you'd actually stand behind in an audit, without your governance and engineering headcount having to grow in lockstep with every new agent you ship.
That's a smaller claim than “we've got a better platform.” It's also the true one. It's what we've built elsai to be.
If you want to see where you actually stand
Get an architecture session
Send me your agent count and I'll tell you, roughly, how much of it is duplicated work. Most teams are surprised by the number.
Recent blogs
Secure your agents
We’d love to chat with you about how your team can secure and govern Ai agents everywhere
