AI becomes a cost to manage and a workflow to connect

Three announcements today point the same way. The software a business runs is being judged less by what it does on its own, and more by how it connects to the AI its people already use and what that AI costs. For anyone choosing tools this quarter, that shifts the first questions away from features and towards plumbing and price.

Know what your AI habit costs before you standardise on anything

Most companies have already bought AI without deciding to. It arrives one seat at a time, on personal cards and expense claims, because an individual found a tool that helped and did not wait for a policy. That is how you end up with a dozen overlapping subscriptions and no single view of what any of them earn back. In a report today, Rippling's Parker Conrad described one employee using an AI assistant to plan around their calendar and email at a run rate of thirty thousand dollars a year for a single person [1].

The number is less interesting than the fact that it was invisible until someone went looking. Before you can choose a tool for a team, you have to see what the team is already paying for, who uses it, and whether the spend maps to output. This is not an argument against letting people experiment. It is an argument for measurement. A tool that quietly costs more than the person it helps is a decision you want to make on purpose, not discover in an audit.

The practical step is boring and it works. List every AI subscription in the business, name an owner for each, and put a number next to it, both the cost and the work it replaces. Only then does standardising make sense, because now you are comparing like with like instead of guessing. We cover the underlying discipline in what AI should and should not do in your business, and the same habit of putting a figure on a decision is the point of numbers that change a decision.

Model choice is becoming a procurement question, not a technical one

For years, picking an AI coding tool meant picking a model, and the two were the same decision. That is loosening. GitHub published results today for its Copilot agentic harness, describing strong performance across several benchmarks together with token efficiency while keeping the ability to choose among more than twenty models [2].

Two things in that description matter to a buyer. The first is token efficiency, which is simply cost per unit of work. A tool that does the same job with fewer tokens is cheaper to run at scale, and at scale the difference compounds. The second is model choice. When the surrounding tool is separate from the model it drives, you are no longer tied to one vendor's pace or price. You can move as better or cheaper models appear, without changing how your team works.

For a business choosing tools, the lesson is to separate the workflow you are buying from the engine underneath it. Ask whether the tool lets you change models later, and ask what a typical task costs to run, not just what the licence costs to hold. A monthly price is easy to compare. The cost of the actual work is the number that decides whether the tool pays for itself.

Your content is only useful where your AI can reach it

The value of a document is not in the file. It is in whether the person, or now the assistant, doing the work can get to it at the moment they need it. Content that lives in one system and AI that lives in another means someone spends their day copying between the two. Dropbox announced today three integrations that connect its stored content directly to Claude, describing them as a way to close the gap between teams, their content, and the AI they use [3].

This is the quiet, important half of the AI story. The models are only as good as what you let them see, and most business knowledge sits in files, not in the chat window. An integration that brings stored content to the assistant removes a copy step, and every removed copy step is a place where mistakes and stale versions no longer creep in. It also raises a question worth asking before you connect anything: what does this tool now have access to, and who approved that.

When you evaluate tools, treat integrations as a first-class feature rather than a footnote. A product that does one job well but cannot talk to the systems around it will cost you in manual glue work. We wrote about that failure mode in why your tools do not talk to each other, and it applies just as much to AI as to a CRM or a billing system.

Shipping fast is a sequence you can copy, not a feature you can buy

Speed of delivery is often admired and rarely understood. At SaaStr, the story today was that Booking.com for Business built a free expense product in six weeks [4]. The obvious reading is to want the tool. The more useful reading is the one the write-up insists on: the thing worth copying is the sequence that produced the tool, not the tool itself.

That distinction matters when you are deciding whether to build or buy. A six-week build is notable because of what came before it, a clear problem, a narrow scope, and the discipline to ship something small rather than plan something large. Copy the tool and you get a feature. Copy the sequence and you get the ability to do it again for the next problem. Most teams do not need a bespoke expense product. They need the habit of shipping a small, useful thing quickly and learning from it.

The trap on the other side is the promise that anything can be added later. We wrote about that in the real cost of well build it later, because later is where scope and cost quietly accumulate. The sequence Booking.com describes is a defence against that trap, not an exception to it.

Agents that do real work, not agents in a demo

The gap between an agent that demonstrates well and one that carries a real workload is wide, and it is where most disappointment lives. At SaaStr AI, Replit's Amjad Masad reacted on stage to the agents the conference runs its own operations on, described as the actual agents doing the actual work rather than a demo deck [5].

That framing is the right test for any business considering agents. A demo shows the best case. Real work shows the edge cases, the handovers, and the moments where a human still has to step in. Before you hand a task to an agent, you want to know how it behaves when the input is messy, not just when it is clean. The decision to automate is a judgement about the task, not about the technology, and it is worth making deliberately. We set out how to make that call in how to tell whether a task should be automated.

The thread across all of today is the same. AI is no longer a feature you switch on. It is a cost you manage, an engine you choose, and a set of connections you have to think about before you commit. The businesses that treat it that way will spend less and get more than the ones that buy the demo.