The numbers usually look something like this:

- licenses purchased

- active users

- prompts submitted

- tokens consumed

- agents deployed

- workflows automated

- hours saved

It creates the appearance of rigor. There are charts. Trends move up and to the right. Someone can say adoption increased 34% this quarter.

And then the CFO asks one painfully simple question:

“What changed in the business?”

That’s where the story usually falls apart.

The problem isn’t that these measures are useless. Most of them are useful diagnostics. The problem is that we keep treating evidence of activity as evidence of value.

AI makes activity cheap. It can generate more emails, more forecasts, more summaries, more recommendations, and more content. If volume is the measure, AI will look extraordinary almost every time.

But a business does not benefit because a model produced something. It benefits when that output changes a decision, a workflow, or an economic result.

That means the AI era doesn’t need a completely separate universe of metrics. It needs a better chain of evidence.

The missing middle

Most AI measurement jumps from one end of the story to the other.

On the left: “We deployed AI.”

On the right: “Revenue grew.”

Between those two claims is a giant blank space.

Did people trust the output? Did they use it? Did it change what they did? Did the process improve? Was the improvement large enough to affect the economics? Could something else have caused the result?

That missing middle is where credibility lives.

The framework I would use is simple:

Capability → trusted use → changed workflow → operating improvement → business impact

Each step answers a different question. Together, they create a story an operator can manage and a CFO can believe.

1. Capability: Can it work reliably?

Before measuring value, establish whether the workflow can perform its intended job.

This is the technical and data foundation:

- Is the required data present and current?

- Are the necessary systems connected?

- Is the workflow available when users need it?

- Can it operate within the approved permissions?

- Does it complete the task often enough to be useful?

Typical measures include data completeness, integration coverage, eligible-user coverage, workflow uptime, and task-completion rate.

These are not board-level business outcomes. But without them, every downstream claim is built on sand.

2. Trusted use: Do people accept it?

Usage matters, but raw usage is weak evidence.

Someone can open a tool and ignore everything it recommends. A seller can receive an opportunity-risk score and do nothing. A manager can skim an AI-generated forecast summary and rebuild the analysis manually.

That is technically adoption. It is not behavioral adoption.

The stronger measures are:

- percentage of eligible work completed through the AI-enabled workflow

- recommendation acceptance rate

- repeat usage

- override rate

- material-correction rate

- percentage of outputs used in an actual decision or next action

The scarce resource in the AI era is not generated output. It is trusted output.

3. Changed workflow: Did work materially change?

This is the layer most companies skip.

AI has to alter the mechanics of work before it can alter business performance. That change should be observable.

Did the workflow require fewer human touches? Did cycle time fall? Did handoffs disappear? Did work move from reactive to proactive? Did the employee receive a recommended action inside the system where the action occurs?

Useful measures include:

- end-to-end cycle time

- human touches per completed task

- automation rate

- time to insight

- rework rate

- escalation rate

- time from signal to action

This is where the difference between an AI feature and an AI operating system becomes visible.

An accurate model that creates one more thing for an employee to interpret may be technically impressive. It is still adding work. The system has to produce a trusted insight, explain why it matters, recommend the next action, and meet the user inside the workflow they already use.

Adoption and behavior change are part of the product definition.

4. Operating improvement: Did the process perform better?

Now we reconnect the AI workflow to the metrics the company already uses to run the business.

For a revenue workflow, that might mean forecast accuracy, conversion, sales cycle, pipeline progression, or retention-risk response time.

For customer support, it might mean resolution time, reopen rate, escalation, satisfaction, or cost per resolved case.

For healthcare revenue-cycle work, it could mean denial rate, days in accounts receivable, cost to collect, or touchless-processing rate.

The important point: AI does not get a special exemption from the operating model.

If the AI-enabled workflow is supposed to improve a business process, the existing process metric should move. If it doesn’t, you have adoption without impact—or you chose the wrong operating metric.

5. Business impact: What was the change worth?

At this layer, every use case needs to tell one of four stories:

- Grow: create revenue, conversion, expansion, or retained revenue.

- Save: reduce labor, vendor, compute, or operating cost.

- Accelerate: shorten cycle time or time to value.

- Protect: reduce error, churn, compliance exposure, or revenue leakage.

That sounds obvious. In practice, it forces useful discipline.

“Employees saved 10,000 hours” is not yet an economic-impact statement.

There are three separate stages:

1. Capacity released: the task consumed fewer hours.

2. Capacity redeployed: the organization intentionally moved those hours to higher-value work.

3. Economic value realized: the redeployed capacity created a measurable financial result or eliminated a real planned cost.

Those stages are not interchangeable.

Released capacity is useful. It can improve employee experience, create headroom, and increase resilience. But unless headcount, spend, output, or revenue changes, it should not be booked as cash savings.

Honest language makes the AI case stronger, not weaker.

6. Risk and durability: Is the gain safe and sustainable?

Every speed or efficiency metric needs a paired quality measure.

- Faster proposal creation, paired with rework and win quality.

- Faster case resolution, paired with reopen and escalation rates.

- Higher automation, paired with error and correction rates.

- Lower operating cost, paired with customer and employee outcomes.

Otherwise, the system can appear successful by producing bad work faster.

For consequential workflows, also track policy violations, unauthorized actions, model drift, exception volume, and human escalation.

And don’t evaluate AI cost in isolation. Raw token cost is rarely the useful unit.

A better measure is:

Cost per successful outcome = model + platform + oversight + rework cost ÷ accepted completed outcomes

A cheap output that requires extensive correction is not cheap.

The five-number scorecard

You do not need 40 metrics for every AI use case. You need a small scorecard that preserves the causal chain.

For each priority workflow, start with five numbers:

1. Adoption: What percentage of eligible work uses the AI-enabled workflow?

2. Quality: What percentage of outputs are accepted without material correction?

3. Workflow: Did cycle time, human touches, or automation rate improve?

4. Operating result: Did the business process perform better?

5. Economics: Did the company grow, save, accelerate, or protect value—net of AI operating cost?

Add one risk metric when the workflow can create material harm.

Consider AI-assisted pipeline management:

- Adoption: percentage of pipeline reviews using AI-generated insight

- Quality: recommendation acceptance or correction rate

- Workflow: analyst hours required to prepare the weekly review

- Operating result: forecast accuracy or time from risk signal to seller action

- Economics: revenue protected through earlier intervention

- Risk: false-positive rate on opportunity-risk flags

That tells a coherent story. “We generated 10,000 insights” does not.

Three gates for choosing metrics

Not every theoretically perfect metric belongs on the scorecard. Each candidate should pass three practical tests.

Is it reasonable to achieve?

Can the team materially influence it within the measurement period? Is there a baseline? Is the expected movement credible? Is the metric close enough to the workflow to support attribution?

For an early workflow, “reduce proposal preparation time by 30%” is more credible than “increase company revenue by 5%.”

Is the data available and accessible?

Classify the metric:

- Green: already captured reliably in an accessible system

- Yellow: captured, but requires system joins or definition cleanup

- Red: not captured or dependent on manual self-reporting

A metric should not enter the executive scorecard without a named source, owner, baseline, and refresh cadence. Red metrics belong on the instrumentation roadmap—not in the next board commitment.

Does it tell a meaningful business story?

Can the measure connect to growth, savings, acceleration, or protection?

If not, it may still be operationally useful. But it is a diagnostic, not the headline.

Manage workflows as a portfolio

The final shift is organizational.

Do not run one giant enterprise AI ROI exercise. Measure AI workflow by workflow, then manage those workflows as a portfolio.

For each use case, create a one-page measurement contract:

- business problem

- eligible workflow population

- baseline and comparison period

- intended behavior change

- five primary metrics

- data source and metric owner

- expected range

- attribution method

- scale, revise, or stop threshold

Then sort the portfolio into four decisions:

- Scale: adoption, quality, operating movement, and economic evidence are present.

- Improve: adoption or quality is working, but the operating result has not moved.

- Instrument: the use case looks promising, but the data cannot support a conclusion.

- Stop: activity exists without workflow or outcome improvement.

That is what measurement should do. It should not merely report what happened. It should help leadership decide where to place the next dollar, the next engineer, and the next hour of organizational attention.

The question that replaces “How much AI are we using?”

AI will produce more activity than any technology we have deployed before. If we measure volume, almost every experiment will look successful.

The harder—and far more valuable—work is proving the chain:

Did the capability work? Did people trust it? Did their behavior change? Did the process improve? Did the improvement create meaningful economic value? And did it do so without unacceptable risk?

The question isn’t, “How much AI are we using?”

It’s this:

Which workflow changed, how do we know, and what was that change worth?

That is the measurement framework the AI era needs.

They start with a department. Build a sales agent. Add a support agent. Then a finance agent. Then every team buys two more. Six months later, the company has a pile of chatbots, automations, copilots, and internal demos that do not know one another exist.

It feels like progress because there is a lot of activity.

It is not a system.

A diagram of Stripe’s internal company agent, Kai, landed in front of me this week. I have not found a primary public source confirming every Kai-specific number in the diagram, so I am not going to repeat those as fact. But the architecture itself is worth studying because it flips the usual approach.

Instead of asking employees to choose from a catalog of agents, Kai appears to give them one place to start. The system reads the request, identifies the relevant skills, loads only the tools attached to those skills, does the work in a controlled environment, and returns a durable artifact.

That is the part that matters.

The future company agent may look less like an org chart full of digital employees and more like a capable chief of staff who knows which expertise to pull in, which systems it can touch, and what finished work should look like.

The agent is the front door.

A regional leader asks:

“Show me why implementation time increased in the Midwest, identify the accounts at risk, and draft the intervention plan.”

Today, that request usually becomes a relay race.

Someone pulls data from the CRM. Someone else asks implementation for a spreadsheet. Finance checks whether the accounts matter. Customer Success adds context. A leader turns the whole thing into a deck. By Friday, five people have produced six versions of the truth and scheduled a meeting to reconcile them.

A company agent should handle the coordination.

It should know that the request requires implementation analytics, account health, financial context, and an intervention-planning capability. It should load those skills, obtain the permitted data, run the analysis, and produce a report the team can inspect and continue editing.

The employee should not need to know which model, connector, database, or specialist workflow sits behind the request.

That is what a front door does. It receives intent and routes it into the building.

But a good front door does not make the building unnecessary.

How a thousand skills stay usable

The architecture depicted for Kai uses two passes.

In the first pass, the model sees lightweight descriptions of available skills. Enough to understand what each capability does, but not the complete instructions, examples, tools, and reference material behind it.

Once the relevant skills have been selected, the second pass loads the tools attached to them.

That sequence matters.

Most teams assume a more capable agent needs more context and more tools loaded at once. In practice, every extra option creates another decision. The model has to determine whether a tool is relevant, how it differs from similar tools, and whether invoking it will help. A giant global tool list turns capability into confusion.

