I watch this happen constantly. A leadership team spends a quarter mapping a transformation roadmap with eleven workstreams, and at the end of the quarter the number of GTM agents actually running in their business is zero. Not because the team is incapable. Because nobody picked one workflow, drew a box around it, and shipped it. The roadmap was the procrastination. The first agent is the work.

Here is the thing about the first agent. It is the hardest one you will ever build, and it has almost nothing to do with the technology. The model is good enough. The tools are good enough. What is hard is the organizational act of choosing one workflow, defining what “good” means precisely enough to measure it, running it next to a human without flinching, and then killing the manual process when it works. The second agent is ten times easier because by then the company has done the hard part once. It has proof. It has a pattern. It has a person who has shipped.

So this playbook is about the first one. Thirty days. One workflow. End to end. Running.

And it is written for the Tactical CEO, which means I want to be precise about your job, because your job is not the one you think it is. You are not building the agent. If you are the CEO and you are in the prompt, something has gone wrong. Your job is to install the conditions under which the agent gets built and survives. You name the owner. You protect the thirty days. You set the cancellation target. You demand the exit criterion. Four moves, and if you make them, the agent ships. If you skip them, you get another roadmap.

Three readers should be following along here, and the job splits cleanly. The individual operator builds the thing. The leader clears the runway. The founder or CEO sets the target and refuses to let the calendar eat it. I will mark who does what as we go.

Here is the sequence.

Days 1-3: Pick the Workflow

Everything downstream is determined by this choice, and most teams get it wrong by picking the workflow that is most exciting instead of the one that is most shippable. The first agent is not where you prove ambition. It is where you prove the company can ship at all.

The move. Map your GTM workflows. Not your org chart. Your workflows. The repeated, nameable units of work that move revenue: lead research, inbound triage, meeting prep, CRM hygiene, follow-up drafting, renewal flagging, deal-desk approvals, onboarding sequences. Then score each one on three axes. Frequency: how many times a week does this run? Manual hours: how much human time does each run burn? Clarity: how cleanly can you describe what “good output” looks like? Multiply, sort, and the top of the list is your candidate. High frequency times high manual-hours times high clarity. Pick ONE.

The clarity axis is the one people undervalue. A workflow that runs two hundred times a week but where “good” is fuzzy and contested will sink your first agent in edge cases. A workflow that runs forty times a week but where good is obvious to everyone is a far better first target. You want frequency for ROI and clarity for shippability. Where they overlap is your agent.

What good looks like. One workflow named on a whiteboard, with a number next to it. “Inbound lead research. Runs roughly sixty times a week. Eats about twenty minutes of an SDR’s time each run. Good output is a five-field brief: company, funding, role fit, recent trigger, and a suggested opener.” That sentence is the deliverable for days 1 through 3. If you cannot write that sentence, you have not picked yet.

The CEO’s role here. You name the owner. This is the single most important thing you do in the entire thirty days, and it takes one decision. One person owns this agent end to end. Call them the Agent Builder. Not a committee. Not “the RevOps team.” A name. The Agent Builder can be a RevOps analyst, a sharp SDR, a sales engineer, anyone close to the work with enough technical comfort to wire tools together. What matters is that the responsibility lands on a person, because agents that belong to everyone get built by no one. If you do nothing else as CEO, do this.

Common mistake. Picking the flashiest workflow instead of the most shippable one. The autonomous outbound agent that personalizes at scale is the dream, and it is a terrible first agent because “good” is contested, the blast radius is your brand, and one bad send is a customer-facing incident. Start somewhere internal, high-frequency, and low-blast-radius. Earn the right to the flashy one by shipping the boring one.

Exit criterion. One workflow is named, scored against the other candidates, and written as a single sentence with a frequency number and a manual-hours number attached. The Agent Builder is named. When that is true, days 1 through 3 are done.

Days 4-7: Define the Contract

This is where most first agents die quietly, before a line of anything gets built. The team skips straight to building because building feels like progress, and they never wrote down what the agent is actually supposed to produce or how they would know if it worked. Then four weeks later there is a thing that runs and no way to say whether it is any good. Define the contract first.

The move. Write the agent’s contract on one page. Four parts.

Inputs: exactly what the agent receives. The lead’s email and company domain. The inbound form submission. The CRM record. Be specific about what is and is not available at runtime, because half of agent failures are the agent reaching for context it was never given.

Outputs: exactly what the agent produces, in what format, to what destination. “A five-field brief written to a Slack channel and appended to the CRM contact record.” Not “research on the lead.” A format a human can check at a glance.

What good looks like: the quality bar, written as something you can actually evaluate. Pull five real past examples that a human did well. Those are your gold standard. The agent’s output gets compared against them.

How you measure it: the metric, against the human baseline. Time saved per run. Accuracy versus the human-done version. Acceptance rate, meaning how often a human ships the agent’s output without rewriting it. Pick the one or two that matter and write down the current human number, because you cannot prove the agent is better than the human if you never measured the human.

What good looks like. A one-page contract that a person who has never seen the workflow could read and then correctly judge whether a given agent output passed or failed. If two people read the contract and disagree about whether an output is good, the contract is not done. Tighten it until they agree.

The CEO’s role here. You demand the exit criterion before a single thing gets built. The Agent Builder brings you the contract, and the question you ask is one sentence: “What number tells us this worked, and what is that number for a human today?” If they cannot answer, the agent is not ready to be built, it is ready to be re-scoped. This is a five-minute conversation and it is the highest-leverage five minutes in the project. You are not reviewing the work. You are refusing to let the work proceed without a definition of done.

Common mistake. No human baseline. The team builds the agent, it produces plausible output, everyone nods, and nobody can say whether it is faster or more accurate than what the SDR was already doing. Without the baseline you have a demo, not a result. Measure the human first, even roughly. A baseline that is approximate beats a baseline that does not exist.

Exit criterion. A one-page contract exists with inputs, outputs, a gold-standard set of five examples, and a named metric with the current human number written next to it. When that is true, days 4 through 7 are done.

The Architecture Every Agent Gets Built Against

The one-page contract is the spine. It is not the whole skeleton. The contract names what goes in, what comes out, what good looks like, and how you measure it, which is a real start, but a contract is not yet an agent. This is where most first agents quietly turn into demos. The team has a contract, they hand it to a model, the model produces something plausible, and nobody can say why it works on Monday and falls apart on Thursday. The reason is almost always a missing layer.

So here is the architecture I build every agent against. Seven layers, plus three things most people leave out, plus one rule that matters more than all of it. Your contract from days 4 through 7 already covers four of these layers. The other three are what separate an agent you can cut over to from a science project you keep babysitting.

Layer 1, identity. Name the agent, its domain, and one thing that decides everything downstream: its authority level. Advisor recommends and a human acts. Operator acts but asks permission for anything with real blast radius. Executor acts on its own inside declared bounds. Your first agent should almost always be an advisor or a tightly scoped operator, because authority is where damage lives. And write the “you do NOT” list. Name the specific ways this agent goes wrong, not generic negatives. “Never fabricate a trigger event it cannot source from the input” teaches the model something. “Be helpful” teaches it nothing.

Layer 2, objectives. The outcome it owns, and the anti-goal. The anti-goal is the part people skip and it is the part that saves you. “Optimize for accuracy even if it means flagging the lead as out of scope instead of guessing” is an anti-goal. It tells the agent what to sacrifice when the two things it wants are in conflict, which is exactly the moment unguarded agents improvise.

Layer 3, context. What is in scope, what is out, and the single most undervalued instruction in agent building: what to do when context is missing. An agent that guesses when it lacks input is an agent that hallucinates on a schedule. The fix is one line: when a required input is missing, do not guess, say what is missing and stop.

Layer 4, reasoning. Here is the counterintuitive part. If you are building on a modern thinking-capable model, do not script its thought process. Telling a reasoning model to follow your five steps usually makes it worse, because it plans better than your script does. Constrain the output, not the thinking. The one piece worth keeping is a verification step: before it answers, have it check its own work against the contract, and when something is ambiguous, ask one clarifying question instead of charging ahead.

Layer 5, tools. What the agent can reach, when to pick one tool over another, and the step nearly everyone omits: post-tool verification. After the agent calls a tool, it has to check that the result is actually what it asked for before it acts on it. Skip this and one bad lookup cascades into a confidently wrong output. This is the single most common hole in a first agent. If you do nothing else technical, make the agent verify its tool results before it trusts them.

Layer 6, output and guardrails. The format, and the hard nevers. Use blast-radius gates: read-only actions can run on their own, anything that writes asks for confirmation, anything customer-facing or irreversible requires a human. That gate, tied to the authority level from Layer 1, is what makes an agent safe to cut over to in week 4.

Layer 7, orchestration. Mostly skip this for agent number one, and that is the point of naming it. Orchestration is how an agent delegates to other agents, compacts a long conversation, and persists what it learned between runs. Your first agent does one thing, so it barely needs this. But know it exists, because agent number five will, and the most common orchestration failure is a fuzzy delegation map. “Hand off to a specialist when needed” is not a map, it is a shrug. When you get there, name exactly who receives what.

Then three things that are not optional, even though everyone treats them as extras.

A role contract, if the agent owns an outcome. For anything modeled on an actual revenue role, write what outcome it is accountable for, what artifacts it emits, what it consumes upstream, what consumes it downstream, and the metrics that prove it works. This is the Signal to Decision to Action to Feedback loop made concrete, and it is what keeps a GTM agent from drifting into a generic chatbot.

Examples. Two to five, every time. Show the agent a standard success, an ambiguous edge case it should ask about, and a bad input it should refuse. On a strong model, two or three real examples shape behavior more than any amount of instruction prose. The five gold-standard examples from your contract are the start of this. Add an edge case and a failure case and you are done.

Observability. Have the agent emit a small structured record every time it runs: what it received, what it did, whether it escalated, and the outcome. Ungoverned agents become ungovernable the moment you have more than a couple. A logging stub on agent one is a habit that pays off at agent ten.

And the rule that matters more than the rest: keep the whole spec tight. There is real research, and my own repeated experience, behind a density ceiling of roughly a hundred and fifty lines. Past that, agents get worse, not better, because the model’s attention degrades across a bloated spec and the redundant lines cost you both accuracy and money. Density beats comprehensiveness. Anything that is a standard process, a template, or a rubric does not belong in the agent itself. It belongs in a skill the agent loads only when it needs it. The agent spec holds identity, judgment, and the things the model cannot figure out on its own. Everything else loads on demand.

That is the difference between a tool and a system, which is the whole game. A tool is a clever prompt that works until it doesn’t. A system is an agent with an identity, a verified set of capabilities, guardrails proportional to what it can break, examples of right and wrong, and a record of every run. The first one takes a few extra hours to build this way. Every one after it inherits the pattern.

For agent number one, you genuinely need only Layers 1, 2, 3, and 6, plus a couple of examples and a verification step. That is the minimum viable agent. Build that, ship it, and add the rest as the workflow earns it. The architecture is the standard you grow into, not a gate you have to clear before you start.

Week 2, Days 8-14: Build the First Version

Now you build, and the entire discipline of week 2 is one word: thin. One workflow, end to end, running, even if it is ugly. The failure mode of week 2 is not building a bad agent. It is building half of an ambitious agent. A thin slice that works beats a thick slice that almost works, every single time.

The move. Build the narrowest version of the agent that takes the real input, does the real work, and produces the real output to the real destination. End to end. If the contract says “lead email in, five-field brief to Slack out,” then by the end of week 2 a real lead email goes in and a real brief lands in Slack. It does not have to handle every edge case. It does not have to be elegant. It has to be whole. One complete path from input to output, running on real data, even if it only handles the clean cases for now.

Resist the urge to build the pretty version. No dashboard. No configuration UI. No handling of the seventeen rare input formats. The clean path, working, on real inputs. The edge cases are week 3’s job, and trying to handle them now is how week 2 turns into week 6.

What good looks like. You can point at it and say “watch this,” paste in a real lead, and a real brief appears in the real Slack channel. It is ugly. It misses some cases. It works. That is the bar. A running thin slice on day 14 is worth more than a beautiful architecture diagram of the full system.

The CEO’s role here. You protect the thirty days. Week 2 is when the organization’s gravity tries to pull the Agent Builder back onto their old job. A fire breaks out, a board ask lands, a customer escalates, and the easiest thing in the world is to grab the most capable person, who is your Agent Builder, and put them on it. Do not. The whole premise of a thirty-day sprint is thirty protected days. If the Agent Builder gets pulled for a week, you do not have a thirty-day agent, you have a sixty-day maybe. Your job is to be the wall between the Agent Builder and the next fire. Leaders, this is yours too: clear their calendar, reassign their tickets, and make it socially expensive for anyone to interrupt the build.

Common mistake. Building wide instead of deep. The team tries to make the agent handle every input variation and every output format in week 2, gets buried in edge cases, and arrives at day 14 with a sophisticated half-thing that has never once run end to end. Ship the clean path first. The agent that runs on Monday teaches you more than the agent that is still being designed on Friday.

Exit criterion. A real input produces a real output to the real destination, on real data, end to end, at least once. When you can demo that live, week 2 is done.

Week 3, Days 15-21: Run It in Shadow Mode

The agent works on the clean path. Now you find out what the clean path was hiding. Week 3 is shadow mode: the agent runs next to the human, on the same real inputs, at the same time, and nobody ships the agent’s output to anyone yet. You compare. You measure. You fix the edge cases the real world surfaces.

The move. Run the agent in parallel with the human on live work. Same leads, same tickets, same inputs, both producing output. The human’s output is what actually gets used this week. The agent’s output gets logged and compared against it and against the contract’s gold standard. Every divergence is a finding. The human caught a trigger event the agent missed. The agent produced a cleaner opener than the human. The agent choked on a lead with no company domain. Each one is either a bug to fix or a boundary to document.

This is also where you measure the contract metric for real. Time per run, agent versus human. Acceptance rate: if a human had shipped the agent’s output, how often would it have been fine as-is? You are building the evidence that the agent is at or above the human baseline, on real work, before you let it touch anything live.

What good looks like. A week of side-by-side logs. The agent matches or beats the human on the named metric across the clean cases, and the edge cases where it fails are documented and either fixed or explicitly ruled out of scope. You know precisely where the agent is trustworthy and where it is not, because you watched it run against a human for a week instead of guessing.

The CEO’s role here. You hold the line on the cancellation target you are about to set, and you ask one question at the week-3 readout: “Is it at or above the human baseline yet?” Not “is it perfect.” At or above the human. Humans miss things too. The bar for cutover is not flawlessness, it is “as good as or better than the person doing it today, on the cases we have scoped.” If you let the team chase perfection here, the agent never ships, because nothing is perfect and shadow mode can run forever. Your job is to define “good enough to cut over” as “beats the human on the metric we agreed to,” and then push for the cutover.

Common mistake. Letting shadow mode become permanent. Shadow mode is comfortable. The agent runs, nobody depends on it, there is no risk, and the team can tweak forever. That is not safety, it is avoidance. Shadow mode has a one-week clock. At the end of the week you make a call: cut over, or kill the project and pick a different workflow. What you do not do is run a fourth week of shadow mode because someone is nervous.

Exit criterion. A week of side-by-side data shows the agent at or above the human baseline on the contract metric, with edge cases documented and either fixed or scoped out. The cutover decision is made. When that is true, week 3 is done.

Week 4, Days 22-30: Cut Over and Kill the Manual Process

This is the week that separates a real agent from a science project, and it is the week most companies never reach, because cutting over means committing. Shadow mode is reversible. Cutover is a decision. You are saying: from now on, the agent does this, and the human stops doing it the old way. The agent is no longer running next to the process. The agent is the process.

The move. Four things, in order.

Cut over. The agent’s output now goes live. The human moves from “doing the work” to “supervising the agent,” which mostly means spot-checking and handling the documented edge cases the agent does not cover. The default is the agent. The exception is the human.

Kill the manual process. Actually kill it. Not pause, not “keep it as a backup just in case.” The manual workflow comes off the team’s plate. If the SDR is still doing lead research by hand “to be safe,” you have two processes and zero leverage, and the agent will quietly atrophy because nobody depends on it. Make the agent the only path.

Hit the cancellation target. Here is where the CEO’s number comes due. If this workflow was being done with a SaaS tool you were paying for, cancel it or earmark it for cancellation at renewal. If it was being done with human hours, those hours are now reclaimed and explicitly redeployed to higher-value work, named, not vaguely “freed up.” The first agent should retire something. A subscription, a contractor line, a chunk of hours. That retirement is the proof the agent is real, and it funds the next one.

Write the runbook and pick agent #2. A one-page runbook: what the agent does, where it runs, how to tell if it is broken, who owns it, what to do when it fails. Then, on day 30, the Agent Builder names the next workflow off the day-1 scoring list. The pattern is now installed. Agent #2 will take half the time.

What good looks like. The manual process is gone. The agent runs in production and a real person depends on its output every day. A line item got cancelled or a block of hours got formally redeployed. There is a runbook. There is a named candidate for agent #2. The company has shipped one, and more importantly, it now knows how.

The CEO’s role here. You set the cancellation target at the start of the month, and in week 4 you collect it. “This agent retires the X subscription,” or “this agent gives the SDR team back ten hours a week that go to live conversations.” You name that target on day 1 and you hold the team to it on day 30. Without a cancellation target, the agent becomes additive: a new thing on top of all the old things, and additive AI is how companies end up paying more and moving the same. The cancellation target is what makes the agent a replacement instead of an addition. That is your number to set and your number to enforce.

Common mistake. Running the agent and the manual process in parallel forever because cutting the manual process feels risky. This is the most common failure in the entire thirty days, and it is fatal in slow motion. Two parallel processes means the agent never becomes load-bearing, nobody truly depends on it, the cancellation target never gets hit, and within a quarter the agent is a curiosity nobody maintains. The cutover is the point. If you are not willing to kill the manual process, you were never serious about the agent.

Exit criterion. The agent runs in production, the manual process is dead, the cancellation target is hit or scheduled, the runbook exists, and agent #2 is named. When all five are true, you have shipped your first GTM agent in thirty days.

Why the First One Is the Hardest, and the Most Important

