Lets get into it!

Our guest is Eli Portnoy who is the founder of BackEngine and takes us through his going down in agents and up in effectiveness.

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.

Every “I have 60 agents running” post on LinkedIn is describing a problem, not a win. Eli Portnoy found that out the expensive way. At one point BackEngine.ai had roughly 200 scheduled AI jobs firing across the company. Nobody was reading any of them. Today they run about 10. Pipeline is up, deals close faster, and every one of the 10 has a human owner and a meeting attached to it.

Eli has founded three AI companies (two acquired, by Telenav and Medallia) and runs 90% of BackEngine’s go-to-market inside Claude. On this week’s episode he shared his screen and walked through the actual setup. Here is what a revenue leader can take from it, and at the bottom there is a skill you can paste into Claude today that rebuilds his highest-value job for your own team.

1) The stack lives inside the chat window now, and the tools did not go away

The first thing on Eli’s screen was the connector list: BackEngine, Fireflies, Gmail, Calendar, Granola, HubSpot, Notion, Slack, Superhuman, Zoom, plus two MCP servers he vibe-coded himself (one just returns website stats). His framing is worth stealing for any exec who asks “are we replacing our tools with AI?” The tools stay. The 15 browser tabs go. HubSpot is still the system of record; he just never opens it, because every read and write happens from inside Claude.

The practical implication for a team: connector coverage is the new adoption metric. A rep with a Claude license and zero connectors is doing email polish. A rep with calendar, CRM, inbox, and call recordings connected can run the jobs in the next section. Audit your team on that axis before you audit them on prompt quality.

2) The scheduled job is the unit of value, not the chat

Most people still use AI in what Eli calls single-player mode. One person, one prompt, one answer nobody else sees. Scheduling flips it to multiplayer: the same output hits the whole team on a cadence, so the meeting starts from shared facts.

The four jobs that survived the cut at BackEngine:

• Founder Sales Daily Pulse. Runs at 4pm. Scans all outreach activity against the company knowledge base (Eli calls it “my brain”) and emails what happened, what did not, and what needs a reply.

• Follow-up audit. End of day. Reads the calendar, finds every meeting with no follow-up sent, pulls the transcript, drafts the follow-up.

• PMF from the last 20 prospect calls. Fires every time 20 new prospect calls land. Reports what is resonating, what is not, which discovery questions are working, and whether a new story he tried moved anything. Lands once or twice a month. Eli: “probably the highest value email I get.”

• Health change alert. Any deal or customer that moves a grade (B to A, A to C) triggers an email with the reason, to the whole team.

Notice the pattern. Three of the four are triggered by events in the business (a call count, a health change, an unanswered meeting), not by a clock. The one clock-based job is a summary. If your scheduled jobs are all “every Monday, summarize X,” you are building a newsletter for yourself, not a system.

What makes the PMF job good is the context under it, not the prompt. Eli gave it three things: an expansive prompt that explains what the product does and where it is going, access to all call recordings, and the BackEngine MCP with the sales deck, customer conversations, and prospect history. That is why it can tell the difference between a story he has told 50 times and one he tried yesterday.

3) Your CRM connector is sampling, and it will not tell you

Anyone who plugged Claude or ChatGPT straight into Salesforce and called it done should read this twice. Ask “which of my deals is going sideways?” and the model has no search path for that question. Answering it properly means reading every email and every transcript on every deal, which will not fit in a context window, and answer quality degrades well before you hit the limit. So the model samples.

Eli’s number from watching this across customers: a direct connection to a CRM or call tool pulls roughly 30% of what it needs. The answer reads fine, because 30% of real data still sounds real. The missed deals live in the other 70%.

The fix, whether you buy it or build it, has three parts:

• Join the systems (CRM, call recordings, inbox, docs) into one layer instead of connecting them one at a time

• Build an index and catalog so a question retrieves exactly the records it needs and nothing else

• Permission at the data layer, so a rep’s query on a deal can legally pull the VP’s email thread on that same deal

A quick test for this week: ask your connector “which deals went quiet in the last 14 days,” then hand-check three deals it did not mention. If one of them is quiet, you have your answer on coverage.

4) Two change-management rules that made the AI pay for itself

Eli’s third mistake was treating all of this as a technology problem. His words: “getting real value out of it is not a technology problem, it’s an enablement problem.” Two rules fixed it.

• Fewer, owned jobs. Cap the count. Treat each scheduled agent like a hire: it only performs if someone has time to manage it. Ten with attention beats 200 without.

• No workflow, no job. Every output must trigger a pre-engineered action: a standing agenda item, a required response, a decision with a date. If an email arrives and nothing is scheduled to happen because of it, kill the job. “Information for the sake of information is not helpful.”

The PMF report is the example. The email is the small part. The team meeting that reads it and changes the pitch is the part that moves revenue. That is also why Eli says the ROI is hard to isolate: the mechanism is a team that spends pipeline reviews on “how do we move this” instead of “what happened,” and catches a product miss in weeks instead of a quarter.

5) A 20-second taxonomy for prompt vs. project vs. skill vs. plugin

Teams burn hours arguing about this. Eli’s version:

• Prompt: a one-time task

• Project: the same task repeated, with saved context and documents attached

• Skill: a how. The method you want applied every time (”analyze it this way, in this order”)

• Plugin: packaging. A connector plus a skill plus context, bundled so you can hand it to someone else

Put together a skill for you inspired by all of this and you can grab it at the www.gtmaipodcast.com

The tactical shift

AI maturity is the number of decisions that changed because an agent ran. The agent count tells you nothing about that.

What to do this week:

• List every scheduled AI job your team runs. Pause anything without a named owner and a meeting or response tied to it.

• Run the 14-day quiet-deal test on your CRM connector and hand-check three deals it skipped.

• Install PMF Pulse, fill in the owner and meeting lines, and run it once manually on your last 20 calls before you schedule it. The first run tells you whether your context is good enough to automate.

Eli’s full prompt library (29 sales use cases, each tagged prompt, scheduled, or live artifact) is free at prompts.backengine.org.

Ten agents with owners beat 200 with none.

Top 5 quotes from the episode

1. “Just because we could meant that we did, and so we had, like, 200 of these firing at any given [time]... and then the second that happens, no one’s reading them.”

2. “When you connect directly to a CRM or any of these tools, it’s really only grabbing about 30% of what it needs to be grabbing. And so you’re getting answers that look good... it’s just missing a huge amount of actual important information.”

3. “Getting real value out of it is not a technology problem, it’s an enablement problem.”

4. “Information for the sake of information is not helpful. It has to be a change that we’re actually implementing.”

5. “AI is typically pretty single-player mode. It’s not very good at multiplayer mode. What I like about what we’re talking about here is that by scheduling it, it becomes multiplayer mode.”

Skill for you!

---
name: pmf-pulse
description: Reviews your last N prospect calls (default 20) against your company context and reports what is resonating, what is falling flat, which discovery questions work, and what to change in the pitch or product. Run on demand ("run PMF pulse") or as a scheduled job every time 20 new prospect calls land.
---

# PMF Pulse

## What this skill does

Every 20 prospect calls, produce one report that tells a founder or sales leader whether the pitch is landing, where it is breaking, and what to change next week. The output is a decision memo, never a call summary. If a section does not force a decision, cut it.

## Before you run: context you need

Ask for, or locate via connectors, the following. Do not run without at least items 1 and 2.

1. Call transcripts. The last N prospect calls (default N = 20). Pull from Gong, Fireflies, Granola, Zoom, or whatever is connected. Prospect calls only. Exclude customer success, internal, and partner calls.
2. Company context. The current sales deck, a one-paragraph product description, the current ICP definition, and the three to five discovery questions the team is supposed to ask. If a knowledge base is connected (Notion, Google Drive, BackEngine, or similar), read it. If nothing exists, ask the user to paste the product description and current pitch in two paragraphs.
3. The last PMF Pulse report, if one exists. You are measuring change, so you need the baseline.
4. The change log. Anything the team deliberately tried since the last report: a new story, a new discovery question, a new pricing frame, a new demo flow. If untracked, ask: "What did you try differently on calls in this batch?"

## How to analyze

Work call by call first, then across calls. Do not skim a sample. If the transcripts will not fit in one pass, process them in batches of five and keep a running tally; never conclude from fewer than the full set.

For each call, capture:
- Persona and company type (map to the ICP definition, flag if outside it)
- The pain the prospect stated in their own words (quote it)
- Which parts of the pitch got a reaction (a question, a "say more," a specific objection) and which got silence
- Objections raised, with exact phrasing
- Discovery questions the rep asked, and whether each produced a usable answer or a dead end
- Competitor or alternative mentioned (including "we'll build it" and "we do this in spreadsheets")
- Outcome: next step booked, vague follow-up, or no next step
- Anything new the rep tried (compare against the change log)

Then across all calls, look for:
- Pain statements that repeat across three or more calls (your real positioning)
- Pitch segments that consistently produce silence (dead weight)
- Objections that cluster by persona or segment
- Discovery questions with a hit rate above 70 percent and below 30 percent
- ICP drift: share of calls outside the stated ICP, and whether those went better or worse
- Change-log experiments: did the new story, question, or frame move outcomes versus calls that did not use it

## Output format

Keep the whole report under 700 words. Use this exact structure.

PMF Pulse: calls [date range], N = [count]

1. The one-line verdict. Is the pitch landing better, the same, or worse than last report? One sentence with the evidence.
2. What is resonating. Three items max. For each: the theme, how many of N calls it appeared in, one verbatim prospect quote.
3. What is falling flat. Three items max. Same format. Include any pitch segment that produced no reaction in the majority of calls.
4. Discovery question scorecard. Table: question, times asked, times it produced a usable answer, keep / rewrite / kill.
5. Objection clusters. Objection, count, persona or segment, and whether the rep's response worked (next step booked after the objection) or not.
6. ICP check. Share of calls inside the stated ICP. Whether outside-ICP calls performed better or worse. One sentence on whether the ICP definition should move.
7. Experiments. For each change-log item: used in how many calls, outcome versus calls without it, verdict (keep, extend, drop).
8. Three changes for next week. Specific and assignable. "Cut the integrations slide" beats "tighten the deck." Each change names an owner.
9. Confidence and gaps. What you could not determine from the transcripts, and what context would fix it next run.

## Rules

- Quote prospects verbatim. Paraphrase loses the signal.
- Count everything. "Several prospects" is banned. "7 of 20" is required.
- Never invent a metric. If the transcripts do not contain the answer, say so in section 9.
- Prefer the uncomfortable finding. If the founder's favorite story is producing silence, say it in section 3.
- Be concise. This is read on a phone, before the meeting starts.
- No em dashes.

## Owner and workflow (required before scheduling)

