On March 16, alongside the general availability of Foundry Agent Service at NVIDIA GTC, Microsoft promoted Task Adherence from a standalone Content Safety API to a native risk type inside Foundry's guardrail stack. It's now one of the dimensions Foundry Control Plane evaluates continuously across an agent fleet, alongside groundedness, intent resolution, tool-call success, and prompt-injection exposure.
If you've been following our writing on agentic modernization, this update is the platform catching up to a problem we've been describing in customer conversations for the better part of two years. Microsoft calls it task drift. We've been calling it the 70% wall.
They are the same problem, viewed from two ends of the stack.
The mechanic is straightforward. Before an agent invokes a tool, Task Adherence inspects the conversation history and the planned tool call, and asks a single question: does this action match what the user actually requested and what the system was instructed to do?
If yes, the call goes through. If not, the API returns a structured signal:
{ "taskRiskDetected": true, "details": "Agent attempts to share a document externally without user request or confirmation." }
The developer then chooses what to do with that signal: log it, block the tool call, escalate to a human. Microsoft's own documentation gives examples that read like a tour of how production agents fail:
apply_leave(). Task Adherence catches the mismatch; the user asked for information, not a transaction.change_data_plan(). Same pattern; read intent confused with write action.send_email(). Task Adherence flags this as premature: the instruction said write, not send.These aren't even edge cases. They're the modal failure pattern of any agent given a non-trivial toolset and a slightly ambiguous prompt. Microsoft is now treating the prevention of that failure as a foundational platform capability; not a developer-side concern to bolt on later
Promoting Task Adherence into the native risk stack is more consequential than a feature drop. It's a statement about where Microsoft thinks agent reliability has to live.
Three things follow from that placement.
Adherence is now a continuous signal, not a one-shot check. Inside the Foundry Control Plane, task adherence telemetry flows alongside groundedness scores and tool-call success rates. Operators can see drift trends across an agent fleet the way they see latency or error budgets. That changes what's possible operationally: fleet-wide regressions become visible before they become incidents.
The guardrail composes with the rest of the stack. Foundry already had Prompt Shields for injection, groundedness checks for retrieval, and intent resolution for routing. Task Adherence sits at the tool-call boundary, which is the highest-leverage place to intervene. By the time an agent is about to act, every prior failure mode has had a chance to surface. Catching drift there catches the compounded version of every earlier error.
It formalizes the architectural pattern Microsoft introduced in February with Durable Agent Orchestration. That release made it idiomatic to run multi-agent pipelines with persistent state and explicit checkpoints. Task Adherence is the validation layer that makes those checkpoints meaningful. A checkpointed pipeline without adherence enforcement is just a more elaborate way to compound errors. A checkpointed pipeline with Task Adherence is an audit trail.
The 70% wall is the ceiling DIY AI projects hit when they wire a frontier model to a legacy codebase and tell it to "modernize this." For the first stretch, the well-trodden, structurally similar code, the model performs impressively. Then it crosses into the long tail: VB6 COM interop, ASP.NET WebForms ViewState quirks, PowerBuilder DataWindow logic, Access cross-tab queries against linked tables. The model keeps going. It produces output. The output compiles. The output also no longer corresponds to the behavior of the source application.
That is task drift, dressed up in code. The agent's tool (its compiler, its file writer, its test runner) gets called with arguments that no longer reflect the original intent of the migration. Nothing in the system is checking whether the planned action still matches the actual goal.
Microsoft's documentation puts it bluntly: when an agent drifts, even slightly, the results can be costly or unsafe. In a chatbot, that means an unintended subscription change. In a multi-million-line PowerBuilder modernization, it means an application that looks modern, runs on .NET, and produces wrong answers. The hallucination tax is the cost line for cleaning that up.
For anyone evaluating agent platforms (or anyone already running them) the Task Adherence release reframes the buyer question. It's way bigger than "does the model work?" It's "what is the system doing to keep the agent on task, and where in the stack is that responsibility located?"
A useful checklist:
If the platform doesn't answer those questions, the responsibility falls back on the application layer. That's workable, but it has to be budgeted for. The 70% wall is a real line item, and it shows up about three months in.
For our own work building agentic modernization on Foundry, this release formalizes something we'd already had to design around. The Quality Agent in VELO does at the artifact level what Task Adherence does at the tool-call level: validate that the modernized application still behaves like the source before output is accepted. Same discipline, different layer. With Task Adherence now native to Foundry, that discipline becomes table stakes for anyone building on the platform, which is the right place for it to live.