The first agent costs you a month and teaches you everything. It forces the company to learn the one skill that the entire AI-native transition actually depends on, which is not prompting and is not tooling. It is the organizational muscle to scope one workflow, define done, measure against a human, cut over, and kill the thing it replaced. That muscle is the whole game. Companies that have it ship agent after agent. Companies that do not have it accumulate roadmaps.

Once the muscle exists, the constraint stops being capability and becomes throughput. You will not be asking “can we build an agent?” You will be asking “which workflow next, and who owns it?” That is a completely different company than the one that started the month with a deck and a budget line and nothing running. The first agent does not just automate a workflow. It converts the organization from talking about agents to shipping them. That conversion is worth far more than the twenty minutes a week the agent saves.

The individual operator gets a shipped artifact and a new identity: the person who builds the agents. The leader gets a repeatable thirty-day pattern to run again and again across the revenue org. The CEO gets the only thing that actually matters at the top, which is proof that the company can install AI into its operating model and retire what it replaces, instead of layering AI on top and paying twice.

The window for this is not open forever. The companies building this muscle now are compounding it while everyone else is still mapping. Eighteen months from now the gap between the company that shipped its first agent this quarter and the company that is still planning its transformation will not be a quarter. It will be the difference between an organization that runs on agents and one that runs slides about them.

Pick the workflow. Name the owner. Protect the thirty days. Ship the first one.

Below the line: the build prompt I would hand the Agent Builder on day 1, the SaaS-spend-to-agent mapping worksheet for finding your cancellation targets, and the companion interactive guide that walks the full thirty-day sequence with the templates built in.

Free preview ends here. Everything above is the full 30-day sequence, free to read and free to run: the week-by-week moves, the exit criteria, the CEO’s role at each phase. Below, for paid subscribers, are the copy-paste assets that make it faster: the first-agent build prompt, the SaaS-spend-to-agent mapping worksheet, and the companion interactive guide.

Read more

As per usual, we have podcasts, articles, and notes every week and you can get the rundown here of what to expect.

Subscribe now

Now lets get into it.

You can go to Youtube, Apple, Spotify as well as a whole other host of locations to hear the podcast or see the video interview.

Have you ever asked yourself who actually owns your AI conversations?

I hadn’t. Not really. Then John Williams said this on the podcast and I haven’t stopped thinking about it since:

“Possession is nine-tenths of the law. If you can’t access it, then perhaps you don’t own it.”

Sit with that for a second. You’ve spent a year, maybe two, doing your best thinking inside Claude, ChatGPT, Gemini, and Groq. Prompts that work. Decisions you reasoned through out loud. Whole projects planned turn by turn. Where does all of it live? Behind someone else’s login, under someone else’s terms of service, dependent on someone else’s uptime.

John is a 20-year GTM operator who’s spent the last five years running an independent practice, and he came into the kitchen this week and actually cooked: live demos, real repos, receipts on screen. No keynote fluff. What he showed adds up to something bigger than any single tool, and I want to walk you through all five layers of it, because the through-line is a strategy most operators haven’t named yet.

The strategy is ownership.

1) We just entered the toolbox era of GTM.

John opened with an analogy that reframed how I think about operator careers. An HVAC mechanic shows up to your house with their own toolbox. An automotive tech brings their own tools to the shop. John’s argument: GTM operators are next.

“When we arrive at a situation, whether that’s our next FTE role or as an independent operator, you’re expected to bring some of your own tool stack with you.”

Read that again if you’re job hunting or running fractional. The expectation is shifting from “can you use our stack?” to “what do you bring with you?” And the proof of what you bring lives in public. When someone from John’s network pitches him for project work, his first question is “Would you share your GitHub repo link with me?” Your repo is becoming your resume.

He took it one step further, and this is the part I loved: if he applied for his next full-time role, he’d do the entire application in public. Document the approach, publish the work, and let the employer find him instead of being applicant 847 in the first hour.

The tactical move this week:

• Create a GitHub account if you don’t have one (private repos are free)

• Push one thing you’ve built: a prompt library, a workflow doc, a custom skill

• Side benefit I learned the hard way: it also syncs your work across machines. I once lost two days to an iCloud sync death loop between my Mac Mini and laptop. A repo would have saved me both days.

2) Your conversation history is an appreciating asset. Treat it like one.

Here’s the mental shift: every AI conversation you have produces two outputs. The answer you needed today, and a record of how you think. Almost everyone keeps the first and throws away the second. John argues the second is worth more.

His tool, Chat Archive, is a free open-source browser extension that exports any AI conversation to JSON or markdown with one click. He demoed it live: exported a full Claude conversation about a technical project, uploaded the JSON into Groq, and Groq picked up the project with complete context. It even summarized an overnight run he hadn’t reviewed yet. Mid-project model switching, solved. The thing that matters most architecturally: zero outbound calls. Nothing leaves your machine.

But the convenience play is the small play. Three bigger ones:

• The audit trail. If you work in a regulated industry, raw inference files prove you acted in your client’s best interest. John compared it to preserving security camera footage. When AI-assisted work gets questioned (and it will), the operators with receipts win.

• The digital twin. John is accumulating his full conversational history so a model can mine it for patterns. His framing stuck with me: “We try to do our best as organic LLMs to remember to do all of the right things... but we do forget. We do lose our own context.” A year of archived chats becomes a dataset about your own thinking, and models are exceptional at surfacing patterns you can’t see from inside your own head.

• Federated intelligence on your terms. Each archived conversation becomes a node you control. Stitch them together and you’ve built an intelligence layer that follows YOUR privacy policy, not a vendor’s.

One more detail worth stealing even if you never install anything: John keeps a master markdown file per project. After every session, he updates what got done against what he hoped to get done, then feeds that file into whatever model he opens next. Every conversation starts fully informed. You stop re-explaining yourself to the AI forever.

3) Own your own inference.

John runs local models on his laptop through Ollama, and his reasoning goes well past privacy.

Privacy first, though, because his framing is the cleanest I’ve heard: a cloud model “may be very well-protected, but it’s not contained.” Local inference on a laptop with the wifi off is contained by definition. For client work, for sensitive strategy, for anything you’d hesitate to put in an email, that distinction is everything.

Then redundancy. We watched GPU brownouts hit in March. Think about the supply math John laid out: the GPUs serving you today were purchased and installed two years ago, and the demand curve just went vertical. Every agentic workflow spun up in the past 30 days is token demand that did not exist at the start of the year. Supply is fixed in the short run. Demand is compounding. You don’t need a PhD in economics to see what happens to availability and price. I use Claude every single day, and when it goes down I lose real money in productivity. A local model is the backup generator.

And then the reason nobody talks about: craft.

“In your learning journey, you want to move past being a prompt jockey.”

Working with a small local model teaches you how these systems actually behave: what context does, where models break, when to push back on a plan. John described the aha moments where he’d challenge the model’s direction and it would respond with “that actually is a way better path.” That judgment, knowing when to redirect the machine, compounds into every project after it. You can’t read your way to it. You have to run the reps.

Small models now run fine on a normal laptop. The hardware barrier you remember from a year ago is gone. And one detail that stung: Ollama lets you switch models between turns without losing context. Start a turn with one model, answer with another, context intact. Opus to Sonnet mid-conversation still can’t do that. Open source is ahead of the labs on this one.

4) The token economics nobody is pricing in.

This was the most quietly important stretch of the episode. Two facts, one collision course:

Fact one: the labs lose money on inference. John put it plainly: “the inference costs for them are actually way more than they earn on their subscriptions.” Your $20/month plan is subsidized. That doesn’t go on forever, and we should expect a rebalancing.

Fact two: the work AI is absorbing didn’t get free. It moved. John’s framing deserves to be quoted in full:

“Where we maybe previously paid the W-2 of a human to do this necessary thing for the business, that cost didn’t really go away. It just transferred from a W-2 to an inference provider.”

Put those together and “token efficiency” stops being a nerd concern and becomes a line item your CFO will eventually ask about. The operators who get ahead of it will do three things: route work to the cheapest model that can handle it (I plan in Sonnet, build in Opus; the planning tokens are cheap, the building tokens earn their cost), batch non-urgent work to lower-cost processing, and move private, repetitive, high-volume work to local models where marginal token cost rounds to zero.

John calls the end state “token authority”: the ability to keep processing work on your own terms when the meter, the grid, or the vendor says no.

And on the jobs doomerism that usually hijacks this conversation: we used to employ switchboard operators and lamplighters. Was that the best use of a human mind? Every platform shift in history has produced more jobs than it destroyed, and the W-2-to-inference transfer is the mechanism, watching it happen in real time. The question worth asking is John’s: if nothing prevented you from doing anything, where would you actually spend your time?

5) Agents need contracts before they need apologies.

Your agents are about to spend money and agree to terms on your behalf. Most people have given exactly zero thought to the rules.

John’s Agent Commerce open spec codifies the transaction layer: how much an agent can spend without checking in, which terms and conditions it can accept, how an IP owner on the other side exposes pricing and terms in a language agents understand. It rides existing payment rails. It just makes the rules of the deal machine-readable, so the agent can check itself before committing you.

His AI Acceptable Use Policy spec solves the company-side version of the same problem. Enablement teams got overrun by shadow AI, and most companies are starting from zero. The AUP is an open-source base layer they can adapt, so AI gets embraced responsibly instead of banned badly or ungoverned entirely. Both are open source at github.com/fxops-ai, and notably, the contributing models (Groq, Claude Opus) are listed as authors. That transparency is the point.

Same energy applied to OpenClaw: huge respect for the project, real caution on the blast radius. A tool that can log in as you, write files, and legally commit you deserves scrutiny before trust. John’s filter is one question: “Would my security director approve of my use of this tool?” If the answer is maybe, paste the repo into your model first and ask it to flag the security risks. API keys leak. Prompt injection hides in agent skills. Two minutes of vetting beats a horror story. Or take my preferred play: point Claude Code at the repo, have it understand the concept, and build your own version. You get the capability without inheriting the attack surface.

The through-line

Five layers, one strategy: own your proof of work (GitHub), own your context (archives), own your inference (local models), own your economics (token authority), own your agents’ behavior (guardrails). Each one is small on its own. Stacked, they’re the difference between operators who negotiate from strength when the rebalancing comes and operators who pay whatever the meter says.

John named the urgency early in the episode, and it’s the most honest sentence anyone’s said on this show: “We probably would’ve chosen a slower pace, but we didn’t get to make that choice.”

My challenge to you this week: pick ONE layer and claim it. Easiest start: export one important AI conversation and store it where you control it. Five minutes. Then look at it and ask what a year of those is worth to you.

I hope this one shifts how you think about ownership, because it shifted mine. Reply and tell me which layer you’re starting with. I read every response.

Find John at github.com/fxops-ai and on Hugging Face as johnwilliamsatl. He’s in the Pavilion AI&GTM channel, and if you’re building an independent practice, he and Henning teach the Be Fractional course every six weeks.

The AI Ownership Playbook

Own your chats, your models, your economics, and your agents in 30 days

You’ve spent the last year building your best thinking inside AI tools you don’t control. Your prompts, your workflows, your decisions, your context. All of it lives behind someone else’s login, someone else’s terms, and someone else’s uptime.

Here’s the sentence that should bother you, courtesy of 20-year GTM operator John Williams: “Possession is nine-tenths of the law. If you can’t access it, then perhaps you don’t own it.”

This playbook fixes that in five moves. Each move stands alone, includes copy-paste templates, and tells you exactly what “done” looks like. Work through all five and you’ll have something most operators won’t have for years: full custody of your AI work, a backup plan for the next outage, and a real answer when someone asks what your AI spend is buying.

Inspired by the GTM and AI Podcast episode with John Williams (github.com/fxops-ai). He cooked. This is the recipe.

Start here: The 5-question ownership audit

Score yourself honestly. 1 point per “yes.”

1. If your main AI provider deleted your account tonight, would you still have your conversation history tomorrow?

2. If every cloud AI went down for 48 hours, could you still get AI-assisted work done?

3. Do you know (roughly) what you spent on AI tokens/subscriptions last month, and what it replaced?

4. Have you security-vetted every AI tool and extension you currently have installed?

5. If your agent spent $500 or accepted a terms-of-service agreement tomorrow, would it have been following written rules you set?

Score 4-5: You’re ahead of 95% of operators. Skim for the templates. Score 2-3: Normal. The moves below close the gaps in order of impact. Score 0-1: Good news: you’re one weekend away from a different position entirely.

Move 1: Archive every AI conversation (15 minutes to start, lifetime payoff)

The problem: every AI conversation produces two outputs. The answer you needed today, and a record of how you think. Almost everyone keeps the first and throws away the second. The second is worth more, and right now it sits in someone else’s vault. Lose the account, lose the context, lose the year.

The fix:

1. Install Chat Archive, John Williams’ free open-source browser extension (find it via github.com/fxops-ai). Works in Chromium browsers: Chrome and Edge.

2. Open any AI conversation (it auto-detects Claude, ChatGPT, Gemini, Groq; Perplexity support came from community contributor Nathan Spear, who also added bulk export). Refresh the page so the extension can read the DOM.

3. Export to BOTH formats: JSON (machine-readable, for feeding other models) and markdown (human-readable, for your notes).

4. Save to a consistent local structure: /ai-archive/[tool]/[project]/[YYYY-MM-DD]-[topic]

5. Back the folder up to a private GitHub repo. Private repos are free, and you get cross-machine sync without cloud-sync nightmares. (I once lost two days to an iCloud sync death loop between two computers. A repo would have saved both days.)

What the export captures: the full URL, timestamps, and every turn between you and the model, so a different model can reconstruct not just what was said but when and in what sequence.

The master markdown ritual (the highest-leverage 3 minutes of your week):

John keeps one master markdown file per project. After every working session, he updates it. Then he uploads that file into whatever model he opens next, and every new conversation starts fully informed. You stop re-explaining yourself to AI forever. Copy this template:

# [Project Name]: Master Context File

Last updated: [date] Goal: [one sentence: what done looks like] Current status: [one sentence]

## Session log

• [date]: Planned: [what I hoped to get done]. Actual: [what got done]. Next: [first task of next session]

## Decisions made (and why)

• [decision]: [reasoning in one line]

## Open questions

• [question]

## Things that didn’t work (don’t retry)

• [approach]: [why it failed]

Why both formats matter: the JSON export is portable context. Start a project in Claude, hit an outage or a rate limit, upload the JSON to Groq or Gemini, and the new model picks up exactly where you left off. On the episode, Groq summarized John’s overnight Claude run before he’d even reviewed it himself. Mid-project model switching, unlocked.

The compounding play: mine your archive. Once you have 90+ days of archived conversations, feed batches into a model with prompts like these:

• “Here are 3 months of my AI conversations. What topics do I keep circling back to without finishing? What does that suggest I should prioritize or drop?”

• “Identify the 5 prompts or framings in these conversations that produced my best outputs. Turn each into a reusable template.”

• “What patterns do you see in how I make decisions? Where do I consistently lose time?”

• “Based on these conversations, what’s an opportunity or connection I appear to be missing?”

This is John’s “digital twin” concept in miniature: a year of archived chats is a dataset about your own thinking, and models are exceptional at seeing patterns you can’t see from inside your own head. As John put it: “We try to do our best as organic LLMs to remember to do all of the right things... but we do forget. We do lose our own context.”

Bonus use case for regulated work: raw inference files are an audit trail. If you handle financial stewardship or client funds, the original conversation files prove you acted in good faith. John compares it to preserving security camera footage. When AI-assisted work gets questioned, the operator with receipts wins.

Done looks like: extension installed, top 5 conversations exported in both formats, archive folder backed up to a private repo, master markdown file started for your most active project.

Move 2: Set up local inference (45 minutes)

The problem: GPU brownouts arrived in March. The GPUs serving you today were bought and installed two years ago, and every agentic workflow spun up in the past 30 days is new token demand that didn’t exist at the start of the year. Fixed supply, compounding demand. When the meter, the grid, or the vendor decides your day, you don’t have authority over your own work.

The fix: run a small model on your own laptop.

1. Download Ollama (ollama.com). Free. Mac, Windows, Linux.

2. Open a terminal and pull a model sized to your machine:

Your machine Start with Why 8GB RAM ollama run llama3.2 (3B) Small, fast, surprisingly capable 16GB RAM ollama run mistral or ollama run gemma3 Strong reasoning for the size 32GB+ RAM ollama run llama3.1 (8B+) or larger Handles longer context and harder tasks

3. Talk to it. Then disconnect your wifi and talk to it again. That feeling is what John calls token authority.

4. Note the trick the big labs haven’t shipped: Ollama lets you switch models BETWEEN TURNS without losing conversation context. Opus to Sonnet mid-chat still can’t do that. Open source is ahead here.

Your first 5 reps (this is how you move past prompt jockey):

1. Give it a real task from your week (summarize notes, draft an email) and compare against your cloud model. Notice the gaps. The gaps teach you what the expensive models are actually doing for you.

2. Challenge its plan mid-task: “Does it really make sense that we’re headed down this path? Why wouldn’t we do it this way instead?” Watch it either defend the approach with reasons or fold to the better path. That judgment loop is the skill.

3. Paste in an archived conversation (Move 1) and ask it to continue the project.

4. Switch models mid-conversation and watch the context survive.

5. Run something you’d never send to the cloud: comp planning, a sensitive client situation, a negotiation strategy. Contained by definition.

The local vs. cloud decision matrix:

• Local: sensitive client data, regulated work, anything you wouldn’t put in an email, drafts and brainstorming, learning reps, outage backup, high-volume repetitive tasks where marginal cost should be zero

• Cloud: complex multi-step builds, long-context reasoning, final-pass quality, anything where the best model materially changes the outcome

Why this matters beyond the backup plan: as John framed it, a cloud model “may be very well-protected, but it’s not contained.” And the craft argument is real: “In your learning journey, you want to move past being a prompt jockey.” Working with a small model on your own machine teaches you how these systems behave: what context does, where models break, when to redirect. That learning compounds into every project after it.

Done looks like: Ollama installed, one model pulled, one full work task completed offline, one mid-conversation model switch performed.

Move 3: Vet before you trust (10 minutes per tool)

The problem: open tools are powerful and the ecosystem moves fast. So do bad actors. Leaked API keys and prompt injection hiding inside agent skills are not hypotheticals. They’ve happened. And the more powerful the tool (OpenClaw-class agents can open files, write files, log in as you, and commit you legally), the bigger the blast radius.

