The plumbing beneath your AI tools

Three stories crossed the wires today, and they are really one story told from three distances: the runtime a developer platform is built on, the dozens of applications a vendor is now wiring AI through, and the operational software an autonomous agent is expected to drive. For a business choosing tools, the useful question has quietly shifted from "does this have AI" to "what is the AI sitting on, and can it be run without surprises."

That shift is worth slowing down for. For two years the market rewarded any product that could point to a chatbot or a "summarise" button. The conversation today is about the layer underneath that button: the data it reads, the apps it has to reach across, the runtime it executes on, and the permissions that decide what it may change. None of that is visible on a pricing page, which is exactly why it is worth learning to ask about.

When AI is bolted on, ask what it is bolted to

There is a real difference between AI that is built into a product's data model and AI that is added as a layer on top of an existing catalogue of apps. The first kind knows where your records are and what they mean, because the model was designed around them. The second kind has to reach into each app, one at a time, and is only as good as the data in that app and the connections between them. From the outside the two look identical: both show you a chat box. The difference only appears when you ask the assistant something that spans two apps that were never designed to talk.

Atlassian's head of AI described the second situation plainly today. The write-up reports that "He runs AI across the product portfolio and owns the product management craft, which means 450 PMs" [3], and the headline frames the honest version of what that involves: the company "Bolted AI Onto 20+ Apps, Almost Didn't Ship Chat, and Flipped Our Hiring Toward Juniors" [2]. There is a lot packed into that sentence, and most of it is instructive for a buyer rather than a seller.

"Bolted onto 20+ apps" tells you the shape of the problem. When AI is added across a large set of applications that predate it, the integration work — making each app's data legible to the model, and keeping the apps in step — is the actual product. This is the same wall that older software hit long before anyone said "AI": tools that were bought separately rarely share a clean view of the same customer or project. We have written before about why your tools do not talk to each other, and AI does not remove that wall. It just moves the cost of it into the quality of the answers.

"Almost didn't ship chat" is the more interesting admission. It suggests a team that weighed whether a chat surface was the right thing to build at all, rather than adding one because the category expected it. When you evaluate a vendor, that kind of restraint is a signal worth looking for: a feature held back because it was not ready is usually a better sign than a feature shipped because the demo needed it.

Software an AI agent can operate

The second story moves from AI that answers questions to AI that does work. The phrase to learn here is agent-operable software: a product that exposes its actions in a way an autonomous agent can call, not merely a screen a human clicks through. The promise is that you describe an outcome and the agent carries out the steps. The risk is that the agent now has the same keys a person would, and software that was only ever designed for careful human hands is suddenly being driven at machine speed.

SaaStr's app of the week leans straight into this. It describes the vendor as follows: "Remote is a seven-year-old global payroll and employment platform based in Amsterdam" [4], and frames the pitch as "The $300M Payroll Platform Your AI Agent Can Run" [5]. Payroll is a deliberate choice of example, because it is about as consequential as back-office work gets. Pay someone twice, pay them late, or pay them the wrong amount, and the mistake is not a typo you quietly fix — it is money that has left the building and a person who noticed.

So the right way to read "your AI agent can run it" is not as a convenience claim but as a set of questions. What is the agent allowed to touch, and is that scope narrower than a full human login. Is every action it takes written to a record you can read afterwards. And can a wrong step be undone without a support ticket. Those three — scoped permission, a complete log, and reversibility — are the difference between an agent that saves time and one that creates a new category of risk. We have argued the general version of this in what AI should and should not do in your business: the test is not what the model can do, but what it should be allowed to do without a human in the loop.

This is also where a platform's own design matters more than the agent sitting on top of it. In 360REV an action taken on a customer's behalf is held to the same rules as an action taken by a person: it runs inside a defined permission, and it leaves a trail. That is not a feature you notice on a good day; it is what you are grateful for on a bad one.

The runtime beneath your tools

The third story is the furthest from the end user and, over a few years, possibly the one with the longest reach. TechCrunch reported that Cloudflare has acquired Deno, and that "Cloudflare will use this acquisition to improve its Workers programming model and platform" [1]. The words "programming model" are doing the work there. A programming model is the set of rules and tools that decide how code is written and run on a platform — how a developer expresses what they want, and how the platform turns that into something that actually executes close to your users.

Why should a business that buys software, not writes it, care about a runtime acquisition. Because the runtime is where reliability and speed come from, and increasingly it is where the AI features in your tools execute. When a platform owns more of its own plumbing, it can usually make that plumbing faster and more consistent, which is the upside being described today. The trade-off, which no acquisition announcement will phrase for you, is concentration: the more of the stack one provider owns, the more of your vendor's fate — and by extension yours — rides on that single provider. That is not a reason to avoid such platforms. It is a reason to keep asking the unglamorous questions about exit and portability, the ones we laid out in what happens to your data when you leave.

The thread, and what to do with it

The common thread across all three is that the interesting part of software has moved below the surface. Whether AI is built in or bolted on depends on the data model you cannot see. Whether an agent can safely run a platform depends on permissions and logs you have to go looking for. Whether a tool stays fast and yours depends on a runtime most buyers will never name. The products that win the next couple of years will not be the ones with the most AI on the label; they will be the ones where the layer beneath the label was built to be trusted with real work.

For anyone making a shortlist, the practical move is small. For each tool, ask one question from each story today: what does the AI read, what can the agent change, and whose plumbing is it running on. If a vendor cannot answer plainly, that is an answer in itself. For the rest of the week's announcements and how we read them, see yesterday's briefing.