LangChain describes the same principle in its public work on dynamically loaded agent skills (https://www.langchain.com/blog/langchain-skills): skills improve performance by loading specialized instructions only when the task calls for them. The model gets the expertise it needs without carrying the whole library through every conversation.

The simple version is:

1. Read the request.

2. Find the right capabilities.

3. Load their instructions and tools.

4. Execute the work.

5. Save the result.

The catalog can grow while the model’s active decision surface stays small.

That is a very different scaling model from adding another chatbot to Slack every time a team has a new use case.

A skill is more than a prompt

This is where I think most early agent programs will get stuck.

They will treat a skill as a clever prompt.

A real organizational skill needs more structure. It should contain the company’s specific way of doing the work, the knowledge required to do it well, the tools it may use, the permissions it inherits, the expected output, and the tests that determine whether it worked.

Take pricing approval.

The skill is not “analyze this discount.”

It needs the current pricing policy, approval thresholds, margin rules, contract constraints, customer context, escalation path, and output format. It may need access to CRM, billing, CPQ, and legal systems. And it should not inherit permission to change any of those systems merely because it can read them.

The skill becomes a governed capability package.

Publicly, Stripe already describes skills as structured instructions that give agents context to act. Its agent tooling documentation (https://docs.stripe.com/agents) also shows how financial actions can be exposed through agent frameworks. Kai’s depicted architecture brings those ideas inside the company: skills carry the judgment, while tools provide the hands.

That separation gives you scale without handing every request the keys to the entire building.

Keep the permanent context painfully small

Kai’s depicted architecture also includes a set of pinned skills that remain present across requests.

That makes sense, with one condition: the pinned layer has to stay small.

Company policy belongs there. Security boundaries belong there. The rules every employee request must follow belong there. A shared definition of the company, its customers, and its operating principles may belong there too.

The complete sales methodology does not.

Neither does the entire employee handbook, product catalog, approval matrix, or history of every decision the company has made.

Always-on context is expensive even when token cost keeps falling. The larger cost is attention. Every irrelevant instruction competes with the request in front of the model.

I learned this the hard way while building my own agent system. My first instinct was to make the agent smarter by telling it more up front. The result looked thorough and behaved inconsistently. The agent spent too much of its attention sorting instructions instead of solving the problem.

The better pattern is simple: pin the constitution, retrieve the expertise.

The artifact matters more than the answer

The other design choice I would copy is the filesystem.

That sounds painfully unsexy. Good.

Most AI work disappears into a transcript. The analysis is useful for ten minutes, then gets buried under the next thirty messages. Someone copies half of it into a document. Someone else takes a screenshot. The company has technically used AI, but the work has not become part of how the company operates.

Kai’s depicted architecture writes the output into files that can persist across turns. The user receives a report, dashboard, document, model, or other artifact that can be reopened and improved.

This changes the unit of value.

The agent is no longer rewarded for producing an impressive answer. It is responsible for advancing a real work product.

A forecast should remain a forecast model.

A launch plan should remain a launch plan.

A customer-risk review should remain connected to the accounts, assumptions, evidence, and decisions that created it.

Chat is the interaction layer. The artifact is the work.

Put generated work behind glass

The diagram also separates the agent from the environment where model-written code runs.

That is a load-bearing decision.

If the agent needs to execute Python, transform files, build a chart, or generate a document, that work should happen inside an isolated sandbox. The trusted process can inspect what the model proposes, run it under constrained permissions, read the result, and review the changes before accepting them.

Prompt-based guardrails are not enough. Telling an agent “do not access sensitive data” is weaker than building an execution environment where the agent cannot access it.

The permission model should follow the selected skill, the requesting employee, and the action being attempted. Read access to pipeline data does not imply write access to the CRM. Permission to draft a customer email does not imply permission to send it. The architecture has to enforce those distinctions below the prompt.

What Kai does not show

This is also where I would resist copying the diagram too literally.

It explains how one employee request moves through a company agent. It does not appear to explain the entire system the agent depends on.

A production company agent still needs:

- identity and role-based access;

- canonical company data and knowledge;

- durable memory across work and relationships;

- event-driven triggers for work nobody explicitly requests;

- evaluation, tracing, cost, and quality controls;

- human approvals tied to action risk;

- ownership and versioning for every skill;

- feedback loops that improve the system after outcomes arrive.

This is the boundary I use when thinking about the Revenue Nervous System.

The company agent sits at the interface. It interprets intent, coordinates capabilities, and performs work. The nervous system is broader. It supplies the data, memory, intelligence, orchestration, governance, and learning that allow the agent to act like it belongs to the company instead of merely having access to company tools.

The company agent is the executive function.

It is not the entire organism.

What I would build first

If I walked into a new organization tomorrow, I would not begin by building twenty departmental agents.

I would start with one company agent and three high-value skills.

The first skill would answer a recurring cross-functional question that currently takes several people and systems to resolve.

The second would produce a durable artifact that gets reviewed every week.

The third would execute a narrow workflow with a clear permission boundary and measurable outcome.

Then I would instrument the system:

- Did it select the right skill?

- Did it retrieve the right evidence?

- Did it use the correct tools?

- Did a human accept the artifact?

- Did the work change an outcome?

- What did the agent need that the company had never written down?

That last question is where the compounding starts.

Every failure reveals missing context, policy, data, or procedural knowledge. Fixing that gap makes the next run better. Over time, the company is not merely accumulating prompts. It is converting how the organization works into reusable, governed capabilities.

So do not start by asking how many agents your company needs.

Ask where employees should bring a request, how the system will find the right capability, what that capability is allowed to do, and where the finished work will live.

One front door.

A growing library of real skills behind it.

And a system that gets smarter every time someone walks through.

Run the same org on an agentic SDLC and the shape inverts. Sixteen teams of three to four, a product owner, a tech lead, and what McKinsey calls an “AI-enabled engineer,” someone whose job stopped being writing code and became supervising the system that writes it. The business analyst and the tester didn’t make the cut. Total headcount drops by roughly 40 percent. Total output goes up, because more, smaller pods run in parallel.

Read that twice. The number that matters is which roles disappear and which one gets redefined. The business analyst and the tester spent their days taking a ticket, doing the task, closing it out, and that’s precisely the work that disappeared. What got rebuilt, and rebuilt around, is judgment: deciding what to build, how it should be architected, whether the system that builds it is actually working. McKinsey’s own framing of the surviving engineer says it plainly: “their role is less about producing artifacts and more about supervising and improving the system that produces them.”

That is not a software engineering story. It is the clearest version of a story happening in your revenue org right now, and most GTM and RevOps teams haven’t clocked that it’s the same story.

The system was always there. Now it has a name.

Strip away the job titles and what’s actually running your pipeline, your funnel, your retention motion, your forecast, is a connected stack, process, data, tooling, wired together, producing outcomes whether anyone is managing it deliberately or not. Call it what it is. It’s a system. It was a system when it was a spreadsheet and a shared inbox. It’s a system now that it has a CRM, a marketing automation platform, a handful of point AI tools, and a RevOps team stitching the seams.

You already have a system. The open question is who owns it.

Here’s how most RevOps teams actually spend their week, and I’d bet money you recognize this even if the org chart calls it something nicer: build this report, fix this routing rule, clean this list, reconcile these two systems that don’t talk to each other, answer why a lead didn’t route correctly on a Tuesday afternoon. That’s a ticket queue. It has a queue depth, an average resolution time, a backlog of requests from sales and marketing and finance that never actually empties. It looks like work. It is work. It’s also exactly the layer AI eats first, because it’s request-shaped and rules-based, and an agent that can build the report, write the routing logic, and dedupe the list doesn’t need a human standing between the ticket and the fix.

I sat in on a planning meeting a few weeks back, cross-functional, product and revenue leaders in the same room, working through the next two quarters. The group agreed decisions had been made. Priorities were set. Everyone nodded. Then someone asked a flat, unadorned question: what got traded off to make room for what’s on there now. Silence. Nobody could produce the list. The roadmap tool showed what was in. It had nothing on what got bumped, or why, or who decided. The room figured out in real time that alignment happens in the meeting, but there’s no mechanism that tracks whether it survives the meeting. That’s the ticket-queue failure mode in its purest form: activity happens, decisions get made, and none of it is versioned or owned in a way that outlives the room it happened in.

Every company already has a working model for what comes next, sitting two floors down: the IT help desk. You submit a ticket. Someone closes it. The queue empties, refills, empties again, forever, measured in resolution time rather than outcomes. That works fine for password resets. It falls apart for the system that produces your revenue, because a help desk has no roadmap, and nobody on one is asking what the system should become in two quarters. They’re asking what’s broken right now.

What “own it like a product” actually means

Product management is not a vibe. It’s a specific discipline with specific artifacts, and every one of them has a direct GTM and RevOps translation.

A roadmap. This quarter we’re improving lead routing accuracy and rebuilding the ICP scoring model. Next quarter we’re instrumenting the handoff between sales and CS because that’s where NRR is leaking. A sequenced set of bets tied to outcomes, written down and published somewhere the whole GTM org can actually see it. A project list is whatever’s loudest this week, living in one operator’s head, and calling it a roadmap doesn’t make it one.

A backlog. A request inbox gets triaged by whoever’s loudest or most senior that week. A backlog is prioritized against a stated set of criteria, revenue impact, risk if left alone, effort to fix, and someone with actual authority decides what gets built next instead of the org’s political weather deciding it for them.

Ask your RevOps lead a simple question: what version is the lead scoring model on right now. Four? Eleven? Most can’t answer, because software ships v1, then v2, with a changelog, and most GTM systems have no version history at all. Nobody can tell you what the model looked like six months ago, or what changed the week conversion rates moved. Deliberate versioning fixes that. No version history means no way to learn, because there’s nothing to compare against.

Forty tickets closed in a week feels like a good week. It’s activity. A product team asks a harder question: did the thing we shipped move a number that mattered, pipeline velocity, time-to-value, NRR, the actual bowtie metrics Winning by Design uses to frame acquisition and retention as one motion instead of two departments. That’s the measure that counts.

A named owner. This is the one that actually matters, because the other three don’t happen without it. Somebody has to be able to say, out loud, in a room with the CRO: this system’s health is my job, here’s the roadmap, here’s what shipped last quarter, here’s what it bought us. Can’t point to that person today? Then what you actually have is a collection of tools with a budget line and no one accountable for whether they work together.

Why there’s no comfortable middle path

The uncomfortable part of the SDLC data isn’t the headcount number. There was no version of the future where the team stayed the same size and did the same work, just with an AI copilot bolted on. The request-shaped work either got automated, or it stayed manual and got outcompeted by whoever automated it first. Standing still was the one option the technology didn’t leave on the table.

RevOps is walking into the identical fork. The honest read of where most teams sit today: still fielding the request queue, still measuring resolution time, still without anyone who could produce a roadmap on demand. Nobody planned it this way. The function grew this way because every past complexity jump, a second product line, a new channel, a CRM migration, made RevOps bigger, someone had to wire the new pieces together, and that work accreted onto the team.

AI is the first complexity jump that doesn’t work like that. It doesn’t hand RevOps more work to absorb. It automates the ticket-taking work RevOps already had. The historical growth engine runs in reverse.

A team whose entire charter is field tickets, ship the weekly dashboard, is describing precisely the layer an agent plus a decent data model closes out. The team that owns the data model, decides which workflows run as agents versus humans, and owns the roadmap and the outcomes gets more valuable every time the underlying AI gets better, because someone still has to decide what it’s allowed to do and whether it’s actually working. Same fork the software engineers are standing in. Different function.

I know how this sounds coming from someone telling RevOps to promote itself. Fair pushback. I’d take it seriously if the mechanism weren’t identical to what’s happening in an entirely unrelated discipline, for entirely unrelated reasons, verified by a firm with no stake in how GTM organizes itself. McKinsey isn’t writing about revenue operations. They’re describing a fork every execution-heavy function hits once AI can do the execution. Software engineering hit it first because code is the most legible thing to automate. RevOps is hitting it now, for the same underlying reason: the execution got cheap and the judgment got scarce, in the same stroke.

The generalist the role actually needs

The person who can own this doesn’t look like the RevOps hire of five years ago. The old profile rewarded depth, the Salesforce admin who knew every trigger, the marketing ops manager who lived inside HubSpot workflows. That’s a specialist bet, and it stops paying off the moment an LLM can configure the tool, write the trigger, and draft the workflow at close to zero marginal cost.

What’s left is a generalist question: which tool, which trigger, which workflow, and how does it all fit together as one system. Someone who can move across product telemetry, the data warehouse, the CRM, and the customer journey without needing a translator at each border. I’ve watched this play out inside a $200M+ ARR healthtech company I worked with, where the operators who mattered most weren’t the ones who knew one platform cold. They were the ones who could see how a change in one corner of the stack showed up three steps later in a completely different metric.

There’s a maturity ladder I use to place people on this: Tourist, Resident, Architect. Most people start as Tourists, using whatever tools get handed to them without ever asking how the pieces connect, and graduate to Resident once they’ve gone deep on one corner of the system, the CRM, the outbound motion, the CS playbook, deep enough to know it cold but still stopping at its edges. The Architect is a different animal, someone who sees the whole stack, owns the roadmap, and is willing to answer for what it produces. It’s a posture people grow into, and the growing only happens if someone actually hands them the authority that goes with the job, not just the workload.

The twist worth sitting with

The request queue never actually goes away. Tickets still come in. Something will always be broken on a Tuesday. A team running a product still has fires. It also has a roadmap that exists independently of them, and enough authority to say no to some of the fires so the roadmap ships anyway.

Most GTM leaders I talk to can tell you their pipeline number cold. Fewer can tell you the version number of their lead scoring model, or what changed in it since Q1, or who owns the decision to change it again. That gap is the whole argument. You already run a system. The only open question is whether anyone’s actually driving it, or whether it’s driving itself while everyone stays busy closing tickets.

So here’s the exercise, and it takes less than an hour. Pull up your GTM stack and ask, out loud, in a room, with whoever runs RevOps: who owns this system’s roadmap, and when did we last ship a version of it we could name. Then sit with the harder one. What outcome did the last quarter of RevOps work actually move. If you’re coming up blank, you know exactly what needs a name: an owner.

-- J

Two runs. Same task. Same quality bar. One cost $10,565. The other cost $1,339.

That gap is the most important number in Cursor’s new post on agent swarms and model economics, and it deserves your attention even if you never write a line of code.

Here’s the setup. Cursor pointed a swarm of agents at a genuinely brutal task: implement SQLite from scratch in Rust, working from the 835-page specification, with no access to the original source code. Grading was unforgiving. The output ran against sqllogictest, a suite that throws millions of queries at the result. This is not a demo task. It’s months of work for a strong human team.

The first configuration used GPT-5.5 for everything, planning and execution. Total cost: $10,565.

The second split the work into two tiers. Planners, running on a frontier model (Opus 4.8), decompose the goal into a task tree and own every design decision. They never write code. Workers, running on a much cheaper model (Composer 2.5), execute explicit subtasks. They never plan. Total cost: $1,339, with identical quality. The worker layer alone dropped from $9,373 to $411, a 95 percent reduction on the layer consuming 69 to 90 percent of the tokens.

Before we dive in -- thank you to our paid subscribers! Make sure to take full advantage of all the value you get.

Check out our AI Education section, and this is where things get real. Step-by-step guides, how-to breakdowns, and hands-on training to help you build agents, build systems, and use tools like Claude Code, ChatGPT, and Perplexity at a level most people don’t even know exists. This isn’t surface-level stuff -- it’s the training that actually moves your AI capabilities forward.

Paid subscribers get access to interactive tools and guides that free subscribers don’t see.

Office hours and live events where you can bring your real questions, get them answered by people who’ve actually built this stuff, and get hands-on keyboard time with experts in the room.

Come build with us.

Cursor’s own summary is the line worth taping to your monitor: “Few moments in a large task genuinely require frontier intelligence, such as the original decomposition, the design decisions, and certain trade-offs. Once a frontier planner has collapsed the ambiguity into a detailed, explicit instruction, less expensive models simply have to follow it.”

Read that twice, because it generalizes well past software.

You already know this model, actually. It’s how every professional services firm on earth works. Partners don’t draft every document. They set strategy, structure the matter, and delegate to associates who bill at a third of the rate. The pyramid is the profit model, and it’s survived a century because it matches where judgment actually lives. But the pyramid only works because of everything around it: the precedent library, the review process, the training system. A partner and a pile of associates with no system is not a firm. It’s expensive chaos.

Cursor’s data on the chaos is spectacular. Their earlier harness, running a Grok swarm on the same problem, produced 68,000 commits and more than 70,000 merge conflicts, ending at 64,305 lines of code. The rebuilt harness: roughly 970 commits, under 1,000 conflicts, and 9,908 lines of code at 100 percent accuracy. Same class of models. Six times less code for a perfect score. The difference was never the model. It was the coordination system wrapped around it.

Look at what that system actually contains. A neutral referee agent that resolves merge conflicts, because the two agents in the conflict both think they’re right. Decorrelated review lenses: multiple reviewer agents on different models, each given different inputs (one sees the full transcript, one sees only the output, one sees only the codebase), stacked so they catch different error classes. A self-authored Field Guide, a living document the agents write for themselves that gets injected into every new agent at startup, coordination through a shared environment the way ant colonies coordinate (biologists call it stigmergy). And a custom version control system built from scratch because Git couldn’t keep up with 1,000 commits per second.

None of that is model capability. All of it is harness.

Now the part I actually care about: what this means for the applied layer.

Multi-model routing is becoming THE core design pattern of serious agent systems. Frontier model plans and orchestrates. Workhorse models execute. But there’s a catch, and it’s exactly where differentiation lives: you can only capture that 15x if you know the domain deeply enough to know which moments genuinely need frontier intelligence. Cursor knows coding. That’s why they knew the decomposition and the design trade-offs were the frontier moments, and everything else was execution.

In a revenue organization, that’s a specific list, and you should be able to write it down. The moments that need frontier-grade judgment: how you segment the market, the pricing structure for the new product line, the account strategy for the eight-figure renewal, the design of the qualification logic itself. The moments that don’t: enriching 4,000 accounts on a Monday morning, drafting the follow-up after Tuesday’s discovery call, summarizing the call notes, checking whether last night’s signups match the ICP definition someone already wrote. The second list is most of the volume. Cursor’s numbers say it can run at a few percent of the cost, if, and only if, something upstream has already collapsed the ambiguity into explicit instructions.

That “if” is the whole business.

I’ve seen this from the inside. Care Agent, the multi-agent product I helped build at Experity, has handled more than 12 million conversations. At that volume, model economics stop being a rounding error and start showing up in the margin line. Nobody runs every one of those conversations on a frontier model. The system decides, per moment, how much intelligence each step deserves. Get the routing wrong in one direction and quality breaks customer trust. Get it wrong in the other and the unit economics never close.

Which is why the 15x number is not an efficiency story. Cost is the gate on the addressable market for agents. Every workload that penciled out at $1,339 but not at $10,565 just became a market. Now multiply that across coding, finance, legal, healthcare, life sciences. The companies that master planner-worker routing in their domain will sell automation into workloads their customers literally could not afford last year. That’s how markets actually expand: not when the technology gets better, but when the price crosses the line where the next tier of buyers says yes.

So here’s where I land, and it’s the same place I keep landing. The labs will keep making models better and cheaper, and every competitor you have will get the same models you do, on the same day you do. Rent the model. The routing logic, the referee, the review lenses, the field guide your system writes for itself, the accumulated knowledge of which moments in your domain need frontier judgment: that’s owned. That compounds. In my Revenue Nervous System framing (the six-layer architecture I use for AI-native GTM), this is the Orchestration layer earning its keep, deciding what runs where and at what cost. The harness is the alpha.

One exercise before you close this tab. Pick one workflow you’re paying for right now, human hours or API bills, doesn’t matter. List every step. Mark the two or three moments that genuinely require your best thinking. Then ask what it would take to turn every other step into an explicit instruction a cheaper model could follow. I’ve done versions of this exercise with GTM teams and the ratio surprises people every time: the frontier moments are rarer than anyone expects, and the harness to exploit that fact doesn’t exist yet in most companies.

Whoever builds it first in your category sets the cost curve everyone else has to chase.

-- J

That memo has been in my head for two years, because it names the tension every operator is living through right now. You can have the best product in your category and still have nothing that protects you. And you can have a mediocre product sitting on top of something that competitors cannot touch, and print money for a decade.

The best tool I know for telling those two situations apart is Hamilton Helmer’s 7 Powers. So let me run it through the two worlds I actually work in: the go-to-market software stack, and healthcare software and services. Because when you do, the same answer falls out of both. The moat was never the product. It’s the system and the data around it. And AI is about to make that the only thing that matters.

Power = Benefit + Barrier

Helmer defines Power as the potential for persistent differential returns. Plain version: the ability to stay more profitable than your competitors for a long time, without them competing it away.

Every Power has two parts. A Benefit to you (lower cost, higher price, more value) and a Barrier that stops competitors from arbitraging that benefit away. The benefit is the easy part. Everybody can get a benefit. The barrier is the rare part, and the barrier is the whole game. If a rival can copy your advantage next quarter, you never had a moat. You had a good feature.

He also draws a line most people blur. Operational Excellence is table stakes, the stuff everyone in your category is grinding on to stay in the fight. Power is the durable condition underneath. Being good is not a moat. Being good in a way that others structurally cannot copy is.

The 7 Powers, fast:

1. Scale Economies. Cost per unit drops as you get bigger. Barrier: a challenger would have to match your share to match your cost, and that is prohibitively expensive.

2. Network Economies. The product gets more valuable as more people use it. Barrier: a new entrant faces the chicken-and-egg problem of an empty network.

3. Counter-Positioning. A newcomer adopts a superior business model that the incumbent won’t copy, because copying it would blow up the incumbent’s existing business. Barrier: the incumbent’s own collateral damage. The innovator’s dilemma, weaponized.

4. Switching Costs. Customers are locked in. Barrier: what a rival would have to spend to compensate a customer for the pain of leaving.

5. Branding. You charge more because people trust the name. Barrier: the long, uncertain years it takes to build that trust.

6. Cornered Resource. Preferential access to something coveted: talent, a patent, a dataset, a credential. Barrier: you own it and they don’t.

7. Process Power. Embedded organizational processes that deliver lower cost or a better product. Barrier: a long, opaque sequence nobody can shortcut, only live through.

Helmer even sequences them. Counter-Positioning and Cornered Resource tend to show up at a company’s origin. Scale, Network, and Switching Costs during the takeoff. Process Power and Branding at maturity. Hold onto that. It matters for who gets attacked next.

The GTM stack: only two moats, and neither is the workflow

Look at the modern revenue stack. CRM (Salesforce, HubSpot). Sales engagement (Outreach, Salesloft). Conversation intelligence (Gong). Data (ZoomInfo, Apollo). Forecasting and RevOps (Clari). Enablement (Highspot). Six neat categories, all describing themselves as mission-critical.

Run 7 Powers across them and the field separates fast.

The strongest Power belongs to the system of record, and only the system of record. That is Switching Costs, and it is enormous. Your CRM has data gravity, every workflow is wired through it, your whole team is trained on it, and a web of integrations hangs off it. Ripping it out is a year of pain nobody volunteers for. That is why Salesforce prints money. Not because the software is beloved. Because leaving is a project no one wants to sponsor.

The second real moat sits with the data players, and it looks like Cornered Resource plus Network. ZoomInfo and Apollo run contributory data co-ops, which is a genuine network effect: every customer makes the dataset better for the next one. And Gong’s actual moat was never the workflow app the reps click around in. It is the largest proprietary corpus of recorded sales conversations on earth. In an AI world, that corpus stops being a feature and becomes a cornered training-data resource.

Then there’s everything in the middle. Sales engagement. Enablement. The point solutions. Thin switching costs, no network effect, no cornered resource. Good products. Real benefit. No barrier. They are features sitting in the open, waiting to be absorbed.

Here is the AI wrinkle, and it is live right now, not a 2030 forecast. AI compresses this stack. Agents can rebuild a workflow cheaply, which means workflow-only tools are the most exposed things in all of B2B SaaS. If your entire company is “we move data from A to B and make it pretty,” an agent does that now. What survives the compression is the system of record and whoever sits on proprietary data. Everything in between gets squeezed.

Healthcare: the gravity well

Now the world I spend most of my time in. Healthcare software has a sun, and everything else is a planet.

The sun is the EMR. Epic, Oracle Health, athenahealth, the vertical urgent care EMRs. This is the deepest moat in all of software, and it is not close. Switching costs here are not “a hard project.” They are data migration plus clinician retraining plus recertification plus rebuilding every integration, all while carrying patient-safety risk at the moment of cutover. Nobody rips out the EMR on a Tuesday to try something they saw in a demo. And that switching-cost wall is reinforced on every side: regulatory certification (ONC), Network Economies as aggregated clinical data flows across the install base, Scale, and a cornered clinical dataset that is quietly becoming the training substrate for clinical AI. There is no soft flank.

Now watch what orbits it. Patient engagement, the scheduling and intake and communication layer (Phreesia, Weave, Luma), is the most exposed category in the well. Moderate-to-low switching costs. Usually a bolt-on. And its real problem is not internal, it is positional. It sits right next to a fortress that keeps expanding outward. The day the EMR ships native scheduling and intake, the standalone vendor doesn’t lose on features. It loses on the bundle. Its entire market can get absorbed by the thing it was orbiting, and no amount of product polish changes the physics.

Revenue cycle management (R1, Waystar, athenahealth’s RCM) is more defensible than people assume, and it’s where the Powers that looked weak in the GTM stack turn strong. Scale Economies from payer connections, clearinghouse relationships, labor pools, and automation spread across enormous claim volume. Switching Costs tied directly to cash flow, which is the one thing no health system will gamble on. And, rarest of all, real Process Power: the opaque, payer-specific machinery of actually getting a claim paid, built and tuned over years. You cannot buy that. You have to have lived it.

Teleradiology (vRad, Radiology Partners) runs on Cornered Resource. The asset is a network of radiologists licensed across many states and credentialed at many hospitals. Licensure times privileges is a combinatorial credentialing barrier that takes years and armies of administrators to assemble. Add Scale from follow-the-sun 24/7 coverage, subspecialty depth, and load balancing, and you get a moat that is genuinely hard to storm.

The two through-lines

Line one. In healthcare, the moat is proximity to two things: the system of record, and cash. The EMR owns the record, which is why it has the deepest switching costs in software and why it keeps eating adjacent categories for breakfast. RCM owns the cash, which buys it deep switching costs and real process power. Any layer that owns neither, patient engagement being the clearest case, is structurally weak no matter how good the product is. Position beats polish. It just does.

Line two, and this is the one to sit with. AI does not erase moats evenly. It erases labor.

Look at what’s actually under attack right now and the pattern is not random. RCM back offices. Radiology reads. GTM workflow execution. Every one of them is a category where the moat leans on human labor, and every one of them is getting counter-positioned by AI-native entrants whose whole pitch is “we do the labor with software.” That is textbook Counter-Positioning, the incumbents can’t fully follow because their P&L, their headcount, and their pricing are all built on the labor they’d have to cannibalize. For now, regulation, liability, and credentialing are holding parts of the line, especially in radiology. For now.

But flip it over. Every category that leans on data gravity, credentialing, regulation, and system-of-record lock-in doesn’t just survive AI. It gets stronger. Because AI turns accumulated proprietary data into the next moat. The EMR’s clinical dataset becomes the training substrate. Gong’s conversation corpus becomes the model. The data that took twenty years to accumulate compounds into an advantage that a well-funded challenger with a better UI cannot buy.

The one question

So the strategic question is the same one the AI labs are fighting about, and it’s the same one whether you run a healthcare software company, a GTM tool, or a services business:

Are you defending labor, or defending the system and the data?

One is a melting moat. You can feel good about it for a few more quarters while the water rises. The other compounds, quietly, while everyone stares at the model.

Pull up your own P&L this week and answer it honestly. Draw the line between the revenue you earn because a task is hard and expensive for a human to do, and the revenue you earn because you sit on data, a record, or a lock-in that a competitor structurally cannot replicate. That ratio is your real valuation. Not your ARR. Not your growth rate. That ratio.

Because the model was never the moat. The system was.

Harvard Business Review Analytic Services published a new report, “Agentic AI: Expectations, Readiness, Results,” sponsored by AWS.

It’s built on a July 2025 survey of 623 decision-makers from the HBR audience. They featured six expert voices in it. I’m one of them, quoted as Jonathan Moss, EVP of Revenue Growth and Operations at Experity, alongside people from Syngenta, Vanguard, and McAfee.

I’m proud of it. Getting a full-page pull quote in an HBR report is a milestone, and I’m not going to pretend it isn’t.

But I want to use this post to talk about the thing in the report that actually keeps me up at night, because it’s the part most people will skim right past.

Here’s the headline everyone will quote: 84% of respondents agree agentic AI will transform their business. 90% expect most organizations in their industry to be using it. Big numbers. The kind of numbers that make a board meeting feel exciting.

Now here’s the number nobody’s putting on a slide. Only 5% say their organization has well-defined success metrics for agentic AI. Five.

Sit with that gap for a second. Eighty-four percent are certain it’ll change everything. Five percent can tell you whether it’s working.

That’s not an AI problem. That’s a system problem. And it’s the difference between a company that’s actually building something and a company that bought a collection of apps with a budget line and called it a strategy.

The messy-data excuse, and why it’s an excuse

The most common thing I hear from executives is some version of “we can’t really do agentic AI yet, our data is a mess.” And look, they’re right that the data’s a mess. Everyone’s data is a mess. If we’re all honest about it, there isn’t a company on earth sitting on pristine, perfectly governed data waiting for the robots to show up.

But here’s where the logic breaks. People treat “fix all the data” as a prerequisite, a multiyear cleanup project that has to finish before the real work can start. So the project gets scoped, gets funded, gets a steering committee, and three years later you’ve got a slightly cleaner data warehouse and zero agents in production.

Here’s what I told HBR, and it’s the thing I’d put on the wall: you don’t have to embark on a multiyear project to get data right before you adopt agentic AI. Align on which data you actually need for the specific workflow the agent is doing. Find where that data lives. Make sure it’s good and consistent. Just start there.

That reframe is the whole game. The workflow tells you which data has to be good. Not all of it. The slice the agent touches.

This is why I think of agentic AI as a forcing mechanism. It’s the thing that finally makes you get serious about data quality, because now there’s a job on the line that depends on it. For years “good data” was a virtue nobody could schedule. Agentic AI gives it a deadline and a reason. You don’t boil the ocean. You clean the one cup of water the agent is about to drink from, and you go.

Directed autonomy, because the stakes are real

The other thing the report surfaces is readiness, and it’s brutal. Only 5% say their workforce is very prepared. The top barriers are a lack of talent and skills (48%) and no clear roadmap or strategy (46%). Everyone wants the outcome. Almost nobody has built the system that produces it.

In healthcare, where I spend my days, you can’t hand-wave this. The cost of an agent getting it wrong isn’t a bad email. So the governance question isn’t optional, it’s the design.

The model I use is what I call directed autonomy. It’s three tiers, and you place every workflow into one of them.

For routine workflows, agents run fully autonomous. Let them go.

For context-dependent workflows, it’s shared control. The agent and the human work the problem together.

For high-impact workflows, there’s always a human in the loop, with explicit escalation pathways built in.

A concrete one: we would never let agentic AI produce a medical diagnosis on its own. That’s not the job. The job is to put every relevant piece of patient information in front of the clinician so they make the correct diagnosis faster. The agent does the gathering. The human does the deciding. That’s the line, and it doesn’t move.

There’s a quieter payoff to all of this that I love. One of the oldest complaints in medicine is that people who trained to practice medicine have become typists,burning their time and energy on notes and admin. Orchestrate the workflows between the provider, the front desk, the biller, and the patient inside an agentic ecosystem, and you give that time back. The point of removing the admin burden was never the admin. It’s letting the human be fully present for the work that needs ahuman. Make the delivery of care more human, not less.

What I’d actually do Monday morning

If you read the report and feel the 84%-versus-5% gap in your own org, don’t start with a tool. Start with one question: which single workflow, if an agent ran it, would create value you could measure this quarter?

Pick that one. Define what good looks like before you build anything, so you’re not the 95% who can’t tell if it’s working. Clean only the data that workflow needs. Slot it into the right autonomy tier. Ship it. Measure it.

That’s the whole thing. Not a transformation. A workflow with a number attached to it. Do that three times and you’ve got a system. Skip it and you’ve got a press release.

The report is worth your time. I’d read it for the gap, not the hype.

Read the full HBR Analytic Services report here.

If you want the longer version of how I’d build this out layer by layer, the Revenue Nervous System breakdown, that’s what Sunday’s Under the Hood is for. See you there.

— J

WHAT YOU’LL LEARN IN THIS ARTICLE

• That GTM is a system, not a set of functions.

• AI amplifies whatever already exists, both the good and the bad.

• There is a right sequence for deploying AI. Most companies are doing it backward.

• Revenue Operations is a system discipline, not a departmental one.

• GTM ownership is a CEO decision.

Every CEO has an AI strategy. Almost none of them have answered the question of who actually owns the system it creates. Not who picks the vendor. Not who runs the pilot. Who owns the architecture: the data, the workflows, the agent layer, the feedback loops that increasingly determine whether your go-to-market actually works. AI will either absorb Revenue Operations (RevOps), automating away reporting, process documentation, and tool administration, or elevate it to the chief architect of the entire go-to-market system. There is no middle path.

The work RevOps does today is the work AI is best at eliminating.

The only version of the role that survives is one that fundamentally transforms. That transformation, and the ownership question it creates, is what this piece is about.

RevOps didn’t start as a strategic function. It started as CRM administration. Someone had to keep Salesforce from catching fire, so a team formed around data hygiene, report building, and making sure the dashboards said something useful before the Monday meeting. Then go-to-market got more complex. Marketing automation, multi-touch attribution, product-led growth signals, expansion revenue models, customer health scoring.

Each layer of complexity created a new process that needed an owner, and RevOps absorbed it. The CRM administrator became the process owner. The process owner became the system owner. The scope kept expanding as the go-to-market model became harder to operate. This is the pattern, not the exception. RevOps grows because go-to-market complexity grows. AI is the largest complexity jump yet. Which means RevOps is either about to have its biggest expansion, or its last.

The System No Longer Runs on People

Most executive teams have not fully internalized what their go-to-market has become. It is no longer a people-and-process operation. It is a system. And it is becoming a system that humans can no longer operate by hand. A modern go-to-market motion requires real-time signal detection across hundreds of accounts. Dynamic lead scoring that adapts to behavioral patterns. Automated workflow routing based on segment, intent, lifecycle stage, and deal velocity. Cross-functional handoffs that need to happen in hours, not days. Customer health models that synthesize product usage, support tickets, NPS data, and billing patterns into a single score that triggers the right action at the right time.

The problem is not the number of tools. It is the number of potential connections between them. The average company runs 106 SaaS applications as of 2024. In a stack that size, the number of possible pairwise integration points grows quadratically. Add one tool, and you do not add one unit of complexity. You add 106 potential interconnections. The management infrastructure most companies have built is linear. That gap is where go-to-market systems break. Not just at the tool level. At the interaction layer between them.

Figure 1. Number of tools vs. integration complexity

With the advent of AI, most executives believe they are on a path to consolidation. What we experience in practice suggests otherwise. Two things are happening simultaneously in most companies. RevOps is using AI to consolidate in one department, while another department adopts eight new AI tools without telling anyone. The result is complexity that quietly grows at the interaction layer as AI tools are added outside any governance structure. No single team has visibility. No dashboard tracks the whole. That is the gap where RevOps lives. Not in the tools. In the system that governs their interactions.

No human team, regardless of talent, can manage that interaction layer manually and keep pace with it. Most signals get missed. Most handoffs happen late. Most health scores trigger action after the moment has passed. AI is not enabling this transition. It is forcing it. The companies adopting AI-driven go-to-market motions are setting a pace that manually operated teams cannot match. This is not a theoretical future state. It is a competitive reality already playing out in pipeline generation, deal velocity, and retention economics. Someone has to architect and orchestrate this system. Someone has to be the translation layer between business objectives and machine execution. The question is who.

AI Does Not Fix What Is Broken. It Scales It.

AI is a multiplier, not a corrector. It amplifies whatever it touches. Clean processes, agreed-upon definitions, and healthy data become dramatically faster and more effective. Broken processes, inconsistent definitions, and messy data become dramatically worse, at scale.

An AI layer dropped onto a broken foundation produces outputs that look authoritative and say nothing accurate. The AI is not malfunctioning. It is doing exactly what it was designed to do: synthesizing the inputs it receives. When those inputs are garbage, the outputs are confident garbage.

I watch companies make this mistake over and over. They skip straight to the application because it has a compelling demo and a visible ROI story. What they are actually doing is betting on the short term — starting at the end of a sequence that has to be earned from the beginning.

Four stages have to be in place to enable AI to deliver its best work: data, process, system, and application. The companies playing the long game move through that sequence deliberately. They do not perfect each stage before connecting to the next. They get each stage connected quickly enough that the system can start teaching them what needs to improve. Learning happens across connections, not in any single stage.

Figure 2. The sequence AI requires to deliver its best work

The companies betting on the short term do the opposite. They skip to the application, patch backward when it fails, and wonder why the gains never compound. A disconnected system cannot learn. A system built right-to-left will always need fixing left-to-right. Playing the long game means building in the right order. AI scales what works. Betting on the short term means skipping the sequence and counting on AI to figure out what it needs to scale. It usually scales the wrong thing.

The Role That Has to Exist

Every major platform shift creates a new executive role. Not an upgraded version of what existed before. Something genuinely new. The CTO emerged when technology became a competitive differentiator. The CMO emerged when marketing became a system. The CRO emerged when go-to-market became too complex for sales leadership alone. Each time, a function that had been treated as operational suddenly became strategic. The market created a new seat at the table to reflect that.

AI is creating a new executive role that most do not yet have a name for.

We have started calling it the VP of Growth. Not a rebranded Head of Demand Generation. Not a marketing leader with a new title. A dedicated revenue operations role, someone who owns the growth model, the data architecture, the system, and the AI layer that connects functional teams around shared outcomes. This is the role Revenue Operations must grow into. Not exclusively, but the function that has spent a decade sitting across acquisition, conversion, and expansion is well-positioned to leap.

The market is already pricing it accordingly. LinkedIn shows 6,000 openings as of April 2026, with a base compensation range of $250,000–$350,000 and total compensation packages up to $550,000. That is not a coincidence. That is a market recognizing a function for the first time at its actual strategic value. Here is the provocative part. The Chief Customer Officer was created to unify customer-facing functions under one executive.

But that unification was organizational, not architectural. It connected reporting lines, not systems. The VP of Growth does what the CCO was supposed to do, but with actual system authority. A new executive has entered the room.

Go-to-Market as a Product

Once go-to-market is understood as a system, the organizational implications follow directly. A system needs a product organization, not a support function.

The best RevOps teams are already moving in this direction. Not by design. By necessity. They form cross-functional pods: a data engineer, a workflow automation specialist, and a go-to-market operator with deep domain knowledge. They run sprint cycles. They maintain backlogs. They do release management. They have arrived at product development vocabulary because the work demands it.

The team that owns the GTM system as a product is the team that owns growth.

The shift is to formalize what is already emerging. RevOps stops being a centralized service desk that takes tickets from Sales and Marketing. It becomes an embedded systems organization that builds and maintains the go-to-market architecture. The same transition product engineering made, from building what the business asks for to owning the product, is the transition RevOps is now positioned to make.

Figure 3. Revenue Operations as a system — responsibility by ring

The CEO sits at the center, not because they operate the system but because they make the ownership decision that gives everyone else the authority to do their job. The VP of Growth owns the architecture. The Data Architect and GTM Engineer own the infrastructure. The AI Agent Layer is the interface of the go-to-market product. It sits at the edge of the infrastructure, serving as the translation layer that protects the functional teams from the underlying complexity of the stack. The functional teams operate in the outer ring. They are not subordinate to Revenue Operations. They are the generators the system is built to serve.

The ownership question is not about reporting lines. It is about the gap between responsibility and governance. Revenue Operations carries the responsibility. They feel it when the system breaks. But without governance authority, agreed-upon rules, shared definitions, and system-level accountability, they can diagnose the problem but cannot fix the structure that keeps producing it. That gap belongs on the CEO’s desk.

The Capability Gap Is Real

This transition will not happen by reorganizing an org chart. It requires a genuine capability upgrade and an honest assessment of who can make the leap. The divide is real. If not uniform. Some RevOps professionals are already trending toward systems thinking and AI fluency. They are building automations, experimenting with AI tooling, and thinking in terms of architecture rather than administration. They will evolve into the systems architects this moment demands. Others are deeply skilled at the current jobs, reporting, tool management, and process documentation, but have not yet built the capabilities required for what comes next. The gap is not about intelligence or work ethic. It is about capability. And capability cannot be changed by motivation alone.

The RevOps role is not being eliminated. It is being elevated.

Elevation has a talent requirement that most companies have not yet considered. For the CEO, this resolves into three decisions. First, assess honestly which RevOps people are trending toward the system architect role, and what investment accelerates that trajectory. Second, build specific capabilities, data architecture, workflow design, and AI literacy, not generic AI awareness training. Third, accept that some of this capability will have to come from outside the company and cannot be developed from within.

The GTM Ownership Decision

Everything in this argument leads back to the question it opened with: “Who owns the GTM system?” And in most companies, the honest answer remains: nobody owns it. Pieces are owned by Marketing. Pieces by Sales. Pieces by IT. Pieces by nobody. The system as a whole is an orphan. You can feel it in the broken handoffs, the conflicting metrics, the tools that don’t talk to each other, the AI pilot that worked in the demo but failed in production.

The solution is not talent. It is governance.

If AI is going to become the execution layer of your go-to-market, and the pace of change makes that a question of when, not if, then system ownership becomes an executive-level decision. It determines org design, talent strategy, competitive positioning, and whether AI investments compound into structural advantage or scatter into point solutions that nobody maintains. This is not a tooling decision. It is not a department decision. It is the gap between having AI capabilities and having someone accountable for the system in which those capabilities live. That problem belongs on the CEO’s desk. So, who owns it?

A team burns a quarter running a demand gen program that produces pipeline the sales org cannot close. Another team spends six months building an expansion motion on top of a renewal base that is leaking. A third team doubles SDR capacity to fix a number that was never a capacity problem to begin with. The spend is real. The activity is real. The compounding is zero, because the organization was optimizing against the wrong binding constraint.

I have watched this at multiple companies now, and the pattern is the same every time. Leadership can name a handful of things that feel broken. Leadership cannot name the one thing that is actually binding the system. And in the absence of a named binding constraint, every function optimizes locally, the plans look reasonable on their own, and the quarter gets spent chasing whichever symptom made the loudest noise in the last board prep.

Pillar 5 named the seat that owns this. Deep Dive #5 is about what the person in that seat actually does every week. Forever.

The answer is not strategy. It is not planning. It is not forecasting. It is constraint diagnosis as a continuous practice. At every point in a growing company, the growth system is bottlenecked somewhere, and that somewhere moves quarter over quarter as the business grows out of one bottleneck into the next. The VP of Growth’s job is to continuously diagnose where the constraint is, name it precisely, and align the organization around resolving it. That is the operating loop of the role. It is the closest thing to a superpower a scaling company has, because most companies are still guessing, and the guesses compound.

The three places a growth system gets stuck

The reference job description Growth Institute has been circulating is uncommonly specific on this point. At any given moment, a B2B growth system is constrained in one of three places.

Capacity. Not enough pipeline to hit the number. The motion that creates qualified demand, whether outbound, inbound, partner, or product-led, is producing under what the downstream close rate and cycle time would require. The sales team has the skill to close what they see. They are not seeing enough of it. Capacity constraints look like reps with open calendars, AEs covering too many accounts to run a decent process on any of them, and a forecast where the math only works if conversion rates improve to levels the historical data has never touched. On a Monday, the symptom is a pipeline coverage ratio sliding below 3x while nobody wants to say it out loud.

Conversion. Enough pipeline arrives. The pipeline does not close at the rate it should. Something about how the team qualifies, runs discovery, handles proof, or structures the deal is broken. The cycle is getting longer, the win rate is sliding, and every no-decision post-mortem identifies a different root cause. Conversion constraints look like pipeline that looks healthy in the CRM and decays through the funnel in ways the forecasting model did not predict. On a Monday, the symptom is a sales leader walking into the forecast call with the same stalled opportunities they brought last week, re-categorized under different probability weights.

Retention. The logos land. The logos do not stay, or they stay and do not expand. Gross retention is below plan, net retention is not compounding, and the cohorts behind the current quarter’s headline revenue are quietly eroding. Retention constraints look like a renewal forecast that came in at 88% when the plan was 94%, an expansion pipeline that depends on three marquee accounts closing in Q4, and a product usage curve that peaks at day 45 and never reaccelerates. On a Monday, the symptom is a CS leader flagging the same five at-risk accounts they flagged last quarter, with the same intervention plan, and the same outcome.

Three places. One of them is binding, at any given point, and the diagnosis matters because the response is completely different.

Here is the mistake I have watched in every room where the diagnosis has not been done. The team says “we need more pipeline” when the actual constraint is conversion. They are not lying. They are reasoning locally. Marketing sees their pipeline number and takes it as a directive to build more. Sales sees their miss and assumes the top of the funnel was the issue. Nobody looks at the throughput from stage to stage and asks whether the problem is volume or efficiency. A capacity investment on a conversion problem is the most expensive kind of wrong answer, because it produces motion, the motion produces more pipeline, the pipeline compounds the conversion drag, and two quarters later the system is worse, not better. With a confident tone. With a clean deck. I have seen it happen four times in the last three years.

The first job of the VP of Growth is to stop that.

The constraint moves. That is not failure.

This is the part most companies miss.

Solve a capacity constraint and conversion becomes the new bottleneck. Solve conversion and retention becomes the bottleneck. Solve retention and you are probably back at capacity for the next segment you are trying to enter. The constraint does not sit still. The system does not stabilize at one binding constraint that you optimize forever.

This is not a sign that the work was unsuccessful. It is the nature of scaling systems. Removing a binding constraint reveals the next one, which was not binding yesterday because the first one was absorbing all the visible pain. Companies that do not understand this spend a year optimizing the Q2 constraint into Q3 and Q4, missing the fact that the constraint moved in July and they are now grinding on something that used to be broken and no longer is.

The VP of Growth is the person who sees the constraint shift six to eight weeks before anyone else notices and redirects the organization before it spends another quarter optimizing what was true last quarter. That is an unreasonable thing to ask of any existing functional leader, because every functional leader is compensated against their motion. The CMO is optimized for pipeline generation. The CRO is optimized for bookings. The head of CS is optimized for retention. None of them are structurally positioned to walk into a QBR and say “the binding constraint has moved from capacity to conversion, so the plan I submitted in January is now the wrong plan for the second half.” That sentence has to come from somewhere. The VP of Growth is the only seat built to say it.

Read more

Pillar 4 made the case that the GTM system in most companies is an orphan, and that the ring model fixes it. The question that comes back to me every time from RevOps leaders and CEOs who read that piece is the same question, almost word for word. Okay, what actually changes on Monday morning? Reporting lines, titles, budget authority, who does what. And what breaks first when we start.

This piece is the honest answer. Not a 90-day playbook, that is Tier 3. The strategic picture of what happens inside a real org when the ring model gets adopted, which stress points surface predictably, and which of them are evidence the transition is working versus evidence it is failing.

One thing up front. Transitions break things. That is not a warning. It is a roadmap. The things that break first are predictable, and if you know where to look you can tell whether what you are watching is the system shedding old architecture or the system rejecting the transplant. Different responses in each case.

The ring model, one paragraph

The CEO sits at the center. Not because they operate the system, but because the ownership decision lives there and nowhere else. The VP of Growth owns the architecture: the growth model, the data stack, the constraint diagnosis, the AI layer that connects functional teams. The Data Architect and GTM Engineer own the infrastructure underneath. The AI agent layer sits at the edge of the infrastructure as the interface of the GTM product, a translation layer that protects functional teams from the complexity of the stack. Marketing, Sales, and CS operate in the outer ring. They are not subordinate to the VP of Growth. They are the generators the system is built to serve. Pillar 4 walked this. This piece is about the Monday after the org chart changes.

Five stress points the transition surfaces, in order

I have watched different versions of this transition at multiple companies now, and the same five things break first, in roughly the same order. I am going to name them, because naming makes them manageable. When a stress point is named, the CEO stops reading it as a failure and starts reading it as a stage.

Stress point 1. Reporting line conflict

The new VP of Growth reports to the CEO. So does the CRO. So does the CMO. So does the CCO, if you have one. Within two weeks, usually in the first forecast review, the governance overlap surfaces. The VP of Growth looks at the system-level data and says the current constraint is retention, not acquisition. The CMO, who has just gotten budget approval to double down on demand gen, hears that as an attack on their plan. The CRO, who was told this year’s number depended on pipeline volume, hears it as a contradiction of the strategy they committed to at the QBR.

On a Tuesday, the CEO now has four people in a room disagreeing in front of them, and all four of them technically report to the CEO. This is where most transitions get stuck. The instinct is to smooth it over, to let everyone defend their piece, to adjourn until people have had time to cool off. That instinct is wrong, and it is the thing that kills the transition more often than any other.

The conflict is not a failure mode. It is exactly the conversation the new role was designed to force. Before the VP of Growth seat existed, that conversation never happened, which is why the system was an orphan. The CEO’s job in that meeting is not to resolve it back to the old equilibrium. The job is to hold the room long enough that a system-level answer, not a functional-level compromise, gets named.

If you are three months in and the reporting line tensions have disappeared, the transition is not working. The new role has been quietly defanged. The old functional leaders are still running the strategy. The VP of Growth has become another middle layer shipping reports nobody acts on.

The remaining four stress points, the layer that breaks in month three, the three-layer org model that finally makes the whole structure legible, the cross-functional pod that ships the GTM system on a release cadence, the capability divide nobody wants to name out loud, and the five questions you can run on your own org this week are the rest of this piece.

Read more

Loop Gain is not a metaphor. It is not a marketing concept. It is a ratio, and if your architecture is correct, you can calculate it on a Tuesday and recalculate it next Tuesday and watch it move. If your architecture is incorrect, you cannot calculate it at all, and what you have instead is a slide that says “we are compounding” because somebody wrote that sentence into the board deck two quarters ago and nobody has challenged it since.

Deep Dive #1 made the case that the feedback-loop moat behaves differently from every historical moat because it compounds instead of depreciating. This piece is the operator answer to the obvious next question: how do you measure compounding, as a number, on an ongoing basis, and how do you build the thing underneath it so the number actually means something.

I am going to try to make the technical content concrete. It has been over-gated long enough. Consultants have built careers on keeping this fuzzy. It is not that fuzzy.

What Loop Gain actually is

Jacco van der Kooij’s formulation is the cleanest I have seen. Loop Gain is the ratio of productive output that feeds back as input per cycle.

Break that apart.

Output is what your system produces in a cycle. A closed deal. A renewed contract. A resolved ticket. A campaign that ran. A submission approved. Something observable, with a result attached.

Input is what feeds the next cycle. Not the raw effort. The learning. The updated model, the refreshed scoring, the retrained agent, the playbook that now includes what last week taught you. Input is the part of the output that gets captured and becomes the starting condition for the next run.

A cycle is whatever the natural unit of repetition is for the workflow you are measuring. Outbound sequences run on a weekly cadence. Support tickets run on an hourly one. Pipeline reviews run on a two-week one. You do not have to normalize across the business. You do have to name the cycle for the workflow, because without a cycle there is no ratio.

Loop Gain greater than one means the system is compounding. Output exceeds input. Each cycle strengthens the next. The moat widens without defense.

Loop Gain less than one means the system is decaying. Output underperforms what the inputs would predict. You are spending more than you are getting back. No headcount addition fixes it. No budget increase fixes it. No CRO hire fixes it. The mechanics are mechanical. A decaying loop compounded by more resources is a decaying loop running at higher volume.

That last point is the one most CEOs flinch at. The instinct when growth stalls is to add. Add sellers, add marketers, add a head of demand gen. If the underlying Loop Gain is below one, you are paying linearly for output that decays geometrically. I have seen this at multiple companies. The board meeting where somebody says “we just need more pipeline” is almost always a meeting where nobody at the table can tell you the Loop Gain of the pipeline motion.

The ratio matters more than the absolute numbers. A small system with Loop Gain at 1.3 beats a large system with Loop Gain at 0.8 over any meaningful time horizon. Compounding is not about scale at t=0. It is about direction at every t thereafter.

Why most companies cannot measure it

A ratio requires three things. What feeds in. What comes out. What cycle you are measuring. Those are not abstract. Those are three pieces of infrastructure that either exist or do not.

Most companies cannot answer any of the three for their own growth system.

Feeds in: marketing counts MQLs, sales counts SQLs, CS counts NPS, product counts DAU, and nobody agrees on how the motion starts or where the boundaries are. There are four definitions of “lead” in the room, and three of them are hidden inside departmental spreadsheets that do not talk to each other.

Comes out: every team has its own output metric, tied to its own comp plan, defined at whatever granularity made it easiest to hit the number last year. The output of the sales motion is not the input to the CS motion in any automated sense. A human copies, pastes, reformats, summarizes. Signal leaks at every hand-off.

Cycle: the planning cycle is quarterly. The forecast cycle is monthly. The pipeline cycle is weekly. The agent cycle is real-time. Nobody has named which cycle Loop Gain is supposed to measure, so the number is unmeasurable by default.

That is the architecture problem showing up in the metric layer. You cannot measure what you have not built. The inability to cite Loop Gain is not a reporting failure. It is the stack revealing itself. If somebody on your team tells you they cannot calculate Loop Gain, they are not making excuses. They are diagnosing the real problem.

The five-layer stack that makes the number real, the three ways it quietly hollows out, what Loop Gain above one looks like on an actual Tuesday morning, a build I shipped one level deeper, and the five-question diagnostic you can run at your desk this week are the rest of this piece.

Read more

I will make this concrete. Pull your calendar from last week and color-code every block into four buckets. Green for Aim, the work of sharpening where the company is going. Blue for Army, the work of developing the people who will take it there. Orange for Assets, the work of deciding what gets capital, attention, and focus next. Gray for everything else. Do it honestly. Count the hours.

Most CEOs I run this exercise with spend over seventy percent of last week on gray. That gray bucket is not a time management problem. It is the architecture problem, measured in hours on a calendar. Every block of gray is work the system should be doing. The system is not doing it because the system does not exist yet, and the CEO is covering for the gap. Their reward for building a company is a full calendar of work the company should be able to run without them.

The calendar is the test. Show me where Aim, Army, and Assets live in your calendar, and I will tell you whether you are operating in Architect Mode or just talking about it.

Aim in practice

Aim work is not an offsite. It is not the annual planning ritual that eats three days in January and produces a slide deck the org ignores by March. Aim, done right, is a continuous practice that takes about four hours of real CEO time every week. Not in one block. Distributed.

Here is what Aim looks like on a Tuesday. You sit down at nine. The intelligence layer has already surfaced the five market signals from the last seven days that are most relevant to your thesis. Not a digest of fifty headlines. Five. Filtered against what you are actually trying to build. A competitor hire. A shift in customer behavior in your top segment. A pricing experiment that landed differently than the model predicted. A regulatory move. A loss you took against a specific alternative. You read each one with a specific question in mind: does this sharpen the thesis, weaken it, or tell me my thesis needs a scenario I have not run yet?

You spend the next ninety minutes on one of those. You run it against the model. You pressure-test your assumption about where the market is going against what the signal is actually saying. You get three defensible counter-arguments back. You read them. Some of them are better than the argument in your head. You either update or you do not, but you do it explicitly.

Then you make a call. That is the part that does not automate. The model will give you a rank-ordered list of options. It will size them. It will flag the risks. It will not tell you which hill is worth bleeding for. That is yours. It will always be yours.

One concrete Aim decision from this quarter, pattern version. I have seen this at multiple companies now. A CEO runs their thesis through the scenario layer and gets back a very plausible case for moving up-market into enterprise. The analysis is clean. The TAM is bigger. The ACVs are larger. The gross margin profile is better. Every number on the page says do it. The CEO does it anyway, in the other direction. They double down on mid-market, not because the enterprise analysis is wrong, but because they know something the model does not. They know the distribution motion they have actually built. They know which of their people would be energized by that move and which would quietly leave. They know what the brand can credibly carry. The analysis is input. The call is theirs.

That is four hours well spent on a Tuesday. Four hours of Aim beats a twelve-hour planning offsite, because it happens while the signal is fresh instead of two quarters later when the data has already moved.

Army in practice

Army work does not live in the quarterly review cycle. It runs continuously, and in Architect Mode it runs through the system, not through a process.

On a Thursday morning, a CEO in Architect Mode should be able to open a single view and see which of their leaders are trending up, which are stalling, which are compounding institutional knowledge into the system, and which are treating AI as a threat rather than a multiplier. Not performance scores. Behavior patterns. Did this leader ship a workflow into the system this month that will keep running after they leave for vacation? Did they build something the rest of the org is now standing on? Or did they ship another dashboard nobody opens.

The signals that matter are specific. Who is pulling work out of the gray bucket on their team’s calendar and putting it in a system. Who is pushing work back into the gray bucket by approving things that could be governed by policy. Who is prompting well and feeding corrections back into the agents they deploy. Who is typing the same email for the ninth time and calling it their job. Who is hiring in their own image because the team feels safer that way. Who is hiring missionaries who are going to stretch the bar.

The middle manager question is the sharpest one, and it is the one most CEOs skip. In Architect Mode, a middle manager is not an information relay node. If they are still operating as one, you have an architecture problem on their team specifically. The middle manager in Architect Mode is a micro-architect. Their job is to take every frontline signal, every customer friction, every pattern their people see that the system has not yet captured, and feed it back into the architecture so the rest of the org gets smarter. The best ones are actively compounding the moat at the team level. The worst ones are quietly starving it, usually because their identity was built around being the person who held the answers.

The Thursday conversation that follows from the view is the one CEOs most often avoid. It is the honest one. “You are an excellent leader by the standards that used to define the job. By the standards of the job we are running now, here is what I am watching for, and here is what has to change in the next ninety days.” That conversation, run with directness and genuine care for the person, is the single highest-compounding hour on a CEO’s week. The cost of skipping it is paid every day after in the form of a team that is quietly working around a leader who should have been given the chance to adjust.

I could be wrong about the ninety-day window. I am not wrong that the conversation has to happen. I have seen companies lose twelve to eighteen months by postponing it.

Assets in practice

The scarce resource in Architect Mode is not information. It is not capital in most venture-backed companies. It is the attention of your best people, and the focus of the organization on a small enough set of bets that any of them actually get leverage.

Friday is Assets day. It does not have to be Friday. It does have to be once a week, not once a quarter. Once a quarter is when most companies review their bets, and once a quarter is also why most companies spread their best people across eight initiatives and get compounding from none of them. A weekly Assets rhythm catches drift before it becomes debt.

Here is what a good Assets hour looks like. The analysis layer surfaces the week’s movement on every live initiative. Pipeline, adoption, Loop Gain (how fast it is learning) on the ones that have a learning loop, cost per unit of progress on the ones that do not yet. You read it through a single filter: which of these is deserving more of our best people, and which is deserving less. You are not asking whether any of them are good. Most of them are plausibly good. You are asking which three are asymmetric.

Then you use the Pillar 2 distinction, operationally. Uncertain versus unclear. Uncertain is honest. I have a hypothesis on initiative four, I placed the bet eight weeks ago, the signal is mixed but trending right, I will update when the data says to. Unclear is an organizational tax. I am not actually sure which of these five things we are prioritizing, which means every one of my reports is guessing, which means the best people are hedging their effort across bets that will not compound, which means we are funding motion and calling it momentum.

The discipline of Assets work is saying no to plausible opportunities, not obviously bad ones. The analysis will always make three things look reasonable. Four will have credible internal champions. The Friday afternoon decision, made explicitly, with the reason attached, and transmitted clearly downstream on Monday, is the difference between a company that compounds and a company that experiments. Experimentation is not the moat. Compounding is.

I have seen this pattern at multiple companies. The best people are spread across eight initiatives, each one getting fifteen percent of their attention, each one producing fifteen percent of what they could produce. Contract it to three. Watch what fifty percent attention does to the curve. That move almost never happens in the quarterly review. It happens on a Friday when a CEO decides they can live with five disappointed VPs for the sake of the people who are actually going to build the moat.

Read more

That stopped being true about two years ago.

The moat the Architect Mode company produces is structurally different. It does not depreciate. It compounds. That is not a marketing claim. It is a mechanical property of how learning systems behave once they are wired correctly, and understanding the mechanics is the difference between CEOs who are actually building the new moat and CEOs who are funding twelve AI pilots and hoping one of them turns into a strategy.

The moat taxonomy had a half-life

Walk the history.

Coca-Cola’s brand moat took a century to build and is now policed by a marketing budget that would run a mid-sized country. It still works. It also has to be reinforced every quarter, because attention has fragmented into 400 channels and a brand that does not show up dies on a timeline measured in years, not decades. Brand depreciates with neglect. The rate has accelerated.

Walmart’s distribution moat was physical. Real estate, trucks, warehouses, a supply chain no competitor could match. Amazon did not out-Walmart Walmart. They built a different distribution model on top of the internet and routed around the whole thing. Distribution depreciates when the underlying channel shifts.

Oracle’s switching-cost moat was architectural. Once the database was installed, the business logic got written on top of it, and ripping it out meant rebuilding eight years of custom integrations. Postgres, Snowflake, and a decade of API-first tooling did not kill Oracle. They made switching tolerable enough that the moat stopped acting as one. Switching costs depreciate when the ecosystem around them standardizes.

Facebook’s network effect moat was the canonical one. More users means more value means more users. Unbreakable, until it turned out you could break it by building a network that targeted one use case, one demographic, one format, and pulled users off the mothership one thin slice at a time. Network effects depreciate when someone unbundles them.

Pharma’s patent moat expires on a legal calendar. Amazon’s scale-economy moat requires billions of dollars in capex to defend every year. Every moat in the taxonomy has a half-life, and that half-life has been shortening for two decades.

This is the part most CEOs agree with and then promptly forget. They build the next AI strategy on top of the same depreciating-moat logic they were raised on. Pick a category. Buy a tool. Lock in a vendor. Call it differentiation. That is Manager Mode with a better budget line. The moat erodes the moment somebody shows up with a marginally better tool, which in AI is about every nine weeks.

Why feedback loops are categorically different

A feedback-loop moat does not behave like the others. It does not require defense. It does not require reinforcement. It does not require capex to hold its ground. The mechanism is different in kind.

Every interaction trains the system. The system improves without human intervention. The moat widens with each transaction the company runs. The competitor landing in your market tomorrow faces the same learning curve you faced on day one, while your system has been compounding on that problem for eighteen months. That is not a metaphor. It is a property of how learning systems behave once they are connected to a data loop that actually closes.

The closing is the part most companies get wrong. A dashboard is not a feedback loop. A weekly review meeting is not a feedback loop. A churn model you rebuild quarterly is not a feedback loop. A feedback loop exists when the output of one cycle automatically becomes the input of the next without a human stopping to decide whether to carry the signal forward. When that loop is closed, the system compounds. When the loop is open, the system does not learn. It just produces more reports.

I could be wrong about how long the first-mover window lasts. I am not wrong about the mechanics. The curve is always the same shape. Flat for a while. Then inflection. Then a gap between you and everyone else that widens instead of closes.

What the loop looks like in three industries

These are not case studies. They are the same mechanism wearing three different costumes, so you can recognize it in your own business.

Picture a GovTech firm that stops treating regulatory rejections as bad news and starts treating them as training data. Every rejection, the specific language that failed, the exact clause that triggered pushback, the reviewer who rejected the submission and on what grounds, all of it feeds back into a model. Not into a spreadsheet. Not into a shared drive anyone might read. Into a system that processes every rejection and adjusts the next submission automatically. Eighteen months in, approval rates climb and cycle times compress. The system holds things about that specific regulatory environment that no single human could carry in their head. A competitor landing next quarter meets the bureaucracy this firm met a year and a half ago. The gap does not shrink. It widens every week a new rejection comes in and gets absorbed.

Take a customer support team that stops writing macros and builds a response intelligence system. Every ticket, every resolution, every satisfaction score, every escalation pattern feeds back. Ticket volume rises. The hiring curve stays flat. CSAT improves on a trend line headcount no longer explains. The institutional knowledge that used to live in the heads of the three best agents, the ones who might quit on a Tuesday and take eight years of customer context with them, now lives in the system. Churn among the senior staff stops being an existential risk. That is a structural change, not a morale initiative.

Or a marketing agency that feeds every campaign, every brief, every performance result into a central creative model. The result is not what you would expect. The senior strategists do not get displaced. The juniors get elevated. Junior account managers produce work that used to require a senior strategist to even draft, because the system does the pattern-matching the senior used to do in their head. The gap is not because the juniors got smarter. It is because they are standing on a system that got smarter, and the senior strategists now spend their time on the problems the system cannot touch yet. The agency’s win rate on new business climbs. Its cost to produce a pitch drops by half. Its competitors, still running the old senior-juniors-and-a-brief model, are pitching against a system instead of a team.

Three different industries. Three different workflows. Same mechanical property. Every interaction trains the system. The system improves without human intervention. The moat widens.

That is the diagnosis. The number that proves it, the four things that quietly kill it, the confession of the worst report my own team ever shipped, and the five-question test you can run at your desk this week are the rest of this piece.

Read more

Not 106 features. Not 106 integrations. 106 separate tools, each with its own data model, its own vendor, its own update cycle, and its own team of people who decided to adopt it without asking the person three desks over if it would play nicely with what they already had.

Now here’s where it gets uncomfortable. In a stack that size, the number of possible integration points doesn’t grow linearly. It grows quadratically. Add one tool and you don’t add one unit of complexity -- you add 106 potential new interconnections. Your management infrastructure is still linear. Your calendar still has 24 hours in it. Your RevOps team still has a headcount it can fill.

That gap -- between quadratic complexity and linear management -- is where GTM systems break. Not at the tool level. At the interaction layer between them.

And AI is not closing that gap. In most companies, it’s widening it.

GTM Is Not a People-and-Process Problem Anymore

I’ve spent 21 years building GTM systems at companies across health tech, real estate, clean energy, education, logistics. At every stage of that career, the dominant assumption was the same: if you hire the right people, define the right process, and hold people accountable to the right metrics, revenue follows.

That assumption worked -- until it didn’t.

Go-to-market today requires real-time signal detection across hundreds of accounts simultaneously. It requires dynamic lead scoring that adapts to behavioral patterns in hours, not quarters. It requires cross-functional handoffs that happen in hours, not weeks. It requires customer health models that synthesize product usage, support tickets, NPS scores, and billing data into one score, routed to the right person at the right moment.

No team of humans can run that by hand. Not because they aren’t talented -- because the problem has outgrown the operating model.

GTM is a system. Not a collection of people with aligned OKRs. Not a set of functions with shared reporting. A system -- with inputs, processes, feedback loops, and compounding outputs. And the companies treating it like a people-and-process operation are going to fall behind companies that treat it like an engineering problem. Not eventually. Already.

The harder part: most companies don’t have a system. They have a collection of functions that happen to share a CRM.

What AI Is Actually Doing to This Problem

Here’s where the complexity problem gets a second layer. While RevOps teams are consolidating tooling and trying to get governance in place, another department just adopted eight new AI tools without telling anyone. Marketing is running three different AI content workflows. Sales is using AI for prospecting, for call summarization, for follow-up sequencing. CS adopted something for churn prediction. Product has its own data pipeline.

None of it connects. No one reviewed it. No one has visibility into the interaction layer between any of it.

Agent sprawl is the new SaaS tool sprawl, at 10x the speed. A 200-person company with 3 employees each building two AI agents is suddenly running 600 disconnected systems. No procurement. No governance. No one who owns how the outputs from one agent become the inputs to another.

This is not a hypothetical scenario. It’s what’s happening inside GTM organizations right now.

And here is the thing about AI that everyone needs to understand before they deploy another one of these tools: AI is a multiplier, not a corrector. It amplifies whatever it touches. Clean processes plus AI delivers dramatically faster, dramatically more effective output. Broken processes plus AI delivers dramatically worse output, at scale.

An AI layer dropped onto a broken foundation produces outputs that look authoritative and say nothing accurate. The AI isn’t malfunctioning -- it’s doing exactly what it was designed to do: synthesizing the inputs it receives. When those inputs are garbage, the outputs are confident garbage.

Jacco van der Kooij at Winning by Design put it precisely: “A wrong answer you can catch. A hallucinated strategy looks right.”

That’s the failure mode no one is talking about clearly enough. A wrong forecast gets caught in the next pipeline review. A hallucinated growth strategy -- one that looks rigorous, cites internal data, passes the sniff test of a board presentation -- runs for quarters before anyone traces the problem to its source.

The Right Sequence (Most Companies Are Doing It Backward)

There is a right order for deploying AI in GTM. Four stages have to be in place for AI to deliver its best work:

Data -- Process -- System -- Application

Most companies start at Application. There’s a compelling demo. There’s a visible ROI story. The vendor makes it look easy. So they skip to the end and patch backward when it fails.

Here’s what patching backward costs you: a disconnected system cannot learn. Every AI initiative that lives on disconnected data stays local. It doesn’t compound. The learning from this quarter’s outbound motion doesn’t feed into next quarter’s customer success motion. The signal that close-won deals generate doesn’t improve the prospecting model upstream.

You end up with AI-assisted points of productivity -- individual efficiency gains scattered across the org -- instead of a system that gets smarter with every interaction.

Playing the long game means building in the right order. Not perfectly -- you don’t perfect each stage before connecting to the next. But you do get each stage functional enough that the system can start teaching you what to improve. The sequence is the discipline.

The Five-Layer Stack You Probably Don’t Have

Read more

The Bifurcation

RevOps has moved through three distinct eras.

From roughly 2015 to 2021, it was a service desk. CRM administration, report building, process documentation. Reactive by design. The function existed to support Sales and Marketing, not to operate alongside them. From 2021 to 2024, it became a strategic partner -- cross-functional by default, increasingly involved in tech stack decisions, revenue planning, and go-to-market design. That era produced a generation of RevOps leaders who genuinely understood the business, not just the tools.

Now it is becoming something else. The Growth Architect era. And the shift is not gradual.

AI is eliminating the service desk work. Reporting, hygiene, documentation, ticket management -- these are exactly the tasks AI handles well and handles fast. The middle of the RevOps function, where most of its headcount currently lives, is also where AI is most efficient. There is no safe version of the old job. The only path forward is the one that moves up the value chain fast enough to stay ahead of what AI absorbs below it.

There is no middle path. The middle is exactly what AI eliminates best.

The New Executive Seat

Every major platform shift creates a genuinely new executive role. Not an upgraded version of the previous one -- something new, with new scope, new authority, and new compensation to match.

The CTO emerged when technology became a competitive differentiator and needed someone who spoke both engineering and business at the executive table. The CMO emerged when marketing became too complex and too expensive to leave in the hands of a VP reporting to a generalist. The CRO emerged when go-to-market became multi-motion, multi-segment, and multi-year -- too complex for sales leadership alone. Each time, a function that had been operational became strategic. The market created a seat to reflect that.

The VP of Growth is that seat right now.

The data makes it concrete. LinkedIn showed approximately 6,000 open VP of Growth and VP of Revenue Operations roles in April 2026. Base compensation runs $250,000-$350,000, with total comp packages reaching $550,000. VP of RevOps titles grew 300% in 18 months. The GTM Engineer talent pool expanded 45% in three months. These are not coincidences. They are a market discovering, in real time, that a function it has been undervaluing has become structurally necessary at the executive level.

The Chief Customer Officer was supposed to solve this. It didn’t. The CCO unified reporting lines but not systems. Functional leaders reported up to the same person without changing how the underlying architecture worked. Handoffs still broke. Data still fragmented. The org chart changed; the system didn’t. The VP of Growth does what the CCO was supposed to do, but with actual system authority rather than organizational proximity.

A new executive has entered the room. The question is whether your company is putting someone in that seat or leaving it empty.

What It Owns and What It Doesn’t

Read more

Every CEO has an AI strategy. Almost none of them have answered the question of who actually owns the system it creates. Not who picks the vendor. Not who runs the pilot. Who owns the architecture: the data, the workflows, the agent layer, the feedback loops that increasingly determine whether your go-to-market actually works. AI will either absorb Revenue Operations (RevOps), automating away reporting, process documentation, and tool administration, or elevate it to the chief architect of the entire go-to-market system. There is no middle path.

The work RevOps does today is the work AI is best at eliminating.

The only version of the role that survives is one that fundamentally transforms. That transformation -- and the ownership question it creates -- is what this piece is about.

RevOps didn’t start as a strategic function. It started as CRM administration. Someone had to keep Salesforce from catching fire, so a team formed around data hygiene, report building, and making sure the dashboards said something useful before the Monday meeting. Then go-to-market got more complex. Marketing automation, multi-touch attribution, product-led growth signals, expansion revenue models, customer health scoring. Each layer of complexity created a new process that needed an owner, and RevOps absorbed it. The CRM administrator became the process owner. The process owner became the system owner. The scope kept expanding as the go-to-market model became harder to operate. This is the pattern, not the exception. RevOps grows because go-to-market complexity grows. AI is the largest complexity jump yet. Which means RevOps is either about to have its biggest expansion, or its last.

The System No Longer Runs on People

Most executive teams have not fully internalized what their go-to-market has become. It is no longer a people-and-process operation. It is a system. And it is becoming a system that humans can no longer operate by hand. A modern go-to-market motion requires real-time signal detection across hundreds of accounts. Dynamic lead scoring that adapts to behavioral patterns. Automated workflow routing based on segment, intent, lifecycle stage, and deal velocity. Cross-functional handoffs that need to happen in hours, not days. Customer health models that synthesize product usage, support tickets, NPS data, and billing patterns into a single score that triggers the right action at the right time.

The problem is not the number of tools. It is the number of potential connections between them. The average company runs 106 SaaS applications as of 2024. In a stack that size, the number of possible pairwise integration points grows quadratically. Add one tool, and you do not add one unit of complexity. You add 106 potential interconnections. The management infrastructure most companies have built is linear. That gap is where go-to-market systems break. Not just at the tool level. At the interaction layer between them.

With the advent of AI, most executives believe they are on a path to consolidation. What we experience in practice suggests otherwise. Two things are happening simultaneously in most companies. RevOps is using AI to consolidate in one department, while another department adopts eight new AI tools without telling anyone. The result is complexity that quietly grows at the interaction layer as AI tools are added outside any governance structure. No single team has visibility. No dashboard tracks the whole. That is the gap where RevOps lives. Not in the tools. In the system that governs their interactions.

No human team, regardless of talent, can manage that interaction layer manually and keep pace with it. Most signals get missed. Most handoffs happen late. Most health scores trigger action after the moment has passed. AI is not enabling this transition. It is forcing it. The companies adopting AI-driven go-to-market motions are setting a pace that manually operated teams cannot match. This is not a theoretical future state. It is a competitive reality already playing out in pipeline generation, deal velocity, and retention economics. Someone has to architect and orchestrate this system. Someone has to be the translation layer between business objectives and machine execution. The question is who.

AI Does Not Fix What Is Broken. It Scales It.

Read more

That’s the thing most CEOs miss when they first encounter Architect Mode. They hear “the AI handles the synthesis” and they think: less for me to do. But the analysis, the dashboards, the approval chains, the cross-functional status updates -- none of that was the real work. It was the cost of a broken information architecture. You were the synthesis layer because the org had no other way to pull signal from noise at scale. Take the broken architecture away, and what remains is sharper and harder, not easier.

This piece is about what remains.

In Pillar 1, I laid out why Architect Mode is the current operating era -- not a future state, not a strategic option, but the terrain companies are competing on right now. If you’ve accepted that frame, the natural next question is: so what does the CEO actually do? Specifically. Monday morning.

Three things. Only three. They’re not new concepts, but in Architect Mode they carry a different weight because everything else has been stripped away.

I call them Aim, Army, and Assets.

Aim: Where We’re Going

AI can map markets, model competitive scenarios, surface second-order effects, and run strategy stress-tests faster than any human team you could assemble. I mean that without qualification. The analytical firepower available to a CEO who knows how to deploy it is genuinely without precedent. You should be using it aggressively.

But strategy is not the same as vision. And vision is not just where the market is going.

Vision is where you are willing to go.

Here’s the distinction that matters: AI can tell you what is rational. It cannot tell you what is meaningful. Given any strategy question, a well-prompted model will give you a defensible answer, usually several of them. It will map the adjacencies, size the opportunity, flag the risks, and rank the options by expected return. What it will not do -- and this is the permanent gap -- is tell you which hill is worth bleeding for.

That’s yours. It will always be yours.

As intelligence becomes more abundant, conviction becomes more scarce. When every company has access to the same analytical layer, the ones that win will be the ones where someone at the top made a clear call about what mattered and held to it long enough for the system to compound. The CEO still sets the meaning. The CEO decides the hill. And in Architect Mode, that judgment doesn’t reduce. It sharpens -- because now you have better information going into the decision and less excuse for sitting in strategic ambiguity.

The most dangerous CEO pattern I see right now is what I’d call “strategy by committee plus AI.” The team gathers the data, the model synthesizes it, someone builds a slide, and the CEO nods along because the analysis looks rigorous. But rigorous analysis of a mediocre thesis is just a well-dressed mediocre thesis. The machine can sharpen the thinking. It cannot supply the conviction.

If you are uncertain about the direction, say so and use the tools to sharpen the thesis. That’s legitimate. If you are unclear about the direction -- unwilling to make the call -- that is an execution failure that no amount of AI synthesis will fix.

Army: Who We’re Going With

The talent calculus has changed in a way most hiring processes haven’t caught up with yet.

The traditional assumption was additive: more headcount equals more capacity. You needed a team of twelve to run a function because twelve humans could produce more output than six. That math held in Manager Mode. It held less cleanly in Founder Mode. In Architect Mode, it breaks down entirely.

One high-agency operator with genuine AI fluency -- someone who knows how to build systems, prompt well, automate their own process, and feed signal back into the machine -- can now outperform teams built around average performers. I’ve seen it at multiple companies: the output-per-person gap between your best system-thinker and your average contributor has widened from a factor of 2x to somewhere closer to 10x, and that gap is still expanding.

This means you are not just hiring for skill anymore. You are hiring for the multiplier.

The new talent mandate breaks into four hard shifts:

Find missionaries, not mercenaries. In a world where anyone can generate competent work with a good prompt, the differentiator is belief. Missionaries don’t need to be managed into caring. They’re already running diagnostics on the system because they want the thing to win. Mercenaries produce adequate output and wait for the next directive. In Architect Mode, mercenaries become expensive drag before you notice them.

Test for taste and agency, not credentials. Give candidates a real problem and a set of tools. See what they build. See how they think about the system, not just the output. The credentials tell you what they’ve done in the past in someone else’s architecture. The test tells you what they’ll do in yours.

Remove drift fast. Standards decay quickly when the bar is unclear. This is not about being ruthless -- it’s about being honest. Every person who is trending away from system-architect capability and staying in place is a signal to the rest of the org about what you actually tolerate. The best thing you can do for culture is be precise about what good looks like and move on problems early.

Reward the ones who already get it. Not just with compensation -- with scope. The people in your org who are actively building systems, compounding institutional knowledge, and feeding signal back into the machine are your moat builders. Give them more surface area.

The honest CEO decision that follows all of this: assess your current leadership team with clear eyes. Some of them are trending toward system-architect capability. Some of them are not. That’s a real conversation, and it’s not a comfortable one. It is, however, a necessary one. The people who made you successful in Era 1 or Era 2 are not automatically the right people for Era 3. That’s not a judgment on them. It’s a judgment on fit.

Middle management, specifically, deserves its own note here. In Architect Mode, the middle manager’s job changes completely. They are no longer information routers -- that function is gone, and if they’re still doing it, you have an architecture problem. The middle manager in Architect Mode is a micro-architect. Their job is to take everything happening at the frontline -- every customer signal, every friction point, every pattern -- and feed it back into the system so the whole organization gets smarter. The best ones are actively compounding the moat. The worst ones are quietly starving it. The question isn’t whether they’re a good manager in the old sense. It’s whether they’re feeding the machine or blocking it.

Assets: What We Deploy

Capital. Attention. Focus. Brand. Trust. How you bet them is the third non-delegable function.

The scarce resource in Architect Mode is not information. AI gives every company more data, more dashboards, more options, more machine-generated strategy documents than they can possibly act on. Most companies will drown in possibility. They will run 12 pilots simultaneously and get signal from none of them. They will spread the best people across eight initiatives and get leverage from zero. They will confuse motion with direction.

The CEO’s job -- the part that cannot be automated, no matter how good the tools get -- is to decide with conviction: what are we actually doing, and what are we not doing?

That second question is the harder one. Saying no to a plausible opportunity is more cognitively difficult than saying yes to it. The analysis will always make three options look reasonable. Four options will have credible champions. Your job is not to validate the analysis. Your job is to select the handful of asymmetric bets that deserve your best people and your best years, and to be clear enough about that selection that the org doesn’t have to guess.

This is where capital allocation gets redesigned in Architect Mode. Before Architect Mode: you reviewed an annual budget. A large team gathered information from across functions. Resource allocation decisions came from point estimates and gut feel, compressed through management layers. You were the chief approver.

In Architect Mode: you design a live system that continuously updates priorities. You get fast synthesis from the intelligence layer and spend your time on judgment, not gathering. Capital allocation means selecting the handful of bets worth amplifying and actively de-investing from the rest. You are the chief architect of the portfolio, not the chief approver of the line items.

The best CEOs in Architect Mode are allowed to be uncertain. They are not allowed to be unclear.

Uncertain means: I have a hypothesis, I’ve placed the bet, I’m watching the signal, and I’ll update when the data says to. Unclear means: I’m not sure which of these five things we’re actually prioritizing. Uncertainty is honest and functional. Unclear is a cultural tax that every team member pays every day in misaligned effort.

The Identity Shift (The Hard Part)

Read more

Check out our AI Education section, and this is where things get real. Step-by-step guides, how-to breakdowns, and hands-on training to help you build agents, build systems, and use tools like Claude Code, ChatGPT, and Perplexity at a level most people don’t even know exists. This isn’t surface-level stuff -- it’s the training that actually moves your AI capabilities forward.

Paid subscribers get access to interactive tools and guides that free subscribers don’t see.

Office hours and live events where you can bring your real questions, get them answered by people who’ve actually built this stuff, and get hands-on keyboard time with experts in the room.

Come build with us.

———————————————————————————————————————————-

Most CEOs I talk to believe they’re running a modern company. They’ve got AI tools rolling out across the org. They’ve flattened the hierarchy. They move faster than they did three years ago. And they’re right -- they probably are running a more modern company than they were in 2020.

The problem is the bar moved again.

What “modern” looked like in 2020 is not what modern looks like now. And the companies that are treating this moment like an incremental upgrade rather than an era shift are going to find out the hard way. Not five years from now. Already.

This is the argument I want to make in this piece -- and across the four pieces that follow it. There have been three distinct eras of business leadership in the last four decades. Each era had a dominant logic, a dominant bottleneck, and a dominant moat. Two of those eras are closed. The third one is where business is won or lost right now. And most companies are still operating in Era 1 or Era 2 -- convinced they’ve arrived when they’ve barely departed.

Let me walk through all three.

Era 1: Manager Mode

Manager Mode was the dominant logic of 20th-century business. It was built for one purpose: scale through hierarchy.

The structure was a pyramid. Information traveled upward through relay nodes. A customer insight started at the individual contributor level, got compressed by a team lead, reframed by a manager, summarized by a director, and reached the CEO as a filtered version of the original signal. Four hops. Signal decayed at every relay node before it reached the top. By the time the CEO saw it, it was a sanitized PowerPoint slide with three key takeaways.

This wasn’t a failure of leadership. It was a rational system design for a world where coordination required human intermediaries at every layer. You couldn’t transmit raw customer data across an org in real time. So you built relay nodes. And the relay nodes became departments. And the departments became empires. And the CEO’s value came from organizing the machine -- from figuring out which levers to pull across a system that was too complex to see whole.

The moat in Manager Mode was contracts and switching costs. You locked customers in with long-term agreements, proprietary integrations, and the sheer friction of change. Headcount was a sign of strength. A 5,000-person company felt more defensible than a 500-person company, because the size itself was a moat.

It worked. For decades. And it produced enormous companies.

But it has a fatal flaw. Every relay node compresses signal. Every compression layer adds latency. And in a market where the feedback loop between customer behavior and business response needs to run in hours, not quarters, Manager Mode’s architecture becomes its liability.

Era 2: Founder Mode

In August 2024, Paul Graham wrote an essay called “Founder Mode.” It spread through the startup and executive world faster than anything I’d seen in years.

The argument was simple: most management advice is built for professional managers, not founders. And founders who follow that advice -- who delegate, who hire professional managers, who “step back” -- often watch their companies lose the thing that made them worth building. Graham gave founders permission to stay close, go deep, break the rules. Flatter orgs. Faster decisions. More founder instinct. Closer to the end customer. Skip the relay nodes and see the signal yourself.

It resonated because it was true. The best founders ARE obsessed. They DO know things their org chart doesn’t. The six-layer management hierarchy DOES compress signal into uselessness. And the conventional wisdom about “hiring people smarter than you and getting out of the way” has killed more high-potential companies than it’s saved.

Founder Mode was a necessary correction. If you were drowning in bureaucracy, it gave you permission to break the glass and breathe again.

But Founder Mode has a ceiling. And the ceiling arrives faster than founders expect.

Founder Mode scales to about 30 people and then breaks. The bottleneck shifts. It’s not bureaucracy anymore. It’s the founder. Every decision flows through one person. Every creative call requires one brain. Every strategic judgment waits in one queue. The founder’s calendar becomes the constraint on the entire organization’s velocity. And the founder -- no matter how brilliant -- has 24 hours in a day, processing capacity that plateaus under cognitive load, and attention that degrades under scope.

The moat in Founder Mode is the founder’s taste, network, and speed. Which means the moat retires when the founder does. Or burns out. Or gets distracted. The company’s competitive advantage is entirely load-bearing on one human being.

This is why so many companies hit a ceiling between 30 and 150 employees that looks like a product problem or a market problem but is actually a leadership architecture problem. Founder Mode is a brilliant early-stage operating mode. It is a catastrophic late-stage one.

Era 3: Architect Mode

This is where we are now. And most companies haven’t arrived yet.

Architect Mode keeps the speed and conviction of Founder Mode. It keeps the founder’s closeness to the customer, the flatness, the intolerance for bureaucracy, the bias for action. But it adds something Manager Mode never had and Founder Mode can’t: AI leverage at the center of the operating system.

Here’s how it works in practice.

In Manager Mode, the intelligence lived in relay nodes -- in the heads of middle managers who synthesized information and passed it up the chain. In Founder Mode, the intelligence concentrated in the founder’s head. In Architect Mode, the intelligence lives in a system that sits at the center of the organization. Every functional unit connects to it directly. Signal from a customer churn event, a rejected contract submission, a failed sales call, a support ticket resolved -- all of it flows directly into the center and reflects back to whoever needs to act on it. No relay nodes. No compression. No decay.

And here’s what changes everything: every signal that enters the system makes it smarter for the next one.

This is not “let AI run the company.” That framing is almost always wrong when I hear it, and I hear it often. Architect Mode is not abdication. It is the discipline to work ON the system rather than IN it -- to combine human meaning, human taste, and human accountability with machine-assisted analysis, machine-assisted execution, and machine-assisted scale.

The CEO’s job in Architect Mode compresses to three things. I call them Aim, Army, and Assets.

Aim -- where we’re going. AI can map markets, model scenarios, surface patterns across competitive landscapes. But the human decides which hill is worth bleeding for. That judgment doesn’t reduce. It sharpens.

Army -- who we’re going with. AI can surface performance data, flag drift early, model org design. But the human transmits belief, creates psychological safety, and removes the dysfunction that data alone can’t diagnose. Culture doesn’t compress to a model. Leadership does.

Assets -- what we deploy. AI can stress-test capital allocation, model ROI across investment scenarios, flag opportunity costs in real time. But the human decides what deserves their best people and their best years. Strategy is not an optimization problem. It’s a values problem that benefits from better information.

Everything else -- the analysis, the synthesis, the execution, the monitoring -- that’s where the system runs.

The Framework: Three Eras, Ten Dimensions

Read more

Before we dive in -- thank you to our paid subscribers! Make sure to take full advantage of all the value you get.

Check out our AI Education section, and this is where things get real. Step-by-step guides, how-to breakdowns, and hands-on training to help you build agents, build systems, and use tools like Claude Code, ChatGPT, and Perplexity at a level most people don’t even know exists. This isn’t surface-level stuff -- it’s the training that actually moves your AI capabilities forward.

Paid subscribers get access to interactive tools and guides that free subscribers don’t see.

Office hours and live events where you can bring your real questions, get them answered by people who’ve actually built this stuff, and get hands-on keyboard time with experts in the room.

Come build with us.

Most CEOs I talk to are running a 2022 company with a 2026 tool stack and calling it transformation. The AI line in the budget doubled. A ChatGPT subscription went out to the whole team. Copilot landed in the sales org last quarter. The board deck has a slide titled “AI-native.” And the underlying system that actually produces revenue is unchanged from three years ago.

That gap is not a technology gap. It is an architecture gap. And the growth-rate spread between companies that have closed it and companies that have not is already visible in the pipeline numbers, in retention, in the hiring curve. Not a projection for 2028. Current reality.

Five shifts explain the gap. Each one compounds into the next.

1. The era has changed. Three logics of running a company, three moats, only one that compounds automatically.

2. The CEO’s job got clarified, not simplified. Aim, Army, Assets. Everything else is an architecture problem.

3. The revenue system most companies run is hollow. 106 SaaS apps, quadratic complexity, a five-layer stack that was never built.

4. The system is an orphan. Everyone owns a piece, no one owns the whole.

5. A new executive seat is emerging to own it. Reports to the CEO. Different scope, different comp, different hire.

Shift 1. The Era Has Changed

Three logics have governed how companies get built in the last forty years. Two of them are closed. One is where business is won right now.

Manager Mode was the dominant logic of the 20th century. Information climbed a pyramid. A customer insight got caught by a rep, filtered by a team lead, reframed by a director, and arrived at the CEO as a sanitized slide with three bullets. Four relay nodes, four rounds of compression. The moat was contracts, switching costs, and org chart depth. It worked for decades. It built enormous companies. Its fatal flaw is latency. Every relay compresses signal. Every compression adds delay. When the feedback loop between customer behavior and company response has to run in hours, not quarters, Manager Mode’s architecture becomes its liability.

Founder Mode was a correction. Paul Graham named it in 2024 and it landed because it was true. The best founders are obsessed. They know things the org chart does not. The six-layer management hierarchy does compress signal into uselessness. Founder Mode was permission to break the glass and breathe. But it has a hard ceiling. It scales to roughly thirty people and then the bottleneck stops being bureaucracy and starts being the founder’s calendar. Every decision runs through one person. Every creative call requires one brain. The moat is the founder’s taste, network, and velocity, which means the moat retires when the founder does.

Architect Mode is where we are now. It keeps the speed and conviction of Founder Mode. It keeps the closeness to the customer. And it adds the piece neither prior era had: an AI-native system at the center of the operating model. In Manager Mode, intelligence lived in the relay nodes. In Founder Mode, it concentrated in the founder’s head. In Architect Mode, intelligence lives in a system that sits at the center, and every function connects to it directly. A churn event, a rejected submission, a support ticket, a closed deal, signal flows into the center and reflects back to whoever needs to act on it.

Every interaction makes the system smarter.

The moat column is where this gets real. Manager Mode’s moat erodes the moment something meaningfully better shows up. That used to take decades. It now takes months. Founder Mode’s moat is non-transferable and leaves with the founder. Architect Mode’s moat is different in kind: a proprietary feedback loop that compounds automatically. The competitor landing in your market tomorrow faces the learning curve you faced on day one while your system has been compounding for eighteen months.

Three examples of what that looks like right now, none of them demo slides.

A GovTech firm stopped treating regulatory rejections as bad news and started treating them as training data. Every rejection, the specific language that failed, the clause that triggered pushback, the reviewer who rejected and on what grounds, fed back into a model. Eighteen months in, approval rates climbing, cycle times compressed. The system now holds things about that regulatory environment no individual could hold in their head. A competitor walking in next quarter meets the bureaucracy this firm met eighteen months ago. This firm’s system has been compounding on that exact problem the whole time.

A customer support team stopped writing macros and built a response intelligence system. Every ticket, every resolution, every satisfaction score fed back. Volume is up, hiring curve is flat, CSAT is improving. The institutional knowledge that used to live in the heads of people who might quit on a Tuesday now lives in the system.

A marketing agency fed every campaign, every brief, every performance result into a central creative model. Junior account managers are producing work that used to require a senior strategist. The gap is not because the juniors got smarter. It is because the system got smarter and they are standing on it.

Most companies are tourists. They visit AI. They take the photos. They use a tool, learn something, share it at the next offsite. Tourists have a great time. They learn things. They come home with stories. But they go home. They do not build a life there. They do not put down the roots the compounding requires. The tourist trip is fun. The efficiency gains are real. The budget line looks good on the board slide. The transformation is not happening.

“Are we using AI?” is the wrong question. The right question is harder. Is your AI smarter today than it was yesterday, and does that gap widen automatically without your involvement? If not, you are in Founder Mode with a better toolkit. You are not in Architect Mode.

Shift 2. The CEO’s Job Got Clarified, Not Simplified

The most common mistake a CEO makes on entering Architect Mode is assuming it makes the job easier. It does not. It makes the job sharper and more uncomfortable, because the cover stories for what was broken go away.

The dashboards, the approval chains, the cross-functional status updates, the personal synthesis between a board meeting and a Tuesday ELT, none of that was the real work. It was the cost of a broken information architecture. The CEO was the synthesis layer because the org had no other way to pull signal from noise. Take the broken architecture away and what remains is three things.

I call them Aim, Army, and Assets.

Aim. Where are we going. AI maps markets, models scenarios, surfaces second-order effects, and runs strategy stress-tests faster than any internal team. Use it aggressively. Strategy is not the same as vision. A well-prompted model will give you a defensible answer to any strategic question, usually several of them. It will size the opportunity, rank the options, and flag the risks. What it will not do, and this is the permanent gap, is tell you which hill is worth bleeding for. That is yours. It will always be yours. As intelligence becomes more abundant, conviction becomes more scarce.

Army. Who are we going with. The talent calculus shifted in a way most hiring processes have not caught up with. One high-agency operator with genuine AI fluency, someone who builds systems, prompts well, automates their own process, and feeds signal back into the machine, now outperforms teams built around average performers. The output gap between your best system-thinker and your average contributor widened from 2x to something closer to 10x, and it is still widening. The honest CEO conversation that follows is not a comfortable one. Assess your current leadership team with clear eyes. Some of them are trending toward system-architect capability. Some are not. The people who got you here in Era 1 or Era 2 are not automatically the right people for Era 3. That is not a judgment on them. It is a judgment on fit.

Assets. What do we deploy. Capital, attention, focus, brand, trust. The scarce resource in Architect Mode is not information. AI gives every company more dashboards, more data, more machine-generated strategy documents than any team can act on. Most companies will drown in possibility. They will run twelve pilots simultaneously and get signal from none. They will spread the best people across eight initiatives and get compounding from none. The CEO’s job, the part that does not automate no matter how good the tools get, is to decide with conviction: what are we doing, and what are we not doing? The second question is the harder one. Saying no to a plausible opportunity is more cognitively difficult than saying yes to it. The analysis will always make three options look reasonable. Four will have credible champions. Your job is not to validate the analysis. Your job is to pick the asymmetric bets that deserve your best people and your best years, and be clear enough about the pick that the org does not have to guess.

The best CEOs in Architect Mode are allowed to be uncertain. They are not allowed to be unclear. Uncertain means: I have a hypothesis, I placed the bet, I am watching the signal, I will update when the data says to. Unclear means: I am not sure which of these five things we are actually prioritizing. Uncertainty is honest. Unclear is a cultural tax every team member pays every day in misaligned effort.

Aim, Army, Assets sounds clean on the whiteboard. The application of it requires something leadership training does not talk about enough: an identity shift. In Founder Mode, your value came from your involvement. You knew the answers because you were closest to the problem. Your fingerprints were on everything. Architect Mode asks for a different discipline. Build the thing that runs without your constant involvement while staying deeply accountable for what it produces. You optimize for system quality over personal heroics. That takes real work to sit with.

The question I would leave here is not “am I in Architect Mode?” Most CEOs will say yes and mean something closer to “I think about AI a lot.” The real question: if you were removed from your company for sixty days, which decisions would be better because your system kept learning, and which would be worse because the system does not exist yet? The length of the second list is the honest measure of how far you have to go.

Shift 3. The System Most Companies Don’t Have

Read more

Go count the SaaS tools your GTM team pays for. Not the ones in the deck. The ones actually running. The ones someone signed up for eighteen months ago that still bill the credit card even though the champion left. Now count how many of them share data without someone manually exporting a CSV.

That gap between “tools we pay for” and “tools that actually talk to each other” is the most expensive line item nobody tracks.

The Garage Problem

Every GTM team I have worked with over the past 21 years has the same issue. It looks different at every company, but the shape is identical.

It starts with a problem. Pipeline visibility is bad. Someone buys a tool. Content production is slow. Someone buys a tool. Competitive intel is stale. Someone buys a tool. Customer health scores are unreliable. Someone buys a tool.

Each purchase made sense at the time. Each vendor demo was convincing. Each implementation had a champion who cared. And now you have 14 tools across marketing, sales, CS, and RevOps that were never designed to work together, connected by integrations that break quarterly, managed by people who spend half their time maintaining the plumbing instead of doing the work the tools were supposed to make easier.

This is not a technology problem. It is an architecture problem. And the entire GTM industry has been pretending it is normal.

I can say this with confidence because I was one of the people pretending. I signed the contracts. I championed the tools. I sat in the QBRs and told my team the new platform would fix the data problem. Three of those tools are still billing my old company’s credit card right now, and I am not sure anyone knows the login.

The Market Map Illusion

You have seen the market maps. The ones with 150 logos arranged in neat categories. CRM. Marketing Automation. Sales Engagement. Revenue Intelligence. Conversational Intelligence. Customer Success Platform. ABM. Content. SEO. Competitive Intel.

They look organized on a slide. They feel chaotic in practice.

Here is what actually happens when you run a GTM operation across those categories:

Data lives in silos. Your CRM knows about deals. Your marketing automation knows about engagement. Your CS platform knows about health scores. Your content tools know about performance. None of them know about each other. The competitive intelligence your analyst gathered last Tuesday lives in a Google Doc that three people have read.

Integrations are duct tape. Zapier, native connectors, custom API work. They move data from point A to point B, but they do not carry context. A lead score in your MAP tells your CRM a number. It does not tell your sales team why that number is high, what content the prospect engaged with, or what competitive alternative they were evaluating.

Signal loss is the default. Every handoff between tools loses information. Marketing qualified a lead and passed it to sales. What was the qualification signal? It is in the MAP, but the AE is in the CRM. The customer told your CSM something important on a call. It is in the conversational intelligence tool. Your product team will never see it.

Nobody owns the whole picture. Each tool has an admin. Nobody administrates the system. Because there is no system. There is a collection of tools.

What This Actually Costs

The direct costs are obvious. License fees stack. A mid-market GTM team easily spends $200K-$400K annually on SaaS subscriptions across these categories. Enterprise teams spend millions.

But the indirect costs are worse:

Time tax. Your ops team spends 30-50% of their time on integration maintenance, data hygiene, and tool administration. That is your most strategic team doing janitorial work.

Decision latency. When a signal has to travel through three tools and two manual handoffs before it reaches the person who can act on it, you are making decisions on stale information. Every time.

Context collapse. The thing that makes your business distinctive -- your market knowledge, your customer relationships, your competitive position -- gets flattened into whatever fields the tool allows. Your institutional intelligence lives in people’s heads instead of in the system.

Training drag. Every new hire learns 8-12 tools. Every tool update resets muscle memory. Every tool switch requires migration. The switching costs are so high that teams stay on bad tools because moving is worse than suffering.

The Question Nobody Asks

Here is what I kept asking myself across two decades of GTM work: why do we accept this?

Why do we accept that marketing, sales, and CS should operate in different software environments? Why do we accept that “integration” means a fragile API connector instead of shared context? Why do we accept that every department has its own version of the truth?

The answer is that we did not have an alternative. The SaaS model was the best we had. Best-of-breed tools in each category, connected by integrations, managed by ops teams. That was the architecture. It was the only architecture available.

It is not the only architecture available anymore.

What is behind the paywall: The five-step Tech Stack Audit framework I use to diagnose exactly where signal dies in a GTM stack, the thesis that ties this entire series together, and a paid subscriber resource -- a complete Tech Stack Audit Interactive Guide you can run with your ops team this week.

The diagnosis above is free. The prescription is for subscribers.

Read more

“We’re not even using AI that well yet,” he told me. “But the board read the Block announcement and now everyone’s counting heads.”

This is the moment we’re in. And I want to be honest with you about how strange and how consequential it is.

The Block Signal and What It Actually Means

Jack Dorsey didn’t dress it up. When Block cut from 10,000 to fewer than 6,000 employees this month, he said: “This is not driven by financial difficulty, but by the growing capability of AI tools to perform a wider range of tasks.”

Read that again. He’s not saying AI replaced those roles. He’s saying he believes it will.

Oracle followed the same week: 20,000–30,000 cuts to free up $8–10 billion for AI infrastructure investment.

And here’s the data that makes this stranger: 45,000 tech layoffs in March 2026. 20% explicitly attributed to AI — up from less than 8% last year. But at the same time:

• Only 14% of organizations have AI solutions ready to deploy

• Only 11% are actively running AI in production

• 76% are deploying or implementing agentic AI in theory

Companies are restructuring for a capability that hasn’t fully arrived. The expectation of AI performance is driving business decisions faster than AI performance itself.

This has never happened before. In every prior technology wave — cloud, mobile, SaaS — companies restructured after the technology proved itself at scale. This time, the restructuring precedes the proof. The expectation economy has arrived.

And if you run a GTM organization, you have a decision to make before someone makes it for you.

The 65-Point Gap Nobody Is Talking About

Here’s the number that should keep every executive up at night: the gap between intent (76% deploying agentic AI) and reality (11% in production) is 65 points.

Sixty-five percent of organizations are somewhere in between — buying tools, running pilots, writing policies, reorganizing teams, reallocating budgets — but not actually running AI-powered workflows at scale.

They’re paying for the transition without getting the performance. That’s the worst possible position. You have the cost of change without the benefit of capability.

Why does the gap exist? Three reasons, and they’re all fixable with the right architecture:

Data quality. Organizations are committing to agentic AI workflows faster than they’re addressing the data quality those workflows require. An AI agent is only as good as the signals it runs on. If your CRM is 60% accurate, your AI-powered outreach is 60% accurate — and it’ll move 10x faster than a human in the wrong direction.

Integration depth. Demandbase’s new B2B AI GTM Report found that integrating CRM, marketing automation, predictive scoring, and advertising tools into a unified stack boosts conversion rates 53%. Most companies have those tools. Almost none have them fully integrated. You’re not missing software — you’re missing connective tissue.

Governance frameworks. 76% of GTM leaders are deploying agentic AI at a faster rate than they’re establishing the governance frameworks those deployments require. No decision rules. No escalation logic. No human-in-the-loop design. Just agents running in the wild.

The companies that are winning — the ones in that 11% running AI in production — aren’t doing something heroic. They built the infrastructure first. They didn’t skip the connective tissue.

Check out the Claude Cowork and Code Guides for Go-To-Market Below

Click Here

What the AI-Native GTM Org Actually Looks Like

Read more