The fix: the Security Director Test. Before adopting any open tool, ask one question: “Would my security director approve of my use of this tool?” If the answer is maybe or not sure, run this prompt before you install anything:

“Review this GitHub repository: [URL]. Act as a cautious security engineer. Flag any information security risks including: outbound network calls and where they go, credential or API key handling, permissions requested, prompt injection surface in any skills or instruction files, code that writes files or executes commands, and anything that could commit the user financially or legally. Rate overall risk low/medium/high and explain your top 3 concerns in plain English.”

The red flags checklist:

• [ ] Outbound network calls you can’t explain (the best privacy tools make zero; everything stays local)

• [ ] API keys or credentials stored in plain text or sent anywhere

• [ ] Permissions broader than the job requires

• [ ] Instruction or skill files that could carry prompt injection

• [ ] Ability to transact, agree to terms, or act as you without an approval step

• [ ] No visible community, contributors, or commit history (ghost repos)

The rebuild play (often better than installing): point Claude Code at the repo and ask it to understand the concept, then build YOU a version scoped to exactly what you need. You get the capability without inheriting the attack surface. Don’t copy the code. Copy the idea.

Calibration note: this is not a reason to avoid open source. John’s entire stack is built on it, and he credits the builders he learned from by name (Jaron at TriFall’s chat export approach became the foundation of Chat Archive). Trust but verify. Use the test, then move with confidence.

Done looks like: Security Director Test run on every AI tool and extension currently installed, anything that fails removed or rebuilt.

Move 4: Give your agents a budget (30 minutes)

The problem: agents now research, transact, and agree to terms on your behalf. Most people deploy them with no written rules at all. That works right up until it really doesn’t, and “it really doesn’t” looks like an agent accepting exclusivity terms or recurring billing you never saw.

The fix: write the guardrails before the first incident. Copy this and fill in your numbers:

Agent Spending & Terms Policy (personal)

1. My agent may spend up to $___ per task and $___ per month without asking me.

2. Any single purchase over $___ requires my explicit approval before checkout.

3. My agent may accept standard terms of service for: [research data, content access, API usage]. It may never accept terms involving: exclusivity, sharing of client or personal data, recurring billing over $___/month, or legal commitments beyond the purchase itself.

4. My agent identifies itself as an agent wherever disclosure is required.

5. Every transaction gets logged: date, vendor, amount, terms accepted, task it served.

6. I audit the log every [week/month].

The transaction log (one row per event, keep it in the same repo as your archive):

| Date | Agent/tool | Vendor | Amount | Terms accepted | Task served | Flag? |

If you’re doing this for a company, not just yourself: John’s open-source AI Acceptable Use Policy is the base layer. Enablement teams got overrun by shadow AI, and most companies are starting from zero. The AUP gives L&D and HR a starting point that embraces AI responsibly without being overly restrictive (the two failure modes: ban it badly, or let shadow AI run the show). His Agent Commerce spec covers the transaction layer: machine-readable rules for what agents can buy and agree to, riding existing payment rails. Both at github.com/fxops-ai.

Done looks like: policy filled in and saved, transaction log created, and (if applicable) the AUP forwarded to whoever owns enablement at your company.

Move 5: Run a token budget (20 minutes, then 10 minutes monthly)

The problem: the labs lose money on inference. Your $20/month subscription is subsidized, and a rebalancing is coming. Meanwhile, every task AI absorbs from a human didn’t get free; as John put it, the cost “just transferred from a W-2 to an inference provider.” When prices correct, token efficiency becomes a line item. Get ahead of it now.

The worksheet (15 minutes, once):

1. List your AI spend: subscriptions + API costs + agent/tool costs = $___/month

2. List what it replaced or produces: hours saved/week × your effective hourly rate = $___/month

3. Your ratio: if line 2 isn’t at least 3x line 1, your usage is a hobby, not a system. Fix usage before cutting spend.

The 3 efficiency moves, in order of impact:

• Route by cost. Plan with a cheaper model, build with the expensive one. (My pattern: Sonnet plans, Opus builds. Planning tokens are cheap; building tokens earn their cost.) The cheapest model that can handle the task gets the task.

• Batch the non-urgent. Overnight and batch processing run at lower cost. Anything that doesn’t need an answer in real time shouldn’t pay real-time prices.

• Go local for the repetitive. High-volume, private, repetitive work goes to your local model (Move 2), where marginal token cost rounds to zero.

Done looks like: you know your number, your ratio, and which workloads move to cheap/batch/local this month.

The 30-day ownership plan

Week 1: Custody. Run the audit. Install Chat Archive. Export your top 5 conversations. Create the private repo. Start one master markdown file.

Week 2: Authority. Install Ollama. Pull one model. Run the 5 reps. Complete one real task fully offline.

Week 3: Security. Run the Security Director Test on every installed AI tool. Remove or rebuild anything that fails. Write your agent spending policy.

Week 4: Economics. Run the token budget worksheet. Move one workload each to cheap-model, batch, and local. Calendar a monthly 10-minute review.

Then keep two habits forever: update the master markdown file after every session, and export important conversations as you go.

The final checklist

• [ ] Ownership audit scored

• [ ] Chat Archive installed, top 5 conversations exported (JSON + markdown)

• [ ] Private GitHub repo created, archive backed up

• [ ] Master markdown file live for your most active project

• [ ] Ollama installed, one model pulled, one task done offline

• [ ] One mid-conversation model switch performed

• [ ] Security Director Test run on every installed tool

• [ ] Agent spending policy written, transaction log created

• [ ] Token budget worksheet done, ratio known

• [ ] First archive-mining prompt run (after 90 days of archiving)

Ten boxes. Thirty days. Full custody of your AI work.

My challenge to you: check the first two boxes today. Export one conversation that matters and put it where you control it. Then come back and tell me what it felt like to hold your own data for the first time.

I hope this saves you the two days I once lost to a sync death loop. Learn from my pain ;)

Stay curious.

Coach K GTM AI Academy

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?

I watch GTM leaders do this constantly. They try Claude Code, or OpenAI’s Codex, or Anthropic’s Cowork, get a sloppy first result, and conclude the tool isn’t ready. The model is fine. The model is, frankly, astonishing. The problem is they dropped a brilliant operator into a junk drawer of files with no labels and no system, then judged the work that came back out.

Here is the thesis, and I’ll defend it the whole way down: the bottleneck with agentic AI is almost never the intelligence. It is the operating environment you put the intelligence into.

The new hire nobody onboarded

Think about the best person you ever hired. Sharp, fast, eager, ready to go on day one. Now imagine you sat them at a desk, pointed at a wall of unlabeled boxes, and said “the files are in there somewhere,” gave them no idea where finished work goes, no sense of how your team writes things or names things, and then walked away.

A great hire would still try. They’d dig through the boxes, guess at your conventions, produce something. And it would be wrong in a dozen small ways, because you never told them what right looks like. You’d look at the output and think, “maybe this person isn’t as good as I thought.”

That is exactly what happens with agentic tools. The agent is the brilliant new hire. The repo or the folder is the desk and the boxes. And most people skip onboarding entirely, then blame the hire.

Here’s the twist. With a human, that onboarding is fuzzy and slow. It lives in hallway conversations and Slack threads and the slow osmosis of “how we do things here.” With an agent, the onboarding can be a file. One file. Written once, read at the start of every session, applied perfectly every time. The thing that takes a human three months to absorb, you can hand an agent in three hundred lines. That is a gift most people are leaving on the table.

Stop prompting. Start operating a system.

The first mistake is thinking the skill you’re building is prompting. It isn’t. Prompting is what you do in a chat window when you want a one-off answer. Working with an agentic tool is something different, and the leaders who get this pull away fast from the ones who don’t.

You are not prompting anymore. You are operating a system.

In that system, the repo or the working folder is the operating system. It is the environment the agent lives inside, the place where context, history, and output all accumulate. And the conventions file is the constitution. It is the document that tells the agent what the rules are, where things go, and what “done” looks like in your world.

Every serious tool now has a version of this constitution:

• Claude Code reads a CLAUDE.md file at the start of every session. It’s the standing brief the agent gets before it touches anything.

• OpenAI’s Codex uses AGENTS.md, which the team describes as a README for agents. Codex walks from the repo root downward and merges these files hierarchically, so a rule at the top applies everywhere and a rule deeper in applies locally.

• Anthropic’s Cowork, the desktop agentic workspace that operates inside folders you authorize, holds the same thing inside Projects: instructions, scheduled tasks, context, and memory.

Different names, same job. The tool changes. The principle does not. And this is the part that separates people who get leverage from people who get frustrated: a tool is something you buy, a system is something you build. The agent is the tool. The constitution and the folder structure are the system. If you only ever shop for tools, you’ll keep wondering why the magic doesn’t show up. The magic is in the system you wrap around the tool.

The one habit that compounds

If you do nothing else, do this. Keep a conventions file, and give everything a place to live. Then maintain both as the work grows.

That sounds almost too simple to matter. It is the most underrated move in the entire space, and the evidence backs it up. A study comparing human-written conventions files against ones the model generated for itself found the human-curated versions won. The machine-generated files actually reduced task success in five of eight settings tested. Read that again. Letting the agent write its own rulebook made it worse most of the time. The judgment about what matters, what’s non-obvious, what your team actually cares about, that still has to come from you. The agent executes the constitution beautifully. It is not yet the right author of it.

So write a lean one. The teams shipping with Codex say the same thing the Claude Code teams say: keep it tight, focus on the non-obvious rules, commit it and review it like code, because that’s what it is. For CLAUDE.md specifically, keep it under roughly two hundred lines, because the agent reads it every single session and bloat costs you. Boris Cherny, who built Claude Code, has a rule I’ve adopted wholesale: anytime the agent does something wrong, add a line to the file so it never does it again. That’s it. That’s the flywheel. Every mistake becomes a permanent correction instead of a recurring annoyance.

There’s a principle I live by in my own system, and it applies perfectly here: if it won’t exist next session, write it down now. The agent has no memory of yesterday unless you gave it one. The folder is its memory. The conventions file is its judgment. Every time you fix something verbally and don’t write it down, you are paying to teach the same lesson twice.

The compounding works like this. Day one, your conventions file is thin and your output is rough. You correct a few things, you write them down. Day thirty, the file knows where everything goes and how you like it, and the output lands clean on the first try. The system got smarter while you slept. That is the whole game, and almost nobody plays it on purpose.

Where to start

Read more

Subscribe now

Let’s get into the podcast!

You can go to Youtube, Apple, Spotify as well as a whole other host of locations to hear the podcast or see the video interview.

The RevOps leader who stopped hiring

“Every time I think I need to hire someone, I just solve it with AI instead.”

Nathan Follen said that to me this week, and I have been chewing on it ever since. Nathan leads go-to-market systems and ops for Perplexity Enterprise. Before that, he was a big reason RAMP scaled like a rocket. So when he tells me he is running RevOps with a team of agents instead of a team of people, I do not roll my eyes. I take notes.

He showed me 3 skills he built in the last 2 months. Work that used to eat his team hours every week. Now it runs by itself, every single day, whether his laptop is open or sitting in a drawer.

Here is what he is actually doing.

1. Voice of Customer that runs itself

Most teams treat voice of customer like a quarterly project. Nathan turned it into a living dashboard that refreshes daily.

The build was almost embarrassingly simple. Two prompts and an API key into his call recording tool, Momentum.io synced with Salesforce. From there the agent does the work a data team used to:

• Auto-tags discovery calls vs follow-ups from the context of the conversation alone. No admin. No manual fields.

• Surfaces the week’s themes: pricing objections, feature requests, rollout blockers, champion quotes.

• Tells him what the product team should do about each theme, and what enablement should build.

Then it did something I did not expect. It pulled the top 20 customer quotes, grabbed the clips using the new Momentum.io SmartClips product, and edited a 2-minute customer sizzle reel with music. Inside the same tool. The thing marketing usually waits two weeks for.

Why it matters: Your customers are telling you exactly what to build and how to sell it. The bottleneck was never the data. It was the hours to process it. That bottleneck is gone.

2. The weekly deck that builds itself

Nathan runs a weekly RevOps go-to-market call. The deck for it used to take an hour to build by hand.

Now a skill kicks off every Thursday on a schedule and does the whole thing:

• Pulls live numbers from Snowflake and project updates from key Slack channels.

• Pings the sales team to clean up stale pipeline before the data gets pulled.

• Sets a cron job to re-check that Slack thread, grab whatever people added, and drop it into the final slides.

One hour of work, every week, reduced to a notification that the deck is ready. The agent even decides which buried Slack updates the whole team needs to see.

Why it matters: Reporting is the tax RevOps pays to do its real job. Nathan stopped paying it.

3. A CRM that cleans itself at night

This is the unglamorous one that quietly runs everything.

Account ownership, Salesforce hierarchies, mismatched domains and contacts. All of it gets cleaned on a nightly batch job instead of a pile of real-time flows that break the moment you scale. When Computer catches something it should fix, it runs the cleanup, sometimes directly and sometimes through a tool like Polytomic or Hightouch.

Then the part that earns trust: a monitoring agent reads every Slack channel and his inbox, and DMs him each error, ranked by severity, with the fix already attached.

Why it matters: Nathan said the speed unlock was not the building. It was the confidence to build fast because he knows the system will catch its own mistakes.

The shift underneath all three

Here is the line that got me out of my chair. Nathan runs a daily standup with his agents. He asks them what they worked on and what they could do better.

The old RevOps job was to find the top two priorities and protect focus. The new job is to broaden the aperture and run dozens of projects in parallel, because a v1 ships in the time you used to spend arguing about whether something was worth doing.

He put it perfectly. If you hire two people to do the same thing with agents, you get a mess. If you give people their own surface area and let each one manage a team of 10, 20, 100 agents, you hire them on the spot.

People keep calling this the future. Nathan is doing it on a Tuesday.

Nate Follen: Pull Quotes & Learnings

On hiring vs building

“[Every time I think I’m going to hire someone, I just solve it with Perplexity.]”

“In some cases, you don’t need expensive software to do fit-for-purpose things. Building something out internally with Computer or other agentic tools is the right solution.”

“If you hire two people and tell them to do the same thing with agents, it’s going to be a mess. But if both have different responsibility areas, and each can manage a team of 10, 20, 100 agents, then absolutely hire that person right away. Especially if they’re curious and willing to manage an agent team.”

On confidence and decisions

“Things like territory carving and total addressable market used to take a headcount or two to really nail. Now I feel really confident in those decisions using AI.”

“The accuracy in search, and then the memory, makes it much more accurate.”

On the orchestration layer

“We’re the orchestration layer across 400 different tools. If there’s a very good tool for something, we want it to be agentic so we can make modifications and monitor it. We leverage the best of what each tool is built for, and orchestrate between them.”

“The connectors are a huge game changer, and it’s a flywheel. The better the tools get and the more accessible they are through agents, the better for us.”

On Voice of Customer

“Instead of needing a Salesforce admin or a data team to analyze whether something’s a first call, it parses that based on the context of the call itself.”

“The ‘what do we do about it’ has been the game changer. Sometimes viewing a dashboard isn’t really actionable.”

On the mindset shift

“The job of RevOps used to be: find the top two things to work on, stay focused, get them done. With agents, you can broaden that aperture.”

“In the time you tried to push back on a project, it could have been a version 1, completed, to see if it works.”

“We can run a lot more projects in parallel and test a lot more things, especially on the marketing side, with less resources.”

On managing agents like a team

“I asked all my skills and agents to do a daily standup: what did you work on, and what should you do better?”

“Every week I ask: where have projects stalled, and where should I focus that would have the biggest impact?”

On speed and accuracy

“A couple of minor inaccuracies about someone’s company or role can kill a deal early.”

“The monitoring is automated. That confidence, that we can change things quickly and we’ll catch the errors, makes it a lot easier to build fast.”

“It’s solving for organizational change and making that painless.”

“These last couple of months have been unbelievable. It’s a different world than it was a year ago.”

How Nate Thinks (the learnings)

1. Orchestrate, don’t replace. He doesn’t rip out his stack. He sits an agentic layer on top of 400 tools, uses each for what it’s best at, and orchestrates between them. The agent is the conductor, the tools are the orchestra.

2. “What should we do about it” beats any dashboard. A dashboard reports. Nate’s agents recommend: what the product team should build, what enablement should fix, what marketing should say. Insight without a next action is just decoration.

3. The buy-vs-build line moves every month. His test isn’t features. It’s “what works and what we can maintain.” Expensive software earns its place by depth and support. Everything else is a candidate to build fit-for-purpose. Nate still went out and grabbed Momentum.io because he knows the limits of what AI can or cannot do.

4. Accuracy plus memory is the moat. Tell the system once that “sellers” means the AE team, and every future answer gets sharper. Context compounds. Bad data breaks every agent downstream, which is why CRM hygiene runs nightly.

5. Broaden the aperture. Old RevOps protected focus by killing projects. New RevOps ships v1s. A version 1 is cheaper than the meeting where you debate whether to build it.

6. Manage agents like a team, with rituals. Daily standup with his agents. Weekly project triage. Zero-lead-leakage checks. The work shifts from doing the task to running the team that does it.

7. Hire for new surface area, not duplicate work. Two people pointed at the same agent-driven task = chaos. One curious operator running 100 agents on their own surface area = leverage. Hire the agent-managers.

8. Monitoring is what unlocks speed. The build wasn’t the hard part. The confidence to build fast came from an agent that DMs him every error, ranked by severity, with the fix attached. Safety nets make speed possible.

9. Most friction is internal. The thing slowing the team down usually isn’t the customer. It’s the internal process. Make organizational change painless and the team moves at a speed that looks unfair.

The Perplexity Computer RevOps Playbook

Build the 5 agentic workflows that let a Perplexity RevOps leader stop hiring and start orchestrating. Setup, exact prompts, and a 7-day rollout. Steal all of it.

Part 1: What Perplexity Computer actually is

Perplexity Computer is what they call a general-purpose digital worker. You give it a goal in plain English. It figures out the steps, picks the right tools, does the work, and hands you the finished thing. Most AI tools give you a summary or a plan you then go build yourself. Computer delivers the actual artifact: a built dashboard with a shareable link, a cleaned dataset with charts, a research report with citations, a finished deck.

