The Roadmap Became a Feed: Buying Automation Without Release Dates

What changed, precisely

On 25 August 2026, Microsoft published a post titled "Moving beyond release waves with the AI at Work roadmap". The substance is straightforward: Dynamics 365, Microsoft Power Platform and Dataverse roadmap content moves into a single AI at Work roadmap alongside Microsoft 365. New capabilities begin publishing there from September 2026. Existing release plans on Microsoft Learn stop receiving new content but stay available for historical reference. The Release Planner tool that a generation of administrators used to filter, save and share upcoming features retires on 15 November 2026. In Microsoft's own framing, the company will "publish new capabilities as soon as plans are committed and ready to share, rather than holding them until the next scheduled wave", with each item moving through stages labelled In Development, Rolling Out and Launched.

Read as an engineering decision, this is sensible and overdue. Holding a finished feature for four months so it can appear in a numbered wave made sense when software shipped on discs and enterprises upgraded once a year. It makes very little sense when the same platform is shipping agent capabilities that are obsolete by the time a wave document is edited. Microsoft is not alone in reaching that conclusion, and the company is explicit that customers should now set their own review rhythm — monthly or quarterly — using RSS subscriptions and saved filters instead of waiting for a wave announcement.

Read as a procurement decision, though, something real was taken away. The release plan was never only an engineering artefact. It was the closest thing buyers had to a dated commitment, and entire purchasing arguments were built on it: we will sign now because the capability we need is listed for general availability in April; we will delay the migration because the connector is not planned until the second wave; we will budget training for October because that is when the interface changes. A rolling feed of committed items, however honest and however current, does not carry the same weight in a budget meeting.

The same week the transition began, UiPath used its FUSION conference on 23 September 2026 to announce more than a dozen platform additions at once, including the general availability of its Coding Agents, a productivity agent called Delegate, and a set of governance controls — a Model Hub for visibility into which models are being used, a Runtime Checker that validates agent behaviour against policy, and an LLM-as-Judge guardrail that evaluates outputs. Whatever you think of the features, notice the shape of the event: a large batch of change, announced on the vendor's calendar, arriving at customers on a rollout schedule that each customer has to discover for themselves.

How the major platforms disclose change now

Disclosure practice has quietly become one of the most consequential differences between automation vendors, and it is almost never on an evaluation scorecard. Here is where the main layers of a typical automation stack stand in late 2026.

The scale of that fifth row deserves a moment. Zapier alone now advertises more than 9,000 connected apps exposing over 66,000 triggers and actions. Every one of those apps has its own product team, its own release habits and its own view of what counts as a breaking change. No automation platform can give you a dated roadmap for someone else's API. When your workflow spans six tools, you are subscribed to six change calendars whether you know it or not, and the platform in the middle is a messenger, not an insurer.

Three things that break when the calendar goes away

The shift to always-on disclosure is not a catastrophe. It is a transfer of work, and it lands in three specific places that buyers rarely budget for.

• Budgeting loses its anchor. Annual automation budgets were built around known change events: a wave in April, an upgrade in October, a renewal in January. Continuous delivery converts a small number of large, plannable events into a constant trickle of small ones. The annual total may be identical; the ability to forecast which quarter absorbs it is gone.
• Change control loses its evidence. If you operate in a regulated sector, your auditor does not want to hear that a capability "rolled out". They want a record of what changed, when, who approved it and what testing preceded it. A dated release plan was half of that record for free. A feed you did not subscribe to is not a record at all.
• Training loses its cue. Waves gave internal enablement teams a natural moment to retrain staff and refresh documentation. Continuous change means interfaces drift between your training video and your screen, and nobody ever sends the email that says now is the time to re-record it.

There is a fourth, less obvious cost. Vendor-published benchmarks this year put the price of a single custom API integration at roughly €3,000 to €8,000 for a modern SaaS API and €8,000 to €15,000 for an enterprise system. Those are build numbers, not maintenance numbers, but they set the order of magnitude for rework. A connector rewrite forced by an unannounced field rename is not a rounding error for a small business, and it arrives without a line in the budget because the change that caused it never appeared on a calendar you were reading.

The regulatory calendar moved too

It would be convenient to blame this entirely on software vendors, but the same thing happened to the compliance dates that many automation projects were sequenced against. The EU's Digital Omnibus on AI entered into force on 27 July 2026, days before the AI Act's high-risk obligations were due to apply. It deferred those obligations for stand-alone Annex III systems to 2 December 2027, and for AI embedded in regulated products under Annex I to 2 August 2028. Some duties moved in the other direction or stayed close: the transparency requirement to mark AI-generated content applies from 2 December 2026 for systems already placed on the market before 2 August 2026, and the Omnibus added new prohibitions to Article 5.

If you scoped an automation programme in early 2026 around an August compliance date, that date is now sixteen months further out, and the internal case you built on urgency has lost its deadline. The reasonable response is not to relax. Deferral is not cancellation, the obligations themselves were not materially softened, and the work of classifying which of your automated decisions are high-risk takes longer than the time you just gained. It is the same discipline the software side now requires: track the date, re-plan when it moves, and never let a single published date be the only thing holding a project together. Our overview of what the EU AI Act means for business automation goes through the classification work in detail.

What to write into the agreement

When a vendor stops publishing dates, the only dates you can rely on are the ones you negotiated. None of the clauses below are exotic, and most vendors will agree to at least some of them on a standard contract, because they cost the vendor nothing except discipline they should already have.

