Ungoverned, Untrained AI Is Raising Your CAC

Ten issues. Every week I sit down intending to write about CAC, and almost every week I end up writing about something upstream of it: a handoff nobody owned, a field nobody trusted, an agent nobody could explain. This week was the clearest version of that yet. Shadow AI, governance, and AI education looked like three separate conversations until I lined them up.

A teammate puts an AI tool on a personal card. A security team realizes it can't turn off an agent it didn't know existed. A company doubles its workload because nobody trusts the output. In every case the cost shows up somewhere other than where the decision was made, and eventually it lands in what it costs to win and keep a customer. Because this is issue ten, I've also added a short look back at the end on what the last ten weeks taught me about CAC.

90% of CIOs Say They Track Every AI Agent. 81% Can't See the Ones Built Outside IT.

Shadow AI rarely starts as a security event. It starts as a harmless-looking integration ticket, and by the time IT notices, the tool is already holding customer records.

Last issue I wrote about how many employees are using GenAI tools their employer doesn't know about. The question I kept coming back to this week was what happens next, when one of those tools needs access to company data. The answer is almost always a support ticket, and the ticket is where the story gets expensive.

Here's how I've watched it go. Someone in marketing or customer success finds an AI tool they genuinely love. It saves them hours every week, so they put it on a personal card instead of waiting on procurement. Paying out of pocket feels like it keeps the tool off the company's radar. The customer data they paste into it every day doesn't know that.

Then they want it connected to the CRM so data flows both ways, and they file a ticket that says something like "should be a quick one." It takes about ten seconds to write. IT opens it, googles the vendor's name, and realizes the vendor isn't anywhere in the system. The team is already buried in three other projects this quarter, so the ticket slides into the backlog and the requester starts asking for status updates.

Eventually security gets pulled in, and now somebody is working out where the data is stored, whether the vendor trains on it, and what happens if the vendor is breached. People assume this is legal's job. It isn't. It lands on security, who didn't know the tool existed until it was already holding customer records.

Part of why this keeps happening is that nobody has one view of any of it. Each AI platform sees its own agents, and nothing sees across them. A survey of 685 CIOs captured the gap neatly: 90% said they're confident they track every AI agent, and 81% said they lack oversight of agents built outside approved channels. Both can be true at once, because you can only be confident about the agents you know exist.

I don't want that teammate to stop looking. The best operators I've worked with find the good tools before anyone else does, and I'd take that instinct over a team that waits for permission. I'd just rather the curiosity show up somewhere IT can see it, long before it shows up as an integration ticket.

Seeing the agent is only half of the problem. The other half is what you can do once you've found one that's misbehaving.

79% of Security Leaders Expect to Restrict AI Agents Within 18 Months. Can Your Team Turn One Off?

Probably not yet. Most teams planned how to turn agents on and never how to undo one, so the first realistic control isn't a red button. It's a one-click rollback of a single change.

This is the pendulum swing I've been describing for weeks, now showing up in survey data: 79% of cybersecurity leaders expect their company to claw back or restrict AI agent usage within 18 months.

I keep picturing one of those toy dolls with a switch built into its body. Off. On. Full reset. And the ultimate kill switch. Most teams I talk to have put all of their energy into "on." Very few have thought about how to turn an agent off, how to roll back what it did, or what they'd do if one went rogue.

The research backs that up. In a survey of 251 security leaders, decommissioning ranked last among the controls they plan to add before scaling, and fewer than half said they're very confident they could reliably disable an agent. Gartner predicts 40% of enterprises will demote or decommission autonomous agents by 2027 after governance gaps surface in production. Those are predictions, not certainties, but they all point the same direction.

My honest take is that this is the pullback. Teams that raced to put agents everywhere are now asking how to turn one off without stopping an entire fleet of agents working together.

I don't think the answer starts with a big red button like in the movies. The realistic first form is the reset setting, a one-click revert. An agent changes a batch of records, you see exactly what it changed, and you undo that specific action while everything else keeps running. That only works if there's an audit trail and a human approving anything that touches revenue. It's boring on purpose.

