Outreach optimisation agent

What it does

A journey step that decides when to send an email rather than sending it the moment a contact arrives. It reads aggregated engagement history — opens and clicks — works out when that audience actually engages, and schedules the send accordingly. Give it more than one email and it also spaces the sequence out and stops early once a goal you nominate is met.

Key facts

Preview. Restricted functionality, subject to change, not for production workloads.
Enabled per environment in AI Hub, alongside the journey creation agent. It is not on the ordinary Feature switches list.
Consumes Copilot credits, drawn from Microsoft Copilot Studio capacity allocated to the environment (prepaid message packs or pay-as-you-go).
Documented for email. Do not assume SMS or push are covered — the docs describe email sequences.
Single-email mode: the agent picks a send time, the contact moves to the next step once the email has gone.
Multi-email mode: it schedules each email at its own optimal time with spacing between them, and you must pick a goal condition.
The three goal conditions are All emails are sent, Any link in any email is clicked, and Selected links are clicked.
You set an end date. Everything is sent before it, and goal evaluation completes at it.
It honours the organisation's configured quiet times and each contact's or lead's consent — the agent is not a way around either.
New environments with no engagement history get a fallback behaviour rather than an error, so it will run on day one, just without much to go on.

When to use / skip

Use it where the journey is a nurture or follow-up sequence and the client genuinely does not know the right cadence — a three-email sequence over a fortnight where the alternative is someone guessing "wait two days" in the canvas. The goal conditions are the real value: stopping a sequence when the contact clicks is the sort of thing teams say they want and then never build by hand.

Skip it for anything time-critical or transactional. Order confirmations, event reminders, appointment notices, anything tied to a real-world clock — those need to send when they need to send, and handing the timing to an agent is wrong. Skip it in a brand new environment with no send history, at least for the first few months, because there is nothing for it to learn from and you are paying credits for a guess. And skip it where the client's compliance posture will not tolerate a preview feature deciding when a customer gets contacted.

Note the overlap with the older Smart scheduler feature switch, which also picks a send time. Decide which one you are using; do not run a mental model where both are in play on the same journey.

Configuration decisions

Single email or multi-email sequence — this changes whether you have to define a goal at all.
Which goal condition matches the business outcome. "All emails are sent" is really "no goal", and choosing it by default wastes the feature.
If you pick Selected links are clicked, which links count. That decision needs to survive content edits, so agree it with whoever owns the email templates.
The end date, and what happens to contacts still in flight when it passes.
Credit allocation shared with any other agent in the environment, and who monitors the burn rate.
Whether existing quiet-time settings are actually configured. The agent respects them, which is only useful if someone set them.

Gotchas

Quiet times and consent constrain the agent, so in a tightly restricted setup the "optimal" send window can collapse to a narrow slot and the clever scheduling adds nothing.
Credits are shared with the journey creation agent and anything else on Copilot Studio capacity in that environment. One team's experiment can starve another's production-ish journey.
Changing an email's links after you have selected them as the goal condition will quietly break the goal. Nothing warns you.
The end date is a hard boundary. Contacts entering late in the window get a compressed sequence rather than the cadence you designed.
Being preview, it can change between updates. Do not document the click path for end users in a training pack yet.
Sparse engagement history is invisible in the UI. The agent runs happily on a fallback and the client assumes it is being data-driven when it is not.

Consultant notes

Frame it to the client as cadence optimisation, not send-time magic. The multi-email goal handling is the part worth demoing; the single-email send time looks like a small thing in a demo.
Pair the conversation with quiet times and consent configuration — those want to be right regardless, and the agent gives you a reason to get them done.
Push back on using it for transactional or event-driven messages. That is the misuse you will see most often.
Before go-live, confirm Copilot credit capacity is allocated to the right environment and check what the existing engagement data actually looks like — a client with three months of low-volume sending should be told the agent is guessing.
Keep a manually-timed variant of the journey available. If the agent has to be switched off mid-campaign you do not want to be rebuilding under pressure.

Worth another look when it exits preview, or if the channel support widens beyond email.