You're Not Paying for AI, You're Paying for What It's Sitting On

Four things landed on my desk this past week that look unrelated on the surface: token budgets spiraling with no shared view of where the spend goes, a GTM Engineer role nobody defined before hiring for it, a CRM migration debate, and a CAC target getting chased with more spend instead of a fixed handoff. Look closer and all four break the same way, and get fixed the same way: a clear diagnostic of what's actually broken, a step-by-step brief a team can act on the same day, and, wherever AI is involved, a prompt built for the specific task instead of a frontier model burning tokens to guess at it. That combination is quickly becoming the difference between AI spend that lowers CAC and AI spend that just becomes a new expense sitting on top of the same leak. This issue walks through all four patterns with that lens, not just what happened, but what to actually do about it.

Where Is Your Token Spend Actually Going, and Why Isn't "Tokenmaxxing" a Strategy?

You can't answer that from a billing dashboard. You answer it by mapping which tasks actually require a frontier model and which ones don't, then checking your usage against that map.

Some companies now hand out an actual token budget alongside a salary. I've heard it framed at companies like NVIDIA roughly like this: if you're a $500K-a-year employee, you're expected to put another $250K into tokens. The intent isn't wrong, you want capable people actually using the tools. But a budget without a map just becomes permission for everyone to run wide-open multi-agent orchestration with nobody checking what any of it produced.

Here's the audit I'd actually run before that conversation goes any further. First, pull the last 30 days of usage and break it down by task type, not by team: which calls are classification or retrieval (cheap, small-model work) versus multi-step reasoning or generation (where a frontier model earns its cost)? Second, for every recurring task still running on a frontier model, ask whether a smaller or open-source model produces an acceptable result. A frontier model can run 8 to 14 times the cost of a smaller alternative for the same job, and that gap is the first place to recover margin. Third, check how much of that spend is actually compensating for bad inputs: an agent re-querying, retrying, or over-explaining because the underlying data was messy in the first place. That's not a model cost. That's a data-readiness cost showing up on the wrong invoice.

The fix here is never a bigger AI budget. It's knowing what a single action should cost before multiplying it by ten, a hundred, or every role in the company. That's an AI-readiness question wearing a budgeting disguise.

See how to reduce agent token spend.

What Does a GTM Engineer Actually Do in the First 90 Days, and Why Do So Many Hires Fail by Then?

The first 90 days shouldn't be spent proving the hire was smart. They should produce one documented, repeatable fix to a handoff that was previously invisible, and everything about how the role is set up should point toward that.

Pay for the role has climbed to $150K-$280K, often for candidates with just three to five years of experience, which is pulling a lot of people toward it fast. Here's the 30-60-90 I'd actually hold someone to, whether you're hiring for the role or stepping into it. Days 1-30: audit, don't build. Map every handoff between Marketing, Sales, and Customer Success, and write down who owns each one today, even when the honest answer is nobody. That's the same exercise as an AI-readiness diagnostic, just run on people and process instead of a tech stack. Days 31-60: take the single highest-leverage broken handoff from that map and fix it with a documented, repeatable workflow, not a one-off save that only works because you personally chased it down. Define what happens at each stage and who's accountable when it breaks. Days 61-90: measure whether that fix actually moved a number tied to CAC or pipeline velocity, and write it up in something anyone else in the company could read and repeat.

If a hiring process can't produce that 30-60-90 during the interview itself (ask a candidate to walk through exactly how they'd spend day one, not which tools they've used before), that's the real signal the role was never defined in the first place. That's also what's quietly separating the hires who deliver from the ones who look like failures at the 90-day mark for reasons that were never really about them.

That first 30 days is, whether anyone calls it this or not, an AI-readiness diagnostic run on a person instead of a system.

See the GTM Engineer playbook.

Should You Leave Salesforce or HubSpot for an AI-Native CRM, and What Are You Actually Deciding?

You're not deciding which platform wins. You're deciding whether your current failures live inside the CRM itself or in the layer of tools and data around it, and that's answerable before you sit through a single demo.

TCI Transportation connected one intent signal to downstream routing, task creation, outreach, and visibility. Xerox moved 85,000 accounts into an AI platform. Neither started by ripping out their whole stack, and that's the model worth copying. Before evaluating a single vendor, run this audit instead: list every system that currently touches your CRM (billing, support, marketing automation, enrichment) and mark which ones sync cleanly versus which ones still need manual exports or workarounds. Score your current governance honestly: can you say, right now, which fields an agent would be allowed to touch and who signs off when it gets one wrong? If not, that gap follows you into whatever platform you migrate to next. Then pilot one workflow, a single intent signal or a single routing rule, before you commit to anything larger.

If most of your list comes back "clean sync, no workaround," your real problem probably isn't the CRM. If most of it comes back "manual workaround," a new CRM won't fix that either, because the same disconnected tools still have to talk to whatever system of record you land on. I've never once seen a migration fix a data problem. It just gives the data problem a new address, and that's true whether the new address is more modern or not.

A rewiring decision this size deserves the same discipline as everything else this week: map what's actually broken before deciding which side of the CRM debate to join.

See what belongs in a modern GTM stack.

How Do You Reduce CAC Without Cutting Spend?

Run the handoff audit before you touch the budget: measure the actual queue time between lead creation and first meaningful touch, and have Marketing and Sales each independently write down what "qualified" means. If those two definitions don't match, you've found the leak, and it's cheaper to fix than any new channel.