The ultimate kill switch is a different animal. If we ever reach the point where a literal red button is required, it means AI was handed too much power without guardrails and now needs a manual correction. By then the mistake happened months earlier, when an agent was given authority nobody could take back one change at a time. What worries me most is that even the biggest players seem to be treating this as a race first and a safety question second. We've seen that story before, and it has never ended with safety winning on its own.

Build the rest before you hand over more power, and the red button stays in the movies.

Related: stackfinder.com/answers/ai-agent-governance

Only 31% of $1B+ Companies Say AI Is Fully Embedded. Why Is Everyone Still Double-Checking the Work?

Because trust hasn't caught up with capability. When nobody knows when to trust an output, someone has to reverify it, and the same work gets done twice.

"Hey, it checks out" might be the most dangerous sentence of the AI era. It's what someone says right before they skip fact-checking the plan their AI counterpart produced, and it will probably be the last words of at least a few projects.

A recent study found that only 31% of companies with over a billion dollars in revenue say AI is fully embedded in how they work, and only 29% have orchestration built into their workflows. What strikes me is that those teams have the tools. What they don't have is a sense of when to trust the output.

So quality assurance, in its current form, means doing the work twice. Someone has to reverify what the agent produced, and they're really asking two questions: did it understand the ask, and did it deliver what the human actually meant? That's a person re-checking work the tool was bought to take off their plate.

Governance is slowing the rest down, and trust in agents takes time. I expect it to stay a hurdle until people can rely on AI outputs the way they rely on a good colleague. But while enterprise teams work through that, smaller teams shouldn't sit in a chokehold waiting for the enterprise to go first. That matters just as much.

What helps in the meantime is knowing what AI can and can't do. That conviction is behind the Academy I built: beginner courses on the foundations of AI, intermediate courses on workflows, and advanced courses on data architecture and token economics. The most useful thing people take away isn't a new use case. It's that not every problem needs AI, and sometimes the win is knowing its limits in its current form.

That idea came up again in a conversation this week that I'm still thinking about.

Why Should You Build the Educational Layer Before Buying More Tooling?

Because the tools were never the bottleneck, understanding is. Teams that learn what AI can and can't do first buy fewer tools and trust the ones they keep.

This week I had a bit of a pinch-me moment, joining a B2B podcast production studio in Silicon Valley for a conversation on why most companies are less AI-ready than their dashboards suggest. When you're heads down building, you rarely stop to look back at how far you've come. Zooming out for an hour made me notice how the same few ideas kept surfacing.

Diagnose before you sell a fix. It sounds obvious, but a lot of the market does the opposite: sell the tool, then figure out the problem. Treat data hygiene as the actual bottleneck, not the AI tool, because an agent on messy data produces messy outcomes faster. Let customers pick their own level of hands-on help, since some teams want a roadmap they can run themselves and others want someone inside the workflow with them. Give away the playbook to build the channel, because people trust the person who showed them how it works before asking for anything. And build the educational layer before you build more tooling.

Those five hang together. Each one puts understanding ahead of purchase. A team that understands its own process knows what to ask a vendor. A team that understands the limits of the technology doesn't buy a fourth platform to fix what the first one couldn't. And a team that has learned the basics is far less likely to put a tool on a personal card and file a "quick" ticket.

Thank you to Brett Stapper and Taylor Camarena at The Front Lines, and to my host Andres Figueira, for a conversation that was more fun than I expected. If you listen, I'd love to know which of the five stuck with you.

Related: stackfinder.com/answers/ai-implementation-team

What Does a Private Equity Roll-Up Actually Inherit Besides Revenue?

Five CRMs, five definitions of "customer," and a pile of renewals nobody put on a calendar. Standardizing on one system before mapping them just moves five messy databases into one bigger one.

