Nobody Notices Missing Context Until It's Expensive

Context is the resource every team claims to value and almost none of them can point to where it actually lives. That is the thread running through this issue: the context that disappears when middle management gets cut, the buyer context missing before a single outbound sequence fires, the maintenance context nobody accounts for when picking between build, buy, or DIY, and the technical context most teams do not have about their own website right as AI agents start trying to act on it instead of just read it. Four different rooms, the same failure: decisions get made by whoever is left holding the fewest facts, and CAC quietly absorbs the bill a quarter or two later.

What Happens When the People Who Remembered "Why" Leave, and Junior Teams Inherit Decisions They Cannot Yet See in Full?

Nothing looks broken on the day it happens. A plausible first pass and a correct decision look identical until someone with context reads them, and that person usually is not in the building anymore.

The org chart I keep seeing in 2026 is a full C-suite, a bench of junior hires, and almost nobody in between. Middle management got labeled overhead, so it is getting cut, and on a spreadsheet the logic looks clean: keep strategy at the top, execution at the bottom, remove the salaries in the middle. What that spreadsheet does not show is that a junior employee will hand you a fast, plausible first pass on almost anything, and AI just makes that first pass arrive faster. Speed was never the problem. The problem is that a plausible first pass and a correct decision look identical until someone with real context reads them, and that reader is not in the building anymore.

I have watched versions of this play out the same way each time: an attribution field gets tidied up by someone who does not know it feeds the board report, a lead-routing rebuild quietly breaks a Marketing-to-Sales handoff that took two years to negotiate, a strange pricing exception gets deleted because nobody left remembers the customer situation that created it. None of these look like mistakes on the day they happen. They usually surface a quarter or two later, as churn or CAC numbers nobody in the room can explain.

That is not a knock on junior operators. A learning mistake is how everyone gets good. But a learning mistake in a slide deck costs you a round of feedback. A learning mistake inside your CRM, your pricing logic, or your AI workflows costs real money.

Here is the actual squeeze: the C-suite cannot review everything, they do not have the hours, and junior teams cannot know what needs review because they do not have the context yet. Flatten the org without solving for that and you have not reduced management cost, you have deferred it at a worse rate. If you are running lean, and most teams are right now, the fix is not rehiring a whole layer back. It is being deliberate about where operator context lives: write down why a rule exists, not just what it is; define which decisions touch revenue and need a second set of eyes before they ship; and fix the process and data foundation before handing the keys to juniors or AI. That third point is exactly why a diagnostic beats another tool: it points a lean team at the highest-value leak first, instead of guessing where to start.

Losing that kind of context is not only an org-chart problem. It shows up just as fast on the other end of the business, in the gap between having a lead list and actually knowing who is worth calling.

Related: run the free revenue leak scan

What Is "Pre, Pre-Sales," and Why Does More Lead-List Tooling Not Fix a Targeting Problem?

"Pre, pre-sales" is the positioning, ICP, and buyer-context work that has to happen before a single asset or agent gets deployed, and no amount of list-building software can substitute for it.

I compared notes recently with an operator who builds company, product, and buyer context before any assets or agents get deployed at all. That layer is what keeps SDRs from filtering a giant contact list and calling it pipeline. Tools built for finding people are genuinely good at finding people. None of them know who is actually worth talking to, or why that person would care. That judgment does not come from a bigger list. It comes from actually understanding the company, the product, and the buyer before a single sequence fires.

This is a CAC problem hiding inside an activity metric. An SDR working a list that was never qualified against real buyer context is burning fully loaded time, salary, and tooling spend on contacts who were never going to convert. The dashboard shows healthy call volume. The pipeline quietly fills with the wrong accounts anyway, and the cost of that does not show up until deals stall or close-lost reasons start repeating.

Whichever end you start from, product context working outward or a website's revenue leaks working down through the stack, the useful version of this insight is the same: every fix teaches you something, but only if what you learn lives somewhere reusable, instead of scattered across a rep's head, a call recording nobody rewatches, and a handful of documents nobody opens twice.

Buyer context is one layer. The tools you build or buy to act on that context are a whole separate decision, and a lot of teams are getting that one wrong too.

Related: what "pre, pre-sales" ICP and positioning work covers

Build or Buy Is Now a Three-Way Fight, So Which Option Is Actually Safe?

None of the three is safe by default. Legacy software, AI-native tools, and the in-house build your team says they can handle each break in a different place, usually right after everyone stops paying attention.

Legacy software is deeply integrated and built to scale, but it is buried under seat-based pricing and six-figure contracts nobody fully adopts, built for humans first with AI bolted on after the fact. AI-native tools flip that: adoption is high and pricing is honest, usually outcome-based, but the integration layer is thin, built agent-first and human second, and the surrounding ecosystem has not caught up yet. Then there is door three, where someone on the team says they will just build it. Scoped exactly to the workflow, no bloat, genuinely well-intentioned. The challenge shows up later, when nobody has actually asked who keeps it patched and performant once it is live.

I have seen the exact moment this goes wrong more than once: a manager insisting "we have got the talent, let us just build it," waving off the obvious follow-up about what happens if that person leaves. A few months later, they do, and the team inherits a tool nobody documented, held together by one webhook and a lot of optimism.

The blind spot is the same across all three paths. Everyone optimizes for month one: the contract that looks cheapest, the tool with the best demo, the build that is scoped tightest. Almost nobody asks who is actually supporting this eighteen months from now, especially with how fast the underlying technology keeps shifting. Make the call by asking who maintains it in year two, not who ships it this quarter, and the "safe" option usually stops looking so obvious.

