The day's AI agents, and the questions a buyer should ask

Almost every announcement worth reading today was about AI agents — software that carries out work rather than waiting for a person to click through each step. The thread running through the day is that the hard questions are no longer about what an agent can do, but about how you will be charged for it, whether it answers a problem you actually have, and whether the numbers and connections underneath it can be trusted.

What buyers now expect to pay for an agent

For most of the SaaS era, software was sold by the seat. You counted the people who would log in, multiplied by a monthly price, and that was the bill. Seat pricing is easy to forecast, which is why finance teams like it, but it rests on an assumption that no longer holds: that value scales with the number of humans using the tool. An agent breaks that assumption. One agent can do the work of many people, or sit idle for a week, and neither case maps cleanly onto a headcount.

That tension is the subject of G2's 2026 AI Agents report, which found that only 9% of buyers think seat pricing is fair, 57% want usage-based pricing, and 74% say they will shop you at renewal [1]. Those three numbers describe a single shift. If the thing you are buying does work on its own, buyers want to pay for the work it does, not for the chairs around it. And they are prepared to move. A renewal is no longer a formality; it is a point at which a usage-based competitor can make a cheaper, clearer offer.

For a business choosing tools, the lesson is to read the pricing page as carefully as the feature list. Ask what a unit of value is, whether you pay for it when you use it or whether it is bundled into a seat you may not fill, and what happens at renewal if your usage drops. A plan is a promise about what you are allowed to do and what it will cost when you do more of it; we have written before about what a subscription plan is really selling, and the G2 figures are a sign that buyers are reading those promises more closely than they used to.

Deploying AI because there is pressure to, not a problem to solve

The second theme of the day is a useful corrective to the first. Not every AI deployment is driven by a need. In a new episode of its CX series, Zoom opens with the observation that "Every contact centre leader is under pressure to deploy AI — often before anyone has asked what problem it's actually solving" [2]. That sentence is worth keeping on a wall.

The discipline it points to is old and simple. Before you buy a tool, name the problem in one sentence. Not "we should have AI in the contact centre", but "customers wait eleven minutes on hold at lunchtime and half of them hang up". A problem stated that plainly tells you what to measure after you deploy, and it tells you when to stop. A deployment driven by pressure rather than a problem has no such test. It cannot fail, because it was never asked to succeed at anything specific, and so it quietly costs money while everyone assumes it is helping.

This is the same reasoning we applied in what AI should and should not do in your business: the question is never whether a task could be automated, but whether automating it removes a cost or a delay that you can point to. Pressure is not a problem. If you cannot write the sentence, you are not ready to buy the tool.

Trusted numbers, pulled into the moment you ask

The third item is about where AI meets data you already rely on. Xero announced an integration with Google Gemini, framed around a familiar friction for people who work with accounts. As the company puts it, "As an accountant, bookkeeper or small business owner, getting a quick read on your numbers can mean interrupting your workflow" [3]. The promise of the integration is that a question about the numbers can be answered without leaving the task at hand.

The idea worth teaching here is not the convenience; it is the source. An AI assistant is only as trustworthy as the data it reads. A general chatbot that guesses at your cash position from whatever it was trained on is worse than useless, because a confident wrong answer about money is expensive. An assistant wired directly into your accounting records is answering from the figures of record. The trade-off is that you are now trusting a second system to read those figures correctly and to present them without distortion, which is a real thing to verify rather than a thing to assume.

When you evaluate any "ask your data a question" feature, the test is the same: where does the answer come from, and can you trace it back to a record you can open yourself. An answer you can audit is a tool. An answer you cannot is a rumour with a logo on it. This is also why we treat our own figures the way we do — every number a customer is shown is tied to the record it came from, so it can be opened and checked rather than taken on faith.

The self-driving company, and what it asks of you

The fourth item is the most ambitious, and the most worth reading sceptically. TechCrunch reports that Replit's CEO sees the future of work as the "self-driving company": "Replit CEO Amjad Masad envisions a future of 'self-driving companies,' where AI agents handle day-to-day tasks and people focus on higher-level decisions" [4].

It is a clear statement of where agent-first software is heading, and the useful way to read it is as a description of a trade-off rather than a destination. The appeal is obvious: if agents handle the day-to-day, people are freed for judgement. The cost is equally real and is spelled out in the framing itself. The day-to-day tasks an agent handles are where errors used to be caught. A mistyped invoice, a reply to the wrong customer, a refund issued twice — these were caught because a person touched each one. Hand them to agents and you have removed the people who noticed. The "higher-level decisions" humans are left with now include deciding what the agents are allowed to do unsupervised, and building the checks that catch the errors nobody sees any more.

That is not a reason to avoid agents. It is a reason to be deliberate about which decisions you keep. We have written a whole piece on the decisions automation should never make, and a self-driving company is only safe if someone has drawn that line on purpose. The vision is coherent. The work it quietly moves onto your plate is real, and it is worth pricing in before you adopt the posture.

Security you will never click

The last item is the kind of change that matters precisely because no one will notice it. Google announced that Meet now uses post-quantum cryptography. In its own words, "Calls in Google Meet will use post-quantum cryptography (PQC) for extra protection, starting now with laptop web clients and meeting room hardware, with mobile support coming soon" [5].

The concept is simpler than the name. Today's encryption relies on maths that ordinary computers cannot unpick in any reasonable time. A sufficiently powerful quantum computer, which does not yet exist at the needed scale, could unpick some of it. The threat that follows is called "harvest now, decrypt later": an attacker records encrypted traffic today and waits for the machine that can read it. Post-quantum cryptography uses methods believed to resist that future machine, so the recording captured now stays unreadable.

For a business choosing tools, the point is not that you need quantum-resistant video calls this week. It is that the security of a tool is mostly invisible, and the vendors who care are the ones doing work you will never see on a settings screen. When you compare platforms, ask what they are doing about the threats that have not arrived yet, not only the box-ticking for the threats that have. The answer tells you whether security is a feature they sell or a habit they keep.

Taken together, the day reads as a maturing market. The novelty of agents is wearing off, and the questions replacing it are the ordinary, durable ones a careful buyer always asks: what am I paying for, what problem does this solve, can I trust the numbers, who is still watching, and what happens when I am not looking. For more in this series, see yesterday's briefing.