AI inside the tools, and the agents meant to run them

Three announcements landed today, and they describe the same shift from different angles: the software a business buys is being rebuilt around artificial intelligence, both inside the products and in the teams that make them. For anyone choosing tools, the useful question is no longer whether a product has AI, but where the AI sits and who is meant to operate it.

When a suite adds AI to what it already had

There are two ways a software company puts AI into its products. It can build new applications that are AI-native from the first line of code, or it can add AI to applications that already exist and already have customers. The second path is harder than it sounds. An older application was designed around a particular way of working, and bolting a new capability onto it means the new capability has to fit the old shape rather than the other way round.

Atlassian's head of AI, Sherif Mansour, described doing exactly this at scale. He has been at the company for seventeen years, and he now runs AI across the whole product portfolio while also owning the product management craft, which the account puts at 450 product managers [1]. The company has more than twenty applications. Only a handful were born in the generative AI era; the rest are years older and are being retrofitted. The headline adds two details worth sitting with: the team almost did not ship its chat feature, and it has shifted its hiring toward more junior people.

For a business choosing tools, the lesson is not about one vendor. It is that a suite with AI stamped across it is not the same as a suite designed around AI, and the difference shows up in how coherent the experience feels once you are three applications deep. When you evaluate a broad product family, ask where the AI was added and where it was built in. Ask whether the assistant in one application knows what you did in another, or whether each one starts from zero. The honest answer tells you more than any feature list. This is also why we keep saying that AI inside a product should have a clear job and clear limits rather than being everywhere at once, a point we set out in what AI should and should not do in your business.

Payroll that a software agent is meant to run

The second announcement moves the idea one step further. It is no longer only about AI living inside an application. It is about an AI agent operating the application on your behalf.

Remote was named this week's app of the week by SaaStr, described as a seven-year-old global payroll and employment platform based in Amsterdam that leaned in early to making payroll work for distributed and global teams, and is treated as one of the more trusted vendors in its space [2]. The framing of the piece is the part to pay attention to: a payroll platform that your AI agent can run. The claim is that the work a person used to do by logging in, reading the screen, and clicking through a process can instead be handed to a software agent that carries it out.

That is a meaningful change, and it is worth being precise about what it does and does not mean. Payroll is one of the least forgiving processes a business operates. It runs on a fixed calendar, it touches money and tax, and a mistake is felt immediately by the people it affects. Handing any of that to an agent raises a straightforward question of accountability: when the agent acts, who checked the result, and who answers for it if it is wrong. The attraction is real, because payroll is repetitive and rule-bound, which is the kind of work agents are suited to. The caution is equally real, because some decisions should always pass in front of a person before they take effect. We wrote about where that line sits in decisions automation should never make, and payroll is a good test of it. An agent that prepares a run and shows its working is a help. An agent that commits the run with nobody looking is a risk dressed as convenience.

The practical advice for a buyer is the same as it was yesterday. Before you let any agent operate a system, find out what it can do without asking, what it must ask about, and what record it leaves behind. If those three answers are vague, the agent is not ready to run anything that matters.

The plumbing beneath your tools

The third announcement is the one a business is most tempted to skip, because it sits a layer below anything you log into. It still deserves a moment.

Cloudflare has acquired Deno, and it has said it will use the acquisition to improve its Workers programming model and platform [3]. Workers is the environment in which developers build and run code on Cloudflare's network, and the plain reading of the announcement is that the company is investing in how that code gets written and run.

Why should a business that never touches any of this care. Because the applications you buy are built on platforms like this one, and the direction those platforms take eventually reaches you. When a large infrastructure provider absorbs the tools that developers use to build on it, two things tend to follow. The experience of building on that platform gets more unified, which usually makes the applications built there faster to ship and easier to maintain. At the same time, the platform's gravity grows, and the companies that build on it become a little more tied to it. Neither of those is good or bad on its own. They are a trade-off, and it is the sort of trade-off that quietly shapes which features arrive in your tools next year and how quickly a vendor could move if it ever wanted to.

You do not need to track acquisitions at this layer. You do need to understand that the software you choose rests on choices made below it, and that consolidation at the bottom is one of the forces that decides what the top can do.

What ties the day together

Read together, the three stories trace a single line. AI is being added to the applications you already use, it is being given the ability to operate some of them for you, and the ground those applications stand on is consolidating. For a business choosing tools, the response to all three is the same discipline rather than three different ones.

Ask where the intelligence sits and whether it is built in or bolted on. Ask what an agent is allowed to do unsupervised and what record it keeps. Ask what your tools are built on and how much that ties your hands. None of these are questions a demo answers for you, and none of them are new. They are the ordinary questions of choosing software worth using, applied to a week where the answers are moving quickly. If you want the running thread, yesterday's edition is the 9 October briefing.

The steady advice holds. Buy tools whose behaviour you can see, whose automation you can bound, and whose data you can get back out. The AI on top and the plumbing underneath will keep changing. Those three tests will not.