Do not schedule this skill until these three lines are filled in. A report with no owner and no meeting is noise.

- Owner: [name]. Reads the report the day it lands and brings it to the meeting below.
- Meeting: [weekly pipeline review / founder sync / Monday stand-up]. Section 8 becomes a standing agenda item.
- Kill criteria: If two consecutive reports produce no changes the team actually ships, pause the job and revisit the inputs.

## Scheduling prompt

Paste into Claude's scheduled tasks. Use a fixed cadence (every two weeks is a reasonable default for a team doing 10 calls a week) or a count-based trigger if your call platform exposes one.

Run the pmf-pulse skill on all prospect calls since [last run date]. Pull transcripts from [connector]. Load company context from [knowledge base or file]. Compare against the previous PMF Pulse report at [location]. Email the report to [owner] and [team list] with the subject "PMF Pulse: [date range], N = [count]". Keep it under 700 words.

## Adapting this skill

- Customer success: swap prospect calls for renewal and QBR calls, replace "pitch" with "value story," replace the ICP check with a churn-risk check.
- Enablement: add a section scoring each rep on discovery question usage, route the report to the enablement lead.
- Marketing: run on inbound discovery calls only, add a section on which campaign or content the prospect mentioned.

Thankfully I am back at it and have some really amazing guests to get things kicked back off in the best way possible.

Let’s get into it

In June, Joel Horwitz ran a lead gen campaign on LinkedIn for a client and it came back at $1,800 per lead.

This is a guy who ran product-led growth for all of IBM. 800 digital marketers across the world reported into his org. He was VP of Product Marketing at Weights & Biases. He ran growth at Sourcegraph and helped launch Ampcode, one of the first real coding agents. He has now written more than 7 million lines of code with AI agents to build his own ad platform.

And he told me, on the podcast, that he was almost in tears looking at that campaign.

I’ve been on the other end of that same feeling for five years. I’ve hired agencies, including one of the top LinkedIn ad shops in the business, with great products and great orgs behind me, and the best result I ever got from social ads was “brand awareness.” Which is the thing you say when you can’t point to a lead.

So I asked Joel the question I’ve wanted to ask someone for a long time. Why?

The part nobody tells you

Here’s the mechanism, and it took Joel six months of digging to find it.

LinkedIn has two API tiers. The developer tier is what most tools and most agencies run on. It lets you launch campaigns, set budgets, pick targeting criteria. It does not let you use custom audiences. That feature sits behind the Marketing API tier, which LinkedIn hands out to very few people.

So what happens to your money when you run ads without real audiences? Joel sees the same two things every time. You set up your targeting by title and industry, come back a month later, and one enormous company has absorbed most of your spend. In his case it was Walmart. Thousands of employees match your criteria, the algorithm finds them, and your budget goes to people who will never buy. Whatever’s left lands on business development reps, because they are the most active people on the platform and they click on everything.

That was the $1,800 lead. Good creative, reasonable offer, real budget, and the platform quietly sent it to the wrong 10,000 people.

The same shape shows up on Meta and Reddit. The platform’s default targeting optimizes for who is easy to reach, not who is likely to buy. Without your own audience data, you are paying to find out who is cheap.

What Joel does instead

Once he had audiences unlocked, the playbook flipped.

He stopped starting with paid. Synter’s company page went from zero to about 2,500 followers in three months, and none of it was ad spend. He posted. Then, and only then, he used audiences to reach the people who had already raised a hand. Retarget your followers on LinkedIn. Retarget them on Reddit, where they also live. Or skip the ad entirely, pull the domain, and send a human message.

His line on it was the best thing in the episode: “Don’t start from the bottom. This is not a Drake song.”

That reordering is the whole insight. Most of us run social ads as a cold introduction. Joel runs them as a follow-up.

The bigger idea underneath it

Then he showed me something on screen that I’ve been doing by hand for years, badly.

He typed one request into his agent: pull the last 30 days of organic search performance, find the keywords getting impressions but zero clicks, and target those with exact-match Google Ads.

Think about what that list is. People are searching for things you already rank for, they see you on the page, and they don’t click. Either the page is wrong for the query or someone else’s listing is winning. You should fix the page. That takes weeks. In the meantime, you can bid on the exact term for a few dollars a day and win the click while the fix ships.

Joel calls this demand capture, and he treats it as a different discipline from demand generation. Demand gen tries to create interest. Demand capture finds interest that already exists and shows up in front of it. He says it’s the most sustainable engine he’s built, whether the company is a two-person startup or IBM.

What makes it work is refusing to treat SEO and paid search as separate teams. The buyer doesn’t know which budget line paid for the result they clicked. When your organic data and your paid accounts sit in the same system, the organic report becomes the paid media plan.

Same logic applies to social. The followers you earned organically are your best paid audience. The threads where people already discuss your problem are where your ads should run. Every channel has a “demand already exists here” layer, and almost nobody is buying ads against it.

The five lines I keep thinking about

1. “I don’t call this demand generation. This is demand capture. I look for where there’s already demand.”

2. “Everyone separates SEO from paid search. They treat these as different things. They’re not. They’re the same.”

3. “$1,800 cost per lead. I’ve never seen a worse campaign in my life. And then I realized: audiences.”

4. “In 2022, 2023, everyone said paid media doesn’t work. They fired their marketing teams, fired their agencies. Two years later: we have no pipeline. Now everyone’s back, OpenAI is doing ads, and no one knows how the heck to do ads.”

5. “The more gap you put between your go-to-market team and your development team, the worse you’re going to do.”

Why this matters right now

Joel’s clients are all making the same move. They use an agent to audit what their agency has been doing, and then they bring paid media in-house. Higher click-through rates, higher ROAS. The technical founders who always hated ads (usually because the positioning was off and they could feel it) are finally close enough to the work to fix it.

That’s the window. Agencies had a two-year run filling the hole that the 2022 layoffs created. Agent-run ad platforms just made it possible for one person to see everything the agency sees, in one afternoon.

I’m putting Synter into my own agent setup this month to test all of this on my own accounts. I’ll share the numbers either way.

What to do this week

• Ask whoever runs your LinkedIn ads one question: “Are we on the Marketing API tier with custom audiences enabled?” A pause is your answer.

• Export 30 days of Search Console. Filter for 100+ impressions and under 1% CTR. Hand the list to your ads person with a small exact-match budget.

• Build one retargeting audience from your organic followers before you spend another dollar on cold targeting.

THE DEMAND CAPTURE PLAYBOOK

6 fixes for ads that don’t produce pipeline

From the GTM AI Podcast episode with Joel Horwitz, founder of Synter (ex-IBM, Weights & Biases, Sourcegraph). Compiled by Coach K, GTM AI Academy.

Start here

Most paid media fails for a boring reason. The money goes to the wrong people, in the wrong order, from a system that can’t see what the other systems know.

This playbook covers six fixes that came out of one conversation with Joel Horwitz. Joel ran product-led growth for all of IBM, then growth at Sourcegraph, and now runs Synter, an ad platform operated by AI agents. He spent six months figuring out why his own LinkedIn campaigns underperformed and came out the other side with a different model for paid media.

Each fix follows the same shape: what’s broken, why it happens, how to fix it step by step, what to measure, and how it usually fails when people try it. Read the ones that hurt. Skip the rest.

Quick self-check. If any of these are true, at least one fix applies to you:

• Your social ads report “brand awareness” and nothing else

• Your SEO team and your ads team have never sat in the same meeting

• You can’t name your cost per lead by channel without asking someone

• An AI agent has access to your ad accounts and you’re not sure what it can do

• You installed a skill or workflow file without reading it

Fix 1: Run SEO and paid search as one job

What’s broken. Organic search and paid search sit in different teams with different tools and different reports. The organic team optimizes rankings. The paid team optimizes CPC. Nobody owns the question “where are people already looking for us and not clicking?”

Why it happens. The tools were built separately. Search Console lives with SEO. Google Ads lives with paid. The reports never meet, so the insight never forms.

The fix. Treat organic search data as the input to your paid search plan. Your zero-click keywords are a list of buyers who already know you exist.

Step by step:

1. Open Search Console. Set the date range to the last 30 days.

2. Export the Queries report. You want query, impressions, clicks, CTR, and average position.

3. Filter for impressions over 100 and CTR under 1%. Sort by impressions descending.

4. Flag the commercial-intent rows: pricing, cost, vs, alternative, review, best, “for [use case].”

5. Hand that list to whoever runs Google Ads. Exact match only. Small daily budget per term ($5 to $20) to start.

6. Separately, queue the organic page fix for each flagged term. The ad buys time while the page gets rewritten.

If you’re running an agent connected to both systems (Synter does this natively; you can also wire Search Console and Google Ads into Claude or another agent through their APIs), the whole sequence is one prompt: “Pull the last 30 days of organic search performance, find keywords with impressions but zero or near-zero CTR, and build exact-match Google Ads campaigns for the commercially relevant ones. Draft mode.”

What to measure. CTR on the paid version of each term versus its organic CTR. Cost per click on exact-match terms versus your account average (these are usually cheaper because the intent is narrow). Organic CTR on the same terms 60 days later, after the page fix.

How it fails. Broad match. The moment you loosen the match type, you’re back to buying generic traffic. Keep it exact until you have data. The second failure is skipping the page fix, which means you pay for the click forever.

Fix 2: Capture demand before you generate it

What’s broken. Most paid budgets go to demand generation: creating interest in people who weren’t looking. It’s the most expensive thing you can do with an ad dollar, and it’s the default because it’s the thing agencies know how to sell.

Why it happens. Demand gen is visible. Big campaigns, new creative, a story to tell the board. Demand capture is quiet. It looks like a spreadsheet of search terms and a list of subreddits.

The fix. Before any cold campaign, map the places where demand for your problem already exists and put your budget there first. Joel’s phrase: “I look for where there’s already demand.” He calls it the most sustainable engine you can build.

Where demand already exists:

• Search queries you rank for but don’t win (Fix 1)

• Comparison and alternative searches for your competitors

• Reddit threads and communities where your problem is actively discussed

• Your own organic followers (Fix 4)

• Your website visitors who didn’t convert

• Questions your buyers ask AI assistants (AEO / LLM visibility tools like Gage or Gumshoe show you these)

Step by step:

1. Build a one-page “demand map.” One row per source above, with an estimate of monthly volume and a note on whether you’re present.

2. For each source, decide on one of two moves. Enter the conversation as a human (comment, answer, post), or serve an ad to that audience. Joel uses both, depending on the audience.

3. Fund the demand map first. Whatever is left goes to cold demand gen.

4. Revisit monthly. Demand moves.

