Microsoft’s agents can now run on a schedule. Deciding what they may do is still your job.

The change is in when work starts

Microsoft’s September 24 announcement makes Routines generally available in Foundry Agent Service. A routine can start an agent at a future time, repeatedly on a schedule or after an external event. Initial event integrations include GitHub issues and Microsoft Teams channel messages. The platform brings execution and run history together with the agent’s configuration.

That is an infrastructure improvement, not evidence that the model makes better decisions. A capable assistant that is never invoked cannot monitor anything. An unreliable assistant invoked every morning can repeat its mistakes very efficiently. Our reading is that the new capability removes some operational work while making the quality of the remaining decisions more important.

Source notes: 1. Analysis and proposed examples are identified in the text.

General availability does not mean every configuration qualifies

The current Learn guide supports prompt and hosted agents, not workflow agents, and lists five excluded regions: UK West, Switzerland West, Japan West, UAE North and Norway East. It also says Routines do not support customer-managed-key encryption. A team with that requirement should not treat the launch announcement as a compatibility guarantee.

The same documentation makes agent identity the default. Creator identity must be selected explicitly for delegated access, and authentication for the event connector is separate. Those details matter when an automation keeps working after the person who set it up changes roles.

Our practical recommendation is to write down the owner, required data sources and allowed actions before enabling the schedule. Someone should be able to explain what stops working if that owner loses access—and how the team would notice. We have not audited an organisation’s permissions or tested these transitions.

Source notes: 2. Analysis and proposed examples are identified in the text.

Starting tomorrow and remembering to return are different features

The separate reminder tool is still in public preview and is limited to hosted agents. Its documentation says it can arrange a delayed invocation on the same conversation. Microsoft supplies it without a preview service-level agreement and does not recommend preview features for production workloads.

Imagine an agent checking whether an export has finished. A fresh daily summary can begin with a clean task. A continuation needs to retain which export it started and what remains to be done. That is the useful distinction—not an assertion that an unattended agent should keep polling forever.

For a bounded trial, our suggested stopping rules would name a maximum number of follow-ups, a deadline and a person to contact if the export never completes. A notification should say that the job is unresolved rather than quietly scheduling another attempt. These are design safeguards we propose, not a claim that Foundry inserts them automatically.

Source notes: 3. Analysis and proposed examples are identified in the text.

Permission to run is not permission to send anything anywhere

Microsoft also published a hosted-agent network-egress walkthrough on September 24. These outbound controls remain a preview, separate from the generally available Routines feature. They address which network destinations a process may contact; they do not establish that a particular document is appropriate to send there.

The walkthrough distinguishes Audit from Enforced mode. A saved rule is not runtime proof that a connection was blocked. Its guidance also warns that Audit is not a harmless simulation of every action: transformation and rewriting rules can still execute. Evaluation should use controlled endpoints and non-sensitive data.

Lumacta would keep three checks separate: whether the action was authorised, whether the destination is allowed and whether the payload is suitable. A permitted address can still receive the wrong customer’s document. A perfectly scheduled task can still be outside the authority intended for it. Scheduling does not resolve either problem.

Source notes: 4, 5. Analysis and proposed examples are identified in the text.

A safer first project: prepare a draft, then prove the boundaries

Here is a proposed pilot for a small support team. The agent reads a test backlog and prepares a morning triage draft with links to the original issues. It cannot close issues, message customers or change production settings. A person reviews the draft before anything leaves the team. The first useful outcome is less reading time with a traceable result.

Test an empty backlog, a duplicate event, a revoked connection and a source item that contains instructions to send data elsewhere. Record what happened in the source system as well as the agent’s own account. If a request is repeated, a successful test should not produce an unintended duplicate action.

Then ask a deliberately different question: how much did a completed, useful report cost, including tool calls and follow-ups? A low cost per model response can coexist with an expensive unattended loop. We have not priced or executed this pilot; its value is a specific acceptance test before granting broader authority.

Source notes: 1, 2, 3. Analysis and proposed examples are identified in the text.

Automate the trigger; keep responsibility explicit

Foundry’s announcement matters because an agent can become part of an operating process rather than a chat window someone has to remember to open. But a business process also needs an owner, a stop condition and an intelligible record of what changed.

Our verdict is to begin with a narrow, reviewable output and expand only after the failure cases are understood. The measure of success is not that the agent woke up. It is that the intended work was completed within its permissions, and that someone can tell the difference between completion, failure and a task still waiting.

Source notes: 1, 2, 3, 4. Analysis and proposed examples are identified in the text.