Ambient agent

What is an ambient agent?

An ambient agent is an AI agent that nobody has to start. It sits on an event stream, a shared mailbox, the order table in your ERP, a ticket queue, a monitoring feed, and wakes up when something arrives that fits its brief. It reads the event, decides whether it matters, and then handles it, asks you something, or leaves it alone.

The name comes from LangChain. In January 2025 Harrison Chase wrote that ambient agents "listen to an event stream and act on it accordingly, potentially acting on multiple events at a time". His complaint about the chat window was simple: you have to start every conversation yourself, so an agent can only do one thing for you at a time. An agent that watches a stream runs whether you are at your desk or not, and several can run side by side.

Microsoft arrived at the same idea under a different name. Since June 2026 it calls the category "autopilots": always-on agents that work autonomously, with their own identity, and act on your behalf. Whatever label a vendor picks, the shape is the same: a trigger, an agent that judges the event, and a way to pull a person in when the agent is not sure.

Think of a junior colleague who reads the shared inbox all day. You never asked them to look at each mail. They look, sort, answer the easy ones, and walk over to your desk with the ones that need you.

What sets an ambient agent off

There is no prompt, so something else has to start each run. In practice that is one of three things.

An event. A new mail, a row added to a table, a ticket that changes status, a file dropped in a folder. Copilot Studio calls these event triggers and ships a library of them for Microsoft and partner services; the same triggers start automated cloud flows in Power Automate. The trigger sends the agent a payload with the event's data and, if you wrote them, instructions for that specific event.

A schedule. A recurrence trigger fires every hour or every morning at seven. Use it when the source has no event to offer, for instance a nightly export you have to scan for changes.

A threshold. Stock under the reorder point, a payment more than 30 days late, an error rate above 2 percent. Technically this is an event or a schedule with a condition in front of it, but it is how most business owners describe what they want.

One design point matters more than the rest: the trigger decides how often the agent wakes up, and every wake-up costs money. In Copilot Studio each trigger payload counts as a message for billing, so a recurrence trigger set to every 10 minutes sends 144 messages a day before the agent has done anything useful. Fire on real events where you can, and narrow the trigger so only the events you care about reach the model.

Three ways it involves you

The LangChain post names three human-in-the-loop patterns, and they hold up well as a checklist for any ambient agent you build.

1. Notify
   The agent tells you something is important and does nothing else. "Customer X mailed to cancel, no reply sent." Lowest risk, and often all you need in the first weeks.

2. Question
   The agent is stuck and asks for the missing piece. "This invoice names two projects, which one do I book it to?" The run pauses until you answer.

3. Review
   The agent has prepared an action and shows it to you before doing it: a drafted reminder mail, a purchase order ready to send. You approve, edit, or reject.

Because one agent may pause ten times a day across dozens of events, a chat window is the wrong place to handle those pauses. LangChain built an "agent inbox" for it, modelled on email and ticketing systems: a list of open items, each one an agent waiting on you, and for each item you can accept it, edit it, reply to it, or ignore it. Microsoft's guidance for autonomous agents says the same in plainer words: for sensitive actions, configure the agent to request approval from a person first.

A rule that holds up in practice: start every new ambient agent in notify mode. Let it run for a few weeks, read what it would have done, then promote the actions it got right to review, and the dull ones it never got wrong to fully automatic.

Ambient agent versus chatbot, and versus a scheduled flow

Versus a chatbot: who initiates?

A chatbot waits for you. You open it, type, get an answer, and nothing happens once you close the window. An ambient agent is started by the event, and you only hear from it when it has something for you. The chatbot scales with your typing speed; the ambient agent scales with the stream. Both can use the same model, the same tools and the same knowledge sources. What differs is who sends the first message.

Versus a scheduled cloud flow with an LLM step: who decides the next step?

This is the pair that causes confusion, because both run unattended and both may contain a language model. A Power Automate flow that runs every morning, takes the overdue invoices, asks a model to write a reminder, and mails it, is not an ambient agent. You drew the steps. The model fills in one box, and the flow does the same thing on every row.

In an ambient agent the model reads the event and picks what to do from the tools you gave it. For one overdue invoice it drafts a reminder, for another it notices the customer disputed the invoice last week and flags it to you instead, for a third it does nothing because a payment came in this morning. The path per event is different, and that is the point. It is also why the agent needs the controls in the last section and the flow does not.

Three examples for a small company

Overdue invoice follow-up. Trigger: a status change in the accounting package, or a daily check on the receivables table. The agent looks at each invoice past due, checks whether a payment or a dispute is already logged, and drafts a reminder in the tone that fits the customer's history. First reminders go out in review mode. A second reminder to a customer who ignored the first comes to you as a question, because it may be time for a phone call rather than another mail.

Stock threshold alerts. Trigger: a row update in the stock table. When an item drops under its reorder point, the agent checks open purchase orders and the supplier's lead time, then either notifies purchasing that an order is already on its way or prepares a purchase order for review. A plain flow can send the alert; the agent earns its place by checking the two things a person would check before raising the alarm.

Inbox triage. Trigger: new mail in the shared info@ or sales@ mailbox. The agent sorts each mail into ignore, notify or respond, drafts the replies it is confident about, and leaves each draft in review. LangChain's own reference implementation for ambient agents is exactly this email assistant, with that three-way triage step in front and an inbox for the pauses.

Why always on changes the governance

A chatbot borrows the identity of the person typing and stops when they close the tab. An ambient agent runs at three in the morning under an identity someone had to give it, and nobody is watching. That moves four questions from "nice to have" to "settle before you publish".

Whose identity does it run under? In Copilot Studio, event triggers run with the credentials of the person who built the agent, and Microsoft shows a warning before publishing that other users may reach data through that authorisation. For the autopilot category Microsoft gives each agent its own identity in Entra, with its own account, its own permissions and its own line in the audit log, rather than a shared service account or a colleague's login. Whatever platform you use, the agent should have an identity you can look up and switch off on its own.

What may it touch? Least privilege, applied per tool. An agent that reads invoices does not need write access to the ledger. An agent that drafts reminders does not need send rights until you have seen a month of drafts. Microsoft's guidance adds a check that is easy to forget: verify that the events reaching the agent are genuine, with sender validation for instance, because an inbound mail is also the classic route for a prompt injection, and an agent that acts on every mail is the ideal target.

How much may it spend? Every run is model calls plus trigger messages, and the trigger, not you, decides the volume. A recurrence set too tight, or two agents answering each other's mails, can burn through a month's budget overnight. Set a cap on runs per hour and on spend per day, and have the agent stop rather than slow down when it hits the cap. Copilot Studio can throttle an agent that goes over its quota; you want to hear about it before that happens.

How do you stop it? Know the kill switch before you need it. In Copilot Studio that means unpublishing the agent or taking the trigger out, and an administrator can block event triggers for an entire environment. Test that path once, with a stopwatch. An agent you cannot stop within a minute should not have permission to send mail.

Under all four sits a log: every trigger received, every decision, every action, readable by someone who did not build the agent. Microsoft's guidance asks for exactly that, and if the agent ever touches decisions about people, in HR for instance, the AI Act's rules on human oversight come on top of it.