TL;DR
If you want to watch the full CRMKonvo, please go ahead here (optimized for smartphones) or here (optimized for tablets/computers).
Else, be my guest and continue to read.
Or do both …
Tokenmaxxing Is a Symptom, Not a Strategy
Tokenmaxxing probably peaked about six months ago, Jon reckons, and the wake-up call followed. One of his recent stories covered yet another per-user cap on AI spend, and the pushback he got on X captures the muddle: a $29 cap might be short-sighted, while $10,000 per user might be a good investment. It depends on what comes back. Most companies cannot say, so they cap.
One response to this problem is a shift to smaller, right-sized models. The less glamorous approach may just be more promising. Still, we keep sitting through agentic demos that classic automation could have handled. Jon called it "really stupid" for enterprises to reach for the most expensive tool for every problem, then added the part keynotes leave out: the cheaper technology is often the more reliable one too.
Deterministic workflow, the "boring automation" of the debate, is not a consolation prize. It is the part of the stack that works, alongside agents rather than instead of them. In blunt words: an agent doing a rules engine's job is a rules engine with a token meter. In other words, it is regularly not the best idea to throw a 21st century solution at a 20th century problem.
The Reseller's Paradox: When Inefficiency Pays
Jon's list from the road put two items at the top of customers minds: pricing and ROI, then interoperability and user experience. How do Copilot, SAP and ServiceNow agents work together? Vendors lead with the next agent instead.
That discrepancy is not an accident. Every vendor touting an orchestration layer, Zendesk, SAP, Oracle, ServiceNow or HubSpot, you name it, wants interoperability – but with itself in control. The customer's benefit is often a side effect. Meanwhile new residents of what I’d call the zoological garden of agents arrive whether or not anyone asked for them.
Under consumption pricing, the vendor puts the risk straight on the client. An inefficient agent burns a few more tokens: bad for you, good for me, because I am reselling them. The worse it works for you, the better for me. No vendor says this out loud; few have designed their commercial model to rule it out. Until a vendor shares the cost of its agent's inefficiency, its incentive to remove that inefficiency is weaker than its marketing suggests.
Context, Harnesses and the Dependency Nobody Prices In
Jon's most useful model was built around a pair of terms customers rarely discuss: context and harness. Context means getting the agent exactly the right enterprise data at the moment it needs it, from a variety of reliable sources. Harnesses are the guardrails, verification, traceability and explainability that keep the agent compliant.
His conclusion is worrying, almost scary. Most customers cannot build and maintain the necessary architecture themselves, and many data providers have not cracked the variety part either, whatever they claim. So customers depend on vendors, which is why every vendor is jockeying for that spot. This autumn's keynotes offered plenty of forward-looking statements about owning that layer and far less that ships today.
Vendors conflate "our AI is trustworthy" with "we are trustworthy". Jon rejects the first premise. We should keep a healthy distrust of AI systems, the same way a zero trust architecture declines to trust any user or device by default. And, in his words, "the customer gets to define trust for themselves." You can trust a vendor while nobody trusts the technology. A vendor that asks you to trust the model is asking for the wrong thing.
Risk-Blind Keynotes and the AI You Deserve
Jon's recurring keynote grievance: presenters breeze from a low-risk HR self-service agent answering benefits questions to candidate screening, which lands in the high-risk category of the EU AI Act, without a word on how they treat the difference. Many have good answers and simply do not give them; it comes across as cavalier. Add NIS2 obligations and the silence becomes a sales problem.
An interesting question sharpened the point: are we building the most expensive surveillance system ever and calling it a relationship system? The short answer: maybe we are, and if so it is our own fault. "You get the kind of AI you deserve." Vendors supply the architecture; customers own the results and the implications. The difference is in the mindset; the implementation is either looking inside-out or outside-in. Inside-out uses the data to maximize my profitability. Outside-in uses it to make my client successful, which tends to make me successful too. Same tooling, different intent, opposite outcome for the customer.
Ownership applies to people too. The claim that domain expertise is becoming a commodity is "complete and utter bullshit". Only a domain expert can tell faux results from real ones, which is precisely what the forward deployed engineer model assumes the model itself will supply.
Measuring CX Value Starts Before the AI Does
Another good question is how companies get better at measuring AI's real impact on customer experience. Jon's baseline is right: agree with every stakeholder how results and costs get measured before the project starts. The simple truth is: this is not an AI problem at all. Most organizations still lack a hierarchy of measurable objectives that interlock. Marketing and sales each have targets that roll up into nothing anyone can move. Without that you are stuck, whatever you buy. Jon's follow-up belongs above every steering committee door: AI has a nasty habit of exposing problems it cannot solve. It exposes your silos and your data quality without fixing either. And it does it fast.
Then there is the goal itself. As an example, you can choose your service being best in the industry versus cheapest in the industry. Both are the wrong first question, however. The best service is the one that does not need to happen, so start by asking why the customer has to contact you at all. Jon's CVS pharmacy made it impossible to phone the pharmacist, so he walks in and joins the store queue instead. The demand did not disappear; it moved somewhere more expensive. And cutting half a contact center while CSAT stays flat – or tanks – is not a success story. It is proof you are not excelling at anything.
Cheaper Tokens, Longer Loops, Higher Bill
Token prices fall, but agents loop more, so the bill climbs back. That’s the inference paradox. Every vendor this autumn has an agent that works while you sleep; as Jon put it, there are no volunteer agents working for free. Memory compounds it, because each turn carries the history. A hard cap creates its own failure mode. Picture the agent running your factory hitting its token ceiling at 3 a.m. and simply stopping …
An ERP customer argued on stage that over ten years almost every CFO would sign off, if the benefits are quantified transparently. A ten-year business case on a cost curve nobody can forecast twelve months out is a blind faith, not a calculation. Compounding this is that the ROI of one pocketed use case matters less than whether it scales. Vendors are in no better position: if they cannot tie their own cost to your outcomes, their glass ball stays murky, and they cannot help you do it.
However, enterprise vendors deserve credit for doing more on governance than the frontier labs. Unluckily, they just bury it under the next agent announcement.
Pragmatic Playbook for Enterprise CX Buyers
None of this argues for waiting until prices stabilize. The sidelines are not a strategy. This speaks in favor of buying differently.
Make the vendor justify every agent. For each proposed use case, ask why deterministic automation will not do, and get the answer in writing. Demand pricing tied to achieved outcomes, explicit loop limits and documented behavior when a budget ceiling is hit. Ask to see their orchestration layer hand off to another vendor's agent, not to one of their own. If the vendor will not share the cost of its agent's inefficiency, price that risk into the deal.
Fix objectives and context before you buy agents. Agree an interlocking hierarchy of objectives from the strategic CX outcome down to departmental KPIs, and decide whether you are aiming for better service or cheaper service. Then audit where the context actually lives. If what matters about a key account sits in Slack threads rather than the system of record, ask the vendor exactly how its context layer reaches it, and under which permissions.
Design for risk tiers and human expertise. Require the vendor to map each use case to a risk tier, starting with the EU AI Act categories, and to show the different controls per tier. Put domain experts next to engineers in use case design; they are the ones who can tell a plausible answer from a correct one. Tell your employees what the AI is for, monitoring them or making their work better, before they read about it in a headline.
Trust the vendor if it earns it. Never trust the model.
Comments
Post a Comment