Many useful business automations begin when nobody is looking at a chat window. A request arrives, a deadline approaches or an operational report becomes available. An assistant that only works after someone remembers to ask leaves the business responsible for noticing every trigger.
On 24 September 2026, Microsoft announced general availability of routines in Foundry Agent Service. Routines can invoke agents at a specified time, on a recurring schedule or in response to supported events. The same announcement identifies the separate reminder tool as a preview. This article, reviewed on 2 October 2026, explores a practical first use without treating every related capability as equally mature.
Begin with an operational delay you can describe
A hypothetical equipment supplier receives service enquiries through a shared team channel. Staff review the messages, identify missing information and decide which team should respond. The problem is not that nobody can write a reply. It is that a request can wait unnoticed while everyone assumes another person is handling it.
A useful pilot might prepare a triage record when a qualifying message arrives: the apparent request, missing details, supporting references and a proposed owner. The action should make pending work visible. It should not promise a service date or change a customer's contract without the relevant business process.
Before choosing an agent, ask whether ordinary rules are sufficient. Routing a form using an explicit region code may need no language model. Interpreting varied free-text requests may benefit from one. Combining a deterministic trigger with a limited AI classification can be a better starting point than handing the whole workflow to an agent.
Check the trigger that exists today
Microsoft's routines documentation describes configuration and supported integrations. The announcement's initial event examples include GitHub issues and new Teams channel messages. Do not infer that every CRM, mailbox or ERP is already a native event source. Confirm the connection, authentication method and deployment availability for the intended environment.
Write down the exact start condition. “A customer needs help” is too vague for an event contract. “A new message in the agreed service channel that has not already been processed” gives the implementation a testable boundary. Decide what should happen to edited messages, replies and attachments.
For schedules, agree the business timezone and what a missed run means. A morning report that silently uses UTC when staff expect local time will behave differently when clocks change. These are delivery requirements, not details to discover after people depend on the automation.
Give every request a durable identity
An event can be delivered more than once, and a run can fail after performing part of its work. Design the receiving application so that repeating the same request does not create another customer task or send the same commitment again. Use a durable event reference and record what has been completed.
In the equipment supplier example, one source message should map to one triage item, even if the trigger is retried. A later update can revise that item's proposed classification with a visible history. It should not silently appear as a separate customer enquiry and inflate the team's workload.
Managed execution does not remove this business responsibility. The platform can report that an invocation ran; your application needs to establish whether the intended operation happened once and whether downstream systems accepted it. Keep both kinds of evidence available to support staff.
Assign an identity that survives ordinary staff changes
Decide whose permissions the routine uses and which systems its tools may reach. Document the difference between the person who created the automation and the identity performing the work. Review the supported identity options in the product documentation against the authentication requirements of each tool.
Avoid making an important operational process depend accidentally on a departing employee's personal access. At the same time, a service identity should not gain unrestricted rights merely because it runs unattended. Give it the minimum access needed for the agreed task and test that unrelated records remain inaccessible.
Assign an internal owner even when a supplier maintains the technology. That owner should understand when the automation runs, what it changes and how to stop it. Ownership is especially important when a previously quiet routine starts producing unexpected work after a business process changes.
Put business decisions behind explicit boundaries
Separate preparation from commitment. An agent may propose a service category or draft a response, while an authorised colleague approves a booking, price or external message. The application should recheck permissions and record state when executing an approved operation.
Give uncertain cases somewhere to go. If the request names an unfamiliar product or contains conflicting dates, create a review item rather than inventing a confident classification. Make the reason visible so the reviewer does not have to repeat the entire investigation.
Also consider malicious or irrelevant instructions in incoming content. A message in a monitored channel must not be able to redefine the routine's access, redirect its output to an arbitrary destination or suppress the audit trail. Treat source content as task data and keep authorisation in the application services.
Make failure visible to the people doing the work
Distinguish technical execution from the business result. A run may finish successfully while producing an item that still needs review. Another may fail after saving the triage record but before notifying its owner. Both deserve a clear status that the operations team can understand.
Create a small operational view showing received work, completed work, pending review and failures requiring intervention. Link each item to the source and relevant run history. Avoid measuring success solely by the absence of exceptions in a dashboard that nobody outside engineering can interpret.
Choose a recovery procedure before launch. Staff should be able to retry a safe step, assign a request manually or pause the trigger without deleting evidence. Test those actions with someone who did not build the routine. Their questions often reveal hidden assumptions in the design.
Estimate cost from triggers, not demonstration messages
An unattended agent can run while the office is closed. Estimate likely events, repeated deliveries, document sizes and tool calls, then include rejected work and retries. A busy channel may generate far more activity than a small demonstration suggests.
Apply sensible filtering before invoking expensive reasoning. Limit concurrent work and establish what happens when capacity or the agreed spend limit is reached. Queueing for later and pausing are different business decisions; a time-sensitive service request may need human routing instead.
Measure cost per useful outcome alongside review effort. Saving a small amount of classification time is less attractive if every result requires a long correction. The business case should include integration, monitoring and support, not only the price of model calls.
Launch one complete routine and review the evidence
Choose a bounded audience and run representative cases before enabling live actions. Include ordinary requests, ambiguous messages, duplicates, unavailable tools and revoked permissions. Set acceptance criteria that cover correct routing, visible exceptions and the ability to resume manually.
During the pilot, compare the time from enquiry to an accountable owner with the previous process. Track missed requests and incorrect classifications without claiming that automation alone creates sales. Faster, more reliable handling can support a better customer experience; converting that opportunity still depends on the service offered.
Worktechlabs can help design business AI workflows and connect them to existing systems through reliable integrations. Our guide to background jobs in .NET covers the underlying question of how to make unfinished work visible. Routines become valuable when the business can see what started, what happened and who handles what remains.
Official sources and further reading
