When agents start choosing your software

The announcements that crossed the wire today share a single thread: business software is increasingly operated by AI agents, not only by people. That shift changes what you should look for when you choose a tool, because a program that works well for a human can still fail the agent acting on your behalf.

Agents are starting to choose your software

For most of the history of business software, a person decided which tool to buy and a person decided when to leave. That decision rested on things people notice: the interface, the price, the sales relationship. An AI agent notices none of those. It reaches a tool through the tool's API, and if the API will not let the agent do enough work quickly enough, the tool is unusable to the agent no matter how good it looks to a person.

A widely read account today described exactly this. A company wrote that it had "just moved 10+ years of data off Marketo into Salesforce Marketing Cloud" [1], and it named the reason plainly: "The final straw was the rate-limiting in their API made it unusable for 10K, our AI agent for marketing and revenue" [2]. Read past the specific names and the lesson is general. The feature list did not force the move; the rate limit did. When an agent runs part of your marketing, the ceiling on how many calls it can make per minute becomes a hard ceiling on what that part of your business can do.

This is why the quiet parts of a tool now matter more than the demo. Before you commit, ask how the API is rate-limited, whether those limits rise with your plan, and how you would get a decade of records out if you decided to leave. Those are the same questions worth asking about why your tools do not talk to each other and about the data you should be able to export on any Tuesday. An agent does not create these questions. It just makes the cost of getting them wrong arrive faster, and at machine speed.

When a vendor evaluates your product and then builds its own

Build-versus-buy is an old decision, but it takes on a sharper edge when the thing being built is a piece of AI plumbing. Today a startup took a larger company to court over one. As reported, "Runlayer is suing Rippling after Rippling evaluated the startup's MCP gateway product and then opted to build one itself" [3]. Set aside who is right, which the courts will decide. The pattern underneath is worth understanding, because it can touch any small vendor and any buyer who relies on one.

MCP is the protocol that lets AI agents connect to tools and data, and it is new enough that many of the companies building the connective layer are small. When a large platform evaluates one of them, the small vendor tends to show its roadmap, its architecture, and the hard edge cases it has already solved. That disclosure is the evaluation. The risk this dispute highlights is what can happen afterwards, when the evaluator has the option to build the same thing itself.

For a buyer, the practical takeaway is about concentration. If a single platform controls the layer your agents pass through to reach everything else, you inherit that platform's decisions about what to keep, what to absorb, and what to drop. That is not an argument against any one vendor. It is an argument for knowing how replaceable each layer is before you depend on it, which is part of what it means to choose software worth using.

AI arrives inside the document

Two changes to Google Docs today point in the same direction: the AI work is moving into the surface where you already write, rather than sitting in a separate window. Google said "You can now create and edit images, diagrams, and infographics directly alongside your text using Gemini in Google Docs" [4], and separately that "We're introducing Gemini-powered comment workflows in Google Docs to help you quickly understand and respond to collaborator feedback" [5].

The idea to understand here is context. The reason to put AI inside a document, rather than in a chat window beside it, is that the assistant can see the document — the words you have written and the comments people have left on them. That is what makes a generated diagram relevant instead of generic, and what lets a comment be summarised rather than merely counted. It is also the trade-off. A tool that can read your draft and act on your colleagues' feedback is a tool that reads your draft and your colleagues' feedback. For a business, that is not a reason to avoid it. It is a reason to decide, on purpose, which documents an assistant may read and which it may not, which is exactly the line drawn in what AI should and should not do in your business.

The supply chain you inherit with every install

When you install a package or add a step to a build pipeline, you are trusting not only that code but everyone who is able to change it later. That is the software supply chain, and it is the part of your stack you did not write and almost never read. It became visible today because GitHub described its work on it: "Explore the changes we've shipped across npm and GitHub Actions over the past few months to disrupt supply chain attack techniques and limit their impact" [6].

Most people choosing business tools will never touch npm or a build pipeline directly. The reason this still matters to them is simple: their vendors do. Every SaaS product you buy is assembled from open components and automated build steps, and a weakness in one of those can reach you without anyone at your company having made a mistake. You cannot audit your vendors' dependencies yourself, but you can ask how they vet them, how quickly they patch, and how they would tell you if something upstream were compromised. The answers belong in the same file as everything else you keep about a system's behaviour — the sort of record described in the audit trail nobody thinks about.

Choosing an automation platform you will not outgrow

Two comparison pieces published today are a useful reminder that automation is not one category. One opens by noting that "Some of the world's most critical infrastructure runs on technology that predates the internet" [7] — the world of desktop and legacy-system automation, where the job is to drive software that was never built to be driven by a machine. Another looks at enterprise integration platforms and observes how established that market has become, describing how "NetSuite organizes monthly events for its users around the world, from Dubai to Sydney, and in each and every city you'll find a similar sight: people in Celigo shirts handing out swag" [8].

These describe different problems. Automating a modern web app talking to another modern web app is not the same task as automating a decades-old on-premises system, which is not the same task as connecting the systems that run a large finance department. A tool built for one will feel like the wrong shape for another. The mistake to avoid is picking a platform for the automation you are doing this month and then straining it to reach the automation you will need next year. Before you standardise on one, be honest about the kind of work you actually have, using something like how to tell whether a task should be automated, and remember that the answer is sometimes a person rather than a workflow, as covered in when to hire and when to automate.

The common thread

Every item above describes the same movement from a slightly different angle. The agent that switched marketing platforms, the gateway that sits between agents and your tools, the assistant reading your documents, the code you inherited without writing it, and the platform you use to wire everything together are all parts of a stack that now runs partly on its own. Choosing well no longer means picking the tool with the best screen. It means checking the limits, the exits, and the layers you are agreeing to depend on — because those are the parts an agent runs into first, and they are the parts you will feel if you ever have to leave.