A daily operations brief is straightforward until the agent misses a run, receives the same work twice, or reports on the wrong reporting window. The challenge is no longer generating a useful answer on demand. It is deciding what one unattended run is allowed to do and how to establish that the work is complete.
A schedule supplies a starting condition. The application needs a run contract that defines inputs, authority, time boundaries, outputs, recovery, and ownership. Establish that contract before enabling recurring execution.
Choose a task with a verifiable end
Microsoft introduced Routines in public preview in the June Build recap. The July 7 Foundry digest continued to describe Routines as preview for scheduled and triggered execution. Treat that as the maturity basis for an evaluation at this stage, rather than assuming a production service commitment.
Begin with a task whose outcome is easy to inspect. A report summarizing completed maintenance work is a better initial candidate than an agent that can independently change maintenance schedules and notify customers. The first produces evidence for review; the second creates several external commitments.
For a hypothetical maintenance-reporting agent, define the approved data sources, business unit, reporting period, output location, and recipients. Make those application configuration. The model can summarize the permitted records without choosing a broader scope or a new audience.
Give the run an explicit result type: completed, completed with declared gaps, awaiting review, failed, or superseded. A fluent report should not be the only success signal. The operator needs to distinguish “nothing happened” from “the agent could not retrieve the records.”
Define time as business data
Choose a business timezone and use explicit period boundaries. “Yesterday” is ambiguous when the service, database, and users operate in different zones. Persist the intended window with the run so a retry uses the same interval.
Decide whether records are selected by event time, completion time, or last modification. A maintenance job completed late but entered the following morning can otherwise disappear between reports. Consider a correction or reconciliation policy for late-arriving data.
Keep the reporting window independent from the actual start time. If the task begins late, it should still process the intended period unless the run policy explicitly says otherwise. Moving the window during recovery makes successive reports difficult to compare.
A catch-up decision also belongs in the contract. After an outage, should the application create each missed report, produce a consolidated report, or notify an operator? None is universally correct. Choose according to the consumer’s needs and record the choice.
Make repetition safe
Assign a stable business key to each intended result, such as business unit, report type, and reporting window. A retry should reconcile that key before producing another externally visible result.
The February durable-orchestration description provides background on workflows that wait and resume. Persistence helps coordinate execution, but the application still needs to establish whether an external write completed. Resuming a workflow is not proof that its effects occurred only once.
For the reporting example, write an internal versioned artifact before delivery. Mark which artifact is approved for distribution. If delivery times out, inspect its authoritative result before resending. Avoid letting a language-model explanation substitute for delivery evidence.
The 2024 τ-bench study assesses task outcomes through final database state and repeated trials. That evaluation principle transfers well to unattended runs: inspect the report and delivery state after retries, rather than judging only the agent’s final message.
Repeated execution can also produce a different summary from the same records. Keep the source snapshot or record versions needed to explain the difference. If a corrected report supersedes an earlier one, preserve that relationship rather than pretending both are independent daily results.
Bound authority and failure handling
Use a dedicated identity with only the access required by the recurring task. Revalidate permission at execution time. A schedule created by an authorized person should not become permanent permission to read data after access changes.
Restrict destinations through application configuration. A malicious instruction in a service record must not redirect the report or add a recipient. Treat retrieved text as information about the task, not authority to redefine it.
Set resource and retry bounds. Decide how long a run may continue, how many recoverable attempts are permitted, and when an operator receives an actionable failure. An agent should not keep searching indefinitely because a source system is unavailable.
Give incomplete data an explicit handling rule. If one approved source fails, the application may permit a report that clearly identifies the missing section, or it may require withholding the report. The business owner should make that decision before a live failure forces an improvised answer.
For any write-capable extension, separate proposal from execution and preserve the required approval. A timer can authorize starting analysis without authorizing the agent to make every change it recommends.
Prove useful unattended operation
Test duplicate invocation, a delayed start, a restart after artifact creation, a timeout after delivery, revoked access, and late-arriving records. Verify both the intended output and the absence of duplicate external effects.
Add a failure rehearsal for operators. They should be able to find the relevant run, identify the missing or uncertain step, and recover it without manually rebuilding the whole conversation. Keep source and output identifiers in the operational record.
Measure useful completed runs, incomplete reports, delivery errors, duplicate results, correction effort, and the time required to resolve failures. Track total cost per accepted report, including review and operation. A higher run count is not automatically a better outcome.
For the pilot, compare the generated brief with the existing manual report over equivalent periods. Ask the report’s consumers whether it changes a decision or saves meaningful effort. If they must reconstruct the source analysis every day, the automation has not yet earned its operating cost.
Keep the preview evaluation separate from the production commitment. Once the task boundary, recovery path, and value are established, the team can reassess the service’s release status and deployment requirements. A reliable recurring agent begins with a precise definition of one successful run.
References
Microsoft: Foundry Build Edition, June 2, 2026
Microsoft: June digest, published July 7, 2026
