When software stops suggesting and starts acting

The announcements worth your attention today circle a single shift. The products are moving from telling you things to doing things, and the hard questions are no longer about output. They are about how much you let software act on its own, what that costs, and which work still belongs to a person.

That shift changes how you should read a demo. A tool that drafts a reply and a tool that sends it are not the same purchase, even when the screen looks identical. The sections below take the five items that bear most on a tool choice, in order of how much they should affect yours. We build around the same question at 360REV, so treat the framing here as a lens rather than a pitch.

How much an AI should decide on its own

Start with the question that sits under everything else. When software only answers, a wrong answer costs you a moment. When software acts, a wrong action costs you whatever it touched. Zapier put the problem plainly: any product that does things, not just says things, runs into the same decision problem sooner or later [1].

The two obvious settings both fail. If the tool asks before every action, you have not saved any work. If it acts and tells you afterwards, you have handed it decisions you may not want it making. The useful answer is a middle band: the tool acts without asking on low-stakes, reversible steps, and pauses for confirmation on anything that spends money, contacts a customer or cannot be undone.

So when you evaluate a tool that acts, do not ask whether it is autonomous. Ask where the line sits and whether you can move it. A fixed line someone else drew is a worse buy than a lower level of autonomy you control. We wrote more about the decisions automation should never make without a person in the loop.

The bill arrives even as usage climbs

The second item is a reality check on the first. TechCrunch, reporting on spending data from Ramp, noted that AI usage keeps climbing while spending has stalled [2]. The report ties this to price cuts and to larger buyers getting better at cost control.

For a business choosing tools, this matters in two directions. It tells you prices are under downward pressure, so a quote you accept today may look expensive next quarter. It also tells you the sophisticated buyers are not just adopting more; they are metering what they already have. The lesson is to treat AI spend like any other variable cost. Know what each tool charges you per unit of work, watch whether usage and bill move together, and be ready to renegotiate. A tool that is cheap per seat but priced per action can surprise you once the actions scale. We have written before about where small businesses quietly lose money, and unmetered automation spend belongs on that list.

What AI agents actually changed at one company

The third item gives you numbers rather than theory. SaaStr summarised what Vercel's COO reported about running AI agents in production: the company took ten sales development reps down to one, built a support agent in-house in two months, and now handles most support cases with AI. Notably, the team did not deploy blind. They ran the AI sales agent in shadow mode for six weeks first [3].

That shadow period is the detail to copy. It is the autonomy question from the first section, applied in practice: let the agent produce output while a person still makes the call, watch where it is wrong, and only then widen what it can do unassisted. The headcount figures will draw the headlines, but they are the result of a method, not a shortcut. Also worth noting is the reported rule that Vercel will drop any tool without an API. That is a procurement filter, not a technical footnote. A tool you cannot connect to the rest of your stack becomes a place where work gets stuck. We covered that kind of thinking in how to choose software worth using.

Code is cheap, the judgement around it is not

GitHub's guide to agentic engineering makes a point that generalises past software teams. Its framing is blunt: writing code got faster, and the work around it did not [4]. The post walks through planning, writing, reviewing changes and investigating production issues with Copilot, and is explicit that some of that work still needs your judgement.

Swap "code" for whatever your business produces and the shape holds. The step a machine does well, generation, was never the expensive part. The expensive parts are deciding what to build, checking it is right, and understanding why something broke. When a vendor shows you how fast their tool produces a draft, a plan or a reply, the honest follow-up is what happens to the review and the judgement around it. If those get harder or vanish, the speed is borrowed, not saved.

Decisions in milliseconds

The last item narrows the lens to one capability. Salesforce announced a new version of its decision model, Koa Decisions, that handles single-step decisions in milliseconds [5].

Speed like that is worth understanding before you want it. A single-step decision is one with a clear input and a clear rule: route this request, flag this transaction, pick this offer. Making that choice in milliseconds matters when it sits inside something a customer is waiting on, such as a checkout or a live chat. It matters far less for decisions that are rare, reversible or already slow for other reasons. Match the tool to the shape of the decision. Paying for millisecond latency on a choice your team reviews once a day is paying for a number you will never feel.

The thread, pulled tight

Read together, the five items tell one story. Tools are crossing from advice to action, and that crossing moves the risk, the cost and the required judgement onto you. The buying questions follow from that. Where does the autonomy line sit, and can you move it. Is the spend metered to the work. Was the tool proven in shadow before it ran live. Does it connect to the rest of your stack. And is the speed it sells you a speed your decisions actually need. For the previous day's read, see our 5 November briefing.