Microsoft Foundry September 2026: Routines and Tool Search Go GA, Insights Enters Preview

The changes are aimed at the dull, expensive parts of running agents in production. Those parts are scheduling, token spend, and working out why something quietly went wrong at 3 a.m.

Routines: Scheduling Without the Plumbing​

A Routine runs an agent on a timer, a recurring schedule, or a supported GitHub or Teams event. Each Routine starts a single agent from a single trigger. Its configuration, identity and run history stay attached to the Foundry project. Teams no longer need to build their own scheduler, queue and identity layer just to wake an agent up.

What Routines are not​

Microsoft draws clear boundaries:

• Routines do not replace multi-agent orchestration or human approval workflows.
• The agent-scheduled reminder tool remains in preview, even though Routines are GA.
• A Routine starting a job does not prove the job finished or that its output was delivered.

The Microsoft Learn documentation backs up that last point with specifics:

• The default delivery policy is five total attempts with exponential backoff starting at 5 seconds and capped at 60 seconds. I'm quoting Learn's routine documentation here, as captured in the research packet.
• Each downstream HTTP attempt has a 30-second timeout. For Responses API actions, that timeout covers acceptance of the background request and creation of the response. It does not cover completion of the agent's work.
• A completed routine run means only that the downstream API accepted the dispatch. Asynchronous work the agent started may still be running or may fail.

Identity and setup details worth knowing​

• By default a routine runs under the agent's identity. If the agent's tools need delegated user access, you must opt in to the creator's identity when you create the routine. That choice is create-time only. To switch, delete and recreate the routine.
• Creator identity means the principal who created the routine, not an arbitrary user chosen at dispatch time. If that person's access or consent is later removed, the delegated tool calls fail.
• Event triggers (GitHub issues, Teams channels) use a separate connector connection. If the connection owner loses access, the trigger stops firing.
• A routine definition holds one trigger. In the portal, the schedule time is read in your browser's local time zone. Use REST or an SDK if you need to pin a time zone.
• Routines work with virtual-network-secured projects. They don't support customer-managed key encryption, so skip them for workloads that require it.
• Workflow agents are not supported. Only prompt agents and hosted agents are.

A sensible rollout​

Nick Brady, Microsoft's principal product manager for developer experience, recommends a staged approach in his roundup. Do a manual run that sends nothing, review the sources, then enable the schedule. In his own demo, the Monday-morning schedule was enabled only after the delivery path worked. He also notes that the demonstration used a manual dispatch, so it isn't proof of a calendar-triggered run.

Mitch Ashley of The Futurum Group, quoted by DevOps.com, puts the risk bluntly. A scheduled agent runs when nobody is watching, and one that starts but never delivers fails silently. That's his assessment, not a Microsoft finding. It does match what the documentation says about acknowledgment versus completion.

In practice, that means:

1. Run a manual dispatch and open the run history.
2. Check the final state, not just the dispatch acknowledgment.
3. Add your own completion and delivery check, such as a receipt written by the agent's application code.
4. Enable the schedule only after those checks pass.

Tool Search: Fewer Tokens, Same Permissions Problem​

Loading every tool definition into every model request burns context before any work starts. With Tool Search, a Foundry Toolbox exposes discovery and invocation through tool_search and call_tool instead of putting every definition in each request. Hosted-agent Toolboxes were already GA, and prompt-agent Toolboxes entered public preview.

Microsoft Learn explains the mechanics. Foundry ranks tools with BM25 against each tool's name, description and parameter information. A tool with a missing or vague description is unlikely to be found. You can pin always-needed tools so they skip the search round-trip. You can also add search keywords through additional_search_text when your team's vocabulary differs from the tool descriptions. The docs say the feature works best with 10 or more tools, and suggest telling the model in the system prompt to call tool_search before concluding a capability is missing.

The savings numbers​

Microsoft reports an internal evaluation, measured against a prompt-cached baseline. It shows input tokens down by more than 60% for a 50-tool toolbox and more than 97% for a 1,000-tool toolbox. Treat those as vendor figures. They are not guarantees for your workload.

Integration provider Nango published a separate synthetic test of its own product, not Foundry. With 57 tool definitions, discovery plus two pinned tools used 69% fewer input tokens per task than loading everything upfront. Discovery alone saved 44%. Nango notes that pinning common tools beat discovery alone across complete tasks. That is a useful hint for tuning Foundry's pinning too, though it isn't proof Foundry behaves identically.

Discovery is not authorization​

Microsoft's demo toolbox exposes seven GitHub read operations. Application code then restricts them to approved repositories, paths and PR-read methods. As the roundup frames it, finding a tool is not permission to use it. Enforce permissions where tools execute, not where the model sees them.

Insights: Traces Turned into Findings​