What to measure. Cost per qualified lead from demand capture sources versus demand gen sources. Track them as two lines from day one. The gap is usually large enough to change your budget mix within a quarter.

How it fails. Treating demand capture as a one-time project. It’s an operating rhythm. The list of zero-click terms, active threads, and competitor comparisons changes every month.

Fix 3: Unlock real audiences on social (the LinkedIn problem)

What’s broken. Social ads, LinkedIn especially, reach the wrong people at scale. Campaigns finish with a good impression count, a plausible CTR, and no pipeline.

Why it happens. Most LinkedIn tooling and most agencies operate on the developer API tier. That tier lets you launch campaigns and set targeting criteria. It does not let you use custom audiences. Audiences (uploaded lists, retargeting pools, matched companies) live behind the Marketing API tier, which LinkedIn grants sparingly.

Without audiences, two things happen every time:

• One giant company matches your title and industry criteria, the algorithm finds thousands of employees there, and they absorb most of your budget. Joel’s was Walmart.

• The remaining spend goes to business development reps, because they are the most active users on the platform and click the most.

Joel’s June campaign at $1,800 per lead had good creative and a real budget. The platform sent it to the wrong 10,000 people.

The fix.

1. Ask your agency or your ads tool, in writing: “Are we on the LinkedIn Marketing API tier with custom audiences enabled?” A vague answer is a no.

2. If no, either apply for Marketing API access (expect friction), or move to a platform that already has it. Synter does; check any tool you’re evaluating for this specifically.

3. Once you have audiences, exclude before you include. Exclude the mega-companies and the BDR/SDR titles on every campaign.

4. Build your first audiences from people who already know you (Fix 4), not from cold firmographics.

5. Run the same audit on Meta and Reddit. The mechanism differs but the pattern is identical: default targeting optimizes for who is cheap to reach, not who is likely to buy.

What to measure. Cost per lead by audience type (cold firmographic vs. retargeting vs. uploaded list). The share of spend going to your top 5 companies (if it’s over 20%, you have a Walmart). Lead title mix against your ICP.

How it fails. Getting audiences and then still leading with cold campaigns because the creative is ready. The audience unlock only pays off when you change the order (Fix 4).

Fix 4: Organic first, then retarget

What’s broken. Ads are used as an introduction. The first time a buyer sees your company is a sponsored post, which is the most expensive and least trusted first impression available.

Why it happens. Organic feels slow and unmeasurable. Paid feels controllable. So paid goes first.

The fix. Flip the order. Earn attention organically, then use paid to follow up with the people who showed up. Synter’s page went from zero to roughly 2,500 followers in three months with no ad spend, and those followers became the retargeting pool.

Joel’s rule: “Don’t start from the bottom. This is not a Drake song.”

Step by step:

1. Post consistently from the company page and from founders or leaders. Frequency matters more than polish. Three to five posts a week is the floor.

2. At around 1,000 followers, build a retargeting audience from followers and engagers.

3. Retarget them on LinkedIn with a low-friction next step: a guide, an episode, a tool. Not a demo request.

4. Retarget the same people on Reddit and Meta, where the same humans are cheaper to reach.

5. For high-fit accounts, skip the ad. Pull the domain, find the right person, send a human message that references what they engaged with.

What to measure. Follower growth rate (weekly). Retargeting CPL against cold CPL. Reply rate on human outreach to engagers versus cold outreach.

How it fails. Impatience. The organic layer takes 60 to 90 days to be worth retargeting. Teams that quit at week four never see the cheap part.

Fix 5: Give your ad agents scoped keys, not master keys

What’s broken. As teams hand ad accounts to AI agents, the default is full access. A developer key pulled from Google Ads or Meta gives the agent everything the account can do, with no way to narrow it. Then a prompt misfires and something goes live.

Why it happens. The ad platforms’ developer keys were built for scripts written by humans who tested them. Agents run more often, on more inputs, with less supervision. The permission model didn’t move.

The fix. Treat an agent that can spend money the way you treat a Stripe key. Scope it. Sandbox it. Make disconnection one click.

Step by step:

1. One key per agent. The analyst agent gets read-only. The optimizer gets write access to bids and budgets, nothing else. The creative agent gets no account access at all.

2. Default every new key to read-only. Expand permissions deliberately, one capability at a time.

3. Run in draft mode until you trust the output. Joel’s platform has an explicit draft/live toggle so an agent can build a full campaign in a sandbox. If your tooling doesn’t have one, simulate it: the agent writes the campaign spec to a doc, a human pushes it.

4. Keep a one-click disconnect for every connected account (Shopify, Merchant Center, CRM). If the agent shouldn’t wander into a system for this task, unplug it for this task.

5. Log every write action with the prompt that caused it. When something looks wrong, you want the trail.

What to measure. Number of live actions taken by agents per week, and how many of them were reviewed by a human first. Time from “agent proposed” to “human approved.” Zero unplanned live pushes is the target.

How it fails. Setting up scoped keys once and then granting “all access” the first time the agent asks for something it can’t do. Every expansion should be a decision, not a reflex.

Fix 6: Read every skill file before you install it

What’s broken. Skills, workflows, and prompt packages get shared like memes. Someone posts one on X or LinkedIn, or DMs it to you, and it goes straight into your agent’s repo. Some of them contain malicious code.

Why it happens. Skill files look like documentation. Nobody reads documentation. And the person sharing it usually has a big audience, which feels like vetting.

The fix. Joel found malicious code in shared skill files and built an open-source project, Agent Shield, to scan for it. His rule is simple and it costs you five minutes.

Step by step:

1. Only install skills from a source that audits them. skills.sh runs security checks and shows install counts (Corey Haynes’ cold email skill has about 99,000 installs, which is a real signal).

2. When someone sends you a skill directly, thank them, then put it on an audited source or run it through a scanner like Agent Shield before it touches your repo.

3. Read the file. Look for anything that reaches out to a URL, reads environment variables, or executes shell commands that have nothing to do with the skill’s stated purpose.

4. Install into a sandboxed agent first. Watch what it does on a test task.

5. Keep an inventory. Every skill, where it came from, who reviewed it, when.

What to measure. Percentage of installed skills with a recorded source and reviewer. Target is 100%.

How it fails. The inventory exists for a month and then stops. Make the review a step in your install process, not a separate audit.

The one-page checklist

Print this. Work through it with whoever runs your paid media.

Search

• [ ] Search Console export, 30 days, filtered for 100+ impressions and under 1% CTR

• [ ] Exact-match campaigns live on the commercial-intent terms

• [ ] Organic page fixes queued for the same terms

Demand map

• [ ] One-page demand map built (search, competitor comparisons, communities, followers, site visitors, AI answers)

• [ ] Budget allocated to demand capture sources before cold demand gen

Social audiences

• [ ] Written confirmation of LinkedIn Marketing API tier with custom audiences

• [ ] Mega-company and BDR/SDR exclusions on every campaign

• [ ] Top-5-company share of spend under 20%

Order of operations

• [ ] Company and founder posting cadence at 3 to 5 per week

• [ ] Retargeting audience built from followers and engagers

• [ ] Human outreach process for high-fit engagers

Agent controls

• [ ] One scoped key per agent, defaulting to read-only

• [ ] Draft mode or human-push step before anything goes live

• [ ] One-click disconnect on every connected account

Skills

• [ ] Every installed skill has a recorded source and reviewer

• [ ] Scanner (Agent Shield or equivalent) in the install path

Where this came from

Everything in this guide comes from one episode of the GTM AI Podcast with Joel Horwitz. He shared his screen and walked through the workflows live. If you want to see the demand capture prompt run in real time, the SEO-to-paid handoff, and the $1,800 lead story in his own words, the episode is on YouTube, Spotify, and Apple.

Joel is at syntermedia.ai and synterai.com. His DMs are open on X.

I’m Coach K. I run GTM AI Academy, where 10,000+ GTM practitioners have learned to build AI into how they sell, market, and grow. If this playbook helped, the newsletter goes deeper every week.

My challenge to you: pick the fix that hurt the most to read and finish its checklist section before Friday. Then tell me what you found.

How many employees had a license? How many opened the tool each week? How many prompts did they send? How many seats could we roll out next quarter?

Then I saw a chart that made those questions feel dated.

According to A16Z’s visualization of OpenRouter data, agentic systems consumed roughly 7.3 trillion tokens on a seven-day average by August 7, 2026. Direct human usage sat closer to 1.4 to 1.5 trillion. Agentic usage had grown about 14 times since February and crossed human usage around February 6.

That does not mean agents have replaced people. It does not mean five times as much useful work happened. And it definitely does not mean OpenRouter represents the entire AI market.

But it does reveal a change in the shape of demand.

The biggest customer of AI is becoming AI itself.

That sounds circular until you look at what an agent actually does on a Tuesday morning.

A person asks for an outcome. The agent loads context, makes a plan, searches files, calls tools, reads the results, notices a gap, tries again, hands one part to another agent, checks the work, revises it, and packages the answer. The human may type two sentences. The system may process millions of tokens before it returns something useful.

Tokens are no longer just words exchanged with a chatbot. They are fuel consumed by machine labor.

And that changes the economics of software.

A prompt is not the unit of work anymore

The chatbot era trained us to think in turns.

You ask a question. The model answers. You ask another. The model answers again.

That interaction makes token usage feel like a communication cost. Longer prompt, longer answer, bigger bill.

Agents break that mental model because most of their work happens between the request and the result.

I have seen this directly while building agent and knowledge systems. The visible interaction is often the smallest part. The expensive part sits underneath it: retrieving the right context, deciding which capability to use, coordinating work, validating the output, and preserving what matters for the next run.

One human request can trigger an entire chain of machine activity.

Think of the difference between calling a contractor and hiring a crew. A chatbot hands you advice from the front porch. An agent walks into the job site, checks the plans, gathers materials, coordinates specialists, inspects the work, and comes back when it has something ready for approval.

The crew consumes more resources than the conversation. Of course it does.

The mistake is treating that consumption as the result.

More tokens do not mean more value

The chart is powerful, but it is easy to overread.

OpenRouter measures activity routed through its own platform. It does not cover every model provider, enterprise deployment, or private inference environment. Its classifications also describe traffic patterns on that platform, not a clean census of every human and agent using AI.

And token volume alone cannot tell us:

• How many people initiated the work

• How many requests the systems handled

• How much the work cost

• Whether a human accepted the output

• Whether the output created any value

An agent that burns 10 million tokens and completes the task may be useful. An agent that burns 10 million tokens while looping through the same failed browser action is an expensive screensaver.

This is where a lot of AI reporting gets sloppy. We take a measure of activity and quietly turn it into a measure of progress.

They are not the same.

Companies made this mistake with software adoption, too. A seat looked like usage. Usage looked like value. Then renewal season arrived and everyone discovered that 2,000 provisioned accounts did not mean 2,000 people had changed how they worked.