Two things crossed my feed this week from the private equity side, and they belong together. The first is a number: 60.9% of sponsors now want executives who can transform a function with AI, not just adopt a tool. A firm that analyzed 133 recruiting scorecards found three stages, each needing proof: adoption, redesigned workflows, and accountability. Most companies I talk to are still trying to crack stage one. It validates the work I do, because you can't redesign a workflow until you know where it leaks.

The second is a warning for anyone whose parent company is the umbrella over newly acquired businesses. Buy five companies and you've also bought five CRMs, five definitions of "customer," and a pile of software renewals nobody put on a calendar. The integration plan usually covers all of that on a single slide: standardize on one CRM and one ERP by the end of the year.

I understand why. One system is easier to report on, and the board wants a clean view of the platform. But I've spent fifteen years inside stacks after that decision gets made, and the migration never fixes the data. It moves five messy systems into one bigger one with a new logo on the login page, and some data gets lost or fails to map along the way. What you actually inherited is a digital junk drawer multiplied by the number of companies you bought: tools purchased for reasons nobody remembers, spreadsheets doing the CRM's job, a "Status" field that means something different in every business.

My rule is integrations before new tools, and in a portfolio it looks like this. Inventory every tool, contract, seat count, and renewal date across the companies, because most of the savings sit there before anyone touches a system. Map how a lead, a customer, and an invoice actually travel through each company today, the real path and not the one on the process diagram. Get the operators to agree on what "customer," "qualified," and "active" mean, because roll up five definitions and the platform-level numbers stop adding up. Only then decide, tool by tool, what gets connected, replaced, or shut off.

Consolidation is step four, and most integration plans I see stop at step one. That diagnosing and planning layer is where Stack Finder sits: map the stack, the contracts, and the data flows, then hand the operating team a roadmap they can run themselves or with a partner who does the hands-on work.

Related: stackfinder.com/answers/data-governance-framework

Where Does Churn Actually Start? Often on Your Website, With a Promise the Product Can't Keep.

Before the sale. The website makes a promise, sales repeats it, and customer success inherits the gap, so churn shows up months later in the one team that didn't cause it.

Marketing sees traffic. Sales sees pipeline. Customer Success sees renewals. Every one of those dashboards can be accurate and revenue still leaks in the space between them. I've started calling that space the seam.

I mapped it last week with Chintamani Modak, who is building a retention product called RetainIQ at Aielevate, and we put it into a joint thesis: six posts, one handoff each. The simplest version is that the pre-sale leak sets the size of your revenue base, and the post-sale leak decides how much of it you keep. The website promises something. A sales call stretches it. Onboarding discovers the gap. By the time a renewal conversation happens, the real cause is two teams and six months behind it, and the person asked to explain it wasn't in the room when it was made.

That's why it's so hard to fix from inside any one function. Each team sees its own handoff accurately, and nobody owns the whole path. It's the same missing context I wrote about a few issues back, just between departments instead of between people who leave. The question I keep asking is where context gets lost in your funnel, because if you can't point to the handoff, you'll keep paying to acquire customers and paying again to lose them.

Related: stackfinder.com/answers/net-revenue-retention

What Is Shadow AI, and How Does It Show Up in Your CAC?

Shadow AI is any AI tool or agent employees use for work without their employer's approval or visibility. It shows up in your CAC as hidden spend, duplicated tools, and incident and cleanup costs nobody budgeted.

It shows up two ways. The first is teams using tools their security team never approved. The second is people paying out of pocket, which feels safer to the person doing it because the expense never touches the company's books, and is arguably riskier, because the customer list and the pricing sheet still end up inside a model the company has no record of.

What makes it hard to manage is that there's no single place to look. Each AI platform sees its own agents, so a company can honestly believe it tracks every agent while having no view of the ones built elsewhere, which is exactly what the CIO survey showed. And because so many users have never been trained on the tools they're given, few people can tell a safe paste from a risky one.