Insights is in public preview. It analyzes agent traces to surface recurring and previously unknown behavior, explains the likely cause with supporting evidence, and recommends next steps.

From Microsoft Learn:

• It reads traces from the Application Insights resource connected to your Foundry project.
• The first analysis uses a 7-day lookback window. After that you can run scans on demand or enable scheduled generation, depending on configuration.
• Each finding carries a category, a High/Medium/Low severity, a likely cause, highlighted traces and a proposed action. Categories include cost and tokens, latency, reliability errors, security and risk, and tool call failures.
• It needs a GPT-5 or newer judge model. The project's managed identity needs access to that deployment, and the Monitoring Reader role on the connected Application Insights resource.
• Missing identity, content, spans, tool arguments or results reduce the quality of grouping and fixes.
• Microsoft states that severity and diagnosis are decision support, not authoritative classification. Findings can miss real issues or combine unrelated behavior.

In Brady's test workflow, Insights flagged oversized prompts resubmitted after rate-limit errors, sample-heavy prompts that wasted context, and an unconfirmed delivery receipt. None would crash an agent, but all quietly cost money or reliability.

Human in the loop​

Nothing is applied automatically. Microsoft's guidance is to open a finding, check the linked trace, compare against healthy traces, and test the proposed change on the same input before shipping. If the evidence points at a tool, MCP server, data source, network or platform issue, route it to that owner rather than patching the agent. One more detail from the docs: an empty result doesn't prove the agent is healthy. A 404 from the preview API can mean the feature isn't enabled for your subscription context.

Brady's roundup says a rubric evaluator, trace-to-dataset generation and Agent Optimizer were targeted for GA "later this month." That is a target, not a confirmed release. Microsoft's own portal GA overview was, at the time of the search, listing Agent Optimizer as limited preview. Check the current status before you plan around it.

The Rest of the September Update​

Some further detail on the models and router:

• The three GPT-6 models share a 1.05M-token context window and up to 128K output tokens, with reasoning counted inside one shared budget. GPT-6.1 Sol tool calls require the Responses API.
• Microsoft warns that long-context rates are higher, so check current pricing before comparing models.
• One third-party summary says Claude Opus 5.5 from Anthropic is also now available in Foundry. Verify that against your own model catalog, since availability varies.
• Per Microsoft Learn, Model Router's new metadata reports routing mode, latency, ordered model attempts and errors, so you can see when fallback occurred. The model router documentation was later updated for October with more models in the routing pool, so check what your deployment actually routes to.
• Router session affinity can help prompt-cache reuse, but neither a cache hit nor the same model is guaranteed.

Long-running resilience lets hosted agents survive a client disconnect or hosting-process interruption. Microsoft cautions that reconnecting does not make repeated external actions safe. You still need application-level checkpointing and idempotency.

Check Before You Upgrade​

If you use the Azure Developer CLI for hosted agents, Microsoft's roundup flags these changes:

• In azure.ai.agents beta.18 (dated September 30), runtime definitions must live directly in azure.yaml or via an explicit root $ref. Legacy manifest and config discovery is rejected. The extension also requires azd 1.34.2 or later.
• Long-running invocation moves to --long-running and the invocations command group.
• Standalone deploy commands in recent connections and toolboxes releases are removed in favor of azd deploy <service>.
• AgentServer Core's default Azure Monitor trace sampling is 100%. Review trace volume and cost before rollout.

The Learn reference describes azure.yaml as the single project configuration file for hosted-agent projects, covering the project, models, connections, toolboxes, skills, routines and agents. The beta.18 migration details and the 100% sampling default come from Microsoft's roundup. I couldn't confirm them in the separate reference page, so check your own extension release notes before touching deployment automation.

What It Means for Admins and Developers​

The through-line is that agents are being treated like services. They get schedulers, cost controls and telemetry. Ashley argues that what an organization can observe and prove sets deployment pace more than model capability does. That's an analyst's view, but it's a reasonable one. The test he proposes is whether teams route Insights findings through the same release gates they use for code.

A caution on balance: Insights is preview, and Microsoft doesn't recommend previews for production workloads. The headline token savings are Microsoft's own measurements. Routines' GA status does not extend to everything around them.

A practical checklist:

1. Routines: Choose agent or creator identity deliberately, run a no-send manual test, and build your own delivery confirmation.
2. Tool Search: Write good tool descriptions, pin your hot tools, and enforce authorization in the execution layer.
3. Insights: Confirm Application Insights connectivity, roles and judge-model access, then validate each finding against its trace before changing anything.
4. CLI and SDK: Audit azure.yaml and deploy scripts against beta.18 before upgrading.
5. Cost: Review trace-sampling defaults and model pricing tiers.

Foundry now offers better ways to schedule, trim and inspect agents. Whoever builds the agent still owns what it does.