Four things make it different from a normal chatbot, and all four matter for the workflows below.

It runs on many models, not one. Computer sits on top of 19+ frontier models and routes each piece of your task to the model best suited for it. Claude Opus handles the heavy reasoning and orchestration. Gemini runs deep research. Others handle long-context recall, images, and video. You write one prompt. It assembles the team. When one model is down or weak at something, it does not take you down with it.

It works in Tasks, not chats. A Task is a job, not a conversation. When you submit a prompt, an orchestrator breaks the objective into subtasks, assigns each to the right model, runs them in parallel, and compiles the result. You can start a Task, immediately start another, close your browser, and come back to both finished.

It remembers. Computer keeps context across sessions and learns your preferences and standard workflows. Tell it once that “sellers” means your AE team and “CS” means these five people, and every future question gets more accurate. Memory is also why continuing a Task is cheaper than starting a fresh one.

It runs on a schedule, asynchronously. Set a Task to run once, daily, weekly, monthly, or yearly at a trigger time. It runs in the cloud whether your machine is on or off. Each run saves a thread you can go back to. This is the feature that turns a one-time task into an employee who shows up every morning.

Pricing, so you can plan. Pro is $20/month with 4,000 credits. Max is $200/month with 10,000 credits. Enterprise Max is around $325 per seat per month with admin controls, custom connectors, and security and governance. Start on Pro to learn it. Move up when a workflow proves its value.

Part 2: The 30-minute setup that makes everything else work

Do not skip this. The people who say Computer is “just okay” almost always skipped the setup and then wondered why it felt generic. Three steps.

Step 1: Connect your tools

Connectors give Computer real read-and-write access to your actual data, not a summary of it. There are 400+ built in. The ones that matter for GTM:

• Salesforce and HubSpot for CRM data and actions

• Snowflake, BigQuery, or Databricks for your warehouse

• Slack for team comms and notifications

• Gmail and Google Calendar for inbox and meetings

• Your call recording tool (Gong, Momentum, Fireflies) by connector or API key

• Linear, Jira, or Asana for project status

Click Connectors in the sidebar, find the app, click Enable, complete the OAuth login. About a minute each.

If a tool you use is not in the list, you can still connect it. Provide an MCP (Model Context Protocol) server URL and Computer talks to your proprietary CRM, custom analytics server, or private API. This is exactly how Nathan connected his call recording tool: no native connector, just an API key and a shared skill that told Computer how to use it. Enterprise admins can share custom connectors across the whole org.

Step 2: Create your first Skills

A Skill is a saved set of instructions that auto-activates when Computer recognizes a matching task. Think of it as a job description you write once and never repeat.

Without Skills, you re-explain your brand, your formatting, and your reporting structure on every single task. With Skills, you explain it once and it sticks. Computer ships with built-in Skills for Slides, Research, Research Report, and Chart. To make your own: click Skills in the sidebar, click Create skill, and upload a .md file.

Skills stack. A research Skill can hand off to a report-formatting Skill, which hands off to a slides Skill. One prompt runs the whole pipeline.

My rule, stolen from Nathan: if you have explained the same thing to Computer twice, it should be a Skill.

Step 3: Set Custom Instructions

Skills fire for specific task types. Custom Instructions apply to every task, all the time. Keep them under 1,500 characters. The single most valuable one I have found, and the one that will save you the most money:

Always come back to me and clarify any misunderstandings, challenge my thinking to make sure you are clear on the stated outcome, and create a brief plan before you build anything.

That one line forces Computer to confirm what you actually want before it spends credits running the wrong job. Add your context too: who your team is, what “done” looks like, your tone, your no-go zones.

Part 3: How to not waste money (the credit economics)

Three habits separate people who love Computer from people who churn.

1. Continue Tasks, do not restart them. Continuing uses persistent memory and is always cheaper. Start a new Task only when the objective genuinely changes.

2. Control model routing on big jobs. By default Computer often reaches for the most capable, most expensive model. For routine work, tell it which model to use. Save the heavy reasoning models for the hard parts.

3. Make it plan before it builds. The custom instruction above is not just for quality. A clarifying question costs almost nothing. A wrong 2,000-credit Task costs a lot.

Treat credits like a budget and these workflows pay for themselves in the first week.

Part 4: The 5 workflows (copy the prompts)

Each one below has the same shape: what it does, why it matters, the exact prompt to build it, and how to schedule or share it. Swap in your tool names where I use brackets.

Workflow 1: Voice of Customer engine

What it does: Reads every sales call, tags the call type, surfaces the week’s themes, tells you what to do about each one, and finds your best champion quotes. Refreshes daily.

Why it matters: Your customers are handing you your roadmap and your messaging on every call. The only thing that ever stopped you from using it was the hours. Computer removes the hours.

Build prompt:

You have access to my [call recording tool] via the connected API key and to Salesforce. Build me a Voice of Customer dashboard that refreshes daily.

Steps:

1. Pull all call transcripts from the last 7 days. Use Salesforce to enrich each call with account name, deal stage, and the title of who we met with.

2. Auto-tag each call as a first/discovery call or a follow-up based on the content of the conversation, not a CRM field.

3. Group what you find into these sections: Pricing and packaging, Feature requests, Objections and risks, Positive signals and champions, Rollout and use cases.

4. For each theme, write: (a) the key takeaway in one line, (b) 2 to 3 exact customer quotes with the account name, (c) what the product team should do about it, (d) what enablement or marketing should build.

5. Output as a clean dashboard with a shareable link. Remember that “sellers” means my AE team and “CS” means my customer success team for all future questions.

Then turn it into a daily Task: “Run this every weekday at 7am and post the summary to our #voice-of-customer Slack channel.”

Bonus, the move that wowed me: Add a second prompt. “From this week’s calls, pick the 20 strongest customer quotes, pull the video clips, and edit a 2-minute sizzle reel with background music.” Computer has video models built in, so it can actually produce the reel.

Workflow 2: The weekly deck that builds itself

What it does: Builds your recurring meeting deck end to end. Pulls live data, chases stale inputs, and assembles the slides on a schedule.

Why it matters: Reporting is the tax your ops team pays to do its real job. This stops the bleeding of an hour or more every week, per recurring meeting.

Build prompt:

Build me a weekly RevOps go-to-market deck and save it as a reusable Skill called “Weekly Deck Prep.”

Each run should:

1. Pull current pipeline and revenue numbers from [Snowflake/Salesforce]. Include month-over-month and week-over-week trends.