Agents make that mistake more expensive because they can generate activity without waiting for another human prompt.

The metric has to move up the stack.

Measure cost per accepted outcome

I think the right operating metric is not cost per token. It is cost per accepted outcome.

An accepted outcome is work that clears the standard required for the job. A report a manager uses. A support case resolved correctly. A contract review approved by counsel. A campaign brief that reaches production. A research package that survives fact-checking.

The word “accepted” matters because completion is easy to fake.

An agent can mark a task complete because it created a file. That does not mean the file was accurate, useful, or safe. The system needs a clear definition of done and a way to test against it.

For any meaningful agent workflow, I would track five things:

1. Completion rate: Did the agent reach the defined end state?

2. Acceptance rate: Did the human or downstream system approve the work?

3. Total cost: What did models, tools, infrastructure, and review consume?

4. Cycle time: How long did the outcome take from request to acceptance?

5. Intervention rate: How often did a human have to rescue the process?

Now token usage has context.

If one workflow uses twice the tokens but produces four times as many accepted outcomes, the higher token count may be a bargain. If another model cuts token cost by 40 percent but doubles human review time, the savings may disappear.

This is basic operational thinking. But the industry still talks about tokens the way early cloud buyers talked about server prices. The input cost is easy to compare, so we pretend it is the business result.

It isn’t.

Architecture becomes financial control

Once agents become the largest consumers, technical architecture stops being an engineering detail.

It becomes a margin decision.

Take context. An agent needs enough information to act well, but loading every document into every run creates an enormous tax. The system has to retrieve the right context at the right moment, then discard what it no longer needs.

The same logic applies to models. Not every step needs the smartest and most expensive model. Classification, extraction, planning, research, synthesis, and review have different requirements. Routing each job to the right model can change the cost of the whole system without changing the experience the user sees.

Then add caching, compact skills, structured tool outputs, retry limits, and stop conditions. None of these features will make a great keynote slide. All of them matter when an agent runs the same workflow 50,000 times.

This is the part of agent design that deserves more executive attention. The demo shows whether the agent can perform the task once. The architecture determines whether the company can afford to let it perform the task every day.

The questions that become practical:

• Are we sending the entire history back through the model on every step?

• Which tasks require premium reasoning, and which do not?

• When does the agent retry, escalate, or stop?

• Can we trace cost to a workflow and an accepted result?

• Who owns the budget when one agent calls three more?

Those are not token questions. They are system questions.

Pricing will have to follow the work

Agent consumption also puts pressure on seat-based software pricing.

A seat assumes a person is the active user. The vendor estimates how often that person will log in, spreads the cost across the customer base, and charges for access.

But what is a seat worth when one person supervises 20 agents? What happens when those agents work through the night, use five models, call ten tools, and generate more activity than an entire department?

Vendors have a few options. They can charge for consumption, charge for completed work, bundle usage into tiers, or combine a platform fee with outcome-based pricing. Each approach carries risk.

Pure consumption pricing punishes efficient use and makes budgets unpredictable. Pure outcome pricing creates arguments over what counts as an outcome. Flat subscriptions work until a small number of heavy agent users destroy the economics.

The market will probably settle on hybrids.

But buyers should insist on one thing now: the pricing unit needs a clear relationship to value. Paying for an agent to think is not the same as paying for it to finish.

The hidden risk is autonomous waste

Humans have natural brakes. We get tired. We go to lunch. We decide a task is not worth another hour.

Agents need those brakes designed into the system.

Without limits, an agent can retry a broken action, reload bloated context, call another agent that repeats the same research, or continue polishing work that already meets the standard. Every loop consumes tokens. Some loops can also send messages, alter records, make purchases, or create other consequences.

So governance cannot begin after deployment.

Every production agent needs a budget, a stopping rule, an escalation path, an audit trail, and a clear owner. Higher-risk actions need approval gates. Repeated failure needs to trigger a halt, not more optimism.

This is not bureaucracy for its own sake. It is how you give a machine room to work without giving it room to wander.

Build for machine demand, manage for human value

The A16Z chart will keep moving. Token prices will fall. Models will get faster. Agents will run longer workflows and coordinate with more agents. Machine-generated demand will grow even if the number of human users grows slowly.

That is the important signal.

We are moving from a world where people consume intelligence one answer at a time to one where systems consume intelligence continuously in pursuit of work.

The winners will not be the companies that buy the most tokens. They will be the ones that build the clearest connection between machine activity and a result someone values.

So open one agent workflow this week. Pick something already running in your business. Measure the tokens, model cost, tool cost, review time, retries, and final acceptance.

Then divide the total by the number of outcomes people actually kept.

That number will tell you more about your AI strategy than any seat count ever will.

Source note

The chart shown above was produced by A16Z using OpenRouter rankings data. It reports seven-day average token usage by type and identifies agentic, human, and mixed traffic. OpenRouter reflects activity on its platform, not the entire AI market. Token volume does not directly measure users, requests, revenue, productivity, or successful outcomes. Review OpenRouter’s current methodology and rankings at openrouter.ai/rankings: https://openrouter.ai/rankings?benchmark=intelligence.

The numbers usually look something like this:

- licenses purchased

- active users

- prompts submitted

- tokens consumed

- agents deployed

- workflows automated

- hours saved

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

And then the CFO asks one painfully simple question:

“What changed in the business?”

That’s where the story usually falls apart.

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

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

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

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

The missing middle

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

On the left: “We deployed AI.”

On the right: “Revenue grew.”

Between those two claims is a giant blank space.

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

That missing middle is where credibility lives.

The framework I would use is simple:

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

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

1. Capability: Can it work reliably?

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

This is the technical and data foundation:

- Is the required data present and current?

- Are the necessary systems connected?

- Is the workflow available when users need it?

- Can it operate within the approved permissions?

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

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

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

2. Trusted use: Do people accept it?

Usage matters, but raw usage is weak evidence.

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

That is technically adoption. It is not behavioral adoption.

The stronger measures are:

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

- recommendation acceptance rate

- repeat usage

- override rate

- material-correction rate

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

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

3. Changed workflow: Did work materially change?

This is the layer most companies skip.

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

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

Useful measures include:

- end-to-end cycle time

- human touches per completed task

- automation rate

- time to insight

- rework rate

- escalation rate

- time from signal to action

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

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

Adoption and behavior change are part of the product definition.

4. Operating improvement: Did the process perform better?

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

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

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

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

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

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

5. Business impact: What was the change worth?

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

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

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

- Accelerate: shorten cycle time or time to value.

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

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

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

There are three separate stages:

1. Capacity released: the task consumed fewer hours.

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

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

Those stages are not interchangeable.

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

Honest language makes the AI case stronger, not weaker.

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

Every speed or efficiency metric needs a paired quality measure.

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

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

- Higher automation, paired with error and correction rates.

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

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

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

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

A better measure is:

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

A cheap output that requires extensive correction is not cheap.

The five-number scorecard

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

For each priority workflow, start with five numbers:

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

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

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

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

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

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

Consider AI-assisted pipeline management:

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

- Quality: recommendation acceptance or correction rate

- Workflow: analyst hours required to prepare the weekly review

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

- Economics: revenue protected through earlier intervention

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

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

Three gates for choosing metrics

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

Is it reasonable to achieve?

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

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

Is the data available and accessible?

Classify the metric:

- Green: already captured reliably in an accessible system

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

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

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

Does it tell a meaningful business story?

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

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

Manage workflows as a portfolio

The final shift is organizational.

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

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

- business problem

- eligible workflow population

- baseline and comparison period

- intended behavior change

- five primary metrics

- data source and metric owner

- expected range

- attribution method

- scale, revise, or stop threshold

Then sort the portfolio into four decisions:

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

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

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

- Stop: activity exists without workflow or outcome improvement.

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

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

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

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

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

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

It’s this:

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

That is the measurement framework the AI era needs.

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

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

It is not a system.

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

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

That is the part that matters.

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

The agent is the front door.

A regional leader asks:

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

Today, that request usually becomes a relay race.

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

A company agent should handle the coordination.

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

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

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

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

How a thousand skills stay usable

The architecture depicted for Kai uses two passes.

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

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

That sequence matters.

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

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

The simple version is:

1. Read the request.

2. Find the right capabilities.

3. Load their instructions and tools.

4. Execute the work.

5. Save the result.

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

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

A skill is more than a prompt

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

They will treat a skill as a clever prompt.

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

Take pricing approval.

The skill is not “analyze this discount.”

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

The skill becomes a governed capability package.

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

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

Keep the permanent context painfully small

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

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

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

The complete sales methodology does not.

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

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

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

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

The artifact matters more than the answer

The other design choice I would copy is the filesystem.

That sounds painfully unsexy. Good.

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

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

This changes the unit of value.

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

A forecast should remain a forecast model.

A launch plan should remain a launch plan.

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

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

Put generated work behind glass

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

That is a load-bearing decision.

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

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

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

What Kai does not show

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

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

A production company agent still needs:

- identity and role-based access;

- canonical company data and knowledge;

- durable memory across work and relationships;

- event-driven triggers for work nobody explicitly requests;

- evaluation, tracing, cost, and quality controls;

- human approvals tied to action risk;

- ownership and versioning for every skill;

- feedback loops that improve the system after outcomes arrive.

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

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

The company agent is the executive function.

It is not the entire organism.

What I would build first

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

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

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

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

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

Then I would instrument the system:

- Did it select the right skill?

- Did it retrieve the right evidence?

- Did it use the correct tools?

- Did a human accept the artifact?

- Did the work change an outcome?

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

That last question is where the compounding starts.

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

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

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

One front door.

A growing library of real skills behind it.

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

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

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

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

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

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

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

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

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

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

What “own it like a product” actually means

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

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

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

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

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

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

Why there’s no comfortable middle path

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

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

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

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

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

The generalist the role actually needs

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

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

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

The twist worth sitting with

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

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

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

-- J

July was a lot. We changed homes, I traveled a ton, enjoyed a couple family reunions, and I’m just now getting the podcast back on track. Huge thank you for the patience and the kindness while I got my feet back under me. Truly means a lot.

And I wanted to come back with a bang.

This week’s guest is Eddie Reynolds, founder of Union Square Consulting and host of the Go-To-Market Science podcast. I’ve genuinely followed this guy for years. I fully fanboyed the first time we talked, and it turns out he’s one of the coolest dudes on the planet who also isn’t afraid to speak his mind. My kind of peeps.

So we got into it. Specifically on his GTM Efficiency Pyramid, which is one of those frameworks that sounds simple and then quietly rearranges how you think about your whole revenue engine. After the podcast review, I tear apart the pyramid and do my best to guide you through the pyramid and examples of how to apply it, but please note, Eddie is the master, so if you need help applying it, go hit him up.

