When the assistant starts building the tool

The clearest thread running through Friday's productivity releases is that the assistant is no longer just answering questions beside your work. It is starting to build the surfaces you work in, and in some cases to run tasks on your behalf, which changes what you are actually buying when you buy software.

That shift is worth slowing down for. A tool that answers is easy to evaluate: you ask, you read, you decide. A tool that acts is harder, because now you are trusting it with the doing and not only the thinking. Before adopting anything in this category, it helps to have already decided where you draw the line between work an assistant may complete alone and work it may only draft — a line we have written about in decisions automation should never make and in what AI should and should not do in your business. 360REV takes the same view internally: automation drafts, and a person retains the decisions that carry consequences.

Microsoft reframes Copilot around doing, not just answering

Microsoft announced a new version of Copilot organised into three named surfaces: Home, Code and Autopilot [1]. The naming itself is the signal. "Home" and "Code" describe places you go; "Autopilot" describes work that continues without you steering every step. Microsoft frames the change as a reimagining of the product "to enable work as it evolves" [1], which is a broad promise, and a business should read it as an intent rather than a finished specification.

For a buyer, the practical question is not whether the feature list is impressive. It is what an autopilot is permitted to touch, what it records when it acts, and how you review or reverse what it did. Those are governance questions, and they do not go away because the vendor is large or the surface is polished. When you evaluate any tool that promises to act on its own, insist on knowing where its authority ends. A capable assistant that cannot explain what it changed is harder to trust than a limited one that can.

GitHub lets you build the workflow by describing it

GitHub published a guide to building custom workflows with canvases in the GitHub Copilot app. The idea is that you describe the interface you need in plain English and the agent builds a live surface you can both use and update [2]. GitHub's own framing is that you "spend less time adapting to tools and more time getting work done" [2].

This is a genuinely different model of software. For decades, adopting a tool meant learning its shape and bending your process to fit it. Generating the surface from a description inverts that: the tool bends toward the task. The appeal is real, especially for small teams whose needs do not match any off-the-shelf layout.

The trade-off is worth naming plainly. A workflow you generate on demand is only as durable as your ability to recreate or export it. If the surface lives inside one vendor's app and cannot leave, then the convenience of building it quickly is balanced against the cost of being unable to move it later. This is the same discipline we described in the data you should be able to export on any Tuesday: ask, before you commit, what you would keep if you left. A generated interface is useful. A generated interface you cannot take with you is a dependency wearing the costume of a feature.

A small calendar change that removes real friction

Not every useful release is an AI release. Google added the ability to view up to three time zones in Google Calendar on the web, configured as a primary, secondary and tertiary zone [3]. Google describes the goal as "making it easier to schedule and coordinate meetings across global teams by expanding time zone support" [3].

This is a small feature, and that is exactly why it is worth flagging. Coordinating across zones is one of the quiet, recurring costs of distributed work. Every mistimed invitation is a few minutes lost and, occasionally, a missed meeting. A third zone specifically helps teams that straddle, say, the Americas, Europe and Asia at once — the case where two zones were never quite enough.

When you compare tools, it is tempting to weigh only the headline capabilities. But the features you touch every day, the ones that remove a small friction dozens of times a week, often matter more to how a team actually feels about its software than the marquee items do. A calendar that shows the third zone you needed is a good example of value that will never appear on a pricing page.

Why a performance change is a buying signal

GitHub also wrote about improving site performance, explaining how it "fully migrated github.com away from CSS-in-JS" [4]. On its face this is an engineering story about how a page is built. For a buyer, it is more interesting as a signal.

Performance is not a cosmetic property. A tool your team opens hundreds of times a day pays back every millisecond it saves, and it charges you for every one it wastes. A vendor that invests in how quickly its own pages load, and is willing to change its underlying approach to get there, is telling you something about what it values. The trade-off behind any such migration is real work spent on speed rather than on new features, and a business should read that choice as a statement of priorities.

The broader lesson holds across all four of these releases. Speed, exportability, and the boundary around what an assistant may do are not extras you assess after choosing a tool. They are the terms of the relationship. We set out how to weigh them before you sign anything in choose software worth using.

What to take from the day

The assistant is moving into the work, not just beside it. That is the pattern under Friday's news, from Microsoft's autopilot surface to GitHub's generated canvases. It brings speed and flexibility, and it raises the stakes on the boring questions — what it may touch, what it records, and what you keep if you leave. Ask those first. The capability will impress you on the demo; the answers to those questions are what you live with afterwards.