2. Scan these Slack channels for project updates: [#channel-1, #channel-2]. Decide which updates the whole team needs to see and summarize them by project.

3. Pull open and recently closed items from [Linear/Jira] for a quick burndown.

4. Post a message to #sales-team asking reps to update any stale in-month pipeline and to reply in thread with anything they want included in the deck.

5. Set a cron job to re-check that thread 24 hours later and fold their replies into the final deck.

6. Build the deck in our format: title slide, pipeline summary, trends, project status, risks, asks. Output slides with a shareable link.

Schedule it: “Run Weekly Deck Prep every Thursday at 8am.”

Workflow 3: Nightly CRM hygiene plus an error-watcher

What it does: Cleans your CRM on a nightly batch instead of brittle real-time automations, and DMs you any errors with severity and a fix.

Why it matters: Bad data quietly breaks every other agent you build. And the real unlock Nathan named was confidence: he builds fast because he trusts the system to catch its own mistakes.

Build prompt (hygiene):

You have access to Salesforce. Every night, run a CRM hygiene job and report what you changed.

1. Check account ownership against our rules of engagement: [paste your ROE in plain English]. Reassign accounts to the correct owner based on logged activity, so the rep actually emailing an account owns it.

2. Validate account hierarchies and flag or fix mismatched domains and contacts.

3. For anything you cannot safely auto-fix, list it for my review with the recommended action.

4. Prefer a clean batch approach over real-time triggers. If we need data moved between systems, use [Polytomic/Hightouch] and tell me what you set up.

Build prompt (the watcher, this is the trust layer):

Create a monitoring Skill. Every morning, scan my key Slack channels and my inbox for errors, failed syncs, and broken automations. DM me a single summary ranked by severity (critical, high, low). For each issue, include what broke, where, and the exact steps to fix it.

Schedule both: hygiene nightly, watcher each morning before you log on.

Workflow 4: Pre-call prep that flips discovery

What it does: Before every meeting, sends you a one-pager on who you are meeting, why they care, and what to show them.

Why it matters: A couple of small inaccuracies about someone’s role or company can kill a deal early. Accurate prep, done for you, means you walk in already halfway through discovery.

Build prompt (save as a Skill called “Pre-Call Prep”):

Each morning, scan my Google Calendar for today’s external meetings. For each one, use Salesforce, the web, and LinkedIn to build a one-page brief and DM it to me as a PDF.

Include: who I am meeting and their role, their company and what they do, recent news or signals, the deal context from Salesforce, the 2 to 3 use cases that land best for someone in their role, what to make sure I mention, and one genuine personal connection point if you can find one.

Schedule it: “Run Pre-Call Prep every weekday at 7:30am.”

Workflow 5: The daily agent standup and weekly project triage

What it does: Your agents report to you. Each day they tell you what they did and where they are stuck. Each week they tell you where projects stalled and what to focus on for the biggest impact.

Why it matters: This is the actual mindset shift. You are not doing the work anymore. You are managing a team that happens to be made of agents. You need a standup just like you would with people.

Build prompt (daily):

Every morning, have my active Skills and scheduled Tasks report a standup: what each one worked on yesterday, what it completed, what it is stuck on, and one thing it could do better. Then read my Slack and email and suggest where I should add a new agent or Skill to remove a bottleneck.

Build prompt (weekly):

Every Friday, review my core Slack channels and project tools and tell me: where have projects stalled, where is work getting dropped, and what are the 3 things I could focus on next week that would have the biggest impact on revenue and the team. Also run a zero-lead-leakage check: which leads or deals need follow-up and have gone quiet.

Schedule both. This is the closest thing to a chief of staff you can buy for the price of a Pro seat.

Part 5: Turn any workflow into a shareable Skill

The reason this compounds is that good workflows get shared. A Skill is just a Markdown file. Here is a template you can paste, edit, and upload under Skills > Create skill.

# Skill: [Name]

## When to use
[Describe the trigger. Example: "When I ask for a weekly RevOps deck
or it is Thursday morning."]

## Inputs and tools
- Salesforce (accounts, opportunities, activities)
- Snowflake (revenue tables)
- Slack channels: #channel-1, #channel-2

## Steps
1. [First step, be specific]
2. [Second step]
3. [Output format and where to deliver it]

## Rules and definitions
- "Sellers" = the AE team
- "CS" = customer success
- Always confirm the plan before building
- Output format: [dashboard / PDF / slides / Slack message]

## Done looks like
[One or two sentences describing a great result.]

Write it once. Share it with your team. Now everyone’s “rockstar rep workflow” is everyone’s workflow.

Part 6: Your 7-day rollout

You do not boil the ocean. You build one thing a day.

• Day 1: Set up Pro. Connect Salesforce, Slack, your warehouse, and your call tool. Write your Custom Instructions (use the clarify-and-plan line).

• Day 2: Build Workflow 4 (Pre-Call Prep). It is the easiest win and you will feel it in tomorrow’s meetings.

• Day 3: Build Workflow 1 (Voice of Customer). Let it run once, then refine the sections.

• Day 4: Build Workflow 3’s watcher (the error monitor). Trust comes before automation.

• Day 5: Build Workflow 2 (Weekly Deck). Point it at your real meeting.

• Day 6: Build Workflow 5 (the standup). Meet your team of agents.

• Day 7: Turn your two best builds into shared Skills using the template above. Send them to one teammate.

Seven days. Five workflows. One genuinely different way of working.

My challenge to you

You do not have to believe agents will run RevOps. You just have to test it once. Pick the single workflow above that would save you the most time this week and build a v1 today. Not a perfect version. A v1. You will learn more in one hour of building than in a month of reading takes about AI.

The companies that learn to orchestrate this year will move at a speed that looks unfair to everyone else. The ones that wait will spend next year trying to catch up to a team a tenth their size.

So here is my challenge to you: build one. This week. Then come tell me what you made.

I hope this saves you the hours it saved Nathan. Go build something.

mk? mk.

Coach

Sources

• Everything is Computer (Perplexity)

• Computer for Enterprise (Perplexity)

• Perplexity takes its ‘Computer’ AI agent into the enterprise (VentureBeat)

• I Tested Perplexity Computer for Weeks: The PM Playbook (Aakash Gupta)

• Perplexity Computer Slack Integration (Slack Marketplace)

• How We Built Security Into Computer (Perplexity)

But “connect Claude Code to Salesforce” isn’t one setup. It’s four, and the right one depends on whether you’re a solo analyst poking at a sandbox or a RevOps leader wiring an agent into production. This guide walks all four, with copy-paste steps for each.

Prefer to click through it step by step? I built an interactive version that remembers what you’ve checked off, with copy buttons on every command:

Read more

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

As a reminder, we have a TON of free options for you to subscribe to:

GTM AI podcast and newsletter with associated assets, apps, AI tools, etc

We also have Signal vs Noise which is more of a short and to the point update that is important for you to know.

On the paid side, we go DEEP on new AI tools, deep dives on how to use tech, and give you up to date education for GTM pros on how to use AI in your role. We would love for you to subscribe on any level that best for you.

Subscribe now

Free or Paid, regardless of what you want to do, we will always shower you with as much valuable content as possible. Now lets get into it

You can go to Youtube, Apple, Spotify as well as a whole other host of locations to hear the podcast or see the video interview.

One of Fluint’s customers recently watched their top sales rep walk out the door. The same rep who personally closed a $30 million land contract. The single largest deal ever closed using their product. Two weeks notice. Gone.

Every signal that rep read before anyone else. Every implicit cue from a procurement email. Every gut-feel decision on when to hold ACV versus when to discount. All of it walked out with him.

This is the most expensive problem in enterprise sales right now, and I do not see it discussed honestly enough. So this week, I sat down with Nate and John, co-founders of Fluint, on the GTM AI Podcast. Nate is a repeat enterprise sales leader. John is the technical co-founder who built the architecture that captures what Nate could never document.

What came out of the conversation is, I think, the cleanest take I have heard on how to actually solve the “clone your top rep” problem after 15 years of GTM tech promising and never delivering. Four insights worth your attention.

1- The implicit signal example that explains everything

Nate gave this example, and I have not stopped thinking about it.

A rep runs two POC readouts on the same Friday. Two different prospects. Two procurement teams. Team A’s procurement emails the rep back at 9pm Friday night. Team B’s procurement says “we will keep this moving next Wednesday during business hours.”

Same outcome on paper. Both are “moving forward.” Both get coded the same in the CRM. But a top rep is going to negotiate completely differently in those two scenarios. Team A is screaming urgency. The exec could not wait. Friday 9pm follow-up means do not discount, they need this now. Team B is a normal business cadence. You can afford to play the commercial game.

Here is the issue: nobody trained the rep to read that signal. They picked it up over a decade of pattern matching. They cannot tell you they’re doing it. And every average rep on the team would miss it entirely, walk into Team A’s negotiation, and start discounting on instinct.

“That rep who reads that, they’re gonna hold onto ACV at the finish line versus somebody else is gonna miss that signal. So the question is, how do you capture that with AI?” Nate, Fluint

The implicit-signal example is the thesis of the whole episode. Tacit knowledge is the unfair advantage of your top reps. And until now, nobody has had a way to capture and redistribute it.

2- The photo vs. video architecture (the shrimp tacos moment)

This is where John, the technical co-founder, walked through the architectural decision that makes Fluint different from every other AI sales tool I have evaluated.

The conventional approach to AI agents is to give an LLM a giant context window: the CRM record, the call transcript, the email thread, all of it stuffed into one prompt. The agent then produces a summary or recommendation.

Nate’s framing for why this fails:

“Anytime you’re giving an LLM context, it’s like a snapshot. It’s like a photo, and it can write something. Think of it like a caption. A video file is gigabytes worth of data, and the whole meaning of a video comes from the motion in between those frames.” Nate, Fluint

Top reps do not pattern-match on photos. They pattern-match on motion over time. What was the deal doing 30 days ago vs. today? When the prospect went quiet for 4 days and then sent a flurry of emails about pricing, what did that combination mean? The signal lives in the change, not in any single moment.

Fluint’s architecture is event-driven and time-series-based. Every interaction gets tagged, timestamped, and stored so the system can reconstruct the motion of a deal, not just its current state. That is what lets ML models pick up patterns that no LLM-with-big-context-window can.

If you are evaluating AI sales tools right now, this is the single question to ask vendors: “Are you snapshot-based or time-series-based?” Most will not understand the question. Move on from those vendors.

3- AI is not LLMs. ML + LLMs is the actual stack.

John dropped a line that I want every GTM leader to internalize:

“LLMs are like a subcategory of AI which is a subcategory of machine learning. So it’s just this small little sliver of everything that we’re doing.” John, Fluint

The entire industry right now talks about “AI” when they mean “LLMs.” Those are not the same thing. ML has been solving pattern-recognition problems for decades. LLMs are good at human-to-human interaction and language generation. They are bad at retaining state across long conversations and bad at picking up subtle pattern shifts in large datasets.

John’s analogy for why LLMs alone cannot do this work:

“Have you ever seen the movie Fifty First Dates? There’s 10-Second Tom. ‘Hi, I’m Tom. Hi, I’m Tom.’ That’s what an LLM is good at. You have a very short window of time to talk to me before you lose everything that’s there.” John, Fluint

Fluint uses ML to do the pattern recognition (the judgment layer) and then passes the structured output to an LLM for the human-facing communication. Using the right tool for the right job.

This is the architectural decision that separates real enterprise AI from prompt-wrapped novelty. If your AI strategy is “we use ChatGPT and call it AI,” you have not built anything. If your AI strategy is “we use ML to capture pattern signals, then LLMs to communicate them to humans,” you have an actual system.

4- The “no perfect data” answer that ends the AI readiness debate

Nate asked John the question every GTM leader is asking themselves right now: “What if our data is too messy to start? Should we wait?”

John’s response was the cleanest answer I have heard:

“Data is a product of people. Humans are imperfect by nature. So it’s a logical fallacy that you could have perfect data because its originating source is imperfect. If you know what’s wrong with your data, that’s how you use it. That’s what turns it into knowledge.” John, Fluint

Then he walked through the racehorse model, which is genuinely smart. Fluint runs two models in parallel for every customer: a global baseline model trained on aggregated industry patterns, and a customer-specific model trained on that customer’s data. The two race nightly. Whichever produces better predictions on nearest-neighbor analysis gets promoted that day. The custom model wins eventually as it accumulates training data, but the customer gets value from day one because the global model is already trained.

The implication for your team: stop using “our data is not clean enough” as an excuse to not deploy AI. The data is never clean. The question is whether your tooling knows how to work with imperfect input. If the answer is yes, ship. If the answer is no, you need different tooling.

Real outcomes

Three numbers from the episode worth memorizing:

• +$28K added to ACV per team per year (average, enterprise context)

• 32 days trimmed off median sales cycle time

• Maturity curve: Q1 = win existing deals with less discount, Q2 = compress cycle times, Q3+ = win deals you would have lost

That progression matters. Most teams want AI to deliver Q3 results in week 2. Fluint’s curve says the highest-leverage wins happen second half of year one, after the model has had time to learn your patterns. Set expectations accordingly.

Why this matters more than usual right now

Every enterprise sales team is sitting on a hidden time bomb. Your top reps’ tacit knowledge represents the difference between 17% win rates and 50% win rates. None of it is documented. None of it is in the playbook. All of it walks when they take a recruiter call.

The teams that capture it first will compound their advantage every quarter. The teams that don’t will keep paying $5K to $50K per opportunity to generate pipeline that average reps then squander at half the win rate of their top performers.

This is the actual GTM AI play of 2026. Not “automate the BDR sequence.” Not “summarize the call.” Capture the tacit knowledge before it walks out the door.

My challenge to you this week

1- Name your top rep. Out loud, on paper, by name. 2- List 3 things that rep does that no one else on the team does. 3- If you cannot list the 3 things, that is the audit failing in real time. Start a 30-minute conversation with that rep this week. Ask them to walk you through their last 3 deals. Capture what they say.

That’s the smallest possible first step toward solving this. The full 5-step protocol is in this week’s free field guide: The Tacit Knowledge Audit below:

I hope this lands. More to come next week.

The Tacit Knowledge Audit

A 5-step protocol to capture what your top sales reps do unconsciously, before they leave.

A GTM AI Academy field guide. Inspired by my podcast conversation with Nate and John, co-founders of Fluint.

A few weeks ago, one of Fluint’s customers lost their top sales rep. He personally closed a $30 million land contract for them. The largest deal ever closed using the product. He gave two weeks notice and walked.

Every signal he caught before anyone else. Every implicit cue from a procurement email. Every gut-feel decision on when to hold ACV and when to discount. All of it walked out with him.

If you have led a sales team for more than two years, you have lived this moment. The recruiter call you saw coming. The exit interview where the rep tried to put it into words. The 90 days after, where the team’s win rate quietly dropped and nobody could quite say why.

This is the most expensive problem in enterprise sales right now. And almost nobody is solving it honestly. Most playbooks, enablement programs, and “AI for sales” tools attack the wrong layer. They try to document the explicit. They cannot get at the tacit.

I sat down with Nate and John of Fluint on the GTM AI Podcast this week. Nate is a repeat enterprise sales leader. John is the technical co-founder who built the architecture that actually captures what Nate could never document as a leader. What I learned from them, combined with my own pattern-matching across 13 years in enablement, became this 5-step audit.

This is the test I now run on every enterprise sales team I work with. Whether you are a CRO, a VP of Sales, a head of enablement, or a founder selling your own product, the 5 steps below give you a defensible read on how much of your top performers’ knowledge is captured vs. how much is one resignation letter away from gone.

Let’s go.

Why this matters more than it sounds

A small pocket of reps wins 50 to 60 percent of their pipeline. Everyone else sits at 17 to 19 percent. Same product. Same comp plan. Same playbook. The math is not subtle.

The difference is not training. Not coaching. Not effort. Not even talent in the abstract sense. The difference is tacit knowledge: the unconscious patterns top performers cannot even articulate. They just do things. The signal is invisible to them because it has been automated by their brain over a decade of reps.

Nate gave this example on the podcast, and it is the cleanest illustration of tacit knowledge in sales I have ever heard:

A rep runs two POC readouts on the same Friday. Two different prospects. Two procurement teams. Team A’s procurement emails the rep back at 9pm Friday night. Team B’s procurement says “we will keep this moving next Wednesday during business hours.”

Same outcome on paper. Both are “moving forward.” Both get coded the same in the CRM. But a top rep is going to negotiate completely differently in those two scenarios. Team A is screaming urgency. The exec could not wait. Friday 9pm follow-up means do not discount, they need this now. Team B is a normal business cadence. You can afford to play the commercial game.

That signal lives in a 4-hour timestamp difference on a procurement email. No CRM field captures it. No playbook explains it. No call transcript will surface it. A top rep notices it without thinking. An average rep walks into Team A’s negotiation and starts discounting because “the deal moved forward.”

The cost of that single missed signal across a year is six figures of leaked ACV per rep. Multiplied across your sales org, it is the difference between hitting plan and missing it.

Tacit knowledge is the unfair advantage of your top reps. It is the moat under your revenue. And until very recently, nobody had a way to capture and redistribute it.

That is changing. But the change requires you to do the audit first.

The 5-step Tacit Knowledge Audit

Each step has three parts: the question, the diagnostic test, and the action. Work through them in order. Do not skip ahead. Each step assumes the previous one is complete.

Step 1: Name the top rep, list the three things

The question: Can you name your top performer and list three specific things they do that no one else on the team does?

The diagnostic test: Right now, out loud, name the rep. Then write down three behaviors. Not “they’re great at discovery” (too vague). Closer to: “They always email the buying committee individually after a group call with one specific personalized observation about their function.”

If you cannot list three specific behaviors within 60 seconds, you have not actually been studying your top rep. You have been admiring them.

The action: Schedule a 30-minute call with the rep this week. Frame it not as a review but as a curiosity conversation. “I want to understand how you think about deals.” Take notes. Look specifically for the things they do that they think are “obvious.”

The 30-minute curiosity conversation script:

Most leaders skip this conversation because they do not know what to ask. Use this script verbatim. Adjust as needed.

Opening (2 minutes):

“I want to spend 30 minutes understanding how you think, not how you execute. The whole team learns from you whether you realize it or not, and I want to make sure I am capturing the right things to teach the rest of the team. There are no wrong answers. I am taking notes.”

Question 1 (5 minutes):

“Walk me through the last deal you closed. Not the highlights. The texture. When did you first sense it was going to close? Was there a specific moment? What did you see?”

Question 2 (5 minutes):

“Walk me through the last deal you lost or stalled. Same question. When did you first sense it was going sideways? What was the signal you wish you had acted on sooner?”

Question 3 (5 minutes):

“When a buying committee goes quiet for a week, what do you usually do? Walk me through your decision tree out loud.”

Question 4 (5 minutes):

“Tell me about a deal where your gut told you one thing and the playbook told you another. Which one did you follow? What happened?”

Question 5 (5 minutes):

“If I gave you one new rep to onboard, and you only had 60 minutes to teach them one thing that would make them better, what would it be? Why?”

Closing (3 minutes):

“Last question. If you left tomorrow, what is the one thing I would lose access to that I would not even know I had lost? That is the thing I most need you to help me capture.”

Take notes by hand or recording (with their permission). Do not edit during the conversation. The goal is capture, not synthesis. Synthesize after.

Why this is step 1: Everything that follows depends on you having a specific, observed top rep to anchor on. Without that, you are doing enablement in theory. With it, you are doing enablement with a target.

Step 2: Find the implicit signals

The question: What signals does your top rep notice that the rest of the team misses?

The diagnostic test: Pull the call recordings, email threads, and CRM updates from your top rep’s last three closed deals. Then pull the same artifacts from your average rep’s last three deals (won or lost). Read them side by side.

You are looking for moments where the top rep’s behavior changed because of a signal that is not in any structured field. Examples:

• The procurement timing example above

• A buying committee member who went silent for a week, then suddenly engaged with a specific question

• A champion who started cc’ing a different stakeholder on follow-ups

• A delay in a follow-up that was framed as “scheduling” but actually meant internal misalignment

The top rep responds to these. The average rep does not see them.

The action: Document at least 5 implicit signals your top rep responds to. For each one, write down: what the signal looks like, what the top rep does in response, what the average rep does instead, and what the financial consequence is of missing the signal.

Why this is step 2: This is where the explicit playbook breaks down. The signals top reps catch are not in any documented process because nobody could see them well enough to document them. Once you list them out, you have created your first “tacit-to-explicit” translation. That is real enablement IP.

The 5 most common implicit signal patterns (a starter library):

These are the patterns I see top reps catch over and over again, across industries, across deal sizes. Use this list as a starter. Add your own as you find them.

1- The timing tell. Procurement responds at 9pm Friday vs. next Wednesday. A champion who normally replies within 4 hours suddenly takes 36. A buyer who emails on weekends. Time-of-response carries information the content does not.

2- The CC pattern shift. Your champion was cc’ing two people. Now they are cc’ing four. Or: a new name appears on the thread without explanation. Or: a previously-cc’d executive drops off. Each shift means something. Top reps notice the change, not just the current state.

3- The vocabulary drift. A buyer who used “we are evaluating” suddenly says “when we go live.” Or the reverse: “this looks great” becomes “we have some concerns.” Top reps track linguistic shifts. The words change before the deal status does.

4- The post-call silence gap. Top reps know what “normal silence” looks like after each meeting type. 24 hours of silence after a demo is fine. 48 hours of silence after a pricing conversation is bad. The expected gap is contextual. The deviation from the expected gap is the signal.

5- The reverse pull. When a buyer starts asking questions YOU should be asking (”How quickly can your team implement?” “What does onboarding look like?” “Who is our day-one contact?”), the deal has shifted. Average reps answer the questions. Top reps recognize the shift and accelerate.

Add these to your own pattern library. Each one represents tacit knowledge that has been made explicit. The act of writing them down is the audit producing IP.

Step 3: Capture the motion, not the moment

The question: Are you capturing how your deals change over time, or just where they are right now?

The diagnostic test: Open your CRM. Look at a current deal. Can you reconstruct what happened in week 1 vs. week 4 vs. today? Can you see the motion of the deal, or only its current state?

For most teams, the answer is “current state only.” Stage changes are tracked, but the texture of how a deal moved through those stages is gone. CRM snapshots overwrite each other.

This is the same problem Fluint’s John talked about on the podcast. As he put it:

“Anytime you’re giving an LLM context, it’s like a snapshot. It’s like a photo. A video file is gigabytes worth of data, and the whole meaning of a video comes from the motion in between those frames.”

Top reps pattern-match on motion. They notice that a deal that took 3 weeks to get to demo and then closed in another 2 weeks behaves completely differently from a deal that took 6 weeks to get to demo and then sat for a month. Average reps look at the current stage and assume.

The action: Pick one deal type (e.g., enterprise renewals, or new-logo mid-market). For that deal type, define 5 to 7 events that should always be captured with a timestamp: first meeting booked, demo run, ROI doc shared, mutual action plan signed, procurement engaged, security review opened, contract sent, signed. Then capture them. Even in a spreadsheet at first.

Once you have the motion data, you can start asking “what did the average winning deal look like at week 4?” and use that as a guide.

Why this is step 3: You cannot capture tacit knowledge from snapshot data. The signal lives in the change between frames. If your data infrastructure is photo-based, you have already lost the most valuable inputs.

Step 4: Build the feedback loop into the daily workflow

The question: When your top rep does something brilliant on a deal, how does the rest of the team learn from it within a week?

The diagnostic test: Think about the last time your top rep did something unusual on a deal that worked. (Not a documented best practice. A nuanced judgment call.) How did the rest of the team find out about it?

For most teams, the answer is: they didn’t. Or they heard about it in a deal review weeks later. Or they noticed it once in a shadow session. The institutional knowledge transfer rate is approximately zero in real time.

This is where Fluint’s “Ollie deal room” approach is worth borrowing even if you do not use their tool. They run a public Slack channel where every morning their AI surfaces deal changes across the team: who used what move on what deal, what worked, what is stuck. It is the public ledger of tacit knowledge being captured and redistributed in real time.

The action: Pick one of these three minimum-viable feedback loops and run it for 30 days:

1- The Friday “moves of the week” Slack post. Every Friday, the sales leader posts 3 specific nuanced moves a rep made that week that the rest of the team should learn from. Name names. Show emails. Show the outcome.

2- The weekly 15-minute “weird deal” review. Each rep brings the one deal that had a weird inflection point this week. The group spends 15 minutes pattern-matching across the cases.

3- The “what would top rep do” spot check. When a deal hits a known inflection point (e.g., procurement involved), the rep posts the situation in a Slack channel and asks: “What would Cora do here?” Top rep responds in writing. Knowledge captured.

Any of these beats zero. All of these compound.

Why this is step 4: The capture is meaningless without redistribution. Tacit knowledge does not transfer through documentation alone. It transfers through proximity to people doing it, made visible.

Step 5: Stop waiting for clean data

The question: What is the excuse you have used most often for not building the system above?

The diagnostic test: Be honest with yourself. Did “our CRM data isn’t clean enough” come up in your head while reading steps 3 and 4? Did “we need to wait until RevOps finishes the data project” come up?

If yes, John’s answer from the podcast is your answer:

“Data is a product of people. Humans are imperfect by nature. So it’s a logical fallacy that you could have perfect data because its originating source is imperfect.”

Perfect data does not exist and will not exist. The question is not whether your data is clean. The question is whether you are doing something useful with what you have.

The best AI sales tools in 2026 are built on top of imperfect, human-generated data. They use ML to find signal in noise. They get smarter with use. Fluint’s racehorse model (a global baseline and a customer-specific model racing nightly, the winner promoted) is one example of how modern systems handle imperfection by design.

The action: Pick the single highest-leverage tacit knowledge capture (from steps 1 through 4) you have been delaying. Ship a v1 of it this week. Imperfect, ugly, partial. Ship it.

The reason: every week you wait for clean data is a week your top rep is closer to leaving. The cost of “let’s wait” is the brain drain you cannot recover from.

Why this is step 5: The audit is only useful if it ends in action. Most audits end in a slide deck. This one ends in a Friday Slack post, a 30-minute conversation, or a spreadsheet you started today. Choose action.

Scoring the audit

Score yourself 1 (not at all) to 5 (fully done) on each step:

Step Description Score (1-5) 1 Named top rep + 3 specific behaviors 2 Documented 5+ implicit signals 3 Capturing motion (event-driven), not just snapshots 4 A weekly tacit-knowledge feedback loop running 5 Shipped a v1 of capture without waiting for clean data TOTAL /25

20-25: You are ahead of 95% of GTM teams. Keep going. Layer on AI tooling that thinks in time-series (like Fluint or comparable architectures).

14-19: You have the right instincts but the system is incomplete. The most common failure mode in this range is good capture, weak redistribution. Fix step 4.

8-13: You are doing pieces but not the system. Most likely you have a top rep you admire but have not formalized any of the capture. Run step 1 this week.

Under 8: Your top rep is one resignation away from a quarter of pain. Start with step 1 today.

5 anti-patterns that kill tacit knowledge capture

I have seen these failure modes more times than I can count. Each one looks reasonable in isolation. Each one quietly sabotages the work.

1- Treating it as a one-time project, not a system. “We are going to capture tacit knowledge in Q2” never works. The capture has to be embedded in the weekly cadence (deal reviews, Slack posts, retrospectives) or it dies the moment the project sponsor moves on.

2- Capturing without redistributing. Some teams do excellent capture (transcripts, recordings, deal review notes) and then no one ever reads any of it. Capture without redistribution is a graveyard. The Friday Slack post or the 15-minute weekly review is what makes capture into transfer.

3- Asking your top rep to “write it up.” Top reps cannot articulate their tacit knowledge in writing. That is the entire definition of tacit. If you ask them for a “best practices doc,” you will get generic advice. You need conversation, observation, side-by-side review of actual artifacts. Then YOU write it up.

4- Letting the top rep become the bottleneck. Once you start using the top rep as the source of truth for everything, you have made the brain-drain problem worse, not better. The whole point is to distribute what they know across the team faster than they could ever do it themselves.

5- Mistaking explicit playbooks for tacit knowledge transfer. A 60-page sales playbook with everyone’s favorite frameworks is not what we are talking about. Tacit knowledge transfer is “Cora pinged the CFO on Wednesday after her champion went silent for 4 days, and the deal moved.” Specific, named, in-context, recent. The 60-page playbook is what teams produce when they are afraid to do the actual work.

If you find your audit work drifting toward any of these patterns, stop and re-center. The point is transfer, not artifact creation.

The 90-day implementation roadmap

You do not need a quarterly project plan to do this work. You need a 12-week cadence. Here is the calendar-ready version.

Weeks 1-2: Foundation

• Week 1: Run step 1. Name top rep + 3 behaviors. Schedule the 30-minute curiosity conversation. Do step 5: pick the one thing you have been delaying and ship a v1 this week (could be a Slack post template, a deal review structure, a shared notes doc).

• Week 2: Run the curiosity conversation. Take notes by hand. Within 24 hours of the conversation, write down 5 things you heard that you did not know before.

Weeks 3-4: Signal capture

• Week 3: Run step 2. Pull artifacts from your top rep’s last 3 wins and your average rep’s last 3 deals. Read side by side. Document 5 implicit signals.

• Week 4: Share the 5 implicit signals with the whole sales team in a Friday Slack post. Frame them as “things Cora notices that you might be missing.” Watch which signals generate the most discussion. Those are the ones to double-click on next.

Weeks 5-6: Motion infrastructure

• Week 5: Run step 3. Pick one deal type. Define 5-7 events that should always be captured with timestamps. Even if you have to do it in a Google Sheet, do it.

• Week 6: Start backfilling for the last 30 days of deals in that type. You are building a time-series record by hand. Painful but irreplaceable.

Weeks 7-8: Redistribution rhythm

• Week 7: Run step 4. Launch one of the three feedback loops (Friday “moves of the week” Slack post, weekly 15-minute “weird deal” review, or “what would top rep do” Slack channel).

• Week 8: Run the loop a second week. Pay attention to who engages and who does not. Engagement is your leading indicator.

Weeks 9-10: Pattern library

• Week 9: Synthesize what you have captured. Build a “pattern library” of 10-15 tacit knowledge moves with concrete examples. This is internal IP. Treat it like product.

• Week 10: Run a 30-minute team session walking through the pattern library. Have your top rep validate each pattern in their own words.

Weeks 11-12: Tooling decision and re-score

• Week 11: With 10 weeks of pattern data in hand, evaluate AI tools that fit the architecture you have built (time-series, event-driven, ML + LLM stack). Avoid snapshot-only tools regardless of how good the demo looks. Reference the podcast for the architectural questions to ask vendors.

• Week 12: Re-run the audit (score yourself out of 25). Compare to your starting score. Decide what to focus on for the next 90 days.

This roadmap is opinionated. Adapt it to your team’s reality. The key principle: do not skip step 1, do not delay step 5, and do not let any week pass without something concrete shipping.

Three things to do today

If this audit lands and you want to move on it without overcomplicating, do these three things in this order:

1- Today: Name your top rep. Write down 3 specific behaviors they do that no one else does. Time-box this to 15 minutes.

2- This week: Schedule the 30-minute curiosity conversation with that rep. Use the script above. Take notes specifically on what they describe as “obvious.”

3- By month end: Pick one of the three feedback loops from step 4 and run it for 30 days.

That is it. You do not need new tooling. You do not need a budget approval. You do not need a board sign-off. You need 90 minutes and the willingness to ask better questions.

The bigger picture

The next 18 months of enterprise sales will be won by teams who solve two things at once: capturing the tacit knowledge of their top reps before it walks, and building feedback loops fast enough that the rest of the team gets better in days, not quarters.

Most teams will not do either. They will keep paying $5K to $50K per opportunity to generate pipeline that average reps then squander at half the win rate of their top performers. They will keep losing $30M-deal-closers to recruiters. They will keep wondering why “AI for sales” has not delivered the productivity gains the keynotes promised.

The teams that move first on this will compound their advantage every quarter. By 2027 it will look like luck. It will not be luck.

My challenge to you this week

I want you to do one thing.

Name your top rep, out loud, by name. Then list three things they do that no one else on your team does. Be specific. Not “great at discovery.” Closer to: “They always send a personalized note to each buying committee member individually within 4 hours of a group call, referencing a specific question that person asked.”

If you cannot list three specific things in under 5 minutes, that is the audit failing in real time. That is your top rep’s brain being closer to walking out the door than you realized.

The good news: now you know. You can start the conversation today.

I hope this lands. If you do the exercise and want a second opinion on what you wrote down, reply to this post and I will read it. The point of the audit is what comes next, not the score itself.

If this field guide helped, the highest-leverage thing you can do is share it with the one sales leader on your team who is making AI roadmap decisions this quarter. Forward the email. Drop the link in your Slack. The point of an audit is that more people run it.

Subscribe to get the next field guide in your inbox. Listen to the full Nate and John episode on the GTM AI Podcast wherever you get your podcasts. And if you want to go deeper on the architecture (event-driven, ML + LLM stack, racehorse model evaluation), John’s recent blog post at fluint.io/blog is the technical companion to this strategic piece.

Appendix: Printable one-page scorecard

Print this section, take it into your next leadership team meeting, fill it out together.

THE TACIT KNOWLEDGE AUDIT  ·  SCORECARD
═══════════════════════════════════════════════════════════
Date: _________________________   Team / Org: _________________________
Scored by: _________________________

TOP REP NAME: _________________________

3 THINGS THIS REP DOES THAT NO ONE ELSE DOES:
1) _____________________________________________________________
2) _____________________________________________________________
3) _____________________________________________________________