Boards and investors want CAC down even with revenue at an all-time high, so leadership starts cutting, and teams reach for more webinars or more "free" outbound trying to out-organic their way to a better number. None of that touches the actual leak. Here's the three-part test I'd run instead this week. First, pull ten closed-lost deals and ten deals sitting in the current queue, and trace exactly how long each one sat untouched at every handoff. That number is usually more shocking than any channel performance report you've looked at this quarter. Second, check whether your dashboard tracks CAC against lifetime value or still just cost-per-lead. A cheap lead that churns in 90 days is more expensive than an efficient one that stays three years, and a cost-per-lead view can't see that difference. Third, ask honestly whether the last fix you shipped improved a conversion rate or just added more volume on top of the same broken handoff.

Don't stop at Marketing-to-Sales either. Run the same test on the handoff from Sales to Customer Success, where churn quietly wipes out the exact LTV payback that was supposed to justify the acquisition spend in the first place. Track churned logos against how long it actually took CS to receive a real account handoff, not just a Slack message with a name attached to it.

Every one of this week's four patterns gets fixed the same way: a clear diagnostic of where the friction actually lives, then a step-by-step brief a team can act on immediately, not a slide deck someone admires two weeks later and never opens again.

Understand how CAC payback period works.

What Does an AI Readiness Diagnostic Actually Fix, and How Does It Touch Your Token Spend?

An AI readiness diagnostic maps where your systems, data, and processes are broken before anyone deploys an agent, and it lowers CAC directly by cutting the wasted token spend and rework that come from asking a model to compensate for missing context.

A recent TechCrunch report covered June, a Marc Benioff-backed startup that raised $20 million in pre-seed funding, founded by former Salesforce executives who'd watched customers struggle to bring AI into existing enterprise platforms. June's approach is to examine a company's systems and processes, identify the bottlenecks, and produce a step-by-step roadmap for deploying agents safely. That a company can raise real money on "we'll tell you what's broken before you automate it" says the market has stopped pretending the model was ever the hard part.

A credible diagnostic answers a specific set of questions before anyone builds an agent: where is the business losing time, money, or information today, which systems and data sources are involved, which definitions or records conflict, what should be fixed before automation begins, which workflow is worth changing first, what permissions and approvals are required, and how will you actually measure whether the change created value. The output can't be a vague note to "clean up the data." It has to be a sequence: remove the duplicate field, connect the missing source, correct the attribution rule, tighten the handoff, document who owns the decision. Only after that does it make sense to configure the agent that depends on those foundations.

Here's the part most teams skip even after the diagnostic is done. Knowing what's broken doesn't automatically make the fix cheap to execute. That's where a prompt built for one specific, named task (reconciling two CRMs' lead-source fields, classifying churn risk from support tickets, drafting a documented handoff between Marketing and Sales) earns its keep over a generic one. A generic prompt asked to "clean up the data" burns tokens guessing at what "clean" even means, then needs two or three rounds of correction before it's usable. A prompt built around the actual definition of the task, with the relevant context already loaded in, gets a usable answer in a single pass. That difference compounds across every pattern in this issue: the token audit, the GTM Engineer's first fix, the CRM evaluation, the handoff repair. All four get more accurate and cheaper to execute the same day when the diagnostic and the step-by-step brief already exist, instead of getting improvised from scratch under deadline pressure.

None of this shows up as a line item labeled CAC, but it's the same acquisition economics running underneath it. Broken handoffs, unreliable attribution, and inconsistent data all mean more leads are needed to produce the same pipeline, sales spends time correcting records instead of selling, and finance keeps paying for overlapping tools nobody fully uses. Fix the diagnostic layer once, hand the team a step-by-step brief and the right prompt for the job instead of a blank chat window, and the same acquisition spend starts converting more efficiently without a single new dollar added to the budget.

Check whether your business is ready for AI today.

What Do These Four Patterns Actually Cost You in CAC?

Each pattern above hits CAC from a different direction. Lined up together, they all trace back to spending on infrastructure before fixing what it sits on top of.

1. Token spend: Token spend without a shared view of what's being spent or why isn't a strategy, it's an unmonitored budget hole. The result: fully-loaded GTM spend that never gets checked against what it actually returned, quietly inflating the true cost base CAC gets measured against.
2. GTM Engineer role: Hiring for the role without defining what "moving the needle" looks like sets up a strong candidate to fail by design. The result: months of a $150K-$280K salary spent solving the wrong problem, while the handoff leaks it should have fixed keep bleeding revenue.
3. CRM migration: A system-of-record migration doesn't fix a data problem, it gives the same data problem a new address. The result: teams pay the full cost of a migration in time and risk and still end up needing the same governance and handoff work they were trying to avoid.
4. Handoff leak: The CAC leak almost never lives in acquisition itself, it lives in the handoff between Marketing and Sales, and again between Sales and CS. The result: chasing that leak with more channels and more spend just raises acquisition cost against a funnel that was never actually broken at the top.

This Week's Move, starting Monday 8/17/26

Pick one of this week's four patterns (token spend, the GTM Engineer's first fix, the CRM decision, or the Marketing-to-Sales handoff) and run the specific audit from that section this week, in writing, before you spend a new dollar on a tool, a hire, or a migration. The audit is the cheap part. Skipping it is what gets expensive.

Have a workflow, metric, or mistake you want broken down in a future issue? Reply to this or send me a DM on LinkedIn.