Some of my favorite quotes from Eddie:

1. The whole thesis with the wrong question (~33:52)

“I don’t think the question should be ‘what should we do with AI?’ The question should be ‘what should we do to improve our go-to-market so that we can hit our number and consistently perform?’ If the answer happens to be AI, then that’s great. It’s the difference between trying to figure out how to architect a house and grabbing a hammer and looking for nails.”

2. The pipeline truth test (~13:19)

“How many deals do you have in your pipeline right now that are more than 2X your average sales cycle? So let’s say it takes 60 days to close a deal. How many deals do you have that are 121, 125, 150 days old? Because I can tell you right now, those deals are never going to close. Ever.”

3. AI is not a magic button (~17:25)

“You’re not gonna just get this magical result from a tool like Momentum if you haven’t thought through who your ICP and your buyer personas are, what your sales methodology is, what things you should be looking for in these call transcripts.”

4. Focus is the number one thing missing (~25:12)

“We’re targeting 14 different industries, we’ve got 10 different products, we’ve got 50 different geos. And it’s like, how many sales reps do you have? About that many. I don’t know how you get good at all of those things. You can’t perfect 50 different things at once.”

5. The spicy one on adoption (~28:46)

“There’s a really simple way to get people to use Salesforce. Fire everybody that doesn’t use Salesforce. It’s super effective. Now, if you’ve given them a dumpster fire and then you’re threatening to fire them for not using it, that’s on you. But if you’ve done all the right things and built everything out, this is how we do business.”

Here are the top 5 take aways that are inspired from Eddie:

1. You’re probably asking the wrong question about AI

Eddie said something early that I have been saying as well for years, but it was so nice to hear someone else say it.

Most leaders walk in asking “what should we do with AI?” And he flat out told me that’s the wrong question. It’s like grabbing a hammer and then wandering around looking for nails.

The better question is “what do we need to fix in our go-to-market so we can hit our number and actually hold it?” Sometimes the answer is AI. A lot of the time it’s a tighter process or a better manager.

For example, if you double the time your reps spend selling but your close rate is 5%, you didn’t win anything. You just made the leak bigger. Start with the number you’re trying to move. Then work backward to the tool. Never the other way around.

2. The GTM Efficiency Pyramid

This is the model Eddie has rebuilt for years, and I love that it doubles as an order of operations. Four layers, bottom to top:

• Fundamentals: ICP, buyer personas, a documented process for each motion (outbound, inbound, expansion, pipeline), plus the tools and data to run it.

• Adoption: getting the whole team to actually do the thing, every time. He says this is the hardest layer, and honestly, he’s right.

• Optimization: now your data is clean and you can trust it, so you can finally see what’s working.

• Acceleration: where AI amplifies what already works. This is the top of the pyramid, not the bottom.

He said fundamentals plus adoption alone would transform most orgs, and he could’ve ended the podcast right there. AI belongs at the top. You just can’t stand at the top until you’ve built the bottom.

3. The pipeline truth test

Ask yourself: how many deals in my pipeline are older than 2x my average sales cycle? If it takes you 60 days to close and you’ve got deals sitting at 121, 130, 150 days, Eddie’s verdict is brutal and correct. Those deals are never closing. They’re just inflating your number and lying to your forecast.

And here’s the move most teams get backward. Fix the pipeline you have before you go generate more. If you don’t trust a single dollar of your current pipeline, adding $30M more on top of it doesn’t mean anything. Close more of what you’ve already got first.

4. The capacity math nobody actually runs

Do the arithmetic with me. Activities a rep can do per day, times touches per contact, divided across contacts per account. It almost always lands around 200 accounts a year per rep. Eddie calls it the magic number.

Now hand that rep a list of 2,000 accounts and watch what happens. They either call 200 at random and miss 90% of your best ones, or they burn hours in a spreadsheet scoring accounts, which is not what you hired them to do and not what they’re good at.

The fix is focus, and it’s the number one thing he sees missing. Fourteen industries, ten products, fifty geos, a dozen reps. You cannot get good at fifty things at once. Pick the accounts that matter and go deep.

5. Adoption is the real moat, not the tool

Eddie watched about 300 companies during his time at Salesforce, and roughly half of them never actually used the thing they were paying for.

The difference wasn’t budget. It wasn’t the product. It was a leader who said “we are going to make this work” and did the unsexy foundational work to make it easy, versus a leader who delegated it and forgot about it.

AI is no different, friends. A rep who spends 300 hours vibe-coding their own coaching agent, when a tool would’ve done it, is 300 hours not selling. The teams winning with AI aren’t the ones with the most agents. They’re the ones who built the foundation and then focused everything on one outcome until it worked.

So what do you do with all this?

Before Friday, try three things:

• Run the pipeline truth test. Pull every deal older than 2x your sales cycle and be honest about which ones are already dead.

• Do the capacity math for one rep. Compare their real number to the list you actually handed them.

• Pick the one number you’re trying to move this quarter, and ask “what has to change to move it?” before anyone says the word AI.

Grab Eddie’s frameworks at unionsquareconsulting.com/frameworks, and go listen to the full episode. Trust me, it’s a good one.

The tool was never the problem. It’s the humans, the process, the foundation. Build that, then AI-power it. That’s the whole game.

See you next week

GTM EFFICIENCY PYRAMID

A practical, board-by-board guide for GTM leaders

Framework by Eddie Reynolds, Founder & CEO of Union Square Consulting. Full framework and high-res PDF at unionsquareconsulting.com/frameworks.

There are three boards in this framework, and each one has a different job.

The first tells you where to start and how to prioritize. The second and third show you how the exact same four-stage ladder plays out inside every specific GTM motion. Once you see that the ladder never changes, the whole thing gets simple.

For each board below you’ll get: what it’s really for, how to apply it step by step, and an example scenario so you can picture it in your own org.

A quick, honest note on the scenarios: every example below is an illustrative walkthrough, a made-up company with realistic numbers, built to help you conceptualize how the framework gets used. They’re not real client case studies. Think of them as “here’s what this could look like on a Tuesday.”

BOARD 1 — The Master Framework: How to Use It

What it’s for. Every revenue team we meet has 100 things it could improve, from visibility gaps to pipeline struggles, lost deals, churn, missed expansion, and now AI everywhere. That makes anyone’s head spin. This board stops the spin. It helps you find the one gap where improvement moves revenue the most, sequence the work with the four-stage pyramid, and turn it into a roadmap everyone agrees on.

How to apply it, step by step.

1. Start at the top of the tree: “What will impact revenue the most?” Pick a branch. New Business Acquisition, or Improving NRR.

2. Find the bottleneck under that branch. New business splits into Generating Pipeline vs. Closing Pipeline. NRR splits into Reducing Churn vs. Expanding Customers.

3. Quantify the prize. Ask the big question: if we went from where we are today to where we could realistically get, how much would that add to revenue? At 80% NRR on $100M ARR, getting to 100% is +$20M. If you expect $30M in new business, would fixing the process get you to $51M instead? Whichever number is biggest points you to your gap.

4. Locate the gap across People, Process, and Systems using the metrics under each area (close rate, sales cycle, forecast accuracy, lead response time, customer health, and so on).

5. Apply the pyramid to that area: Fundamentals → Adoption → Optimization → Amplification. Start at the bottom. Always.

6. Sequence it with the three steps. Start where impact is highest (in our experience, usually Pipeline Management, then Pipeline Generation). Knock out Fundamentals and Adoption fast, then loop back up the priority list to Optimization.

7. Build a GTM Operations Roadmap so your CRO, leadership, and everyone in ops align on the order.

The rule of thumb that makes this work: Fundamentals and Adoption can be put in place in weeks. Optimization and Amplification are never truly “done.” So get the base of several motions solid fast, before you chase perfection anywhere.

Here’s an example scenario of how this plays out.

A $50M ARR SaaS CRO says, “We need more pipeline.” That’s the instinct. But run the tree: the branch is New Business, and the reflex answer is “Generating Pipeline.” When we look at the metrics, though, the close rate is 18%, the forecast misses every quarter, and the pipeline is full of deals sitting at 140 days when the sales cycle is only 60. The real bottleneck isn’t generation. It’s Closing Pipeline.

Now quantify the prize. Adding raw top-of-funnel to a pipeline you can’t close is worth almost nothing. Lifting the close rate from 18% to 24% on the pipeline you already have is worth real money. So the decision is made for you: attack Pipeline Management first, apply the pyramid there, and put it on the roadmap as priority #1. Outbound improvements become #2.

One board just turned “100 things to fix” into a sequenced plan the whole leadership team can get behind.

Pipeline Generation (Outbound, Inbound, ABM/Allbound, Partner/Channel)

The big idea for this whole board: every motion climbs the exact same ladder. Fundamentals → Adoption → Optimization → Amplification. What changes from motion to motion is only the specific fundamentals at the base. Nail those, and the rest of the climb is the same shape every time.

The Outbound Pyramid

How to apply it.

• Fundamentals: Define WHO (ICP and personas by product) and the step-by-step process to convert targets into meetings and pipeline. That means Capacity and Territory Planning (a rep can only truly work so many accounts, and it usually lands around 200 a year), building and segmenting target lists so a rep works one buyer with one message at a time, and defining the sequencing process (how many calls, emails, and LinkedIn touches, and in what order). Then implement it into the system.

• Adoption: Train the team, build outbound reporting and dashboards, and run a regular cadence of management review so the sequence actually gets completed, instead of “we reached out twice and gave up.”

• Optimization: Analyze outbound insights, test messaging, and bring findings to a GTM Council Meeting.

• Amplification: Now, and only now, add automated trigger-based cadences, AI-personalized messaging, and AI-driven account research and scoring.

Here’s an example scenario. A team hands each SDR a list of 2,000 accounts and wonders why results are random. Applying the base first: they do the capacity math and cut the list to the right 200 accounts per rep, segment by persona, and define a clear 5-call, 5-email, 5-LinkedIn sequence. Adoption: a weekly review confirms the sequences are actually being completed. Only after that do they turn on AI to personalize the first-touch email at scale. The AI amplifies a focused motion instead of spraying 2,000 bad-fit accounts faster.

The Inbound Pyramid

How to apply it.

• Fundamentals: Define which leads should go to sales (a real MQL definition), the customer journey, Speed-to-Lead SLAs, inbound capacity planning, a defined lead-routing process, and a defined follow-up sequence. Implement it into systems.

• Adoption: Train, build dashboards, and inspect that hot leads get worked fully. The classic failure is a hand-raiser getting two touches and then silence.

• Optimization: Attribution, inbound insights, GTM Council Meetings.

