When AI spend meets the question of what it returns

Two things sat next to each other in the news, and they belong together. Money has flowed into AI faster than most companies can show what it buys, and the rest of the day was a set of concrete answers about where that money is actually going — into agents doing real work, into new arms built to deploy AI, and into tools made to replace software you already pay for.

If you are the person choosing tools for a business, the useful question underneath all of it is not whether AI is worth using. It is whether a specific spend returns more than it costs. That is a question you can answer with numbers, and it is the one thread that runs through everything below.

What spending five times as much has to show for it

A recorded conversation among investors and operators kept circling one figure: "Companies quintupled their token spend in the first half of the year." [1] A token is the unit an AI model is billed in — roughly a fragment of a word going in and coming out. When your spend on tokens goes up five times, that is only good news if the work those tokens did is worth more than five times what it was before. Otherwise it is a meter running faster with nothing extra to show.

The trap is that AI spend feels productive. Something is always being generated, summarised, or drafted. But motion is not return. The discipline is the same one that applies to any tool you pay for by usage: you tie the spend to an outcome you would have paid a person to produce, and you check that the outcome actually happened. We wrote about the small set of figures that should decide these calls in numbers that change a decision, and about drawing the line between what AI should and should not touch in what AI should and should not do in your business. The headline number this quarter is that spend rose fast; the number that matters for you is whether your own spend can point at work it replaced.

One person doing the work of ten

The clearest example of that discipline came from Vercel, whose chief operating officer described taking a sales-development team from ten people to one, with the whole arrangement costing about five thousand dollars a year. The person making the call is not new to go-to-market: "Vercel's COO Jeanne DeWitt Grosser ran go-to-market at Google and Stripe for roughly a decade each before joining Vercel." [2] That background matters, because the interesting part is not that agents did the sending. It is that someone who has run large sales organisations decided the function could be rebuilt around software with one human in the loop.

Sales development — the early, repetitive work of finding and reaching prospects — is a good candidate for this kind of rebuild because so much of it is patterned. That does not mean every function is. The honest version of this decision asks which parts of a job are rule-shaped and which need judgement, and it keeps a person on the parts that carry risk. We set out how to make that call in when to hire and when to automate. A ten-to-one figure is a striking headline; the question to take from it is narrower — which of your own repetitive functions could be run by one person and a set of agents, and which would quietly break if you tried.

Microsoft builds a company to put AI to work

Building a model and deploying it are two different jobs, and the day made the split visible. "Microsoft follows Amazon, OpenAI, and Anthropic with its new AI deployment group," [3] standing up its own company, with a two-and-a-half-billion-dollar commitment behind it, focused on getting AI into actual use rather than on the models themselves.

For a business choosing tools, the signal here is not the number. It is that the large providers now treat deployment — the wiring, the change management, the getting-it-into-workflows — as a distinct problem worth a dedicated organisation. That is a quiet admission that the hard part of AI is rarely the model. It is the last stretch: getting it into the tools your team already opens every morning, in a way that survives contact with real work. When you evaluate a vendor's AI feature, the deployment question is the one to press on. Not what the model can do in a demo, but what it does inside the process you actually run.

A new challenger to the office suite

The incumbents are not unchallenged. An Indian entrepreneur is backing a new venture with thirty million dollars of his own money aimed squarely at the software most offices run on: "This time he's taking on Microsoft Office and Google Apps with AI." [4] It is described as "Bhavin Turakhia's fifth venture and his latest involving enterprise software." [4]

A challenger to the office suite is worth noticing precisely because the office suite is the hardest thing to displace. The cost of switching documents, habits, and integrations is enormous, which is why so few attempts get traction. What a new entrant with AI at the centre tests is whether that cost has changed — whether AI-native features are now valuable enough to make people move. For most businesses the practical answer is to watch, not to switch, and to judge any newcomer on the same terms as any other tool: does it earn its place, and can you get your data back out if it does not. That is the frame we set in choose software worth using.

Cleaning up twenty thousand alerts

Security work rarely makes headlines, but this piece is a useful lesson in operating at scale. "GitHub had 20,000+ secret scanning alerts across 15,000 repositories," [5] and the account describes separating signal from noise, building a remediation process, and clearing the backlog over nine months.

A secret, here, is a credential — a password or key — that ends up committed into code where it should not be. Twenty thousand alerts is the kind of number that produces alert fatigue, where so much fires that people stop looking. The lesson is not about the tool that found them. It is about what you do with a flood of warnings: triage them into what is real, build a repeatable way to fix each class, and measure your way down to zero rather than treating every alert as a fresh emergency. Any business that turns on monitoring will meet a version of this. The record you keep of what was flagged and what was done about it is the part most teams skip, and the part we argued for in the audit trail nobody thinks about.

Two automation tools that look alike

Finally, a reminder that similar-looking tools are often built for different jobs. On Power Automate and UiPath: "Power Automate and UiPath overlap just enough to look like rivals, but they're built for very different kinds of work." [6]

That sentence is the whole lesson in choosing automation software. Two products can share a category and a demo and still be aimed at different problems — one fitted to a particular software ecosystem and everyday process work, the other built for heavier, more specialised automation. If you pick on surface resemblance, you can end up with a capable tool pointed at the wrong task. The way through is to describe the specific work you want automated first, in plain terms, and only then judge which tool fits it. We set out that test in how to tell whether a task should be automated.

At 360REV we keep automation and AI features tied to the record they act on, so the work an agent does is visible and reversible rather than happening in a place you cannot see. That is the same principle underneath the day's news: spend, agents, and new tools are only worth it when you can point at what they returned.