
In Short: Microsoft Foundry Routines Let Agents Start Themselves
Most agents only work when someone types into them. Microsoft Foundry routines change that. A routine is a named rule in Foundry Agent Service that runs an agent on a schedule, once at a set time, or when something happens in another system. Microsoft announced routines as generally available on 24 September 2026.
Before routines, a scheduled agent meant building your own scheduler, webhook receiver and token handling around it. Now Foundry queues the run, calls the agent, retries if needed and keeps a run history. That is a small feature on paper, but it is what turns an agent from a chat window into something that does a job every morning without being asked.
This post covers how routines work, the limits worth knowing before you design around them, and where we would and would not use them.
How a Routine Works
Each routine has one trigger (when to run) and one action (which agent to call). Four trigger types are supported:
- Schedule: a recurring run defined by a five-field cron expression and a time zone. The minimum interval is five minutes.
- Timer: a single run at a specific future date and time.
- GitHub issue: runs when an issue is opened or closed in a watched repository.
- Teams message: runs when a new message is posted to a watched Microsoft Teams channel.
The action is always one Foundry agent, called through either the Responses API or the Invocations API. Routines work with prompt agents and hosted agents. Workflow agents are not supported, which matters if you planned to put a multi-step workflow on a timer - you would need to wrap it in a hosted agent instead.
For the two event triggers, the GitHub issue or Teams message payload becomes the agent's input. The input you configure on the routine is only used when you test it manually. So the agent needs instructions that make sense of a raw issue or message, not just a fixed prompt.
You can create routines in the Foundry portal, through the REST API, with the Python, JavaScript and .NET SDKs, or with the Azure Developer CLI. The portal is the quickest way to try one. It offers daily or weekly recurring schedules and one-time runs, and it uses your browser's time zone. If the time zone matters (and for a UK team running on GMT and BST, it does), create the routine through the API or an SDK and set the time zone explicitly.
Identity: Decide This at Creation
Identity is the part that most deserves care. By default, every routine runs as the agent's own identity, so the permissions given to the agent decide what its tools can reach. That is the right default for unattended work, and it fits the approach in our post on governing AI agents with Entra Agent ID.
If the agent's tools need delegated user access, you can opt in to creator identity. Microsoft is specific about what that means: it is the Microsoft Entra identity of whoever created the routine. It is not the agent's author, not a later editor and not the end user. Three consequences follow:
- The identity is set when you create the routine. An update ignores it, so to switch you delete and recreate the routine.
- If the creator loses access to a resource, or withdraws consent, those tool calls fail.
- If a person creates a routine with creator identity and then leaves, you have a dependency on their account. Use a service principal or agent identity for anything that should outlast one employee.
Event triggers add a second identity. The GitHub or Teams connector connection authenticates on its own, separately from the identity the agent runs as. If the connection owner loses access to the repository or channel, the trigger simply stops firing. That kind of failure is easy to miss, so it belongs on someone's monitoring list.
The Limits Worth Knowing
These come from Microsoft's routines documentation, and each one affects design:
- One trigger, one action. To run several agents or several schedules, create several routines.
- Five-minute minimum for schedules. Routines are not for near-real-time work.
- Retries. A failed call is retried up to five attempts in total, with backoff from 5 seconds up to 60 seconds. Each attempt has a 30-second timeout.
- Accepted is not finished. A completed run means the agent accepted the request. For Responses API actions the agent runs in the background, so a green run does not prove the work succeeded. Check the agent's own output and traces.
- No customer-managed keys. Routines do not support CMK encryption. If your project needs CMK, routines are off the table for now.
- Regions. Routines are not available in UK West, Switzerland West, Japan West, UAE North or Norway East. UK organisations with projects in UK West should check before planning around them.
- Private networking works. Projects secured by a virtual network are supported, and the routine follows the project's network configuration.
There is also a related feature: the reminder tool, which lets a hosted agent schedule itself to run again after a delay, for example to check back on a long-running job, with a delay of between 1 minute and 30 days. The reminder tool is still in preview and only works with hosted agents, so treat it separately from routines, which are GA.
What It Costs
The Foundry Agent Service pricing page does not list a separate charge for routines. Microsoft states there is no additional charge for creating or running Foundry-native prompt agents; you pay for model tokens and for tools such as web search or file search. Hosted agents are billed on the container compute they use.
So the cost of a routine is the cost of the agent run, multiplied by how often it fires. A daily summary is cheap. A five-minute schedule on an agent that calls a large model and several tools is not, and an event trigger on a busy Teams channel can fire far more often than you expect. Do the maths per run first, then multiply. Our guide to the real cost of AI agents covers the token side.
Where We Would Use Routines
The good fits are jobs that happen on a rhythm and need judgement, not just data movement:
- A morning data summary: an agent reads the overnight load results and data quality checks, then posts a short summary of what changed and what looks wrong.
- Issue triage: a GitHub issue trigger that labels new issues, asks for missing details and points to likely duplicates.
- Channel support: a Teams trigger on a support channel that answers routine questions from documented knowledge and flags the rest for a person.
- Weekly compliance checks that compare current settings against a written standard and report differences.
The poor fits are just as clear. If the job is moving data, use a pipeline. If it is a fixed sequence of steps with an approval, a scheduled Power Automate flow is simpler, cheaper and easier for the business to own. And if the agent will mostly be used by business users in Teams, Copilot Studio or Foundry is a choice worth making on purpose rather than by default.
Before any agent runs unattended, test it the same way you would test a scheduled report. Evaluate it on realistic inputs first - our post on evaluating AI agents in Foundry and Copilot Studio covers how - then start with a disabled routine, dispatch it manually, read the run history and only then enable the schedule.
Where Solv Systems Comes In
We build agents in Microsoft Foundry for data and operations teams, and routines are now part of most designs we sketch. The hard parts are rarely the trigger. They are the identity model, the permissions behind the agent's tools, the cost per run, and the monitoring that tells you a quiet routine has stopped firing. If you have an agent that works when someone asks it and you want it doing the job on its own, our AI automation services are the place to start. For the platform background, see our guide to building your first production agent with Foundry Agent Service.
Sources and Further Reading
- From chatbots to automated assistants: Routines in Microsoft Foundry are now generally available
- Automate agents with routines - Microsoft Foundry
- Reminder tool for self-scheduling agents
- Foundry Agent Service pricing
Frequently asked
A routine is a named automation rule in Foundry Agent Service that runs an agent when a trigger fires: on a recurring schedule, once at a set time, or when an external event happens. Foundry queues the run, invokes the agent and keeps a run record. Microsoft announced routines as generally available on 24 September 2026.
Two today: a GitHub issue being opened or closed in a watched repository, and a new message posted to a watched Microsoft Teams channel. Both use a connector connection that Foundry provisions. Other event types are not supported, so anything else needs a schedule or your own integration.
The agent's own identity by default. If the agent's tools need delegated user access, you can opt in to creator identity when you create the routine, which uses the Microsoft Entra identity of whoever created it. You cannot switch identity by updating a routine; you delete and recreate it.
A schedule trigger uses a five-field cron expression with a time zone, and the minimum interval is five minutes. Cron expressions that resolve to a shorter interval are rejected.
The Foundry Agent Service pricing page does not list a separate charge for routines. Each run is an agent invocation, so you pay for the model tokens and tools the agent uses, and hosted agents are billed on container compute. Check the pricing page before you schedule anything frequent.
Microsoft's documentation says routines are available in all Foundry regions except UK West, Switzerland West, Japan West, UAE North and Norway East. A project in UK South is not on that list, but a project in UK West cannot use routines.