• Amplification: AI lead enrichment and scoring, AI campaign and channel analytics, AI-assisted lead response and follow-up.

Here’s an example scenario. Marketing floods the funnel with MQLs, but sales ignores them because half are junk. Applying the base: they redefine what actually counts as an MQL, set a 5-minute Speed-to-Lead SLA, and define the follow-up sequence. The adoption cadence enforces it. Only then do they add AI to enrich and score inbound leads so reps hit the hottest ones first. Conversion climbs, because the process got fixed before the AI went on top.

The ABM/Allbound Pyramid

How to apply it.

• This one requires mastering both inbound and outbound and making them work together seamlessly. Fundamentals: ICP and personas, customer journey, capacity and territory planning, an account-scoring model to decide which accounts to target, an account-sequencing process, and Speed-to-Lead SLAs. Because it’s more complex, it also needs more robust reporting: account coverage, account conversion, pipeline generation, and ABM/allbound revenue.

• Adoption, Optimization, Amplification follow the same pattern, with more data to analyze and more surface area to amplify because the motion is richer.

Here’s an example scenario. A team says they “do ABM,” but there’s no account scoring, so reps chase whatever logos look exciting. Applying the base: they build an account-scoring model, lock a focused target-account list, define how marketing and sales tag-team each account, and stand up account-coverage reporting. Adoption ensures every target account is actually being covered. Then AI account enrichment and campaign analytics amplify a coordinated motion instead of a scattered one.

The Partner/Channel Pyramid

How to apply it.

• Fundamentals: Define the Ideal Partner Profile by product, the process to turn a prospect partner into an active partner, and the process to build and nurture that relationship into ongoing deal flow. Capacity and territory planning, segmented partner lists, and a defined partner engagement process. Implement into systems.

• Adoption, Optimization, Amplification: same ladder. Amplify last with automated sequences, AI partner deal summaries, and feedback.

Here’s an example scenario. A channel team signs plenty of partners, but most never source a single deal. Applying the base: they define the Ideal Partner Profile, a clear recruit-to-activation process, and a nurture cadence. The adoption review tracks deal flow per partner. Then AI summarizes partner deals and surfaces which relationships are worth doubling down on, so the team stops spreading itself thin.

Pipeline Management & Customer Success (Renewals + Expansion)

The Pipeline Management Pyramid

What it’s for. Good pipeline management means your reps run the right steps to win the deals they can win, stop wasting precious selling time chasing deals they can’t, and management has the visibility to forecast accurately.

How to apply it.

• Fundamentals: ICP and personas, then pick a Sales Methodology you like (for example, MEDDIC) and translate it into a real, stage-by-stage, step-by-step process: qualification criteria, sales stages defined, stage entry and exit criteria, the steps and questions required at each stage, and a clear rule for when to walk away or close a deal out. Implement it into the CRM.

• Adoption: Train the team, build pipeline reporting and dashboards, and run a management pipeline inspection cadence. This is where you enforce the exit criteria and clear the dead deals. Anything older than 2x your average sales cycle is almost certainly never closing.

• Optimization: Forecasting, GTM insights, GTM Council Meetings.

• Amplification: Pipeline automation, AI-driven pipeline analytics, and AI-assisted enrichment, like AI reading call transcripts to update exit criteria in the CRM.

Here’s an example scenario. A $50M team’s forecast misses every single quarter. Applying the base: they translate MEDDIC into defined stages with entry and exit criteria and a walk-away rule, then build it into the CRM. Adoption: a weekly inspection pulls every deal older than 2x the 60-day cycle out of the forecast. The pipeline shrinks from a fantasy $30M to a real $19M, and forecast accuracy jumps within a quarter. Then, and only then, AI updates exit criteria from call transcripts and flags deals going quiet. The AI amplifies a clean pipeline instead of a fantasy one.

The Renewals Pyramid

What it’s for. Maximizing renewal rates. The key truth: most renewals are won or lost long before the renewal process ever begins at the end of the contract.

How to apply it.

• Fundamentals: ICP and personas, plus the full onboarding-to-renewal process: capacity planning (enough of the right CSMs to execute), account assignment to CSMs, a handoff and onboarding process, a customer health monitoring process, a process to address unhealthy customers, a QBR/engagement cadence, and the process to initiate and run the renewal itself. Implement into systems.

• Adoption: Train, build full reporting and dashboards, run a regular cadence of management review.

• Optimization: Renewals insights, renewals forecasting, GTM Council Meetings.

• Amplification: Automated health scoring, AI-assisted CSM playbooks, AI-driven customer risk signals.

Here’s an example scenario. A CS team scrambles at contract end and keeps getting blindsided by churn. Applying the base: they capacity-plan the CSM load, define the health-monitoring process, define the exact play to run the moment an account goes yellow, and set a QBR cadence. The adoption review catches at-risk accounts months early instead of days late. Then AI health-scoring and risk signals amplify a proactive motion, catching churn while it’s still fixable.

The Expansion Pyramid

What it’s for. Generating and closing expansion pipeline. You manage and forecast it using the Pipeline Management pyramid above; you generate it much like Outbound or ABM.

How to apply it.

• Fundamentals: Define the expansion process. A customer journey map so you understand when and how customers become likely to expand, capacity and territory planning, account scoring and assignment, an account-sequencing process, and product and stakeholder whitespace mapping (which accounts aren’t using certain products, and where you haven’t yet engaged key stakeholders). Implement into systems.

• Adoption, Optimization, Amplification: the same ladder as every other motion.

Here’s an example scenario. An org leaves expansion entirely to chance and hopes CSMs stumble into upsells. Applying the base: they map the whitespace (which accounts don’t use product X, where key buyers aren’t engaged), score and assign expansion targets to the right reps, and define the sequence to work them. The adoption review tracks expansion pipeline like any other pipeline. Then AI account research and personalized messaging amplify a deliberate expansion engine instead of a lucky accident.

The One Rule That Ties Every Board Together

AI and automation sit at the very top of every single pyramid, and they are a sharp, double-edged sword.

Layer an AI agent on top of a clean, adopted process and it amplifies what’s working. You could quickly see more pipeline, more deals won, better retention, more expansion. Layer that same agent on top of a broken process and it amplifies the mess just as fast. You could quickly see your domain tarnished, your best prospects blocking your emails, and your best customers churning.

That’s why AI is always last. Build the right foundation first. Then amplify it.

Where to Start (the quick-start)

• Ask where the biggest gap is: new business or NRR, generating or closing, churn or expansion. Then quantify the prize.

• It’s usually Pipeline Management. There’s no point generating more pipeline just to lose it in the sales process. Get closing in order first.

• Get Fundamentals and Adoption in place fast, in weeks, across a couple of motions, before you chase Optimization anywhere.

• Build a roadmap so leadership aligns on the order.

Reading about it is great. Doing it is better.

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

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

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

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

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

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

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

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

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

Come build with us.

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

Read that twice, because it generalizes well past software.

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

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

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

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

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

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

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

That “if” is the whole business.

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

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

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

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

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

-- J

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

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

Power = Benefit + Barrier

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

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

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

The 7 Powers, fast:

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

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

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

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

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

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

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

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

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

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

Run 7 Powers across them and the field separates fast.

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

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

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

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

Healthcare: the gravity well

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

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

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

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

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

The two through-lines

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

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

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

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

The one question

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

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

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

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

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

Welcome back my friends, today I am pleased to feature a good friend of mine, the CEO and cofounder of Synapsa.ai Mrs. Maddie Bell.

We went deep into what she is doing in Claude Code building a brand and basically the entire product, well worth the time, so let’s dig in!

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 Soap-to-SaaS Operator Who Open-Sourced Her AI GTM System

Maddie Bell ran billion-dollar brands at Procter & Gamble before she became the co-founder and CEO of Synapsa. She calls the journey “from soap to SaaS.” I called her onto the podcast because she is the rare person who can do two things at once: build the AI, and tell you the truth about it.

She opened her actual repo on screen and walked me through the entire AI go-to-market system her team runs. Brand site, content engine, sales motion. Most of it AI-coded. All of it honest about where the AI ends and the human begins.

Here is what was worth stealing.

1. The reason your AI marketing isn’t landing: you made more noise, not more intelligence.

“In our excitement to scale AI, many companies overlaid it onto traditional Frankenstack systems. And rather than creating more intelligence, we’ve created more noise.” said Maddie Bell.

The data backs her up. One in five buyers is now less confident in their buying decision because of the AI-generated mess hitting them. Seven in ten say if you spam them, they never want to talk to you again. When sellers hear “AI for go-to-market,” they get excited. When buyers hear it, they brace for hundreds of spammy emails, needy chatbots, and blogs full of em-dashes.

The fix is not less AI. It is the return to brand-building fundamentals, run through AI instead of bolted onto old tools.

2. AI effectiveness is a pyramid, and almost everyone stops one floor too low.

She framed it like Maslow’s hierarchy. Three layers:

• Protocol. Can the AI follow your playbook and do what you asked? This is the floor. The “I built a business in my closet over the weekend” crowd lives here. Great for an N of 1. Useless for the enterprise.

• Personality. Here is the counterintuitive part. People react more negatively to no personality than to a personality they dislike. And the single most preferred personality for an AI is not “intelligent” or “professional.” It is the one that mirrors the buyer.

• Persuasion. The art of moving a buyer’s focus from a state of need, to an accurate understanding of their problem, to a decision. Persuasion changes shape across the funnel. A blog needs curiosity and nurture. A bottom-funnel moment needs proof points and a value prop. This is where her team spends most of its time.

Most AI deployments get protocol working and declare victory. The advantage lives two floors up.

3. The five layers of an AI GTM system, built in order.

This was the meat. Maddie’s team built their system in a deliberate sequence, and the order matters because each layer feeds the next.

• Layer 1: A load-bearing knowledge base. Not everything. The first document the AI reads every morning has disproportionate power over the 150th. So you codify only what is load-bearing: positioning, ICP, value prop, proof points. Plan on a week of real work here. Dump in 600 docs with no scaffolding and you get degradation, not intelligence. The technical name for the fix is progressive disclosure.

• Layer 2: A design system. AI-first, so the brand shows up identically across every touchpoint. Drop in a call transcript, get a customer deck back that looks hand-designed. Hers are 100% AI-coded.

• Layer 3: A content engine. Blogs, case studies, battle cards, comparison pages, produced end-to-end with human approval. The guardrail is sharp: new content has to pull three random samples from an approved library and score itself on a rubric. Does this sound authentically us? If not, it gets rejected before a human ever sees it.

• Layer 4: The flip. Once the machine is humming, you become the bottleneck. So the agents start proposing. “When I wake up in the morning, the AI’s proposing, hey, this is what I think we should go do next. And I, as the human, am still deciding.”

