Agents start acting across your apps, and choosing between them

A single thread runs through today's product news: the AI that used to live inside one app is being rebuilt to act across many of them, and in some cases to decide between them. For anyone choosing business software, that moves the hard question away from "what features does this tool have" towards "what will an automated agent be permitted to do on our behalf, and who stays accountable when it does."

That shift is worth slowing down for, because it changes how you evaluate a tool. An assistant answers a prompt and stops. An agent plans a multi-step task, carries it out across systems, and only reports back when it is done. The second kind needs more than a good model. It needs permissions, a record of what it did, and a way to switch it off. Most of today's announcements are really about that plumbing, even when they lead with the model.

An agent that gets its own workplace identity

Start with the clearest example. Google said it is turning Gemini into an agent that can plan, execute tasks, and work across business apps and systems, delegate work to subagents, use multiple AI models, and receive its own workplace identity [1]. Each of those is a separate idea, and the last one matters most for anyone who has to sign off on a tool.

A "workplace identity" means the agent is treated like a user account rather than a feature. If an agent has an identity, it can be granted and denied access, it leaves a trail you can read afterwards, and it can be removed when a project ends or when it starts doing something you did not intend. That is the right direction. An automated worker that acts across your email, your files, and your line-of-business systems should be as governable as a human one — joined, scoped, logged, and offboarded.

The trade-off is that the governance now has to exist before you turn the thing on. An agent that can delegate to subagents and call several models is harder to reason about than a single prompt-and-reply. The practical test for a business is not whether the demo is impressive. It is whether you can answer, in advance, three questions: what is this agent allowed to touch, where is the record of what it did, and who gets told when it fails. If a tool cannot answer those, it is not ready for real work, however capable the underlying model is. We have written before about drawing that line clearly in what AI should and should not do in your business.

When agents start choosing the vendor

The next step past an agent that acts is an agent that selects. A SaaStr conversation with MongoDB's returning chief executive, Dev Ittycheria, was framed around exactly that prospect, alongside notes that OpenAI has reaccelerated to a reported $70 billion run rate and that agents are beginning to pick your vendors [2]. Ittycheria had joined the discussion one week into his second run as chief executive of the company [2].

Teasing apart the idea is useful. For decades, software was chosen by a person who read reviews, ran a trial, and weighed price against fit. If an agent is doing the buying — comparing options, reading documentation, calling an API, and committing to one — then the thing you are selling to is no longer a human reading your landing page. It is a program reading your data and your interfaces.

That has two consequences for a business choosing tools today. First, the quality of a product's machine-readable surface — its documentation, its export formats, its API — starts to matter as much as the quality of its user interface, because an agent judges a tool by what it can read and call, not by how the screen looks. Second, lock-in becomes more dangerous, not less. If your own agent can be pointed at a competitor and switch, so can everyone else's, which rewards tools that make your data portable and punishes tools that trap it. The defensive move is the same one it has always been: keep your data exportable and your systems able to talk to each other, so that whoever — or whatever — does the choosing is choosing on the merits.

Skills you can hand to someone else

Slack announced that Slackbot skills are now shareable: you create an external link, send it to anyone on Slack, and browse AI agent skills from Salesforce teams that you can add [3]. Strip away the branding and this is about distribution. A "skill" is a packaged capability — a defined task an agent knows how to perform. Making one shareable by link means a capability built by one team can be adopted by another without rebuilding it.

The upside is obvious: less duplicated work, and a faster path from "someone solved this" to "we all have it." The caution is equally plain. A skill that can be sent to anyone and added in a click is a thing that now runs inside your workspace on someone else's design. Before adopting a shared skill, the questions are the same as for any agent: what can it see, what can it change, and can you audit it afterwards. Convenience in distribution raises the bar on review, rather than lowering it. The point of keeping some decisions off-limits to automation holds here too, as we argued in decisions automation should never make.

The "SaaSpocalypse" question

Salesforce published a discussion with Marc Benioff on the AI boom, the "SaaSpocalypse," and the future of Slack [4]. The word doing the work there is "SaaSpocalypse" — the argument that if AI can generate software and agents can carry out the tasks applications used to perform, then the per-seat subscription model that funded the last decade of business software is under pressure.

For a buyer, you do not need to settle whether that argument is right to act on it. You need to notice what it implies about pricing. If value is moving from seats occupied by people to work done by agents, then the way you are charged will drift from "how many users" towards "how much the system did." That makes usage visibility a purchasing requirement rather than a nicety. Before you commit to a tool whose pricing is tied to activity, you should be able to see what that activity is, in units you understand, before the invoice arrives. A plan you cannot meter is a plan you cannot budget.

Selling what you built for yourself

Finally, a quieter item with a longer tail. Spotify launched technology.spotify.com, a new site that will make its internal tech available to outsiders [5]. Companies have always built tools for their own operations. What is notable is the decision to turn internal infrastructure into something others can use.

For a business choosing tools, this is a reminder that your shortlist is widening. Some of the most battle-tested software was never built as a product — it was built to run one company and later opened up. That can be a strength, because it has been proven at scale on real work. It can also be a risk, because a tool shaped around one company's needs may assume things about how you operate that are not true for you. The evaluation does not change: does it fit your process, can you get your data out, and will it still be supported in two years.

The through-line

Five announcements, one direction. Agents are learning to act across systems, to be governed like users, to be handed around as packaged skills, and before long to choose vendors on your behalf — and the business model that priced software by the seat is being questioned out loud. None of this requires you to move today. It does change what a good tool looks like: one that can be governed, that keeps your data yours, and that shows you what it is doing in terms you can read. Those were sensible requirements yesterday. The news this week only makes them harder to skip. For the rest of the week's items, see yesterday's briefing.