The Agent That Reschedules the Day Isn’t on the Roadmap Yet. Decide the Interval Before It Is.

Search Microsoft’s published roadmap for a 2027 feature that reschedules your day, and you will not find one. Not because it is buried — because as of August 2026, Microsoft retired the twice-yearly release-wave format that would have carried a dated commitment like that at all. There is no 2026 wave 2, no wave scheduled for 2027, and no named capability that autonomously re-shuffles a person’s plan once it is set.

The interesting question here is not “when does this arrive.” It is a governance question that is cheaper to answer now, while the capability is still hypothetical, than it will be once a vendor default has quietly answered it for you.

The question applies past field technicians and shop floors, too. A finance team running close tasks through a queue, a customer service team working cases in priority order, a warehouse crew executing a pick list — anywhere a plan gets handed to a person and then executed over the following hours, the same mechanism eventually shows up. The example below happens to be dispatch and production scheduling, because that is where the real capability exists today. The governance question is not specific to either one.

What Already Exists

Two real, shipping pieces of Dynamics 365 functionality get close to “an agent reschedules the day” without actually doing it.

The first is the Scheduling Operations Agent in Dynamics 365 Field Service, generally available on the same track as 2025 release wave 1. It generates a re-optimized technician schedule and stops there. Microsoft’s own documentation is explicit about the boundary: “Review the agent’s suggested schedule before you apply it.” A dispatcher can “select Apply,” “rerun optimization with different constraints,” or “discard the suggestion without changes.” The agent proposes. A person decides whether the day actually changes.

The second is older and less glamorous: the set of tools Supply Chain Management has offered since 2023 release wave 2 for reacting to last-minute production disruptions — adding margins to manual scheduling, making better use of on-hand inventory and planned receipts, avoiding a warehouse release when materials are missing, changing items or routes on an existing production order. The mechanism is rule-based and manually triggered, not agentic, but it establishes that Microsoft has been building toward “replan in response to new information” as a product direction for three years, well before agents entered the picture.

Put those two next to each other and a trajectory is visible even though a date is not: manual reactive tools, then an agent that proposes a re-plan and waits for a human to apply it. The obvious next increment — not announced, not scheduled, but the plain continuation of the line already drawn — is an agent authorized to apply that re-plan itself, and to do so more than once.

What “Reschedules the Day” Would Actually Change

The Scheduling Operations Agent runs when a dispatcher decides to run it. That requirement is doing more work than it looks like. It means the frequency of replanning is bounded by how often a person chooses to ask for a new plan, which in practice means a handful of times a day, at moments a person judged were worth the disruption.

Remove the approval step and that bound disappears with it. An agent that can apply a re-plan without waiting for a person has no natural reason to stop at a handful of runs a day. Compute is cheap, the optimizer does not get tired of re-solving, and every new order, delay, or cancellation is technically a reason to run it again. Nothing about the capability itself supplies a floor. Something else has to.

That something is the interval: how often the agent is allowed to touch a plan that a person is currently working against. Real-time, so the plan changes continuously as conditions change. Fixed cadence — hourly, at shift boundaries, once overnight. Or a settled window, where a plan is locked for a defined stretch and only reopened at agreed checkpoints, the way a technician mid-appointment is not rerouted no matter what the optimizer finds three streets over.

Each of those is a defensible choice in the right setting, and each produces a genuinely different day for the person on the receiving end. A fixed hourly cadence means a worklist that is stable enough to plan a coffee break around but can still absorb a same-shift emergency. A settled window means total predictability until the checkpoint, at the cost of anything urgent waiting for it. Real-time sits at the other end entirely — maximally responsive, and maximally unpredictable to live inside. None of the three is obviously correct in the abstract. The interval only makes sense in relation to what the work actually tolerates, which is precisely the judgment a vendor default cannot make on a customer’s behalf.

This is not currently a setting on a configuration screen, because there is no shipping capability that removes the human-approval step and needs one. That is exactly the argument for deciding the answer now rather than after the fact.

Why a Default Will Not Be Neutral

Software ships with a default, and an unexamined default still functions as policy — it is simply one no one signed off on. A vendor default tuned for throughput will tend toward frequent replanning, because more replanning generally means a better-optimized plan on paper. A vendor default tuned for adoption might land more conservatively. Either way, the interval a customer ends up running is likely to be whatever shipped, not whatever that customer’s work actually needs. DAX has covered the same pattern in how the ERP already decides what gets worked first — sort orders and priority settings that quietly became policy simply by staying untouched since go-live. What is different here is that this piece of policy does not exist yet, which means for once it can be decided on purpose instead of inherited.

The cost of getting the interval wrong is not abstract. A plan that can change under someone while they are still executing the previous version of it is a different kind of workday than one that holds for a stretch of time. Committing to a specific next task, telling a customer a window, or simply building momentum on a piece of work all depend on the plan staying still long enough to act on. An optimizer has no concept of that cost, because it is not the thing being optimized. A person setting the interval has to supply it deliberately, or nobody will.

Where Frequent Replanning Earns Its Keep

This is not a case for locking every plan down and refusing to touch it. In dispatch and logistics work specifically, the cost of a stale plan is real and sometimes larger than the cost of disruption. A technician sitting in traffic, an urgent case that just came in, a part that turns out to be unavailable — these are exactly the situations the Scheduling Operations Agent and the SCM reactive tools were built to answer, and answering them fast is the entire point. A settled-window policy applied everywhere would recreate the problem Microsoft has spent three release cycles trying to solve: a plan that stays technically valid while the situation underneath it has already moved on.

The realistic position is that the right interval is not one number. It is short where the cost of staleness is high and disruption is cheap — an unassigned queue, work that has not started, a plan for tomorrow rather than the next hour — and long, or locked entirely, wherever a person is already committed to executing what the plan currently says.

How to Set It Before You Have To

• Classify the plan, not just the work. Separate what an agent is re-planning into “not yet started,” “in progress,” and “committed to a person or a customer.” Each category can carry a different interval, and most of the argument about frequency collapses once the categories are drawn — nobody actually wants a mid-appointment reroute, and almost everybody wants a same-morning one.
• Use the human-approval step you already have as a research tool. Because the Scheduling Operations Agent requires a person to apply its suggestion, an organization running it today can observe how often dispatchers actually choose to invoke it, and how much the accepted plan changes each time — real usage data about the interval that would suit the work, gathered before anyone has to remove the approval step at all.
• Assign the interval an owner, not a setting. A configuration screen will eventually offer a number of minutes or a trigger condition. The number needs a name attached to it — someone who can explain why it is what it is, and who is accountable when a plan changes at a moment that turns out to matter.
• Write down what triggers an off-cycle replan. An interval is only half the policy. The other half is the exception path — what is allowed to force a re-plan before the next scheduled one, and who can invoke it. A dispatcher overriding the cadence for a genuine emergency is different from an interval that erodes by exception until it was never really an interval at all.

A configuration screen for this does not exist yet. The four questions above do not need one — they can be answered against the scheduling and planning setup already running in a Dynamics 365 environment today, which is where DAX Software Solutions does most of its work on this specific problem. Get in touch if you want to work through what the right interval looks like for your operation before a vendor default picks one for you.