Whichever path you pick, none of it matters if you do not actually know what you are building on top of, and most teams do not, starting with their own website.

Related: build, buy, or DIY: how to choose a GTM tool

Is Your Website Ready for AI Agents to Act on It, or Just Read It?

Most teams cannot answer that because they cannot answer a more basic question first: what is our website's actual tech stack? You cannot prepare for agents on infrastructure you cannot describe.

OpenAI announced experimental Web Model Context Protocol (WebMCP) support in the ChatGPT desktop browser and ChatGPT Sites this week. WebMCP lets any web page register JavaScript functions as "tools" that AI agents can discover and invoke: the page effectively becomes an MCP server, and the browser becomes the bridge. A compatible site can be used by ChatGPT or Codex to actually complete a task, not just read the page. It is experimental, so nobody needs to rip up a roadmap this week, but if your website is where revenue starts, the direction is worth paying attention to. Under the hood, a page calls a registration function with a name, description, input schema, and handler, agents call a discovery method to see what is available, then invoke the tool with every input validated against the schema first. WebMCP is shaping up to be for AI agents what the DOM has always been for JavaScript: the standard interface layer that makes everything else possible.

Here is where I see teams already getting it backwards. The first question is not "how do we make our site agent-ready?" It is a much more basic one most teams cannot actually answer: what is our website's front-end tech stack, right now, in plain language? You cannot prepare a website for agents, improve its revenue performance, or plan AI-native infrastructure around it if nobody can describe what it is built on. The tool catalog has to come first.

That gap is exactly why I built a simple lookup tool: drop in any website and it surfaces the front-end technologies powering it. Teams use it three ways: competitive intelligence (seeing what is powering a competitor's site), prospecting (knowing what a target account runs before reaching out), and agent readiness (seeing which technologies on your own site an agent could realistically interact with today). Whatever it does not catch, you fill in yourself, and what you walk away with is a simple, actionable checklist for your own team instead of a vague mandate to "get ready for AI."

Websites started as brochures, became funnels, and are becoming interfaces, which tracks with an earlier read I had a few months back that the word "website" would start giving way to just "site," now that pages are becoming less about being browsed and more about being acted on. If your site can only be read while a competitor's can be acted on, the same traffic converts less efficiently for you than it does for them, and that is a fully loaded CAC problem hiding inside a dev backlog nobody has prioritized yet.

Every one of this week's four patterns comes back to the same expensive habit: not knowing something about your own business until the moment it costs you. There is a specific number that captures exactly how long that costs you once a customer has actually signed, and it is worth knowing cold.

Related: what a website tech stack lookup is, and why it matters for agents · look up any site's stack

What Is CAC Payback Period, and Why Does Losing Institutional Context Quietly Lengthen It?

CAC Payback Period is how many months it takes to earn back what you spent to acquire a customer, using that customer's margin-adjusted revenue, and it is one of the fastest numbers to get worse without anyone noticing why.

The formula: CAC Payback Period (months) = CAC ÷ (Monthly Recurring Revenue per customer × Gross Margin %). A commonly cited healthy range for B2B SaaS is under 12 to 18 months. Longer than that, and the business is financing growth for a long stretch before it actually pays for itself.

This is exactly where this week's four patterns come back around. A junior team deleting a pricing exception without knowing why it existed can trigger discounting or churn that quietly lowers margin-adjusted revenue. A rep working an unqualified list closes worse-fit customers who churn before ever paying back their own acquisition cost. A build-vs-buy decision made with no maintenance plan degrades over time, and gross margin absorbs the growing support burden. A website agents cannot act on converts fewer, costlier customers per dollar of traffic, stretching CAC upward before the payback clock even starts. None of these show up as a line item that says "payback period got worse." They show up as a number finance quietly flags a couple of quarters later, with nobody quite able to point to why.

Full breakdown: what CAC payback period is and how to calculate it

What Do These Four Patterns Actually Cost You in CAC?

Each pattern above pulls on CAC from a different direction. Lined up together, they all trace back to a decision made without the context that used to be sitting right there.

1. Context loss from flattened orgs: A plausible first pass and a correct decision look identical until someone with real context reviews it, and that reviewer is often the person who just got cut. The result: mistakes buried in the CRM, pricing logic, or a workflow surface a quarter or two later as CAC or churn nobody in the room can explain.
2. Skipping pre, pre-sales: A bigger lead list was never the same thing as knowing who is actually worth calling. The result: reps burn fully loaded time and tooling spend working contacts that were never going to convert, while the activity dashboard says everything is fine.
3. Build vs. buy without a maintenance plan: Every option in the three-way fight gets picked for what it costs on day one, not for who maintains it eighteen months later. The result: the unplanned-for maintenance shows up eventually as an outage, a documentation scramble, or a full rebuild, usually right after the person who understood it has already left.
4. A website agents cannot act on: You cannot prepare a website for agents, or anything else, without first knowing what it is actually built on. The result: traffic keeps flowing to a site that can only be read, while a competitor's agent-ready site converts the same visitor more efficiently.

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

Pick one decision your team made in the last month that touched revenue: a pricing change, a routing rule, a new tool. Write down, honestly, who actually had the context to know whether it was right. If the answer is "nobody, really," that is the review step to add before the next one ships, not after.

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.