AI/ML

Microsoft Foundry Routines for Enterprise Agent Control

Foundry Routines could be the missing layer between clever demos and repeatable enterprise agents

Frank Garofalo

22 Sep 2026 — 10 min read

Note: “Foundry Routines” is used in this article as a conceptual term for a necessary governance and orchestration layer for enterprise agents, not as an official Microsoft product name.

The real production gap is behavioral variance
Why Routines matter more than people think
Prompt chains versus routinized execution
Approvals and exceptions are the actual test
Observability has to explain the path, not just the answer
Change control is where trust is earned
The trade-off: standardize the work without freezing learning
A pragmatic evaluation plan for Foundry Routines
My take
Sources & References

Last quarter I watched a clean agent demo die in a compliance review in under 20 minutes. The model was fine; the design was sloppy, and that is exactly why Foundry Routines matter.

A convincing agent demo can survive on prompt choreography. Production agents have to survive approvals, exceptions, audits, and the next change request.

That is the gap I want people to focus on.

Microsoft describes Foundry as an AI app and agent factory for building, optimizing, and governing AI apps and agents at scale in Azure AI Foundry. If you read that carefully, the interesting word is not “agent.” It is “governing.” And that is why I think what I’ll call “Foundry Routines” deserve attention as a control point, not as another shiny builder feature. This is not an official product name, but a concept representing the missing layer where clever demos become repeatable operations.

The real production gap is behavioral variance

Teams love to celebrate the happy path.

Agent gets a request. Agent retrieves a few documents. Agent calls a tool. Agent writes a recommendation. Everybody claps because the output looks smart.

Then the first real-world mess shows up:

the approval path differs by region
one source system is stale
the user asks for an action they are not authorized to trigger
the evidence is incomplete
legal wants to know why the agent made recommendation A instead of B
somebody changes a prompt on Friday and Monday’s results drift

That is not a model problem first. That is an execution design problem.

Prompt choreography hides workflow in all the wrong places: system prompts, tool descriptions, retrieval settings, app-side conditionals, developer assumptions, and undocumented human handoffs. You can absolutely ship value that way for low-risk work. I do it in the lab all the time when I am testing patterns on Proxmox VMs before I bother hardening anything in Azure. But if the workflow is consequential, hidden behavior turns into operational debt fast.

In Q1, a 14-person operations team I worked with had an incident triage agent that looked great in a demo and then stalled in production because nobody could explain which cases required human approval after the CMDB lookup failed. That is the kind of failure executives remember.

Why Routines matter more than people think

The useful question to ask about this concept is not “Can Foundry Routines make my agent look more autonomous?”

The useful question is: can a routine make a recurring unit of work explicit enough to review, govern, and own?

That means a routine has to give you a place to define things like:

entry conditions
ordered work
policy checks
approval gates
exception paths
output contract
evidence captured for review

That is where the value is.

Foundry Agent Service is already positioned as a managed platform for building, deploying, and scaling AI agents, with support for frameworks and models in the catalog per the Agent Service overview. So the surrounding platform direction is obvious: Microsoft is tightening the managed surface around how agents are built and run. Routines fit that direction if they become the layer where “clever sequence” turns into “repeatable operation.”

Here is the mental model I use with teams:

Look at the difference in the diagram. The demo jumps straight into agent behavior and tool use. The routinized path introduces policy, review, and audit as part of the execution shape. That is the whole ballgame in enterprise settings.

Prompt chains versus routinized execution

Let me make this concrete with a scenario I see all the time: a vendor-risk decision packet.

The prompt-chain version

You wire up an agent to:

retrieve vendor questionnaire answers
search prior incidents
summarize legal clauses
score risk
propose approve, reject, or escalate

It works. Until it doesn’t.

Because the real rules are scattered:

the “high-risk country” check lives in app code
the “missing SOC 2 report” rule sits in a prompt
the “legal must approve if data residency is unclear” rule exists in a Confluence page nobody encoded
the audit evidence is whatever happened to get logged

That is not a controlled process. That is a talented prototype.

The routinized version

Now take the same business task and give it a visible path:

validate required inputs
run policy checks
call the approved tools
stop if required evidence is missing
route consequential decisions for human approval
return a decision packet plus audit metadata

That does not remove model uncertainty. It gives uncertainty a container.

Here is a sequence I would want architects to reason about before they ever talk about “autonomy”:

The important part is not the diagram syntax. The important part is that you can point to where policy is applied, where tools are constrained, where approval happens, and what comes back to the caller.

That is the difference between a toy and an operating model.

Approvals and exceptions are the actual test