That last row is the one buyers skip most often and regret most reliably. If you purchase or commission an automation, ask for a written list of every external dependency it relies on: platforms, connectors, APIs, authentication methods and model names with their versions. It fits on one page. Without it, a change feed is noise, because you cannot tell which announcements concern you. With it, a monthly review takes an hour. We went through the failure modes of undocumented dependencies in our piece on why every automation you buy has a sunset date, and the argument only gets stronger as the calendars disappear.

A monthly rhythm that replaces the release wave

Microsoft's own advice — establish your own review cadence, monthly or quarterly, with RSS and saved filters — is the right instinct, and it works for any vendor. The practical version, for a business that owns somewhere between three and thirty automations, looks like this.

1. Build the dependency inventory once. One row per automation, with the platforms, connectors, APIs and model versions it touches, plus who owns it internally and what breaks downstream if it stops. This is two or three hours of work and it is the foundation for everything else.
2. Subscribe deliberately. For each distinct dependency, find the change channel — roadmap RSS, changelog, developer newsletter, deprecation page — and route it to one shared inbox rather than to whoever happened to set up the integration.
3. Hold a sixty-minute monthly review. Read the month's announcements against the inventory and classify each one: irrelevant, watch, or act. Most months, almost everything is irrelevant, and that is the point — you are buying the confidence to ignore things.
4. Run a canary on what matters. For the handful of workflows that carry revenue or compliance weight, keep a low-volume test version pointed at preview channels where they exist, and a scheduled run that alerts you when its output shape changes.
5. Re-check after conference season. Vendors still batch their biggest changes around events. When your platform holds a product conference, add a short review the following week rather than waiting for the next monthly cycle.
6. Budget a maintenance line, not an incident line. Assume a predictable annual percentage of the original build cost for keeping automations current, and spend it deliberately. Our guide to whether you need automation maintenance covers how to size that figure honestly.

What this changes if you sell automation

There is a commercial opportunity hiding in this shift, and it belongs to whoever is willing to do the reading. Every buyer who now has to monitor six change feeds would rather not, and most small businesses simply will not. That creates room for a service that has been undersold for years: a documented dependency inventory, a monthly change review, and a commitment to fix what breaks within a named window. It is unglamorous, it is recurring, and it is far easier to price than another build.

It also changes what a good delivery looks like. An automation handed over as a working file is now an incomplete product. An automation handed over with its dependency list, its model versions pinned and written down, its failure alerts configured and a note on which vendor feeds affect it is a product the buyer can actually own. Sellers who make that the standard will find it easier to justify a maintenance retainer, because the value is visible before anything has broken rather than only after.

For buyers, the evaluation question follows naturally. When you are comparing two providers, ask each one what happens when their platform changes something. The one who answers with a process — here is what we monitor, here is the notice we give you, here is the window in which we fix it — has thought about the world as it now works. The one who answers that their workflows are reliable has not.

FAQ

What actually changed with Microsoft's release plans?

From September 2026, Microsoft stopped publishing new Dynamics 365, Power Platform and Dataverse content to the twice-yearly release plans on Microsoft Learn, and began posting capabilities to the AI at Work roadmap as soon as they are committed. The existing release plans stay online for historical reference, and the Release Planner tool from the release-wave era retires on November 15, 2026.

Is continuous disclosure worse for buyers than release waves?

It is faster but less predictable. You hear about a capability as soon as it is committed instead of waiting for the next scheduled wave, but you lose the fixed calendar that budgeting, training and procurement teams planned against. The trade is speed for certainty, and the work of restoring that certainty moves from the vendor to you.

What should I ask a vendor before signing now that dates are fluid?

Ask for the notice period on breaking changes and deprecations, whether a slower release channel or sandbox preview exists, how long a superseded version stays available, and whether changes affecting your configuration will be confirmed to you directly rather than only posted on a public feed. Put the answers in the agreement, not in the sales deck.

Does this affect small businesses or only enterprises?

It affects smaller buyers more. A large company has a platform team whose job includes reading change feeds; a ten-person business bought an automation once and assumed it would keep working. When the fixed calendar disappears, the party without a monitoring rhythm absorbs the breakage.

Did the EU AI Act deadlines move as well?

Yes. The Digital Omnibus entered into force on 27 July 2026 and deferred the high-risk obligations for stand-alone Annex III systems to 2 December 2027, and for AI embedded in regulated products under Annex I to 2 August 2028. Deferral is not cancellation, and some transparency duties still bite sooner: marking AI-generated content applies from 2 December 2026 for systems already placed on the market before 2 August 2026.

How often should we review vendor change feeds?

Monthly is enough for most buyers, with an extra check when a vendor holds a product conference or publishes a deprecation notice. Subscribe by RSS or email, keep a one-page inventory of what each automation depends on, and spend an hour a month matching one against the other.

What is the single most useful clause to add to a contract?

A written notice period for breaking changes and deprecations, paired with the right to remain on the previous working version until you have tested the replacement. Credits, support tiers and escalation paths are all easier to negotiate once you have time on your side.

Should I prefer platforms that still publish fixed dates?

Not on that basis alone, but disclosure discipline deserves a line in your evaluation. Salesforce still ships three seasonal releases a year with sandbox previews four to five weeks ahead, and Google Workspace still offers a Scheduled Release track that trails Rapid Release by at least a week. Where those slower lanes exist, use them.