The risk of trusting one AI for everything

Most days in productivity software are about a single new feature. This one is about a habit of mind: treating the tools you buy as things you should be able to move between, question, and govern, rather than a single system you hand your whole business to. The through-line from a keynote to a sales conference to a developer workflow is the same warning, said three ways: do not let convenience turn into dependence.

Do not let one AI become a single point of failure

The strongest claim of the day came from Microsoft chief executive Satya Nadella, who argued that a company's exposure to artificial intelligence is now a structural question, not a feature question. The reported position is blunt: firms without their own models, or without a separating layer between their prompts and the model they call, will struggle [1]. The term used for that layer is an AI gateway, a piece of infrastructure that sits between your applications and whatever model answers them.

You do not need to run your own model to take the point seriously. The useful idea underneath the headline is separation. When your prompts, your customer data, and your business logic are wired directly into one provider's model, three things become true at once. You cannot compare that model against another without rebuilding the connection. You cannot switch when pricing or quality changes. And you cannot see, in one place, what you are sending and what comes back. A separating layer restores all three: it lets you route a request to a different model, keep a record of what was asked, and change suppliers without changing the rest of your stack.

For a small business the lesson is not to build gateway infrastructure. It is to ask, before adopting any AI feature, a plainer version of the same question. If this provider doubled its price or changed its terms, how hard would it be to leave? If the answer is very hard, you have bought dependence, not capability. This is the same discipline behind choosing tools you can actually leave, and it applies to models now as much as to databases.

Agents have moved from debate to deployment in sales

The clearest sign that this is no longer theoretical came from SaaStr AI 2026, whose write-up of sales lessons opened with a striking observation: the argument about whether to put agents into the revenue organisation is over. As the report put it, no one at the event was still debating whether to place agents in the revenue org; teams had already done it and arrived with the results [2]. The value of that framing is that it moves the conversation from should we to how did it go.

For a business choosing tools, the takeaway is timing. When practitioners stop asking whether and start comparing what broke, the safe move is not to rush in behind them but to read their failures closely before you commit. An agent in your revenue process is software that acts on your behalf. Before you give any tool that authority, you should know exactly which decisions it may make and which it must escalate. There are some decisions automation should never make at all, and the arrival of agents in live sales pipelines makes that boundary more urgent, not less.

A steady workflow beats chasing every new tool

Against that backdrop, a piece from GitHub offered a quieter counterpoint aimed at builders. It described a working method for prototyping, planning, building, and reviewing software without chasing every new AI tool that appears [3]. The word it used for that method was a harness: a repeatable structure around the work, rather than a fresh tool for each stage.

The idea generalises well beyond code. The cost of new tools is rarely the licence fee. It is the switching, the retraining, and the half-finished migrations that accumulate when a team adopts something new every quarter. A harness is the opposite instinct. You settle on a way of working, you keep it stable, and you let the tools inside it change slowly and deliberately. This is why the tools you already run, connected well, usually beat a newer tool bolted on badly, a point that sits at the heart of why your tools do not talk to each other.

Meeting notes are getting more visual, so set the rules first

Google announced that visual screenshots for the automatic note-taking feature in Google Meet will become generally available, and it advised administrators to configure their settings before the rollout arrives. The company said the rollout of visual screenshots for the note-taking feature is beginning in the coming weeks [4]. The reason the announcement matters is not the feature itself but the advice attached to it: decide your policy in advance.

Automatic capture of what is shown on a screen is convenient and also a governance question. Slides, diagrams, and charts shown in a meeting may contain figures, names, or plans that should not be stored automatically or shared widely by default. The right time to decide who can turn this on, and where the captured content lives, is before the feature is live, not after the first sensitive screenshot has been saved. Any capability that records more of your working day should be met with a clear rule about retention and access.

Lowering the barrier for beginners

Finally, GitHub published a getting-started guide for newcomers to its Copilot app, walking through how to start projects, work with AI agents, explore canvases, and set up a development workflow [5]. On its own this is a small item. In the context of the rest of the day it is a reminder that the audience for these tools is widening, which means more people will be making adoption decisions with less experience to draw on.

That is the strongest argument for the discipline running through today's news. The people choosing tools are no longer only specialists, the tools increasingly act rather than just answer, and the convenient default is to hand everything to one provider. The counter-habit is unglamorous and durable: keep the ability to leave, decide what a tool may do before you switch it on, and change your stack slowly. None of that requires owning a model. It requires treating every tool, including an AI, as something you govern rather than something you trust blindly.