If you want to know whether an agent design is production-ready, stop asking how often it answers correctly and start asking four uglier questions:

Which decisions can run straight through?
Which decisions require approval?
Which conditions must force a stop?
Who owns the exception queue?

Most teams are weak on number four.

Exceptions are not a fallback prompt. They are first-class behavior. You need named handling for:

unavailable tools
conflicting source material
unauthorized requests
low-confidence or low-evidence outputs
downstream API failures
business policy violations

When I say Routines could be the missing layer, this is what I mean. A repeatable unit of work creates a boundary where escalation ownership becomes clear. Without that boundary, conversational agents tend to keep trying, keep improvising, and keep making a mess that humans have to untangle later.

If you want the broader platform context for that, I covered some of the managed execution angle in Durable agents in Foundry Agent Service explained. Durability matters, but durability without explicit operational boundaries still leaves you with chaos that lasts longer.

Observability has to explain the path, not just the answer

A final response is not enough.

For high-value agent work, I want to reconstruct:

what context was used
which tools were invoked
what policy checks fired
where execution diverged
whether approval was requested
what evidence supported the outcome

That is why I like the architectural direction around a Foundry resource. Microsoft’s SDK overview describes the Foundry resource as unified access to models, agents, and tools, with higher-level SDKs building on that common layer in the Foundry SDK overview. Unified access does not magically solve governance, but it does reduce the number of fragmented integration seams where behavior gets lost.

This little conceptual example shows the shape I want teams thinking about:

# Concept: Foundry resource as a single integration point for models, agents, and tools; routine APIs below are preview docs to verify.
from dataclasses import dataclass

@dataclass
class FoundryResource:
    endpoint: str
    project: str

    def model(self, name: str) -> str:
        return f"{self.endpoint}/projects/{self.project}/models/{name}"

    def agent(self, name: str) -> str:
        return f"{self.endpoint}/projects/{self.project}/agents/{name}"

    def tool(self, name: str) -> str:
        return f"{self.endpoint}/projects/{self.project}/tools/{name}"

foundry = FoundryResource("https://foundry.contoso.example", "ops")
print(foundry.model("gpt-4.1"))
print(foundry.agent("incident-triage"))
print(foundry.tool("ticketing-search"))
print("Preview note: routine-specific SDK/REST names are illustrative; verify current docs before implementation.")

Notice what matters here: one integration point, explicit references to model, agent, and tool, and a clear reminder that routine-specific API names need to be verified before implementation. That is the right engineering posture. Treat the control plane as deliberate architecture, not as a side effect of prompts.

And this is the minimum audit envelope mindset I push in workshops:

# Concept: Minimal audit envelope for making agent executions repeatable and reviewable.
import json
from datetime import datetime, timezone

audit_record = {
    "timestamp": datetime.now(timezone.utc).isoformat(),
    "routine": "incident-remediation-preview",
    "agent": "incident-triage",
    "inputs_hash": "sha256:demo",
    "tools_allowed": ["cmdb-lookup", "ticketing-search"],
    "approval_required": True,
    "outcome": "draft-only",
    "preview_api_notice": "Routine API shape is conceptual; verify current Foundry docs.",
}

print(json.dumps(audit_record, indent=2))

What should you observe? The audit record is boring by design. Good governance evidence is boring. It tells you what ran, under what guardrails, and what happened. If your logs only preserve the final answer, you are not operating an enterprise agent. You are operating a black box with a chat interface.

Change control is where trust is earned

A tiny prompt edit can change behavior.

So can:

swapping a model
changing a tool schema
adding a new retrieval source
widening permissions
altering stop conditions
tweaking summarization instructions

Traditional app release processes usually do not capture that well enough. That is why I want routine definitions treated as reviewable operational artifacts with:

named owners
test cases
release criteria
rollback expectations
change records

This is also where identity and access stop being an afterthought. Foundry RBAC guidance already lays out scopes, built-in roles, and assignment patterns, including users or service principals that only need to interact with agents in the Foundry RBAC documentation. That should directly shape how you separate:

platform admins
agent developers
approvers
runtime identities
end users

If the same principal can author behavior, widen permissions, invoke tools, and approve outcomes, congratulations, you built a governance bypass.

I also like using trusted context sources as part of this conversation. The Microsoft Learn MCP Server gives clients and agents access to current official Microsoft documentation through a remote MCP endpoint in the Microsoft Learn MCP Server docs. That is a good example of a governed information-source pattern: not “let the model browse anything,” but “give the agent a trusted lane for a known class of information.”