• Layer 5: The sales complement. Because the go-to-market knowledge is codified, the agents read every buying signal, de-anonymize, qualify into the right motion, route, book, and hand the rep a prep doc. Then, in Maddie’s words, the most important thing the AI can do in the live call is “get the F out of the way.”

4. Build vs. buy: pick your hard.

The cleanest decision framework in the episode. Single-player output with human approval (decks, docs, one-pagers) is now solvable yourself. Build it. The big tools are excellent at it.

Buy when you hit the multiplayer orchestration zone: buyer-facing, real-time, with handoffs, fallbacks, and security on the line. Her reason is blunt: 40% of AI products are getting fired because they are not reliable, secure, or able to bring humans in at the right time. You are hiring a system. You do not want to hire one you will have to fire.

And when you do buy, push hard. Everyone can claim everything now. Ask for production thresholds, grades, integrations. The businesses regretting their choices are the ones that did not pressure-test up front.

Why this matters:

The whole episode is one argument: AI did not kill the fundamentals. It made them worth 10x more. The operators who win are not the ones automating at volume. They are the ones crafting buyer journeys at volume.

Three moves for this week:

• Find your top five load-bearing documents and write them like they matter, because the AI will amplify them everywhere.

• Decide who in your org builds and who just uses. Not everyone should be a builder.

• Run your current AI vendors through Maddie’s fire test: reliable, secure, multiplayer, humans in at the right time. If one fails, you already know.

Maddie said the quiet part out loud: “It’s a folder. We call it a repo because it makes us sound cool in front of our friends.” The tools are simpler than the hype. The thinking is harder than the demo. That gap is the opportunity.

My challenge to you: open one empty folder this week and build the first layer. Just the knowledge base. The rest only works once that one is true.

— Coach K

The 5-Layer AI Go-To-Market System

A build playbook for operators who are done with “AI-first” meaning nothing

Inspired by a conversation with Maddie Bell, Co-founder & CEO of Synapsa, on the GTM AI Academy Podcast. Distilled into a system you can build this quarter.

Start here: the standard

Good AI for go-to-market is three things. Instant. Intelligent. And damn near invisible to buyers.

If your buyer can feel the AI, you built it wrong. The goal is not to look like you’re using AI. The goal is to serve a better, faster, more human experience, with AI doing the heavy lifting underneath.

The data on why this matters:

• 1 in 5 buyers is now less confident in their buying decision because of AI-driven noise.

• 7 in 10 buyers say if you spam them, they’re gone for good.

• 40% of AI products get fired for being unreliable, insecure, or unable to bring a human in at the right moment.

AI didn’t kill the fundamentals. It made them worth 10x more. This playbook is how you build on the fundamentals instead of bolting AI onto your Frankenstack.

The diagnostic: the Pyramid of AI Effectiveness

Before you build, know which floor you’re on. Most teams stop one too low.

Floor 1 — Protocol. Can the AI follow your playbook and do exactly what you asked?

• Test: Give it a task it should know cold. Does it follow your process, or improvise?

• Most teams get here and stop.

Floor 2 — Personality. Does it sound like someone a buyer wants to talk to?

• The counterintuitive truth: people react worse to no personality than to one they dislike.

• The winning move: the best AI personality mirrors the buyer, not your brand’s ego.

Floor 3 — Persuasion. Can it move a buyer from a state of need → an accurate understanding of their problem → a decision?

• Persuasion changes across the funnel. Top of funnel = curiosity and nurture. Bottom = proof points, value prop, testimonials.

• This is where the advantage lives, and where you should spend most of your time.

Score your current AI setup 1–3. If you’re at a 1, you have a protocol system, not a persuasion system. That’s the gap.

The build: 5 layers, in order

The order is not optional. Each layer feeds the next.

Layer 1 — The load-bearing knowledge base

A repo is just a folder. Don’t let the word scare you or impress you.

The rule that separates a smart knowledge base from a slow one: the first document the AI reads has disproportionate power over the 150th. So don’t map everything. Map what’s load-bearing.

Your top 5 load-bearing documents:

1. Competitive positioning (how you’re different, how you’re the same as the category, what you own)

2. Customer value proposition

3. Product features and how you articulate them

4. Ideal customer profile (ICP)

5. Customer proof (the case studies you want the AI aware of at all times)

Do this:

• Open an empty folder. Tell your AI: “I’m building a marketing AI repo. Set up the file format and structure for me.”

• Write the five documents above like they matter, because they get amplified everywhere. Budget a full week.

• Structure for progressive disclosure so the AI reads documents in the right order. Without this scaffolding, you’ll hit degradation around 60–600 documents.

Failure mode: dumping every doc you own into one folder and wondering why quality drops.

Layer 2 — The design system

So the brand shows up identically across every touchpoint, automatically.

Do this: build an AI-first design system once. Then a dropped-in transcript becomes a customer-ready deck that looks hand-designed. This is what makes “100% AI-coded” assets look like a human made them.

Failure mode: salespeople asking “why do we need a design system?” Answer: because you want the AI to represent you everywhere without a designer in the loop.

Layer 3 — The content engine

Now you scale production: blogs, case studies, battle cards, comparison pages, funnel optimization. End-to-end, with human approval.

The guardrail that makes this safe: before any new content reaches a human, the AI pulls 3 random samples from your approved library and scores the draft against them on a rubric. Does this sound authentically us? If not, it’s rejected. The human never sees off-brand work.

Do this: build the approved-sample rubric first. Quality control is the feature, not the afterthought.

Layer 4 — The flip (you become the bottleneck)

This one surprises people. Once the machine hums, the constraint becomes your own ideas and your need to sleep.

Do this: stand up agent teams that research, generate ideas, and push proposals to you for approval. You wake up to “here’s what I think we should do next.” You stay the decision-maker. The AI stops waiting for instructions and starts proposing them.

Layer 5 — The sales complement

Because your go-to-market knowledge is now codified, the system can read every buying signal.

Do this: de-anonymize visitors, start a guided selling conversation, qualify into the right motion (SMB vs. enterprise), route and book without friction, log the source, and hand the right rep an AI-generated prep doc.

The rule for the live moment: once the rep is in the seat, the most important thing AI can do is get out of the way. It supports with notes, logging, and system updates. It does not hijack the human conversation.

The decision: build vs. buy (pick your hard)

You can’t own everything. Use this litmus test.

Build it yourself when it’s single-player output with human approval. Decks, docs, one-pagers, internal analysis. The big tools are excellent at this now. There’s rarely a reason to buy.

Buy it when you hit the multiplayer orchestration zone. Check the boxes:

• ☐ Multiplayer — multiple humans and multiple AIs handing work back and forth

• ☐ Buyer-facing and real-time — no 5–10 minutes to figure out the right answer

• ☐ Must follow a strict process — certain steps have to happen before others, every time

If you check those boxes, the cost of failure is a lost opportunity. That’s a job for a supplier who eats, sleeps, and breathes that one workflow.

Bonus test: ask “what’s the buyer-first answer?” Build where your operators have unique, hard-won expertise (your own analytics dashboards). Buy where you want someone obsessing over a workflow full-time, with fallbacks for when an LLM goes down.

The vendor fire-test

You’re hiring a system. Don’t hire one you’ll have to fire. Before you buy, make them show you:

1. Did it actually work? Not “it can make 1,000 posts.” Were they good? What were the outcomes?

2. What are the production thresholds and grades? How is quality measured and enforced?

3. What are the integrations and fallbacks? What happens when a connector or an LLM fails mid-pipeline?

4. Where do humans come in? Reliable, secure, multiplayer, humans at the right time. If they can’t answer, that’s your answer.

Businesses regret not pushing harder up front. Push hard up front.

Your one-week starter plan

• Day 1: Open one empty folder. Have your AI scaffold the structure.

• Days 2–4: Write your 5 load-bearing documents. Make them excellent.

• Day 5: Set progressive disclosure so the AI reads in the right order.

• This month: decide who builds and who just uses. Not everyone should be a builder. 99% of your team’s job is serving a buyer who may not care about AI at all.

You don’t need to boil the ocean. You need Layer 1 to be true. The rest only works once it is.

You bought a stack. You needed an operating system.

The thing nobody admits about their “AI workflow”

Open a random executive’s laptop right now and you will find ChatGPT, Claude, Perplexity, Notion AI, Granola, Gemini in their inbox, Copilot in their IDE, and probably two more they forgot they were paying for. Each one is a fresh chat. Each one has no idea who they are, what company they run, what they were working on yesterday, or what they actually care about.

That is not a workflow. That is twelve strangers in a row, each one introducing themselves to you again every morning.

The reason your AI use feels like productivity theater is that it is productivity theater. The output is fine. The system underneath is empty. You are the only memory in the loop, and you are the bottleneck you were trying to remove.

Why a Personal OS, and why now

I have been writing for two years about what I call the Revenue Nervous System. Six layers, built around a company, that turn AI from a feature into the way the org actually thinks. Data, intelligence, context, memory, orchestration, execution. Companies that build it compound. Companies that buy seats of Copilot and call it strategy do not.

A Personal OS is the same architecture pointed inward. The same six-layer logic, remapped from a revenue org to a single person. The unit of analysis is you.

If you want AI to become part of how your brain actually works, stop shopping and start architecting.

Read more

We would love for you to subscribe and let us be a part of your orbit in this crazy GTM AI world.

Subscribe now

Very Grateful to have dug into some really cool examples of what is making a big difference with GTM teams with AI workflows with the Cofounder of www.workflows.io Dan Rosenthal.

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’ve talked to a lot of people on this podcast. Revenue leaders, founders, RevOps nerds, AI enthusiasts. Most of the conversations are great. Some are really good.

And then every once in a while someone shows up and I’m sitting there thinking... why hasn’t anyone mapped this out this clearly before?

That was my conversation with Dan.

His background is genuinely wild. Master’s in biology. Almost went to Cambridge for a neurodegenerative disease PhD. Applied to exactly one program, didn’t get it, had zero backup plan. (My kind of guy, honestly.) Ended up in sales at a biotech company, ran $5M in revenue with basically no systems, with no CRM until the very end, no infrastructure, just hustle and spreadsheets.

And that experience? It lit a fire. Because the problem that broke you is usually the one you’re most obsessed with solving.

Now he’s living in Barcelona, running a team that builds the systems he desperately wished he’d had.

Here’s what stuck with me.

The GTM Flywheel And Why Most Teams Are Running Sideboat Experiments

Dan opened with something I’ve been saying for a while, but he put a visual to it that I hadn’t seen.

Most GTM teams aren’t running a strategy. They’re running a collection of disconnected experiments that never talk to each other.