───────────────────────────────────────────────────────────
SCORE EACH STEP 1 (NOT AT ALL) TO 5 (FULLY DONE)
───────────────────────────────────────────────────────────

STEP 1  Named top rep + 3 specific behaviors           [   /5]
STEP 2  Documented 5+ implicit signals                 [   /5]
STEP 3  Capturing motion (event-driven), not snapshots [   /5]
STEP 4  Weekly tacit-knowledge feedback loop running   [   /5]
STEP 5  Shipped v1 without waiting for clean data      [   /5]
                                            ─────────────────
                                            TOTAL  [   /25]

───────────────────────────────────────────────────────────
VERDICT
───────────────────────────────────────────────────────────

[ ] 20-25  Ahead of 95% of GTM teams. Layer on time-series AI.
[ ] 14-19  Right instincts, incomplete system. Fix step 4.
[ ] 8-13   Doing pieces, not the system. Run step 1 this week.
[ ] <8     Top rep is one resignation away from brain drain.
           Start step 1 TODAY.

───────────────────────────────────────────────────────────
3 ACTIONS, NEXT 4 WEEKS
───────────────────────────────────────────────────────────

THIS WEEK:    _____________________________________________
NEXT 2 WEEKS: _____________________________________________
BY MONTH END: _____________________________________________

───────────────────────────────────────────────────────────
RE-SCORE DATE (90 days out): _________________________
───────────────────────────────────────────────────────────

The Tacit Knowledge Audit  ·  GTM AI Academy  ·  Coach K

Save the filled scorecard. In 90 days, re-score and compare. The delta is your audit’s ROI.

I knew you were hankering for some more GTM AI goodness… I could feel it in my brazen psyche.. there you were, on your phone or laptop.. refreshing every few moments for this email and newsletter to arrive.

Well no more waiting for BEHOLD! It is time!

Today we have Julia Macdonald the SVP of GTM and AI Solutions at Haize Labs and probably one of the most brilliant and kind individuals I have met.

As usual, this podcast and the goodies along with it are always free and we would love your feedback of any topic you want covered from the vast network of amazing people we know.

Please subscribe and share with your peeps

Subscribe now

Let do it…

You can go to Youtube, Apple, Spotify as well as a whole other host of locations to hear the podcast or see the video interview.

The 99% Reliable AI Agent: How Haize Labs Sells Enterprise AI to Banks, Insurers & Healthcare

I’ve sat through enough enablement chatbot demos to know the pattern. The bot looks perfect in the demo room. Then production hits, and your customers start getting wildly different answers to the same question. One prospect gets “no discount.” The next gets “20% off, just for you.” Your team’s Slack lights up. Your CRO gets nervous. Your AI roadmap goes on a “pause for review.”

Julia MacDonald, SVP of GTM at Haize Labs, has the cleanest framing I have heard for what you are up against:

“Most agents are good enough.. until they’re not.”

That one sentence is going to cost a lot of teams their AI roadmap this year. So this week, I sat down with Julia to walk through how Haize Labs sells 99% reliable agents to banks, insurers, and immigration lawyers, and what you can steal from their playbook by Friday.

Four things came out of this conversation that I think every GTM leader needs to internalize.

1- The “Mostly Fine” trap is a GTM problem, not an engineering one

Most AI agents in the wild today are good enough for personal use. Open Claude. ChatGPT. A handful of internal copilots. The problem starts the moment that same probabilistic behavior steps into a regulated, customer-facing, multi-turn conversation.

Julia’s example is the one to memorize:

“You can’t have a situation where your agent tells Customer A ‘I can’t give you a discount,’ and Customer B ‘maybe I can give you a discount.’ That’s the reliability issue I’m talking about.”

This is what kills enterprise pilots. Not bad UX. Not slow latency. Variance across customers. And it gets worse in multi-turn conversations, because each turn compounds the drift.

Here is what I want you to take from this:

• The enterprise buyer is not pricing your agent’s average performance. They are pricing the worst 1% of conversations, because that’s what triggers a compliance review, a refund, or a CFPB letter.

• “We hit 95% accuracy in testing” is not a closing number anymore. The buyer needs to know what happens in the other 5%, and how often it happens, and whether it can be bounded.

• If your sales motion can’t answer that question with specifics, you are losing deals to vendors who can. Haize Labs is one of those vendors.

The shift for your team this week: stop demoing your agent’s best behavior. Start demoing the boundaries it cannot cross.

2- The hypothesis-first filter (almost mathematical)

This was the part of the conversation I rewound twice. Julia does not pick verticals because they’re “hot.” She runs every use case through a near-mathematical filter before her 2-person GTM team touches it.

Her criteria, paraphrased:

• The workflow is document-heavy

• It cannot be outsourced to a $5/hour worker (paralegals, nurses, claims adjusters, not data entry)

• There is a right vs. wrong answer that someone cares about

• The use case is sufficiently well-defined that you can score it

• The cost of being wrong is high enough to pay six figures to solve

• A human is still on the hook for final accountability (no AI lawyers, no AI doctors, yet)

Concrete example she gave: immigration law. Document-heavy. Talent-constrained (you cannot hire your way out of it). Right and wrong are codified by visa requirements. Stakes are someone’s life trajectory. Lawyer still signs the filing.

Contrast that with: an AI that generates legal letters from a template. Document-heavy, sure. But the cost of a mediocre letter is low. There’s no scarcity. The buyer will not pay $100K for it. Wrong shape, wrong sale.

What to do this week: Take your top three AI agent use cases. Score each against those six criteria. Anything that fails two or more is a roadmap distraction. Kill it or downgrade it.

3- Code of Conduct + Supervisor Models + Red Teaming (the actual reliability stack)

This is where the Haize Labs technology gets interesting, and where I learned something I’m bringing into my own prompt engineering work at Momentum.

Most teams use “LLM as a judge” to police their agents. Another LLM, another prompt, asking “did the first model do a good job?” Julia’s team thinks that approach is too brittle, because the judge is governed by whoever wrote the rubric prompt that morning.

Haize Labs’ stack:

• Code of Conduct. A comprehensive, enterprise-specific rules document. For the bank example she walked through (voice debt collection agent), this includes every CFPB regulation, every authentication rule, every prohibited phrase.

• Supervisor Models. Models actually fine-tuned on that Code of Conduct. Not a judge prompt. A judge architecture.

• Adversarial Red Teaming. Algorithms that try to break the agent against the Code of Conduct. They do not stop. They generate thousands of prompts (Julia mentioned one run hitting 15,000 adversarial queries) using different languages, role-play, multi-turn escalation, emojis, the works.

• Iterative fine-tuning. Every successful attack becomes training data. You loop until reliability stabilizes at 99%+.

Why this matters even if you never buy Haize Labs:

• “We tested it” is not a methodology. Your AI vendor evaluation needs to ask: show me your adversarial test suite, in numbers.

• For internal builds, you can adopt a version of this. Write your own Code of Conduct (the rules your agent must never break). Generate adversarial prompts (Claude or GPT will help). Score every release against the same suite.

• This is the loop that gets you from “demo magic” to “production-grade.” There is no shortcut.

Tactical takeaway: Before your next agent release, draft a one-page Code of Conduct. Generate 100 adversarial prompts against it. Score the agent. Track that number across versions. That alone will outperform 90% of your competitors’ QA.

4- The 2-person AI-native GTM stack (Julia’s actual workflow)

Julia runs partnership, sales, and marketing for Haize Labs with one other person. Her quote: “Without AI, I don’t think we would have survived.” Here is the motion, end to end.

Her enterprise prospecting flow:

• Start with a hypothesis (one of her use cases that passed the filter)

• Use AI to generate a list of companies matching that use case

• Use AI to generate a list of executives at those companies

• Enrich LinkedIn profiles using Clay + OpenAI

• Land in Dripify for low-volume, high-touch LinkedIn outreach (not blast spam)

Her pre-call brief flow:

• Custom prompt that pulls together: customer pain points, recent announcements, competitor moves, Haize capability mapping

• Output: a structured brief with three likely pain points and two recommended use cases to discuss

• Result, in her words: “I am smarter today than I was six months ago, every single call.”

The honest gap she named, which is worth respecting:

• They are not yet doing closed-loop attribution from outreach to revenue. The reason is speed: every hour spent building the meta-agent is an hour not spent talking to enterprise prospects. That’s a real tradeoff for a 2-person team, and it’s worth naming so you don’t beat yourself up for the same one.

The strategic shift for your team:

• Tooling is no longer the bottleneck. Hypothesis quality is. A 2-person team with a sharp hypothesis will outperform a 10-person team running spray-and-pray.

• The pre/post-call brief workflow is the single highest-ROI thing you can build this quarter. It compounds. Every call makes you smarter on the next one.

• Closed-loop measurement is the next frontier. The teams that wire it up first will have an unfair advantage.

Why this matters

The next 18 months of enterprise AI will be won by teams who solve two things at once: reliability that survives the worst 1% of conversations, and a GTM motion lean enough to make money before the funding clock runs out. Julia is doing both. She is also one of the most generous teachers I have had on this podcast.

If you build agents, you need a Code of Conduct. If you sell agents, you need the hypothesis filter. If you run a 2-person GTM team, you need Julia’s prospecting stack. If you have none of the above, you need to start this week.

That’s three hours of work. It will save you a quarter of wasted engineering.

The 99% Reliability Filter

7 criteria to test any AI agent use case before you build it, buy it, or stake your roadmap on it.

A GTM AI Academy field guide. Inspired by my podcast conversation with Julia MacDonald, SVP of GTM at Haize Labs.

I have watched dozens of GTM teams deploy AI agents in the last 18 months. Most of them work great in the demo. Then production hits. One prospect gets “no discount.” The next gets “20% off.” Your team’s Slack lights up. Your CRO gets nervous. Your AI roadmap goes on a quiet “pause for review.”

I sat down with Julia MacDonald, SVP of GTM at Haize Labs, for the GTM AI Podcast this week. Haize Labs is the only company I have seen solve the AI agent reliability problem at the enterprise level. They sell to banks, insurance companies, immigration lawyers, and healthcare systems.

That one sentence is going to cost a lot of teams their AI roadmap this year.

Here is why. Your enterprise buyer is not pricing your agent’s average performance. They are pricing the worst 1% of conversations, because that is what triggers the compliance review, the customer refund, or the CFPB letter. “We hit 95% accuracy in testing” stopped being a closing number a year ago. If you cannot tell the buyer what happens in the other 5%, how often it happens, and whether it can be bounded, the buyer finds a vendor who can.

So before you build the next agent, you need a filter. Something that tells you, in 5 minutes, whether this use case is worth your engineering quarter, your roadmap real estate, and your reputation.

The 7 criteria

You will score each use case 1 to 5 on each criterion. 5 means “strongly true.” 1 means “not true at all.” Be honest, not optimistic. The whole point of the filter is that optimism is what got the failed pilots funded in the first place.

1- Document-heavy workflow

The work being automated is fundamentally about reading, interpreting, and producing structured documents. Not a one-line answer. Real document logic.

YES: Immigration visa filings. Insurance claims adjudication. Loan underwriting packets. Pre-trial discovery review.

NO: Generic chat replies. Single-field data entry. Status lookups. “What was my last invoice?”

Ask yourself: If I removed the documents from this workflow, is there anything left for the agent to actually reason about?

If the answer is “no, the documents are the work,” you have a strong candidate. If the answer is “honestly, this could be a Zapier task,” you are not in agent territory.

2- Cannot be cheaply outsourced

The work cannot be handed to a $5/hour offshore worker without losing quality. The labor itself is skilled, certified, or contextually scarce.

YES: Paralegal review. Registered nurse triage. Claims adjuster decisions. Senior tax preparation.

NO: Lead list cleanup. Data normalization. Generic transcription. Basic moderation.

Ask yourself: If “we already outsource this for cheap and it works,” will I really pay six figures for an AI version?

This is the criterion that disqualifies more roadmap items than any other. There is a giant market for cheap labor automation. There is no market for replacing cheap labor with enterprise software. The economics force you toward regulated, specialist, or scarcity-bound roles. That is a feature of this filter, not a constraint.

3- Has a right vs. wrong answer

The workflow has verifiable outcomes. There is a way to score whether the agent did it correctly. This is what makes 99% reliability even measurable.

YES: Did the visa filing meet the regulatory requirements? Did the claim get categorized to the correct billing code? Did the underwriting hit the right tier?

NO: Did the marketing copy “feel on brand”? Did the meeting summary capture “the vibe”? Did the rep coaching feedback “land well”?

Ask yourself: Could I write a rubric that a human expert would consistently agree with?

If the answer is no, you have no signal to fine-tune against. You can ship an agent, but you cannot make it reliable in a measurable way. That is fine for some internal tools. It is not fine for an enterprise contract.

4- High stakes for being wrong

The cost of a single wrong answer is high enough that someone will pay to prevent it. Regulatory fines, customer harm, reputational damage, or significant revenue loss.

YES: Voice debt collection (CFPB exposure). Anti-money laundering screening. Drug interaction checks. Trade settlement decisions.

NO: Internal meme generation. Low-stakes ranking suggestions. Anything where a wrong answer is shrugged at.

Ask yourself: If this agent got it wrong in 5% of cases, would anyone notice or care enough to act on it?

If the answer is “nobody would notice,” nobody will pay six figures to prevent the 5%. The math collapses. The deal stalls in procurement. Stakes are what make reliability a budget line.

5- Talent scarcity or capacity ceiling

The human role being augmented is hard to hire, hard to retain, or hits a capacity wall. The buyer is not just optimizing cost. They are unblocking growth they cannot otherwise hit.

YES: Paralegals (active talent war). Nurses (shortage in every market). Senior claims adjusters (decade to train).

NO: Roles with abundant labor supply, low turnover, and predictable training pipelines.

Ask yourself: If my buyer could hire their way out of this, would they have already?

If yes, you are selling cost savings into a non-painful problem. If no, you are selling capacity expansion into an actual constraint. The second one closes. The first one does not.

6- Economically worth automating

The value of automating the workflow justifies a real software contract. Not $10 of saved labor per run. Real money: hours of specialist time, days of cycle time, or revenue at risk.

YES: Auto insurance claims cycle time from 60 days to 3 days. Months of paralegal time per filing automated. Days of underwriter review compressed into hours.

NO: Saving 30 minutes of a $15/hour task. Marginal wins that don’t move a P&L line.

Ask yourself: Can I write the ROI story on a single Post-It in a way the CFO would believe?