If this part of the stack is your focus, I went deeper on the surrounding architecture in Microsoft Foundry agent platform for enterprise operations and the runtime side in Azure Functions Skills for Enterprise Agent Architectures.

The trade-off: standardize the work without freezing learning

There is a trap here, and I have seen it in data platforms for years.

The moment a governance feature appears, some organizations try to route every experiment through it. Bad move.

Routinization should be strongest where the work is:

consequential
cross-system
regulated
customer-impacting
financially material

For low-risk exploratory work, keep it lighter. Let teams learn. Let them discover where the real variance sits before you formalize the path.

Otherwise you get the worst of both worlds:

slow experimentation
formalized bad process
fake confidence because the process looks official

A routine will not rescue a business process that nobody can clearly describe. If the business cannot state the approval rule, the stop condition, and the owner for exceptions, codifying the agent path just makes the ambiguity more expensive.

A pragmatic evaluation plan for Foundry Routines

If I were assessing this with a client or in my own lab, I would not start with a broad “agent transformation” program. I would pick one bounded, high-friction workflow where variance and auditability matter more than conversational sparkle.

Here is the evaluation sequence I would use:

1) Pick one workflow with real operational pain

Good examples:

vendor-risk decision packets
finance exception recommendations
incident remediation drafts
access review preparation

Bad examples:

generic chat assistants
broad knowledge bots with no action boundary

2) Document the current hidden workflow

Write down:

prompts
tool permissions
retrieval sources
human approvals
known exception cases
who owns failures today

You will usually discover the “workflow” is smeared across five systems and two people’s heads.

3) Model the routine boundary explicitly

I want a visible execution contract around policy, tools, outputs, and approvals. This conceptual wrapper is the kind of thing I use to force the conversation:

# Concept: Conceptual routine orchestration that wraps an agent call with policy and tool access; preview API names to verify.
from typing import Dict, Any

def run_routine(foundry_endpoint: str, agent_name: str, tool_name: str, task: str) -> Dict[str, Any]:
    request = {
        "foundry_endpoint": foundry_endpoint,
        "agent": agent_name,
        "tool": tool_name,
        "task": task,
        "policy": {"approval": "required-for-high-impact", "max_tool_calls": 3},
    }
    # Preview documentation to verify:
    # response = foundry.routines.run(request)
    response = {
        "status": "simulated",
        "agent": request["agent"],
        "tool_used": request["tool"],
        "decision": "draft remediation plan",
    }
    return response

result = run_routine("https://foundry.contoso.example", "incident-triage", "cmdb-lookup", "Assess failed deployment")
print(result)

What should you do next? Replace the simulated pieces with your actual business checkpoints on paper first. If the team cannot agree on the policy and approval conditions, the agent is not ready for production no matter how good the demo looked.

4) Measure operational outcomes, not demo quality

Track:

path consistency
exception visibility
reviewer effort
time to diagnose failures
ease of controlled change
percentage of cases that stop correctly instead of improvising

That last one matters more than people admit.

5) Tighten least privilege around the workflow

Before you celebrate, review the runtime identity and operator access. This quick RBAC review pattern is the sort of practical hygiene teams skip when they are dazzled by outputs:

# Concept: Compare current roles to a minimal allow-list to support least-privileged agent operations.
param(
    [string[]]$CurrentRoles = @("Reader", "Cognitive Services OpenAI User", "Contributor"),
    [string[]]$AllowedRoles = @("Reader", "Cognitive Services OpenAI User")
)

$review = foreach ($role in $CurrentRoles) {
    [pscustomobject]@{
        Role       = $role
        IsApproved = $AllowedRoles -contains $role
        Action     = if ($AllowedRoles -contains $role) { "Keep" } else { "Review/Remove" }
    }
}

$review | Format-Table -AutoSize

Observe the obvious thing: if a role is not required for the workflow, review or remove it. Least privilege is not paperwork. It is blast-radius control.

My take

Foundry Routines should be judged as an operating-model control point.

That is the standard.

Not whether they make agents feel smarter. Not whether the demo flows more smoothly. Not whether the UI looks polished.

Judge them on whether they make important agent work less surprising, more reviewable, easier to observe, and safer to change.

That is the missing layer between clever demos and repeatable enterprise agents.

Rate your team’s current state on this from 1 to 5: how well can you explain an agent’s approval path, exception path, and audit evidence before it reaches production?

#AzureAI #EnterpriseAI #DataArchitecture

Sources & References

Try it yourself

Run this tutorial as a Jupyter notebook: Download runbook.ipynb (28 cells, 27 KB).