The schedule starts the agent.
Who owns the result?

Microsoft's September 24, 2026 announcement describes Routines as bringing triggers, agent actions, identity, connections and run history into a Foundry project. Invocation and tool use can run under the routine creator's identity or the agent's identity. A later Foundry roundup shows what an application must do after that start. Its title refers to September, but its publication metadata gives October 16, 2026. Read the two accounts together: the announcement describes the execution service; the roundup follows a report through an application.

Routines is labelled generally available; the agent-directed reminder tool is still preview. Neither status establishes end-to-end delivery reliability. The roundup explicitly says Routines does not replace multi-agent orchestration or approval workflows. A managed trigger may remove the need to maintain a separate scheduler, but the application still has to track accepted work, preserve results and handle uncertain sends.

The roundup's changelog workflow divides the work between an agent that gathers public evidence and another that prepares and delivers the report. The application saves a job before acknowledging acceptance, then provides separate ways to inspect status and retrieve the result. The caller can stop waiting without losing the accepted job's identity. At the handoff, the receiver owns its report copy and delivery record rather than assuming access to the producer's private storage. The October 13 demonstration reportedly delivered a saved report and supported navigation within the same card. The producer then adopted the receiver's message receipt without sending again. That is a useful application example, but it was manual routine dispatch. Although the author says the Monday schedule is enabled, the completed demonstration does not establish a calendar-triggered Monday run or unattended production reliability.

Microsoft describes creator identity as delegated access within the creator's permissions, suited to tools using user authentication. Agent identity uses independently configured Microsoft Entra ID permissions, with tools authenticated through keys or managed identity. Check that choice against every actual connection; a schedule is not itself an access grant. Record who approves the permission scope and who can disable execution. For creator-based access, ask what happens if that person leaves or their permissions change. For agent-based access, ask who reviews permissions and maintains connections. These are recommended ownership checks, not lifecycle behavior established by the articles. Also name a delivery owner to approve the destination and resolve ambiguous sends. Otherwise, each component can report success while nobody answers for a missing report.

Start with one report of a defined scope. Inspect the trigger and invocation history for the initiating event, time and configured identity; distinguish manual, calendar-based and event-based starts. Next, find the durable acceptance record, its job identifier and a status you can retrieve later. An API response saying that work was accepted is insufficient if the application subsequently cannot find it. Then retrieve the completed report and supporting sources, keeping coverage gaps visible. A finished invocation is not necessarily a finished business artifact, and saving a report does not establish its correctness. Finally, match the delivery acknowledgment to that report and the approved destination. A channel message receipt supports delivery, not human reading or approval. Request separate evidence of scheduled execution, and exercise interrupted-job and lost-acknowledgment cases. These are proposed acceptance checks, not tests performed for this analysis. Keep an unknown acknowledgment distinct from both confirmed failure and confirmed delivery: retrying an uncertain send can create a duplicate.