You’ve got marketing running LinkedIn ads... to accounts that sales isn’t prospecting. You’ve got SDRs doing cold outbound... without knowing who just engaged with your content. You’ve got content going out... but no one’s capturing that engagement and routing it back as signal.

That’s not a flywheel. That’s a leaky bucket with a fancy name.

Dan’s GTM Flywheel Playbook maps out every major channel from content, ads, outbound, partnerships and forces you to think about how they all FEED each other. Not just operate next to each other.

The line that hit me hardest: “Your best-performing content should become your ads. You should be running ads to the same list your team is outbounding. And you should be outbounding all the people engaging on your content.”

That’s it. That’s the whole thing. If those three sentences aren’t true in your org right now, you have a structural problem, not a pipeline problem.

What AI Is Actually Good For (And What It’s Not)

We talked a lot about how AI is being used by top GTM teams and I think the reality is very different from the hype.

Here’s what Dan said the best AI use case is, in his words: “A web research agent that looks at a company’s website and decides if they’re qualified and can be enriched further to potentially be lead scored.”

Not AI writing your ad copy. Not an AI SDR blasting thousands of emails. Not replacing your reps.

A filter. A sorter. A noise-reduction engine.

In the pre-AI era, if you handed your sales team a list of 500 people who engaged with your LinkedIn content, 90% of it would be junk. So you just... didn’t do it. The signal existed but wasn’t actionable.

Now AI can sort through that 90% junk and hand your team the 10% that matters. And suddenly all those channels that seemed impractical? They’re producing real signal.

That’s the unlock. Not “AI does the job.” AI makes the human’s job more targeted.

Dan also made a point I completely agree with: “Give an old-school seller new-school systems, and that’s where magic can happen.” The fundamentals don’t go away. The people who have them AND can use these tools? They’re going to be scary good.

The ABM Playbook: When the Flywheel Changes Shape

Here’s where it got really tactical. For companies with fewer than 10,000 target accounts, the mass GTM flywheel doesn’t fully apply. You need account-based thinking.

Dan walked through the full infrastructure, and it’s worth slowing down on because this stuff is actually implementable:

Step 1 — Build a real ICP model. Not a guess. Not a committee argument. Export your closed-won customers, remove outliers, enrich with additional data points, and feed it into an AI model to identify the real patterns. Dan described working with a unicorn GTM company, one everyone would recognize that couldn’t agree on its own ICP. If they can have that problem, so can you.

His tiering philosophy hit me: don’t use complex point systems. Use concentric circles. When your rep sees “Tier 1” they should immediately know exactly what kind of company that is. He said: “A Series B company with a growing GTM team in the AI space, that’s our Tier 1. My team should get excited when they see it.”

Step 2 — Map your TAM wide, then filter down. Most databases, even the AI-first ones, miss huge swaths of companies if you search with narrow tags. Dan’s approach: pull from multiple sources, consolidate in an orchestration tool like Clay, then use AI to filter down. The point isn’t to start with a clean list. The point is to start with a complete one.

Step 3 — Track signals in 3 layers. First-party: what you own like gated content downloads, product usage, website visits. Second-party: LinkedIn ad engagement, content engagement. Third-party: technographics, news, job postings, social activity.

The signals that get ignored most? Gated content. Someone downloads your playbook and your sales team doesn’t know for three days. That’s a missed window. Fix that first.

Step 4 — Score awareness, not just lifecycle. This is the one that genuinely surprised me. Dan said: lifecycle stages (MQL, SQL) don’t capture what happens before someone raises their hand. So he layers an awareness score on top: Identified → Aware → Interested → Considering → Selecting.

The result? One client, first day using the awareness scoring system, had three reps each book two meetings all by just filtering their outreach to “Aware” accounts they’d had no idea were already in the ecosystem. Six-figure ACVs. One day.

That’s not incremental improvement. That’s a completely different game.

The Brutal Honest Part

We talked about what happens to teams that skip the infrastructure and just grab tools.

Dan’s been inside companies you’d assume have this figured out. “I shouldn’t say the name, but a massive company had an infrastructure was an absolute mess because they started as a VC-backed startup, shipped fast, and never went back.”

Every month you wait is another month of messy data, mis-routed leads, and reps prospecting blind. And at some point you have to pay that back, except now you’re paying it back while also trying to compete.

The teams who take 2-6 months to actually build the foundation? They skyrocket after. I’ve watched it happen. The short-term pain is real. The long-term payoff is embarrassingly good.

As Dan put it: “It takes time to save time.”

What Workflows.io Actually Does

Before I let you go, Dan’s team at Workflows.io does 4 things:

1. LinkedIn content (helping founders post like his co-founder does)

2. Automated outbound (end-to-end system buildout)

3. RevOps infrastructure (the systems I just described)

4. ABM (4-6 month sprint to full implementation)

If you want to connect with Dan directly, his LinkedIn is: https://www.linkedin.com/in/dan-m-rosenthal/ and you can learn more at

https://www.workflows.io/

The full episode is live at

GTM AI Podcast & Newsletter

Where founders, executives, and GTM operators learn how AI actually works in revenue. Research, case studies, and tactical how-to's without the hype.

By Coach K

Example workflow you can find on the www.workflows.io website

The GTM Infrastructure Checklist: 12 Things Top Teams Build Before They Scale

A modern guide based on what’s actually working with YC startups, Fortune 500 logos, and everyone in between.

The 12-Point GTM Infrastructure Checklist

Section 1: ICP Clarity

1. You have a tested ICP model, not a debated one. Your ICP should be built from data, not committee opinion. Export your closed-won customers, enrich with firmographic and technographic data, and analyze the patterns with AI. Your Tier 1 accounts should be immediately recognizable to every rep on your team at no point system needed, just clear concentric tiers.

Test: Can every rep describe your Tier 1 account in one sentence without looking anything up?

2. Your ICP tiering is backtested against CRM reality. A good ICP model shows a higher proportion of Tier 1 accounts among your closed-won than among your total TAM. If 10% of your TAM is Tier 1, you should see 25-30% of closed-won fitting Tier 1 criteria. If that differential doesn’t exist, your model isn’t working.

Test: Does your ICP model predict what’s already in your CRM?

3. Your tiering stays stable over 6-12 months. Don’t include time-based signals (open job reqs, recent funding) in your core ICP tier criteria. Those change. Build your tiers on firmographics, technographics, and structural fit signals that hold for at least a year.

Test: Would your Tier 1 accounts from 8 months ago still be Tier 1 today using your current criteria?

Section 2: TAM Mapping

4. You’ve built your TAM from multiple sources, not just one database. No single database captures your full market. Apollo misses companies that keyword searches catch. Clay’s prospecting database gets roughly 80-90% of Apollo’s coverage on companies and less on contacts. Real TAM mapping means pulling wide from multiple tools, consolidating in Clay or a similar orchestration layer, and then filtering for fit.

Test: Have you pulled TAM data from at least 3 distinct sources and deduplicated?

5. Every target account and key stakeholder lives in your CRM before your reps start prospecting. If your reps are logging into ZoomInfo to build lists, you’re wasting selling time and getting inconsistent coverage. Pre-load your CRM with every account and contact in your TAM. Your CRM should be the best prospecting database your team has all with custom fields specific to how you sell.

Test: Can a rep go from “I want to prospect” to “first call logged” without leaving your CRM?

Section 3: Signal Infrastructure

6. You’re capturing and routing first-party signals in real time. Gated content downloads, product usage events, and website visits are first-party gold and most teams let them sit in a spreadsheet for days. Every signal should log to your CRM (HubSpot custom events or Salesforce custom objects work well) and trigger an alert to the right rep within hours, not days.

Test: If someone downloads your best piece of gated content right now, does a rep know within 24 hours?

7. You’re capturing and routing second-party signals (LinkedIn ads, content engagement). LinkedIn ad engagement from target accounts is data that exists and almost nobody acts on fast enough. Tools like Fiddler give you account-level ad engagement data directly in HubSpot or Salesforce. LinkedIn content engagement from connections should also be captured and scored.

Test: Do your reps know which of their target accounts have been engaging with your LinkedIn content in the last 30 days?

8. You have at least one third-party signal source feeding your workflow. Technographic data (what tools they’re using), job change tracking for champions, and relevant news events should be feeding your signal layer. If you integrate with a tool, you should be watching for when prospects adopt or drop that tool.

Test: Do you have at least one automated workflow that fires when a target account crosses a third-party signal threshold?

Section 4: Awareness Architecture

9. You score awareness separately from lifecycle stage. Lifecycle stages (MQL, SQL, SAL) capture intent to buy. Awareness scores capture where someone is in their knowledge of you and they’re not the same thing. Build an awareness layer: Identified → Aware → Interested → Considering → Selecting. Score accounts based on signal accumulation.

Test: Can you pull a list right now of accounts that are “Aware” of you but haven’t yet entered a pipeline stage?

10. Your reps’ daily prospecting starts with the highest-awareness accounts, not cold TAM. The first filter your reps should apply in the morning is awareness score. Outbounding someone who has already engaged with your content, attended a webinar, or downloaded a resource is fundamentally different from cold outreach. It converts at a different rate. Treat it differently.

Test: Is awareness score a visible, filterable field in your CRM that reps use daily?

Section 5: Channel Alignment

11. Your ads, content, and outbound all target the same account list. Your LinkedIn ads should be running to your target account list, not a broad demographic. Your outbound team should be reaching the same accounts your ads are warming. Your best content should be retargeted as ads. These three motions amplify each other. Running them separately wastes budget on noise.

Test: Are the accounts your SDRs are prospecting this week the same accounts in your LinkedIn ad audiences?

12. You have a defined feedback loop from CRM activity back to channel strategy. Every signal, touchpoint, and stage change should log back to the CRM and inform your next move. Which content piece drove the most Aware accounts? Which ad sequence led to the most meetings? That data should be shaping your strategy monthly.

Test: Do you have a monthly review where CRM activity data influences your next 30 days of channel investment?

The Honest Reality Check

Building this infrastructure takes time. Anywhere from 2 to 6 months if you’re doing it right. And during those months, it feels like everyone else on LinkedIn is announcing wins while you’re still in the plumbing.

But here’s what I’ve watched happen over and over: the teams that build this? They hit an inflection point and their output gets scary good. The teams that skip it? They keep adding tools to a broken foundation, building what one smart operator called “time debt” or a bill that comes due right when you can least afford to pay it.

The checklist above is a starting point, not a prescription. Your business has unique channels, audiences, and sales motions. But the architecture such as connected signals, tested ICP, pre-loaded CRM, aligned channels are all part what is universal.

Pick the 3 items on this list where your team scores worst. Fix those first.

Then come back and tell me what changed.

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