Here's where it lands in CAC. Personal-card subscriptions and overlapping tools never appear in the software budget, so the true cost of running a GTM team is higher than the number finance sees. Every unsanctioned tool that needs to connect to the CRM turns into IT and security hours, and the delay lands on the team waiting for the answer. And one incident tied to ungoverned AI is paid for out of the same budget that funds acquisition. None of it appears on a report called shadow AI. It appears as a fully-loaded cost per customer that's higher than the plan said it would be.

Full breakdown: stackfinder.com/answers/shadow-ai-governance

How Does Each of These Actually Impact Your CAC?

Here's the direct mechanism behind each pattern above: not just that it costs money, but where in your CAC math it shows up.

• Unseen AI tools with data access: A tool someone adopted on their own becomes an integration ticket, then a security review, before anyone has asked whether it should exist. CAC impact: IT and security hours, plus the delay for the team waiting on an answer, land on the budget meant for acquiring customers, and the tool's own subscription never shows up in the cost base finance sees.

• No way to undo an agent: Teams planned how to turn agents on and not how to roll back a single change. CAC impact: when an agent edits records nobody can trace, the cleanup consumes rep and ops hours, and pipeline numbers stay unreliable until it's done, so decisions about where to spend acquisition dollars get made on bad data.

• Double-checking work the AI was bought to do: Without trust in the output, someone reverifies everything. CAC impact: the labor the tool was supposed to remove stays on the payroll, so cost per deal doesn't fall the way the business case promised.

• Buying tools before building understanding: Teams that skip education buy another tool to fix what the first one couldn't. CAC impact: each extra subscription adds to the fully-loaded cost of every deal while adoption stays flat, so spend rises without output rising.

• Inheriting stacks without mapping them: Consolidating five systems before agreeing what "customer" means moves the mess instead of fixing it. CAC impact: CAC calculated across the combined company mixes five definitions, so nobody can say which acquisition spend is actually working.

• Letting a pre-sale promise outrun the product: Churn often starts at the website and the sales call, then shows up in the team that didn't cause it. CAC impact: a customer who leaves early never repays what it cost to win them, so the CAC was spent for almost no LTV.

What Have Ten Issues of What the CAC? Taught Me About CAC?

That CAC rarely breaks where the dashboard says it does. It breaks at the handoffs, in the data, and in decisions nobody wrote down.

Ten issues in, I went back and looked at how the newsletter changed. The first issue was about the name: CAC measured against LTV is the fastest way I know to tell whether a company has product-market fit or is renting growth. I figured I'd keep writing about that ratio. Instead, week after week, I kept ending up somewhere upstream of it.

The next few issues were about the foundations under AI: the data and process a model sits on, why token spend without a view of what it produces is a hole in the budget, why a role like GTM Engineer fails when nobody defined what it should deliver, and why migrating a CRM just gives bad data a new address. Then the issues got more human. Being the only person carrying an AI initiative and also maintaining it. Context walking out the door when middle management gets cut. The cost of trusting an agent before it has earned that trust. Then they got more precise: why you can't measure AI's return until you've defined it, why the unsexy work is the work, and last issue, the gap between looking ready for AI and being ready for it.

This week fits the same line. Shadow AI, governance, and education are three ways of asking whether you can see what's happening, undo it, and understand it. If I had to compress ten issues into one idea, it's that the cost of acquiring a customer is mostly decided by choices made before and after the acquisition: what you promised, what data you trusted, and what you let run without checking.

Thank you for reading, for replying, and for the pushback that sharpened these. For the next ten, I'd like to hear from you: what's the one place in your business where you can't say, with confidence, where the money goes? Reply or send me a note, and I'll dig into it in a future issue.

This Week's Move, starting Monday, 10/5/2026

Ask IT for the list of every AI tool your team uses, including the ones on personal cards. For each one, write down who approved it, what customer data it touches, and how you'd undo what it does. If you can't answer all three for even one tool, that's your first fix, before the next ticket that “should be a quick one.”

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