If the value of automation is not big enough to fit on a Post-It and survive a 30-second sniff test, the deal will die in procurement. You need a story that lands fast and lands big.

7- Human accountability preserved

A human is still on the hook for the final outcome. The agent collects, structures, recommends, or drafts. The licensed professional signs, approves, or releases. This is the difference between an AI tool and an AI liability.

YES: Agent prepares the visa filing, lawyer signs and files. Agent flags potential fraud, analyst reviews and acts.

NO: “The AI is the doctor.” “The AI is the lawyer.” “The AI is the financial advisor.” Not yet. Not for years.

Ask yourself: If this agent makes a critical mistake, is there a named human who will own it?

If the answer is “no one,” you have built a lawsuit, not a product. Julia’s quote on this was sharp: Haize Labs deliberately does not build AI lawyers or AI doctors. The legal, regulatory, and trust infrastructure for full-replacement AI is years behind the technology. Build for the assistive lane. The full-replacement lane is where pilots go to die.

How to score

For each criterion, score 1 to 5:

• 5 = Strongly true. Perfect fit for the criterion.

• 3 = Partially true. Mixed signals. Would need work.

• 1 = Not true at all. The criterion does not hold.

Add them up. Maximum score is 35. Your total tells you the move.

The decision tree

30 to 35: Build it. High value, well defined, accountability-safe. Prioritize this on the roadmap. Hire or partner for the reliability engineering (Code of Conduct, supervisor models, adversarial red teaming). This is the agent worth your A-team.

23 to 29: Pilot it. Real signal, but at least one criterion is shaky. Run a contained pilot with one named customer or one internal team. Define the exit criteria upfront. If the weak criterion does not move during pilot, do not graduate it to production.

15 to 22: Wait or partner. The shape is wrong for a full build. Either wait for the failing criteria to mature (models get better, regulations clarify), or buy a vendor that has already solved the hard part. Do not build this in-house.

Under 15: Kill it. This use case is a roadmap distraction. Either the work isn’t valuable enough, isn’t well defined enough, or the accountability lane is too murky. Cut it, communicate the decision, and move the team to a higher-scoring use case.

The hardest move on this list is killing the 18-point project that “someone really wants.” An executive sponsored it. A customer asked for it. Someone wants to see what AI can do. None of those are reasons to ship. The filter exists to give you cover. Show the score. Hand them the rubric. Let the math do the conversation.

Three worked examples

Let me show you the filter in action on three real-shape use cases. Scores are mine. You may score them differently for your buyer or your industry, which is the point.

Example A: AI agent that drafts customer claim denial letters for a regional health insurer

The agent ingests the original claim, the policy terms, and the adjudicator’s structured notes. It drafts the denial letter using state-specific regulatory language. A licensed claims supervisor reviews and signs every letter before it goes out.

Score:

• 1- Document-heavy: 5 (claim, policy, notes, regulations)

• 2- Cannot be cheaply outsourced: 4 (licensed adjuster work, not BPO)

• 3- Right vs. wrong: 5 (regulatory compliance is testable)

• 4- High stakes: 5 (state insurance commissioner exposure)

• 5- Talent scarcity: 4 (claims supervisors are hard to hire)

• 6- Economically worth it: 5 (hours of supervisor time per letter, hundreds per week)

• 7- Human accountability: 5 (supervisor signs every letter)

Total: 33 of 35. Verdict: Build it. This is exactly the shape Haize Labs would take on.

Example B: AI agent that summarizes weekly team Slack channels into a “what you missed” digest

The agent reads Slack channels and writes a 200-word digest for each team member who was out of the loop that week.

Score:

• 1- Document-heavy: 2 (chat is not document logic)

• 2- Cannot be cheaply outsourced: 1 (anyone could write this digest)

• 3- Right vs. wrong: 1 (no rubric for “good summary”)

• 4- High stakes: 1 (if it misses something, nobody is fined)

• 5- Talent scarcity: 1 (no one is hiring “Slack digest writers”)

• 6- Economically worth it: 2 (saves maybe 15 min per person per week)

• 7- Human accountability: 1 (no one owns a missed digest)

Total: 9 of 35. Verdict: Kill it. This is a nice-to-have personal productivity feature. It is not a fundable enterprise agent. Build it as a free internal tool with the off-the-shelf models you already have. Stop trying to make it a product.

Example C: AI agent that screens inbound sales emails for ICP fit and routes high-fit leads to AEs

The agent reads inbound emails, scores ICP fit using your customer data, and routes hot leads to the right account executive with a recommended response template.

Score:

• 1- Document-heavy: 3 (some structured email + CRM data, but lightweight)

• 2- Cannot be cheaply outsourced: 3 (SDRs do this, but they are not cheap or fast)

• 3- Right vs. wrong: 4 (ICP fit is fairly testable against historical close data)

• 4- High stakes: 3 (mis-routed leads cost revenue, but no regulatory exposure)

• 5- Talent scarcity: 3 (SDR turnover is real but not crisis-level)

• 6- Economically worth it: 4 (cuts response time, improves conversion measurably)

• 7- Human accountability: 4 (AE owns the lead from the moment it routes)

Total: 24 of 35. Verdict: Pilot it. Real signal, but the stakes and scarcity are mid-grade. Pilot with one segment of your inbound flow. Define a 60-day exit criterion: ICP precision must hit X, response time must drop by Y. If both move, graduate. If neither, contain.

Notice how scoring forces clarity. The Slack digest is not “a bad idea.” It is a wrong-shape idea for an enterprise agent investment. The ICP router is not “a great idea.” It is a contained pilot with measurable exit criteria. The filter turns vibes into decisions.

Why this matters more than usual right now

The next 18 months of enterprise AI will be won by teams who solve two things at once: reliability that survives the worst 1% of conversations, and a roadmap discipline that does not waste a quarter on a use case that never had a chance.

Most teams are missing both. They are demo-buyers, evaluating AI agents on what the demo can do. They are vibe-builders, greenlighting use cases because “AI is hot” or because an executive watched a keynote. The math catches up with them at the end of the quarter, when the agent ships, fails in some embarrassing way, and the CFO asks why the line item exists.

The 7 criteria above are the math. Run them honestly. The math will tell you what your gut already suspected.

My challenge to you, this week

Pick your top 3 AI agent use cases. Score them honestly against the 7 criteria. Then have a 20-minute conversation with your team about the lowest-scoring one, and decide together: kill it, downgrade it, or change it. Done by Friday. mk? mk.

If you do this, three things happen:

• You save your team a quarter of wasted engineering on a use case that was never going to land.

• You walk into your next leadership AI update with a defensible scoring framework, not opinions.

• You become the named person other people in your org bring AI ideas to for review. The framework gives you a position. The position gives you leverage. The leverage compounds.

If you want the interactive version of this filter (live scoring, radar chart, real-time verdict), you can grab it from the GTM AI Academy site. If you want to hear Julia walk through the full Haize Labs methodology (Code of Conduct, supervisor models, adversarial red teaming, the 2-person GTM team that sells reliability to Fortune 500 banks), the full podcast episode is in the show notes.

The next 18 months of enterprise AI will be won by the people who said no to the wrong use cases this quarter. I hope this is the post that helps you say no.

More to come next week, where I will be unpacking the lossless RAG approach Julia teased at the end of our conversation.

As usual, this podcast and the goodies along with it are always free and we would love your feedback of any topic you want covered from the vast network of amazing people we know.

Please subscribe and share with your peeps

Subscribe now

Let’s get into it.

You can go to Youtube, Apple, Spotify as well as a whole other host of locations to hear the podcast or see the video interview.

Your “personalized” outreach isn’t personal. It’s just polite.

Every cold email in your inbox right now mentions where you went to college, what company you joined, or the post you wrote three weeks ago.

That’s not personalization. That’s a name swap on a template.

Dan Baird, the founder and CEO of Wrench.ai, has spent nine years building what he calls a “RoboCMO.” On this week’s GTM AI Podcast, he made one distinction that should reorganize how every revenue leader thinks about AI outreach in 2026:

“Personalization and relevance are not the same. Most teams are personalizing to YOU. Almost none of them are adapting the message to your audience’s preferences.” — Dan Baird

That gap is why your reply rates are flat even though your tool stack tripled. Here’s what to do about it.

1. Stop letting LLMs do your decisioning.

LLMs are autocomplete on steroids. Machine learning is statistics on steroids. They are not the same tool, and they don’t solve the same problem.

When you plug Clay (or any LLM-only stack) into your outbound, the LLM is doing both the message AND the targeting decision. That’s where the wheels come off. LLMs are great at writing the sentence. They are bad at telling you which sentence will convert this specific buyer.

The fix: separate the layers.

• Use ML to build the buyer profile (personality, preference, adoption stage, jargon density).

• Use the LLM only to translate that profile into the message.

• Audit the decisioning. If you can’t explain why the AI chose this angle, you can’t optimize it.

Dan’s framing: “It’s a much more predictable, much more likely-to-actually-work outcome.”

2. Most of your personas are BS. Burn them.

Here’s the Coach K test: open the deck where your personas live. How dusty is it?

Dan went further: “Most of the time, the person with the coolest-looking turtleneck gets to decide what our personas are. They aren’t driven by data.”

The replacement is not 12 prettier personas. It’s 4 to 8 data-driven ones split across the adoption curve:

• Early adopters want jargon, complexity, and the cutting edge. They tolerate friction. They pay full price.

• Late adopters want simplicity, social proof, and discounts. They want to see it work before they buy.

The same product needs two different messages for these two groups. Not because of demographics. Because of risk tolerance.

The tactical move: pull your last 100 closed-won. Tag them as early or late adopters by behavior, not title. Rewrite the top of your funnel for both. Test the split.

3. People mirror their salespeople. Use it.

Dan ran a study against a 27-million-person database for a direct sales client. The question: what predicts a top performer before training?

Answer: top reps got their first commission check fastest, and the customers they closed mirrored their own personality type. Extroverts closed extroverts. Introverts closed introverts. It wasn’t training. It was psychological matching.

The implication for your team:

• Stop assigning leads round-robin.

• Score leads on personality signal (LinkedIn writing samples, post cadence, jargon density).

• Route to the rep whose pattern matches.

• Watch cycle time compress.

“You can remove a ton of psychological friction by literally just mirroring someone’s personality.” — Dan Baird

4. The new content moat is novelty + relevance, not volume.

The incremental cost of new content is effectively zero. Everyone knows this. The next move is not more content. It’s content that lands in the upper-right quadrant.

Dan demoed a 2-axis scatter plot on the episode:

• Vertical = how often you (the sender) talk about a topic

• Horizontal = how often the topic correlates with conversion

The trap most teams fall into: top-left quadrant. You talk about it a lot. Nobody converts on it. (Talking about yourself is the most common offender.)

The gold: bottom-right. Topics you’re not saying that would convert. Those are your novelty plays.

This week’s homework: list 5 topics your buyers actually convert on. Now list 5 topics you’re putting in cold emails. How much overlap? That delta is your conversion ceiling.

5. Stop being first. Be a fast second.

Dan has been building in AI for 9+ years. His take on Open Claw and other tip-of-spear releases:

“I’ll let other people make the mistakes at scale. AI is fantastic, but it allows you to make mistakes at scale, too.”

He’s not anti-innovation. He’s anti-paying-the-tuition-on-someone-else’s-bugs. The pattern: track new tech aggressively, integrate it 60–90 days after the early adopter horror stories surface. You get 90% of the upside with 10% of the risk.

If your team is currently first on every new model release, ask one question: what’s our scar-tissue budget? If you don’t have a number, you’re paying it whether you know it or not.

The bigger pattern

AI is splitting the GTM world into two camps. Camp One thinks AI is a productivity tool. Camp Two thinks AI is a decisioning layer. Camp One is buying more tools. Camp Two is building a moat.

The companies winning in 2026 aren’t sending more emails. They’re sending fewer, better ones, to people who actually want to hear the specific message they’re sending. That’s it. That’s the entire game.

Your AI stack is only as smart as the data it’s reasoning over. Fix that, and the rest gets easy.

The Personalization-vs-Relevance Audit

12 questions that tell you if your AI outreach is built to convert. Or just to send.

Why this exists

Every cold email in your inbox right now mentions where you went to college, what company you joined, or a post you wrote three weeks ago.

Dan Baird put it cleanly on the podcast:

“Personalization and relevance are not the same. Most teams personalize TO the recipient. Almost none of them adapt the message FOR the recipient.”

This 6-minute audit tells you which side of that line your outreach is on. Score yourself honestly. The score determines what you do next.

I also put together a Claude artifact so you can do the AI version instead of old school text version below. Access the Claude artifact here

How to score

For each question, give yourself a score of 0–3 based on how true the statement is for your current outbound, ABM, or AI-assisted outreach motion.

Score Meaning 0 We don’t do this at all 1 We do this sporadically or inconsistently 2 We do this for some segments but not as a system 3 This is operationalized across the team and measured

Maximum possible: 36 points. Add yours up at the end.

SECTION 1: Personalization basics (table stakes)

These four items are the bare minimum every modern outbound team should already be doing. If you score under 8 here, your outreach is being filtered out at the inbox layer before relevance even matters.

1. Every outbound email contains at least one signal specific to the recipient (recent post, role change, content they engaged with, event they attended). Score: _____ / 3

2. We A/B test subject lines on every campaign with at least two variants and statistical significance, not gut feel. Score: _____ / 3

3. Our outbound is segmented by buyer persona, not just by company size or industry. Score: _____ / 3

4. We have a documented brand voice that every AI-generated message has to pass through before sending. Score: _____ / 3

Section 1 subtotal: _____ / 12

SECTION 2: Relevance (the layer most teams skip)

This is where the real differentiation lives. Most teams stop after Section 1 and wonder why their reply rates are flat. The questions below are the ones that compound.

5. We have mapped what topics our highest-converting buyers talk about. Not just demographic data, but psychographic and behavioral signals. Score: _____ / 3

6. We can articulate the top 3 things our buyers want to hear that we are NOT currently saying in our outreach (Dan’s “bottom-right quadrant”). Score: _____ / 3

7. We adapt the style of our message based on the recipient’s communication preferences (more data-driven for analytical buyers, more social proof for relationship-driven buyers). Score: _____ / 3

8. We segment our messaging by adoption-curve stage (early adopters get jargon and complexity; late adopters get simplicity and social proof). Not just by demographics. Score: _____ / 3

Section 2 subtotal: _____ / 12

SECTION 3: Decisioning architecture (the moat)

This is the layer Dan spent half the podcast on. If your AI is an LLM with a prompt strapped to it, you are vulnerable to anyone who builds a real decisioning stack underneath it.

9. Our AI outreach tool is NOT making targeting and messaging decisions from an LLM alone. We have a machine learning, scoring, or statistical layer beneath it. Score: _____ / 3

10. We can audit and explain why our AI chose a specific angle, topic, or recipient. The decisioning is not a black box. Score: _____ / 3

11. We route leads to reps based on fit signals (personality match, communication style, vertical expertise). Not just round-robin or geo. Score: _____ / 3

12. We measure not just reply rate, but the downstream impact: meetings booked, opportunities created, closed-won, and average deal size by AI message variant. Score: _____ / 3

Section 3 subtotal: _____ / 12

YOUR TOTAL: _____ / 36

What your score means

30–36: You’re in the top 5%.

You already get it. Your team is treating AI as a decisioning layer, not a sending layer. Your work now is compounding the moat. Keep tightening the feedback loops between message, conversion, and ICP definition. Most companies will never reach your level. Use that.

22–29: You’re personalizing well, but relevance is your gap.

You’ve nailed the basics. You’re segmenting, testing, and signaling. But you’re still mostly adapting messages to make YOU look thoughtful, not adapting them to what the recipient actually wants to hear. The next 90 days should be focused on Sections 2 and 3. Build a relevance map for your top 3 ICPs. Pull your last 100 closed-won and tag by adoption curve. Stop guessing.

14–21: You’re sending. You’re not converting.

Most teams sit here. The work is real, the tools are bought, the emails are going out. But the math isn’t moving. The fix is almost never “more volume” or “another tool.” It’s pulling decisioning out of your LLM and into a real scoring or ML layer. Start with question 9 and 10. If you can’t audit it, you can’t optimize it.

0–13: Your outbound is on autopilot, and the plane is descending.

This is fixable, but it requires a different kind of investment. Not a tool. A system. Don’t buy another AI SDR until you’ve rebuilt your persona definitions from data and separated your decisioning layer from your generation layer. The good news: most of your competitors are also scoring here. The team that moves first wins the category.

The three moves to make this week, regardless of score

1. Pull your last 20 outbound emails. Count how many were “about the recipient” vs. how many were “adapted FOR the recipient.” If the ratio is worse than 50/50, you’ve found your priority for Q3.

2. Run the bottom-right quadrant exercise. List 5 topics your closed-won customers actually talk about. List 5 topics your team is putting in cold emails. Find the delta. That delta is your conversion ceiling.

3. Audit your decisioning layer. Ask the team running your AI outreach this one question: “When the AI picked this message angle, what was the reasoning?” If the answer is “the LLM decided,” you are reasoning from a black box. Add a scoring or ML layer underneath.

Next steps

If you scored under 22 and want help building the relevance and decisioning layers, that’s exactly what we work on inside GTM AI Academy.

Reply to the email this came in on with your score, and I’ll send you the specific frameworks we use for your range.

— Coach K GTM AI Academy

As a reminder we give goodies and deep dive podcasts every week for you to enjoy, we also have tons of content in our paid level like Claude Code workflows and walkthroughs, AI education for revenue leaders, and tried and true strategies to scale AI.

Todays goodies is all about AI Visibility from Amy.

Subscribe now

On to the podcast!

You can go to Youtube, Apple, Spotify as well as a whole other host of locations to hear the podcast or see the video interview.

I had a guest on the show last week who said something I have been waiting for someone to say out loud for two years.

“Fire your agency.”

That was Amy Osmond Cook. She is the CMO of Fullcast, a PhD in organizational rhetoric, and one of the few marketing leaders I have met who can argue both the philosophy of language and the physics of pipeline in the same breath. She is not the type to say something for shock value.

Here is what you need to know before you read another word.

Amy is running the marketing org of the first AI-native go-to-market platform on earth. Fullcast acquired Copy.ai (AI workflows), Ebsta (revenue intelligence), Atrium (sales performance), and Commissionly (compensation), and stitched them into a single system. They are punching multiple weight classes above their size. And the numbers she walked me through were the kind that make you stop and re-read the slide.

So I asked her how.

This is what she said, and what I think every GTM leader needs to do about it this week.

The numbers she brought to the show

Amy did not hide behind hypotheticals. She brought the receipts.

“We scaled, we reduced our salary by several hundred thousand, and we increased our productivity 5X. In one month we went up 10 points in AI visibility. The results were insane.”

“Copy.ai’s website was in existence for three years, and they went from zero to 84 domain strength with zero human content. Zero.”

Let me sit with that for a second.

Three years. 84 domain authority. Zero human writers.

For context, that is the kind of domain strength that takes a content team of 8 humans about 5 years of disciplined publishing. Copy.ai got there with AI agents and a workflow system. And before anyone yells “but Google will penalize you,” I asked the same question. Here is her answer, and it is the one that should make every CMO take a long look at their content team’s budget.

“That’s the answer to whether Google’s going to downgrade your site if you use AI. There’s the answer.”

Google does not care if it is AI. Google cares if it is good.

The whole game has changed.

The thesis: the AI agency is here

Amy’s frame is the one I have been trying to put words around for months. She just nailed it.

“Using Copy as an AI agency extends your team like an external agency does, only you do it with AI agents. So it doesn’t mean that you get rid of your team. It doesn’t mean you only use robots. It just means your efficiency goes way up.”

Read that twice. The AI agency does not replace your humans. It replaces the external humans you have been renting at $200/hour.

That distinction matters. Because the wave I am watching right now is not “AI is taking marketing jobs.” The wave is “AI is collapsing the agency layer.” Internal teams keep their best people and let them operate at agency-level scale. Agencies that do not pivot to AI-native delivery are getting compressed from both ends: clients want lower cost and faster output.

If you are an agency right now, you have about 18 months to become an AI-native agency or become a feature inside someone else’s stack.

The 3 plays I pulled from the conversation

1- FAQs are the secret sauce of AI visibility

This was the line that stopped me cold.

“The FAQs is the secret sauce for being visible in AI. If there’s one thing I can tell marketers, it is this is good for AI visibility.”

Most marketers treat FAQs as a footer afterthought. Amy treats them as the primary surface area. Why? Because LLMs are trained to match questions to answers. Your FAQs are literally the format the bot is looking for. Every page on your site should have one. Every product. Every category. Every persona.

If you do nothing else this month, audit your FAQs.

2- The combo that creates magic is public + private cloud

I asked Amy what makes Copy.ai different from just using ChatGPT. Her answer is the most important sentence in the episode.

“You take what’s in the public cloud, you combine it with your own Copy.ai digital asset management system that provides all of the private information. You sync it together, and then all of a sudden magic actually happens.”

This is context engineering in plain English. The LLM is the engine. Your private data is the fuel. Most teams are running their engine on premium-grade nothing.

You will get average output until you give your AI access to your CRM, your call recordings, your win/loss notes, your win patterns, your brand voice, your customer language. Then it stops sounding like ChatGPT and starts sounding like you.

3- If it is AI, say it is AI

This one is going to be unpopular with the “AI SDR at scale” crowd. Amy is not having it.

“Marketing has done go-to-market a disservice by pretending that we’re real people when we’re not, when we’ve been trying to personalize at scale. People got wise to it. People were like, ‘Oh, they’re not real. I thought they were real. Now I’m not even gonna listen to them.’”

The fastest way to lose trust in 2026 is to pretend an automation is a person. The fastest way to build trust is to be radically transparent. If a chatbot is doing the work, say so. If a human is on the other end, prove it.

This is not just ethics. It is conversion math. People convert higher when they know what they are talking to.

What this means for you this week

The pattern Amy ran is replicable. You do not need to acquire Copy.ai to do this. You need to make 3 calls.

1- Audit your FAQs. Does every important page have one? Are the answers structured? Are they pulling search traffic AND showing up in ChatGPT and Perplexity?

2- Inventory your context. What private data could you feed your AI tools that you currently are not? Sales calls, brand guidelines, win notes, customer reviews, product docs. Pick the top 3 and load them this week.

3- Run the transparency test. Open your last 3 outbound emails. Open your last 3 chatbot flows. Is it clear when the human ends and the AI begins? If not, fix it before the prospect figures it out themselves.

The AI Visibility Playbook

How to Get Your Brand Found Inside ChatGPT, Claude, Gemini, and Perplexity (Without Losing Google)

By Coach K (Jonathan Kvarfordt) : Founder, GTM AI Academy Inspired by my conversation with Amy Osmond Cook, CMO of Fullcast, on the GTM AI Podcast.

Why I built this

Copy.ai’s website went from zero to 84 domain authority with ZERO human-written content. In one month, her team gained 10 points of AI visibility. Her marketing org is 5X more productive, and they shaved several hundred thousand dollars off salary spend.

I have been studying AI visibility for over a year. I have read every paper, talked to a friend at Google, run my own experiments on the GTM AI Academy site, and built playbooks for clients in the Fortune 500. What Amy said in that conversation crystallized everything for me into a system I could finally write down.

That system is what you are about to read.

If you are a CMO, a head of content, a head of demand gen, or a marketer who suspects the rules of being-found just got rewritten, this is for you. The hard truth is that the old SEO playbook still works for Google. It does not work for ChatGPT, Claude, Gemini, or Perplexity. Those engines do not rank pages. They reason over content. The marketers who figure that out first are going to own the next decade of pipeline.

The marketers who do not are going to wake up one morning and find that their organic traffic disappeared because their prospects stopped clicking links.

Here is the system. I call it the FOUND framework.

The FOUND Framework: 5 Plays for AI Visibility

# Play What it does

F : FAQ Everywhere Match how LLMs were trained: question → answer

O : Own Your Context Combine public + private cloud so AI sounds like YOU

U : Use EEAT, Hard Experience, Expertise, Authority, Trust signals on every page

N : Narrate For The Bot Structure content for parsing, not just reading

D : Distribute Where Bots Train Show up in the corpora the models actually learn from

Each play has a tactical step, a real-world example, a self-test, and a “try this week” rep. Use them as a checklist.

Play 1: F : FAQ Everywhere

The principle

LLMs are not search engines. They are autoregressive question-answering machines. They were trained on billions of Q&A pairs. When a user asks ChatGPT “what is the best sales performance management platform,” the model is doing pattern matching on every Q&A pair it ever ingested.

The structure the model is looking for is the FAQ structure.

Amy said it on the podcast: “FAQs are the secret sauce for being visible in AI.”

She is right. I have audited 47 client sites in the last 6 months. The sites that show up in LLM citations have one thing in common. They have hundreds of FAQs scattered across pages, products, categories, and persona hubs. The sites that do not show up have FAQs buried in a footer link.

The play

Add a structured FAQ block to every meaningful page on your site. Not “Contact us” pages. Every page that matches a buyer question.

The structure matters. It must include: 1- A clear H2 or H3 question (phrased the way a human would ask it) 2- A 2-4 sentence direct answer (lead with the answer, not the setup) 3- Schema.org FAQPage markup for crawlers 4- A short follow-up that names alternatives or related concepts

Example

Bad FAQ:

Q: Tell me about your platform. A: Our platform leverages cutting-edge AI to unlock revenue potential.

Good FAQ:

Q: What is sales performance management software? A: Sales performance management (SPM) software is a category of tools that combines territory and quota planning, commission management, sales analytics, and rep coaching into one platform. Most companies use SPM to align go-to-market plans with actual rep behavior and to forecast more accurately. Categories of SPM include territory and quota tools (like Fullcast), commission tools (like CaptivateIQ and Commissionly), and analytics tools (like Atrium).

Notice the second one names competitors. That is not weakness. That is what LLMs are looking for. They want connection density.

Self-test

Go to your homepage right now. Count the FAQs. If the answer is fewer than 3, you have work to do. Go to your top 5 product or solution pages. Count. If most of them are at zero, you have a structural problem.

Try this week

Pick your top 3 highest-converting pages. Add 5 FAQs to each. Use the buyer’s actual language (mine your sales call transcripts for the exact phrasing). Add FAQPage schema. Republish. Watch what happens in 30 days.

Play 2: O : Own Your Context

The principle

Most teams are using AI as if it is a public utility. They pour the same prompt into ChatGPT that every competitor is pouring. They get the same generic output. Then they wonder why it sounds like everyone else.

Amy explained this beautifully on the show: “You take what’s in the public cloud, you combine it with your own Copy.ai digital asset management system that provides all of the private information. You sync it together, and then all of a sudden magic actually happens.”

The public cloud is the LLM. The private cloud is your data. Magic is the intersection.

If your team is not feeding private context into your AI workflows, you are running a Ferrari on regular unleaded.

The play

Build a private context layer that your AI tools can access for every output. Minimum viable context layer:

1- Brand voice document (with examples of what is on-brand and off-brand)

2- ICP definition (with anti-personas, not just personas)

3- Top 20 customer quotes (verbatim language from sales calls and reviews)

4- Top 10 win/loss notes (why deals closed, why they did not)

5- Your last 50 blog posts indexed for retrieval

6- Your top 30 sales conversations transcribed (Gong, Otter, or equivalent)

Tools that do this well: Copy.ai (workflows), Claude Projects, ChatGPT Custom GPTs, and several agentic platforms. Pick one. Get it running this month.

Example

I ran a test last quarter with two CMO clients. Both wrote a launch announcement for a new product feature. Client A used vanilla ChatGPT. Client B used Claude with a Project containing their brand doc, 5 customer interviews, and their last 10 launch posts.

Client A’s draft: 6 hours of editing before it sounded like them. Client B’s draft: 20 minutes of editing before it shipped.

The difference was not the model. It was the context.

Self-test

Ask yourself: if I gave my AI tool a blank prompt today and said “write a blog post in our voice,” would the output be 80% there or 20% there? If 20%, you have a context problem, not a model problem.

Try this week

Build a single brand voice document. Two pages max. Three examples of how you sound. Three examples of how you do NOT sound. Load it into your AI tool of choice. Test the difference.

Play 3: U : Use EEAT, Hard

The principle

Google introduced EEAT in 2022: Experience, Expertise, Authority, Trust. It was originally a search ranking signal. It turned out to be the most prescient framework of the AI era.

LLMs care about EEAT for exactly the same reason Google does. They are trying to figure out which sources to weight when they generate an answer. Sources with EEAT signals get cited. Sources without EEAT signals get ignored.

Amy nailed this on the show: “The EEAT acronym, experience, expertise, authority, trust. Those things, if you can pull those into your content, even if it’s AI, it’s fine.”

The marketers who lose at AI visibility are the ones publishing AI content with no human evidence layer. The marketers who win are the ones publishing AI-assisted content backed by named experts, real client work, citations, and proof.

The play

Audit every piece of content for the 4 signals:

Experience: Does the author have firsthand experience with the subject? Is that experience visible on the page?

Expertise: Does the author have credentials, certifications, or a body of work that proves they know the topic?

Authority: Is the author cited by peers, mentioned by other reputable sources, or recognized by their industry?

Trust: Does the content include sources, dates, transparent disclosures (including AI assistance), and verifiable claims?

If a page hits all 4, the LLM is more likely to cite it. If a page hits 0, the LLM treats it as noise.

Example

Compare two blog posts on “How to forecast pipeline accurately.”

Page A (low EEAT):

• No author photo

• Generic byline “Marketing Team”

• No citations

• No dates

• Stock images

• AI-generated body with no real examples

Page B (high EEAT):

• Author photo with name (Amy Osmond Cook)

• Author bio: “CMO of Fullcast. PhD in organizational rhetoric. Scaled marketing through 3 acquisitions.”

• 4 citations to peer-reviewed pipeline research

• “Last updated May 2026”

• Original screenshots from a real client engagement

• 3 verbatim quotes from named sales leaders

Page B wins in AI citation 100% of the time.

Self-test

Open your last 5 blog posts. Score each on the 4 EEAT signals (0 to 1 each). If your average is below 3, your AI visibility is leaking.

Try this week

Add author bios with credentials and photos to your top 10 content pages. Add a “Last updated” date. Add 3 verifiable citations per page. This is the lowest-effort, highest-impact move in this playbook.

Play 4: N : Narrate For The Bot

The principle

Human readers scan in F-patterns. They read headlines, skim first sentences, and bounce. They forgive bad structure.

LLM readers do not scan. They parse. They tokenize. They build semantic relationships across an entire document at once. They do not forgive bad structure. Bad structure means the wrong thing gets cited, or worse, your content does not get cited at all.

This is the biggest mental shift for content marketers. You are no longer writing for two audiences. You are writing for three. Humans. Search crawlers. Reasoning agents.

The play

Adopt the “answer-first paragraph” pattern across all content: 1- Lead with the direct answer in the first 2 sentences 2- Add context, nuance, and proof in the next 3-4 sentences 3- Close with a what-this-means-for-you bridge

Then layer in these structural moves: 1- One H2 per major idea, written as a question or a declarative answer 2- Bullet points for parallel concepts (LLMs love these) 3- Tables for comparison content 4- Numbered lists for sequential steps 5- Bolded key terms (acts as a semantic signal) 6- Clear topic sentences in every paragraph

Example

Old paragraph (LLM-unfriendly):

“When you think about pipeline forecasting, there are many factors at play. Some companies use historical data, others use signals from the buyer journey, and the best ones combine both approaches in a unified system that gives them what they need to make decisions.”

New paragraph (LLM-friendly):

Best pipeline forecasting combines historical data with real-time buyer signals. Companies that use only historical data underperform forecasts by an average of 23%. Companies that use only buyer signals overcorrect on small inputs. The winning approach (used by leaders like Fullcast, Clari, and Gong) blends both into a single confidence score. This is the model your forecasting team should be building.

The second one will be cited. The first one will be skimmed over.

Self-test

Read your last blog post aloud. Does each paragraph have a topic sentence? Could a stranger reading only the topic sentences understand the full argument? If no, restructure.

Try this week

Pick your top 3 pages by traffic. Rewrite each opening paragraph as an answer-first paragraph. Add 2 bulleted lists and 1 table to each. Republish. Measure citation rate in ChatGPT and Perplexity 14 days later.

Play 5: D : Distribute Where Bots Train

The principle

LLMs do not browse the web in real time the way Google does. They are trained on snapshots of the internet, then augmented with retrieval. The places they were trained on (and the places they retrieve from) are not your blog.

They are: Wikipedia, Reddit, Stack Overflow, YouTube transcripts, podcast transcripts, major publications, GitHub, and a handful of high-authority industry sites.

If your brand does not appear in those sources, you are invisible to the model regardless of how good your own site is.

The play

Build a distribution strategy that targets the LLM training corpora directly. Minimum viable distribution layer: 1- Wikipedia: get your founders, your category, or your major customers cited (NOT a page about your company, those get deleted) 2- Reddit: get organic mentions in industry subreddits (without astroturfing) 3- YouTube: publish video content with full transcripts and chapters 4- Podcast: be a guest on shows whose transcripts get indexed 5- Industry publications: contribute bylined articles to top trade outlets 6- GitHub or Hugging Face: publish open-source tools or datasets if you are technical

This is slower than running ads. It compounds.

Example

I tested this with a client last year. We took their CMO and got her on 12 podcasts in 6 months. Every one of those podcasts published transcripts. By month 8, when prospects asked ChatGPT “who is the leading expert on go-to-market for fintech,” her name appeared in the answer.

That is the compounding effect. Twelve podcast appearances cost her about 20 hours total. The lifetime traffic and inbound from being cited by ChatGPT and Perplexity is worth orders of magnitude more.

Self-test

Open ChatGPT. Ask: “Who are the top 5 thought leaders on [your category]?” Are you in the answer? If not, you have a distribution problem.

Try this week

Make a target list of 10 podcasts in your space. Pitch 5 of them this week. Even one acceptance starts a flywheel that will pay off for 24 months.

The 30-Day Action Plan

If you do nothing else, do these 4 weeks of work.

Week 1: Audit and structure

1- Run a FAQ audit on your top 10 pages 2- Add author bios and EEAT signals to your top 10 content pages 3- Rewrite the opening of your top 3 blog posts to be answer-first

Week 2: Context build

1- Write a 2-page brand voice document 2- Pull your 20 best customer quotes from sales calls and reviews 3- Load both into your AI tool of choice 4- Test by generating one piece of content and comparing to your baseline

Week 3: Production sprint

1- Publish 5 new FAQ-rich pages targeting LLM-friendly buyer questions 2- Add FAQPage schema to all of them 3- Add internal links between them

Week 4: Distribution

1- Pitch yourself or your CMO on 5 podcasts 2- Publish one bylined article on a major industry publication 3- Run a Reddit AMA in your top relevant subreddit

In 30 days, you will have moved more on AI visibility than 90% of your competitors will move all year. I have watched this play out across 7 clients. The pattern holds.

The Self-Test Scorecard

Use this every quarter to track your AI visibility maturity.

Play 0 : Not started 1 : In progress 2 : Live and measurable F : FAQ Everywhere No FAQs on key pages FAQs on top pages FAQs on every key page + schema O : Own Your Context Vanilla AI prompts Some private context loaded Full context layer in production U : Use EEAT, Hard Anonymous content Author bios present EEAT signals on all content N : Narrate For The Bot Wall-of-text content Some structure added Answer-first across all content D : Distribute For Training Own site only Some external presence Wikipedia, podcasts, publications

A score of 7 or higher is the leadership tier. Most companies are sitting at 2 or 3 today. The gap is wide open.

My challenge to you

Pick ONE play this week. Not five. One.

The marketers who win the AI visibility race are not the ones who do everything. They are the ones who pick the right thing and execute it with discipline. Amy did not transform her marketing org in 90 days by trying to do everything. She picked the workflow layer (Copy.ai), went all in, and let the compounding do its work.

If you tell me which play you picked, I will help you map the first 30 days. Reply to the newsletter, comment on my LinkedIn, or send me a DM. I read every one.

I hope this helps you the way it helped me. The conversation with Amy changed how I think about my own content engine, and this playbook is the receipt.

The future of marketing is already here. It is just unevenly distributed. Go close the gap.

Coach K

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