Every B2B team is sitting on email addresses nobody has identified: webinar registrants, event signups, gated downloads, trial requests and CRM records with an email and nothing else. FullEnrich’s reverse email lookup turns one email, personal or work, into the person and company behind it, including name, title, seniority, company, headcount and LinkedIn, for 1 credit per match and nothing on a miss. If you want to build your own waterfall with custom logic, Clay is the workshop for that, and FullEnrich runs inside it as a provider. If you just want the answer, FullEnrich runs the waterfall across 20+ providers for you, with paid plans from $29 a month. Try it on your last webinar list with 50 free credits.

The 10-intro ask that built $10M in pipeline

The Swarm has about a dozen people. Over the last 12 months they built more than $10M in pipeline, and a big chunk of it came from people who don’t work there: their investors, their advisors, and their team’s old colleagues.

David Connors, their co-founder and CEO, came on the show and walked through the whole motion live. I came away with a play I think most B2B teams are leaving on the table, and a strategic question I can’t stop thinking about.

The problem everyone has

Every company I’ve worked with has the same moment. A rep needs into an account, so someone drops a message in Slack: “Does anyone know someone at Walmart?” Then nothing. Or three people check LinkedIn, one remembers a guy from 2019, and the trail goes cold.

Teams try to fix this two ways. They buy a tool that requires everyone to connect their LinkedIn and email, and adoption stalls at a handful of people. Or they lean on advisors who promise intros and never make them, because they’re busy and nobody asks them in a way that’s easy to say yes to.

Meanwhile cold outbound keeps getting harder. AI made it cheap to send, so every buyer’s inbox is full. David put it plainly: trust and a human relationship are what cut through now.

What David actually does

The Swarm’s internal motion has four parts.

1. Map the network passively. You don’t need everyone to sign up. The Swarm maps former colleagues, school overlaps, investor networks, and LinkedIn engagement from public data, then lets a few key people add their private email and calendar data. David’s rule: get the top 20% to contribute, and you usually get 80 to 90% of the best relationships. Usually that’s the leadership team and a few investors.

2. Score which relationships are real. A LinkedIn connection alone is “Potential.” Add emails or a meeting and it becomes “Likely.” Working together at a small startup, same office, same function, is “Confirmed.” Same big company, different country, doesn’t count for much.

3. Carve the warm accounts out of your list. Start with your target accounts (they build theirs in Clay). Layer intent signals to narrow 10,000 accounts to roughly 1,000. Then split: accounts with a warm path go to the intro motion, everything else stays in cold outbound and ads.

4. Pick the play and batch the ask. There are three plays. Direct: your connector knows the buyer and forwards your note. Indirect: your connector knows someone else at the account who passes it along. Mention: you reach out yourself and reference a shared customer. Then, once a month, each connector gets one email with the top 10 intros you think they can help with. They reply with the numbers they know well. David’s typical result: four out of ten.

The stack for them is simple. Clay for the account list, The Swarm for relationship data, Claude through the Swarm MCP for ad hoc hit lists, Attio as the CRM, and Google Workspace to send.

Where I’d push this further

Midway through the conversation, I asked David: what if this was the strategy? What if, instead of spending the next dollar on ads, a company spent it acquiring networks?

He agreed, and I think it deserves more attention than it gets. Most companies pick advisors for credibility on a slide. Very few pick advisors for who they can reach. If you treated advisor recruiting like channel strategy, you’d look at your top 50 accounts, find the people with real relationships into them, and offer advisory shares or revenue-tied comp for a monthly intro commitment. David said most good advisors will do it for advisory shares if they believe in the product.

Two more things stood out.

First, I guessed on air that the mention and one-hop plays would drive most of the volume, and direct intros would drive most of the pipeline. David confirmed it. So design for both: use mentions to cover ground, and protect direct intros for your highest-value accounts.

Second, the Sequoia “top 1%” exercise. They gave partners and founders a list of 200 to 300 people from their own networks and asked them to mark the ten they’d vouch for. Five minutes each. That’s proprietary data no competitor can buy, and it works for recruiting as much as for pipeline. When I’ve hired sales reps, the best signal always came from people who’d worked with the candidate twice. Almost nobody writes that down.

Run this Monday

1. List every investor, advisor, and former-colleague-rich leader who’d plausibly help. Pick the top 20%.

2. Ask each of them for their LinkedIn Connections export (Settings, Data privacy, Get a copy of your data).

3. Match their connections against your top 1,000 accounts. Score each path Potential, Likely, or Confirmed.

4. Build each connector’s top 10 for this month. Send one email per connector. Ask for numbers back.

5. Write a forwardable note for every yes. Under 120 words, one proof point, one ask.

6. Tag the lead source “Network intro” in your CRM so you can show the pipeline in 90 days.

Free: The Warm Intro Engine

I turned David’s play into a Claude skill you can install. Give it your target accounts and your connectors’ LinkedIn exports. It scores every path, picks the right play, builds each connector’s monthly top 10, drafts the forwardable notes, and sets up a tracking sheet. If you have The Swarm MCP connected, it uses that instead.

To install: download the file, go to Claude Settings > Capabilities > Skills, and upload it. Or paste it into a Project’s instructions.

[Get the Warm Intro Engine at GTMAIpodcast.com]

Watch or listen

• Full episode: GTMAIpodcast.com

• The Swarm: theswarm.com

• David on LinkedIn: linkedin.com/in/connorsdavid

Warm Intro Engine Skill.md

---
name: warm-intro-engine
description: Turn your team's, investors', and advisors' networks into a monthly warm-intro motion. Scores relationship strength, picks the right intro play, batches asks, drafts notes, tracks pipeline.
---

# Warm Intro Engine

Inspired by David Connors, Co-Founder and CEO of The Swarm, on the GTM AI Podcast. The Swarm built over $10M in pipeline in 12 months using its own cap table, investors, advisors, and team for warm intros. This skill runs that play with exports you already have. GTMAIpodcast.com

## What this does
1. Maps who in your extended network knows people at your target accounts.
2. Scores each path Potential, Likely, or Confirmed, then picks the right intro play.
3. Builds one batched monthly ask per connector (max 10 intros), drafts forwardable notes, and sets up tracking so you can prove the pipeline.

## What you need
- **Target accounts** (CSV): company name, domain, fit tier (A/B/C), optional intent signals column. Export from Clay, your CRM, or ZoomInfo.
- **Target contacts** (optional CSV): name, title, company, LinkedIn URL for the buyers you want to reach.
- **Connector roster**: everyone who might introduce you. Name, relationship to you (team, investor, advisor, customer, partner), and their LinkedIn URL.
- **Connector networks** (any you can get, with their permission):
  - LinkedIn: Settings > Data privacy > Get a copy of your data > Connections. Produces `Connections.csv` (First Name, Last Name, URL, Email Address, Company, Position, Connected On).
  - Work history: each connector's past employers, dates, location, function (copy from their LinkedIn profile).
  - Optional: email or calendar contact exports.
- **Suppression list**: people or companies to never route through or contact.
- **Optional upgrade**: if The Swarm MCP is connected in Claude, use it for path mapping instead of steps 2 and 3 below. Prompt pattern: "Use Swarm MCP to find intro paths to [domain]. List connectors, connection strength, and how they know each other."

Start small. Getting the top 20% of your people to contribute (leadership, a few investors, your best advisors) usually covers most of the strongest relationships.

## Process

### Step 1. Narrow the account list
Start from fit, then intent, then relationships. Example: 10,000 target accounts, filtered by intent signals to the top 1,000, then checked for warm paths. Everything without a warm path stays in your normal cold and ads motion.

### Step 2. Find paths
For each target account and each connector, check:
- **Connection match**: a row in the connector's `Connections.csv` where Company matches the target (normalize names: drop Inc, LLC, punctuation; match on domain where possible).
- **Work overlap**: connector and target contact worked at the same company with overlapping dates.
- **Education overlap**: same school, overlapping years.
- **Interaction**: emails, calendar meetings, or LinkedIn engagement (comments, reactions) between them.
- **Investor or customer tie**: connector invested in, advises, or is a customer of the target.

Also note one-hop paths: the connector knows someone at the account who is not the buyer (for example the Chief Product Officer when you want the CRO).

### Step 3. Score strength
| Score | Tier | Signals |
|---|---|---|
| 1 | Potential | LinkedIn connection only. No other evidence. |
| 2 | Likely | Two or more signals: connected plus emails, or a meeting, or school overlap, or engagement. |
| 3 | Confirmed | Worked together at a small company in the same location and function, or the connector says "I know them well." |

Downgrade rules:
- Same large company but different country, office, or function: drop one tier.
- Overlap more than 8 years ago with no recent interaction: drop one tier.
- Anyone on the suppression list: remove the path entirely.

### Step 4. Prioritize
Priority score = fit (A=3, B=2, C=1) x intent (signals present=2, none=1) x strength (1 to 3). Max 18. Work top down.

### Step 5. Pick the play
| Play | When | What happens |
|---|---|---|
| **Direct intro** | Strength 3, or 2 with recent interaction, to the buyer | Connector forwards your note to the buyer. Highest conversion. |
| **Indirect (one hop)** | Connector knows someone else at the account | Connector sends your note to their contact, who passes it to the buyer. |
| **Mention** | Target used to work with one of your happy customers | You reach out yourself and reference the shared connection. Use sparingly and only with the customer's OK. |

Expect mentions and one-hop paths to drive most of the volume, and direct intros to drive most of the pipeline.

### Step 6. Batch the monthly ask
Once a month per connector. Never weekly. Up to 10 targets, ranked. Ask them to reply with the numbers they know well enough to introduce. Protect their social capital: they stay in control, nothing goes out behind their back.

### Step 7. Draft forwardable notes
For every target the connector says yes to, write a note they can forward without editing.

### Step 8. Track it
In your CRM, set lead source = "Network intro" and record the connector name and play. Review monthly: asks sent, yeses, intros made, meetings, pipeline, closed-won. Retire connectors who never respond; thank the ones who do with results.

## Templates

### Monthly ask to a connector (send yourself, from your own inbox)
```
Subject: 10 intros for [Month], reply with numbers

Hi [Name],

Here are the 10 accounts we'd most like to meet this month where it looks like you may know someone. Reply with the numbers you know well enough to introduce, and I'll send a short note you can forward as-is.

1. [Person], [Title] at [Company] ([how you likely know them])
2. ...
10. ...

No pressure on any of them. Thanks for helping.
[You]
```

### Forwardable note (direct or one hop), under 120 words
```
Subject: [Connector] suggested we connect

Hi [Target first name],

[Connector] thought we should talk. [Company] helps [ICP] [specific outcome], and [one concrete reason it's relevant to them now: hire, funding, launch, initiative].

[One proof point: customer like them plus result.]

Open to 20 minutes in the next two weeks? If the timing's wrong, no worries at all.

[You], [Title], [Company]
```

### Mention (you send, only with the customer's OK)
```
Hi [Target], saw you worked with [Customer contact] at [Old company]. We've been working with [them / their team] at [Current company] on [outcome], and they suggested you might find it useful too. Worth a quick look?
```

### The vouch capture (quarterly, 5 minutes per person)
Give each connector a list of 200 to 300 people from their own network in a relevant function. Ask them to mark the 10 they would personally vouch for. Store the marks as tags. Use them for intros and for recruiting.

## Output format
1. **Path table**: Account | Target contact | Connector | How they know each other | Strength | Play | Priority
2. **Monthly ask emails**, one per connector, ready to send
3. **Forwardable notes**, one per approved target
4. **Tracking sheet columns**: Date asked | Connector | Target | Play | Yes/No | Intro date | Meeting date | Opportunity | Amount | Stage
5. **Gaps**: accounts with no warm path (route these to cold outbound and ads)

## Guardrails
- Always draft; never send on anyone's behalf. Connectors send their own forwards.
- Only use network exports the connector gave you with permission.
- Respect the suppression list in every step.
- Cap asks at 10 per connector per month.
- Treat strength scores as hypotheses. The connector's answer overrides the score.

Credit: Inspired by David Connors, The Swarm (theswarm.com), on the GTM AI Podcast. GTMAIpodcast.com

Top 1% Sequia Strategy

---
name: vouch-capture
description: Run the Sequoia "top 1%" exercise. Turns each person's network export into a short review list, captures who they would vouch for, and puts those vouches to work for intros and recruiting.
---

# Vouch Capture

Inspired by David Connors, Co-Founder and CEO of The Swarm, on the GTM AI Podcast. At Sequoia, David's team gave partners and founders a list of 200 to 300 people from their own network and asked them to mark the 10 they'd vouch for. It took 5 minutes per person, and the result was proprietary data nobody else had. This skill runs that exercise for your team. GTMAIpodcast.com

## What this does
1. Turns each person's LinkedIn export into a focused review list of 200 to 300 names in a relevant function.
2. Captures who they would personally vouch for, in one sitting of about 5 minutes.
3. Combines everyone's vouches into a shared list you can use for warm intros, hiring, and referrals.

## What you need
- **Participants**: leaders, investors, advisors, or anyone willing to spend 5 minutes.
- **Each participant's LinkedIn export**: Settings > Data privacy > Get a copy of your data > Connections. Produces `Connections.csv` (First Name, Last Name, URL, Email Address, Company, Position, Connected On).
- **The purpose of this round** (pick one): pipeline (buyers at target accounts), hiring (a specific role), or referrals (people who'd send you customers).
- **Optional**: target account list (for pipeline rounds) or job description (for hiring rounds).

## Process

### Step 1. Define the filter
Write the round's filter in one line before touching data:
- Pipeline: "Directors and above in Revenue, Sales, or RevOps at our tier A and B accounts"
- Hiring: "Account Executives and Sales Managers, 3+ years, at B2B SaaS companies"
- Referrals: "Founders, CROs, and consultants who advise companies in our ICP"

### Step 2. Build each review list
From each participant's `Connections.csv`:
1. Keep rows whose Position and Company match the filter. Use title keywords and, for pipeline rounds, match Company to the target account list (normalize names: drop Inc, LLC, punctuation).
2. Remove anyone on your suppression list.
3. If more than 300 remain, keep the most relevant 300 (tier A accounts first, then seniority, then most recent connection date). If fewer than 50 remain, loosen the filter one notch.
4. Sort alphabetically so the participant scans quickly.

### Step 3. Send the review
One message per participant with their list. Ask for three marks only:
- **V**: "I'd vouch for this person." Limit: 10.
- **K**: "I know them well enough to intro, but wouldn't vouch."
- **X**: "Don't route through me to this person." (Goes to the suppression list, no reason needed.)

Everything unmarked stays unmarked. Do not ask for reasons; speed is the point.

### Step 4. Combine the results
Merge all participants' marks into one table. A person vouched for by two or more participants is a top priority. Record who vouched, the date, and the round's purpose.

### Step 5. Put it to work
- **Pipeline**: V and K marks at target accounts become Confirmed paths in the Warm Intro Engine. V marks get direct intro asks first.
- **Hiring**: V marks get a personal outreach from the participant who vouched, with the role attached.
- **Referrals**: V marks get a thank-you and an ask for one intro.

### Step 6. Refresh
Re-run each quarter or when someone new joins the cap table, advisory board, or leadership team. Vouches older than 18 months get re-confirmed before use.

## Templates

### Review request
```
Subject: 5 minutes: who would you vouch for?

Hi [Name],

Below are [n] people from your network who fit [filter in plain words]. Could you scan it and mark:
V = you'd vouch for them (up to 10)
K = you know them well enough to intro
X = please never route through you to them

Takes about 5 minutes. Nothing goes out without your OK.

[List]

Thanks,
[You]
```

### Vouch-based outreach (for the participant to send)
```
Hi [Target], I'm helping [Company] [find a great Sales Manager / meet a few leaders in your space], and you were one of the first people I thought of. Would you be open to a short call with [Your name]? Happy to share more first.
```

## Output format
1. **Review lists**: one per participant, ready to send
2. **Combined vouch table**: Person | Company | Title | Vouched by | Mark | Round | Date
3. **Top priorities**: people with 2+ vouches, and V marks at tier A accounts
4. **Suppression additions**: all X marks
5. **Next actions**: drafted intro asks or outreach for the top 10

## Guardrails
- Only use exports participants give you, and use them only for this purpose.
- Keep vouch data internal. Never tell a target who marked them, or how.
- X marks are permanent unless the participant removes them.
- Participants approve every message that uses their name.

Credit: Inspired by David Connors, The Swarm (theswarm.com), on the GTM AI Podcast. GTMAIpodcast.com

Vote here

Do it and I’ll invite you on the show and make your wildest dreams come true ;)

Thank you!

If you go to the www.gtmaipodcast.com newsletter on Substack, there lies some skill.md files inspired from this podcast to help you!

Lets go....

Can listen if you prefer on Apple Podcasts, Spotify or Youtube below:

I had Marko Ladis walk me through his decision framework and how he uses it inside of his AI workflows. He is constantly connecting and having AI analyze different people in his world or on Linkedin to find guests for his podcasts, potential customers, or relationship building.

Marko fed it my LinkedIn profile. It did not draft a pitch, instead it returned a verdict which basically said “poor direct sales lead, strong relationship, likely podcast guest”. Then it routed me to a different agent and stopped.

Marko leads an engineering team full time, consults on decision ownership through Decision Stability, and hosts the Decision Load podcast. He is a solo operator, so he built three AI setups that prepare the work and leave the judgment to him. He walked me through all three on this week’s GTM AI Podcast using real outputs with the private details removed.

The three setups in one paragraph each

People pipeline (Claude). A lead identifier researches a person, scores them, and assigns a track. Three downstream agents handle podcast strategy, connection requests, and outreach writing. Each owns one lane.

Podcast clip director (ChatGPT project, Astra model). Reads full episode transcripts and returns cut windows, three title and thumbnail framings per clip, and a publishing order. Results flow back into a performance log it can edit.

Website manager (Claude Code). Works inside his real repository with persistent project memory, GitHub, Vercel, and Hostinger. It previews every change and asks twice before anything goes live.

Five design rules you can copy this week

1) Route before you write

Marko’s lead identifier takes a name, a profile, or a CSV export of 12,000 connections. On the full file it needs about 90 minutes. It researches each person, scores them, and assigns one of four tracks: client, relationship, podcast guest, or “happy to know, do not pursue.”

Most sequences assume every contact is a prospect. That assumption sends cold pitches to champions, partners, and investors. A routing step in front of your sequencer fixes it.

What to do:

• Define four or five relationship tracks for your business, each with a one-line test

• Make “do not pursue” a valid output

• Block message drafting until a track exists

2) Let the agent say U

Marko scores six things: fit, authority, affordability, timing, existing relationship, and the agent’s confidence in the evidence. When it cannot verify a dimension, it writes U. It never invents a number so the spreadsheet looks complete.

Timing beats title. A prospect who just announced layoffs gets a different call than one who just scaled a team, whatever the job title says. Affordability gets checked against his own offer, a $5,000 sprint.

My addition: report two numbers, the score on known dimensions and the coverage. I keep evidence confidence as its own label and count coverage across the five scored dimensions. A lead that scores 80 percent on 2 of 5 known dimensions is a research task. Set a floor, for example 4 of 5 known before any message gets drafted.

3) Hand off with a packet

Marko’s lead identifier does not stop at “podcast guest, good luck.” It passes forward who the person is, what is verified, what is inferred, what is unsure, why it chose the track, and a complete prompt for the next agent.

On the call I said the handoff is the step most people skip, and that the same gap breaks human teams. Marko’s setup shows the fix. Copy this packet:

HANDOFF PACKET
From: [agent]            To: [agent]
Subject: [person, account, or asset]
Decision: [track or verdict in one line]
Why: [two sentences]
VERIFIED: [facts, each with a source]
INFERRED: [judgments, each with its evidence]
UNKNOWN: [every U, listed]
RISKS: [timing, sensitivity, anything that could embarrass you]
NEXT PROMPT: [complete prompt for the receiving agent]

4) Give every agent the same brain file

Marko calls his hub Agent Zero. It holds his bio, his framework, his website, and a main file that lists every agent and its role. A brain file loads into each agent, so each one knows the others exist. Ask the podcast strategist to write an outreach message and it answers: route this to the connection requester.

Agents that know their lane and refer out are what keep a multi-agent setup from turning into one overconfident chatbot.

What to do:

• Write one brain file with three sections: who you are, the lane roster (job, inputs, outputs, what each agent refuses), and routing rules

• Load it into every agent

• Add a line to each agent: “If the request belongs to another lane, name the lane and stop”

5) Gate by reversibility

Inside the sandbox Marko’s Claude Code agent reads files, rewrites code, runs builds, and tests. The line moves when something leaves his environment or gets hard to undo. He says he does not fully trust it yet, so it runs in manual mode and asks twice: once to make the change, once to commit.

Free to run Needs a human gate Research, scoring, summarizing Sending any message Drafting and rewriting Publishing anything Building and testing locally Changing DNS or hosting Planning and prep Deleting or overwriting data Writing the next agent’s prompt Spending money

Pick the gate list before you pick the tool. Marko’s framing is the one to borrow: where do you want the AI to hold authority, and where do you hold it?

Bonus for content teams: the clip director loop

Marko’s podcast agent frames each clip three ways: as a problem, as a claim, and as a story. He tests three reasons to click instead of three random titles. After each clip publishes, he logs what ran and what won, and the agent reads that log before it touches the next episode.

Your webinar and sales-call library can run the same loop. Feed it ten recordings, ask for the five most standalone moments in each, and require the three framings per clip.

Marko calls his stack nothing profound. It is boring on purpose, and judgment stays with the human but automates the tedious items because he believes that decisions are the most expensive and valuable part of a company’s workflows.

Find Marko Ladis at decisionstability.co and his podcast is https://decisionstability.co/decision-load. Decision Load is on YouTube every Wednesday.

Skill.md file inspired by the podcast:

---
name: agent-lane-architect
description: Designs a multi-agent workflow where every agent owns one lane, hands off with a packet, and stops at a human gate before consequential actions. Produces a lane map, a shared brain file, a handoff packet template, a scoring rubric that accepts "U" for unknown, a human gate table, and a plain-English setup manual. Use when the user says "design my agent workflow," "build agents for [process]," "multi-agent setup," "agent handoffs," "lane map," "brain file," "what should AI do versus me," "human in the loop," "agent guardrails," "lead routing with AI," or wants to split one overloaded prompt into specialized agents. Triggers on lead triage, outreach, content or podcast production, and ops workflows. Does not write the outreach itself or the agents' code.
---

# Agent Lane Architect

Inspired by Marko Ladis's multi-agent setup, as shown on the GTM AI Podcast with Coach K. Marko is the founder of Decision Stability (decisionstability.co) and host of Decision Load.

**Job:** Turn a described workflow into a lane-based agent system a person can set up in an afternoon.

**Persona:** A GTM leader, RevOps owner, founder, or content lead who wants AI to prepare work while a human keeps judgment. Decision being made: which steps agents own, where they hand off, and where a human must approve.

**Core rule (Marko's):** Very high autonomy in preparation and execution. A very obvious human gate before consequential external actions.

---

## STEP 0 (REQUIRED): Intake

Do not design anything until you know these five things. If the user already stated them, confirm in one line and move on. Otherwise ask them in one message:

1. What is the workflow, in one sentence?
2. What are the steps today, and who does each one?
3. What goes in and what comes out at the start and the end?
4. Which steps send, publish, change, delete, or spend something outside your own environment?
5. Which platform will run the agents (Claude Projects, ChatGPT Projects, Claude Code, other)?

Do not proceed until questions 1 and 2 are answered. If the user cannot answer 4, assume every outward-facing step is gated.

---

## STEP 1: Build the lane map

A lane is one job with one verb. Split a step into separate lanes when it uses a different data source, requires a different kind of judgment, or carries a different level of risk. Merge steps that are always run together.

Limit the first pass to 7 lanes. If you want more, the workflow needs a second pass after the first one runs.

Output one card per lane:

```
LANE 02: Router
Job: Classify the relationship and choose a track
Inputs: name, profile text or CSV row
Outputs: track, scores, handoff packet
Refuses: writing any message; researching beyond the scoring dimensions
Hands off to: Lane 03 (client track) or Lane 04 (relationship track)
Human gate: none
```

Always include Lane 00, the hub, which holds the brain file (STEP 5).

**Edge case:** If the workflow has one real step, say so. Recommend one agent plus a gate table. Do not invent lanes to look thorough.

---

## STEP 2: Route before you write

If the workflow ends in a message, a deliverable, or an action toward a person, the first working lane is a classifier. It decides what the situation is before anything gets drafted.

Rules:

- Define 4 or 5 tracks, each with a one-line test
- Include a track for "no action" (Marko's version: "happy to know, but do not pursue")
- The classifier never drafts the message or asset. Its output is a verdict, evidence, and a packet
- Every downstream lane accepts input from exactly one track

Example tracks for lead triage:

| Track | One-line test |
|-------|---------------|
| Client | Has the problem we solve, authority to buy, and a timing signal |
| Relationship | Valuable to know, wrong moment or wrong role to sell to |
| Partner or guest | Can bring us an audience, or we can bring them one |
| Research more | Too many unknowns to classify |
| No action | Known, but no reason to pursue |

---

## STEP 3: Scoring rubric with U

Use this when a lane has to score or rank something. Build the rubric from the five scored dimensions below and edit the names for the user's business.

| Dimension | Question |
|-----------|----------|
| Fit | Does the problem we solve exist for them? |
| Authority | Can they decide or influence the decision? |
| Affordability | Can they pay for our offer? |
| Timing | Does a recent event make now a good or bad moment? |
| Relationship | What history exists with us? |

Each dimension is scored 0 to 5 or **U** (unknown). Evidence confidence is reported separately as High, Medium, Low, or U.

**Rules (MANDATORY):**

1. U never counts as 0. If the agent cannot verify a dimension, it writes U and says what evidence is missing.
2. Report two numbers: **Score** = (sum of known scores) / (5 x number of known dimensions), and **Coverage** = known dimensions / 5.
3. Coverage floor: below 4 of 5 known, route to "Research more." Edit the floor to suit the user.
4. Timing override: a negative timing signal (layoffs, freeze, leadership change in progress) caps the track at Relationship, whatever the other scores say.
5. Title never substitutes for fit. A CEO with no evidence of the problem is not a lead.

**Worked example**

Input: VP of Sales at a 300-person company, recent post about tool sprawl, company announced layoffs last month, no prior contact.

| Dimension | Score | Evidence |
|-----------|-------|----------|
| Fit | 4 | Posted about tool sprawl |
| Authority | 5 | VP, owns the budget line |
| Affordability | U | No public data on budget |
| Timing | 1 | Layoffs announced last month |
| Relationship | 0 | No history (known, so it counts) |

Known sum = 10 across 4 dimensions. Score = 10 / 20 = 50%. Coverage = 4 of 5 (meets the floor). Evidence confidence: Medium.
Timing override applies. Track: **Relationship**. Next step: a note to watch for a timing change, no pitch.

---

## STEP 4: Handoff packet

Every lane ends by preparing the next lane. The packet is the contract.

```
HANDOFF PACKET
From: [lane]             To: [lane]
Subject: [person, account, or asset]
Decision: [track or verdict in one line]
Why: [two sentences]
VERIFIED: [facts, each with a source]
INFERRED: [judgments, each with the evidence behind it]
UNKNOWN: [every U, listed with what would resolve it]
RISKS: [timing, sensitivity, anything that could embarrass the user]
NEXT PROMPT: [a complete, standalone prompt for the receiving lane]
```

Rules:

- VERIFIED needs a source. No source means it moves to INFERRED.
- NEXT PROMPT must work if pasted into a fresh chat with no other context.
- If the receiving lane is on a platform that cannot pass files, the user pastes the packet. Say so in the manual.

---

## STEP 5: The brain file

One file, loaded into every lane, so each agent knows the others exist. Marko calls the hub "Agent Zero."

Write `brain.md` from this template:

```
# BRAIN
Owner: [name, role, one-line bio]
Business: [what we do, who we serve, offer and price if relevant]
Voice and standards: [pointer to examples or style file]

## Lane roster
| Lane | Job | Inputs | Outputs | Refuses |
|------|-----|--------|---------|---------|
| 00 Hub | Holds this file and routes | any | routing answer | doing lane work |
| 01 ... | ... | ... | ... | ... |

## Routing rules
- If a request belongs to another lane, reply: "Route to Lane [N]: [name]." Then stop.
- If you do not know something, write U. Do not guess.
- End every task with a handoff packet or a clear "done."

## Gates
See gate table. Never perform a gated action. Prepare it and ask.
```

Every lane instruction file starts with: "Read brain.md first. You are Lane [N]. Stay in your lane."

---

## STEP 6: Gate table by reversibility

Sort every action each lane can take. Run three questions on each action:

1. Does it leave our environment?
2. Is it hard to undo?
3. Does it cost money or reputation?

Any yes means a gate.

| Class | Examples | Rule |
|-------|----------|------|
| Free | Research, scoring, summarizing, drafting, building and testing locally, writing the next prompt | Agent runs without asking |
| Confirm | Sending a message, publishing, merging code, sharing a file externally | Agent prepares, human approves each time |
| Confirm twice | Changing DNS or hosting, deleting or overwriting data, spending money | Agent asks to make the change, then asks again to commit it |
| Never | Anything the user lists | Agent refuses and explains |

Default to manual mode. Move an action from Confirm to Free only when the user names it and has reviewed several clean runs. If the user asks for full autonomy, produce the table anyway and write the pre-approved actions into it by name.

---

## STEP 7: Feedback loop (include when outputs have measurable results)

Add a log the agents can read and update. One row per output: what was produced, what version ran, the result, what won, and notes for the next run. Each lane reads the log before starting. Without it, every run starts from zero.

---

## STEP 8: Setup manual, explained like the user is 11

Write step-by-step instructions for the user's platform. Each step is one action, one sentence, one expected result. Use plain words. Define any technical term the first time.

Examples of the level:

- Good: "Click New Project. Name it Lane 02 Router. Paste the file called lane-02-router.md into the Instructions box. You should see the instructions saved under the project name."
- Bad: "Configure the agent with the appropriate system prompt."

If file creation is available, write the files into a folder named `agent-lanes/`. Otherwise print each file in its own labeled code block.

---

## Output contract (what "done" looks like)

Deliver, in this order:

1. Lane map (table, then one card per lane)
2. `brain.md`
3. One instruction file per lane, named `lane-NN-name.md`
4. Handoff packet template
5. Scoring rubric (only if a lane scores or ranks)
6. Gate table
7. Setup manual
8. Test script: three sample inputs. One clean case, one with missing data (should produce U and "Research more"), one out-of-lane request (should produce "Route to Lane N").
9. Top three risks in this design, one line each

---

## Edge cases

| Situation | What to do |
|-----------|------------|
| User gives a vague workflow | Ask only the missing intake questions, then proceed |
| Steps contradict each other | List the contradictions and ask one question to resolve them |
| No data available to score | Score everything U, route to "Research more," say what to collect |
| Sensitive data (personal info, contracts) | Add a line to brain.md on what agents may store and where |
| User wants one giant agent | Explain the cost once (overloaded prompts blur judgment), then build what they ask for with a gate table |
| Agents run on different platforms | Use pasted handoff packets and say so in the manual |

---

## Self-check before delivering

- [ ] Every lane has one verb and a "Refuses" line
- [ ] Classifier lane exists wherever the workflow ends in a message or action toward a person
- [ ] No lane both classifies and writes
- [ ] U is allowed and never scored as 0
- [ ] Every packet has VERIFIED, INFERRED, UNKNOWN, and NEXT PROMPT
- [ ] brain.md lists every lane and the routing sentence
- [ ] Every outward-facing action sits in the gate table
- [ ] Setup manual passes the "11-year-old" test
- [ ] No lane was added just to look thorough

---

## Worked example: lead triage

**User:** "Our SDRs email everyone in the CRM. Customers and partners keep getting cold sequences."

**Lane map produced:**

| Lane | Job | Gate |
|------|-----|------|
| 00 Hub | Holds brain.md, routes requests | None |
| 01 Router | Scores and assigns a track, writes a packet | None |
| 02 Account researcher | Deep research for the Client track | None |
| 03 Message drafter | Drafts one message for the Client track | Human sends |
| 04 Relationship notes | Writes a context note for Relationship and Partner tracks | None |
| 05 Review log | Records outcomes, updates the log | None |

**Why it works:** The Router never drafts. Customers and partners land in Lane 04, so they stop receiving cold sequences. Every send is a human click.

Elin Nguyen ran the same customer through the same AI prompt two days in a row. She didn’t change a single line.

She takes people through this on her youtube channel here

Or a quick overview:

Monday: high-value customer. Tuesday: low-value customer.

She was trying to build a sales intelligence tool that would tell her which five customers to call each day. Instead she had a tool that changed its mind overnight. “How am I going to build a business intelligence tool that constantly changes its mind?” she told me. “Am I going to email a high-value customer, and then tomorrow, all of a sudden, it’s low value?”

That frustration turned a mechanical engineer into one of the most interesting AI reliability researchers I’ve talked to. I’ve written prompts for production products, including at Momentum before Salesforce acquired it, and I’ve read most of the prompting research out there. It’s rare I learn something new about prompting. This conversation gave me a new angle.

Top 5 quotes

1. “When you say it worked, it has to work everywhere. When it doesn’t work everywhere, then you basically got lucky.”

2. “They say, oh, it’s 90% correct. That’s great. You know what I say? ... You’re not in control of the rest of the 10%.”

3. “If it’s 10 out of 10 wrong, flip it to 10 out of 10 correct. Then you know what flipped it.”

4. “LLMs never follow instructions. There’s no thing that has judgment. It’s just a structure of language that’s going to work, or it’s not going to work.”

5. “We’ve been operating on unstable semantics in everything, not just AI. AI is making this really explicit, because as soon as something is undefined, it breaks down.”

1) The model computes the same thing every time. The wording decides what it computes.

Elin’s explanation of why AI output varies is the clearest I’ve heard. Picture a roulette wheel. For every next word, the model builds the wheel: big slices for likely words, thin slices for unlikely ones. That part is math and it comes out the same every time. Then the model spins the ball. Usually it lands on the big slice. Sometimes it lands on a thin one.

Most people stop there and conclude AI is random. Elin’s point is that you control the size of the slices. Your input shapes the wheel. Write a tight enough input and there is only one slice worth landing on.

Her proof: across GTM classification, an M&A decision, and abstract reasoning tasks, she kept adding definitions until GPT, Claude, Gemini, and Grok converged. In her reported substrate test (four models, ten runs each), baseline prompts converged 30% of the time. With the substrate, all 40 runs returned one byte-identical output, verified by SHA-256 hash.

2) Interpretation drift is the real problem, and your prompts are full of it

Elin asked me to name a fruit. I said mango. She was thinking of something else. Then she narrowed it: a fruit that isn’t tropical. Fewer options. Then apple. Still too loose. Red apple? Half-red, dark red, pinkish red. Keep going until you get to “the dark red apple from Snow White.” Now everyone pictures the same thing.

That is interpretation drift: the model reads an abstract instruction and picks one of many valid meanings. Different runs pick different meanings. Different models pick different meanings. All of them are fluent and confident.

Her first paper shows it on a GTM-style question. She gave models one company profile ($10M revenue, 20% margin, 40% growth, top three customers at 60% of revenue) and asked whether to acquire it. The answers ranged from “Conditional YES” to “No.” The same 60% concentration was read as manageable by one model and a “house of cards” by another.

Now think about your own prompts. “Score this lead.” “Flag at-risk accounts.” “Is this deal qualified?” Every one of those words is a fruit.

3) The usual prompt tricks barely move the needle

Elin tested 17 prompt variations on the car wash question: “I need to wash my car. The car wash is 50 meters away. Should I walk or drive?” In her upcoming paper, 17 models answer “walk” 10 out of 10 times. They tell you to leave the car at home and walk to the car wash.

What she tried:

• “Think step by step.” Made it worse. Pushed models further toward walk.

• “You are a car wash expert.” Best of the bunch. Moved results about 2%.

• “Do not hallucinate.” No meaningful change.

• ALL CAPS: “I MUST WASH MY CAR.” No meaningful change.

Then the wording test that should worry every RevOps leader. Same question to Opus. Add “answer with exactly one word”: 10 of 10 walk. Leave it open-ended: 10 of 10 drive. Change it to “answer walk or drive”: a different answer again. A human wouldn’t change their answer because you asked for one word. The model does.

Takeaway: “be consistent” and “don’t hallucinate” in your system prompt are decoration. They don’t define anything, so they don’t fix anything.

4) 90% accuracy is a warning

This was her most controversial take. A lot of prompting advice comes from aggregate results: a technique made outputs 2% better across a benchmark. Elin’s counter: it may have made outputs 2% worse somewhere else, and you can’t tell which. That’s correlation dressed up as a method.

Her standard is binary. Find a case where the model is wrong 10 out of 10 times. Change the input until it is right 10 out of 10 times. Now you know exactly which words did the work. If it fails on three of 17 models, those three need more definition, and you know where to look.

For a GTM team, the math is simple. A lead-routing prompt that’s right 90% of the time on 5,000 inbound leads a quarter misroutes 500. You don’t know which 500.

5) Meaning engineering is now a GTM job

Elin used to work in business development, and she hated Salesforce for a very specific reason. “Lead qualified. What does this mean?” Nobody had a hard definition. “Lead hot. Oh, he’s hot. Yeah, but he hasn’t emailed for 180 days. Is he really still hot?”

Revenue teams have run on loose definitions for decades. Humans papered over the gaps with judgment and hallway conversations. AI has no hallway. Any term you leave undefined, the model defines for you, differently on different days.

That is why she calls the next discipline meaning engineering. Before you ask AI to qualify, score, route, or forecast, someone has to write down what those words mean in your business, with numbers.

Before and after: one lead, two prompts

Here’s the hot lead problem as a real prompt.

How most teams write it:

You are an expert SDR manager. Review this lead and tell me if it is
hot, warm, or cold. Be consistent. Do not hallucinate. Think step by step.

Lead: VP RevOps, 450-person B2B SaaS company. Last email reply 182 days
ago. 3 pricing page visits in the last 30 days (latest 12 days ago).
Webinar 64 days ago. No demo request.

The model has to decide on its own whether 182 days of email silence outweighs three pricing page visits. Run it ten times and watch it argue with itself.

With a substrate (condensed example):

ICP_FIT: STRONG if 200 to 2,000 employees AND B2B SaaS or IT Services
AND Director+ in Sales, Marketing, RevOps, or CS. PARTIAL if two of
three. WEAK otherwise.
INTENT: HIGH if demo request or 3+ pricing visits in last 30 days.
MEDIUM if 1 to 2 pricing visits in 30 days or a webinar in last 90.
NONE otherwise.
RECENCY: based on the most recent engagement in ANY channel.
ACTIVE at 30 days or fewer. LAPSING 31 to 90. DORMANT over 90.
Email opens do not count as engagement.

RULES (first match wins):
1. Missing required field: INSUFFICIENT_DATA
2. HOT: STRONG + HIGH + ACTIVE
3. WARM: STRONG or PARTIAL, HIGH or MEDIUM, ACTIVE or LAPSING
4. COLD: everything else

Use only the facts provided. Return exactly:
ICP_FIT= / INTENT= / RECENCY= / TEMPERATURE= / ROUTE=

Output, every run: ICP_FIT=STRONG, INTENT=HIGH, RECENCY=ACTIVE, TEMPERATURE=HOT, ROUTE=AE_SAME_DAY

The substrate made the 182-day question a business decision, written once. If your CRO disagrees with the rule, change one line, and every model applies the new rule the same way.

The full version, plus Elin’s M&A example side by side, is in the resource below.

One caveat: a substrate makes your policy repeatable, including when the policy is wrong. Bad thresholds give you perfectly consistent bad decisions. You still own the definitions.

What to do this week

• Pick one AI classification your team already relies on. Lead score, churn risk, deal stage, ticket priority.

• Run the exact same input 10 times, on two models. Paste the outputs side by side. If they don’t match, you’ve found drift.

• List every undefined word in the prompt. Write a number or a closed list next to each one. Delete “be consistent” and “don’t hallucinate.”

• Rerun until you get 10 of 10. Then test it on 20 real records before it touches a workflow.

Free resource: the Substrate Builder skill

I built a copy-paste Claude skill based on this conversation. Paste in any loose prompt. It audits every ambiguous term, proposes definitions for you to approve, writes the full substrate, walks the edge cases, and hands you a 10-out-of-10 drift test.

Get it below.

The receipts

Elin is an independent researcher, and her work is early. Three of her papers are public on OpenReview as conference submissions (IEEE MiTA 2026 and the ICML 2026 Position Paper Track); acceptance hasn’t been confirmed. The byte-identical results come from her own reported evaluation of a manuscript titled Substrates Are All You Need, which isn’t fully public yet, and the car wash results come from a paper she’s writing now. One tightly specified task doesn’t prove determinism for every task, and a strong substrate encodes much of the decision logic by design. I’d still bet on the method, because it’s cheap to test yourself. Run your prompt ten times and see.

Elin’s work: omnisensai.com

• Empirical Evidence of Interpretation Drift in Large Language Models

• Framework for Interpretation Drift & Taxonomy Field Guide

• Position: Interpretation Drift Is a Distinct Source of Instability in Large Language Models

• Empirical Evidence of Interpretation Drift in ARC-Style Reasoning — supplementary paper

• Substrates Are All You Need: Defeating Non-Determinism With Natural Language

The AI isn’t going to agree with you on what “hot” means until you write it down.

The Substrate Builder Skill

What it is: A copy-paste Claude skill inspired by the podcast that turns a loose GTM prompt (”score this lead,” “is this account at risk,” “summarize this call and tag the stage”) into a substrate spec that produces the same answer every run, on every model.

How readers install it:

1. In Claude, open your Skills settings and create a new skill. (Claude Code users: create a folder ~/.claude/skills/substrate-builder/ and save the block below as SKILL.md.)

2. Paste everything inside the code block below.

3. Start a chat and say: “Build a substrate for this prompt:” and paste your prompt.

Built from Elin Nguyen’s interpretation drift research and the GTM AI Podcast conversation with her. It reconstructs her method; it is not her official tool.

---
name: substrate-builder
description: Turn a loose business prompt into a deterministic "substrate" spec (definitions, thresholds, precedence, allowed labels, missing-data rules, canonical output) so every run and every model returns the same answer. Use when someone says "make this prompt consistent," "my AI keeps changing its answer," "build a substrate," "score / classify / qualify / tier / route" with AI, or shares a prompt that classifies leads, accounts, deals, tickets, or risks.
---

# Substrate Builder

Your job: take a prompt that leaves meaning up to the model and convert
it into a protocol where the human owns every definition and the model
only applies them. You do not decide business policy. You expose every
place policy is missing, propose defaults clearly marked as PROPOSED,
and get the human to confirm them.

## Principles

- Drift comes from undefined meaning. Every word that can be read two
  ways will be, on some run.
- "Be consistent," "do not hallucinate," "think step by step," "you are
  an expert," and ALL CAPS emphasis do not define anything. Remove them.
- A substrate makes a policy repeatable. It does not make it correct.
  The human owns the thresholds.
- 9 out of 10 is not a pass. The standard is 10 out of 10, across runs
  and across models.

## Workflow

### Step 1: Identify the single operation
Restate the prompt as one operation: classify, score, route, extract,
or decide. If the prompt asks for several, split it into one protocol
per operation and say so.

### Step 2: Run the ambiguity audit
List every gap, grouped under these headings. Quote the exact words
from the original prompt that create each gap.

1. Undefined concepts (for example: "hot," "qualified," "at risk,"
   "high value," "engaged," "enterprise")
2. Missing thresholds (numbers, date windows, counts, percentages)
3. Boundary values (does exactly 30 days count as recent?)
4. Precedence (when two signals disagree, which wins?)
5. Open label sets (can the model invent "Proceed with caution"?)
6. Missing-data behavior (what happens when a field is blank?)
7. Outside knowledge (is the model allowed to use industry norms?)
8. Output format (prose, bullets, or exact fields?)
9. Hidden goals (is the model optimizing something unstated?)

### Step 3: Propose the policy
For every gap, propose one specific rule. Mark each one PROPOSED. Base
proposals on whatever the user has told you about their business. If
you have no basis, say so and offer two options instead of guessing.

Ask the user to confirm or edit in a single message. Do not proceed to
Step 4 until the user confirms, unless they tell you to use the
proposals as-is.

### Step 4: Write the protocol
Use exactly this structure:

    # [Operation] Protocol

    ## Objective
    [One operation.] Use only Authoritative Input and the rules below.
    Do not use outside benchmarks, norms, or unstated criteria.

    ## Authoritative Input
    [The case data, or a placeholder block the user fills per run.]
    Only this section contains facts about the case.

    ## Definitions
    [Every term, each with explicit numeric or categorical boundaries.]

    ## Allowed Values
    [Closed list per output field. No synonyms. No new values.]

    ## Decision Rules
    Apply in order. Use the first rule that matches.
    1. If a required field is missing, output INSUFFICIENT_DATA.
    2. ...
    N. Fallback rule that catches every remaining case.

    ## Precedence Rules
    [Which signal overrides which.]

    ## Boundary Rules
    [Which bucket each exact threshold value belongs to.]

    ## Missing-Data Rules
    [What counts as missing vs. a known zero. Never infer.]

    ## Canonical Output
    Return exactly these lines and nothing else:
    FIELD_1=<value|value>
    FIELD_2=<value|value>

### Step 5: Self-check before delivering
- Every term in Decision Rules appears in Definitions.
- Every possible input combination matches exactly one rule. Walk at
  least three edge cases (both boundaries and a missing field) and show
  the result.
- No rule contradicts a precedence rule.
- The output block has no room for prose.
- No instruction relies on the model's judgment ("use your judgment,"
  "if appropriate," "as needed").

Where possible, write the decision rules as a short Python function and
run it on the sample input to confirm the expected output. If code and
protocol disagree, fix the protocol.

### Step 6: Deliver the drift test
Give the user this test plan with the protocol:

1. Run the protocol 10 times on their main model.
2. Run it 10 times on at least two other models.
3. Compare outputs exactly (diff, or SHA-256 hash of the output text).
4. If any run differs, the difference points to an undefined term or an
   unhandled case. Name the likely gap, patch the protocol, rerun.
5. Repeat until 10 of 10 match on every model tested. Then test on 20
   real records before putting it in a workflow.

## Output to the user
1. The ambiguity audit (Step 2), short.
2. The PROPOSED policy table (Step 3) for confirmation.
3. After confirmation: the final protocol, the expected output for the
   sample input, the edge cases walked, and the drift test plan.

## Guardrails
- Never quietly invent a threshold and present it as fact.
- Never keep "be consistent" or "do not hallucinate" style lines.
- If the task is open-ended writing (an email, a summary for humans),
  say that substrates fit classification and decisions best, then
  substrate only the parts that must be consistent (for example: stage,
  sentiment label, next-step category).

And have my good friend Mark Fershteyn from https://www.masteringai.io/ on the podcast returning with some gold nuggets and at the end of this newsletter, I have 7 skill.md files inspired by the podcast for you to download for free along with the FullEnrich skill.md file.

In partnership with FullEnrich — I built a Claude skill that reads a business signal such as a funding round, a new exec hire, a job posting and then reasons out the right buyer, and enriches them live via FullEnrich’s MCP, no dashboard or CSV required. You can try FullEnrich.com and the skill.md with 50 credits free, it is embedded here, copy it into your Claude skills folder and you’ll be running it in under 5 minutes. The MCP they have is insanely easy to use as well. Just point your AI to this https://fullenrich.com/mcp and it will connect your account.

Let’s get into the podcast!

Mark Fershteyn spent four years, millions of dollars, and a 26-person team to take his startup, Recapped, to seven figures. Then he shut it down and returned money to his investors.

Six months after going solo, working part-time, he is on pace to pass a half-million-dollar run rate.

He does not code. He describes himself as “a dumb sales guy with too many ideas.” For his whole career, every idea came with the same tax: raise money, hire engineers, wait. In his words: “AI allowed me to do that by myself.”

Mark came back for his second time on the GTM AI Podcast. I’ve followed his journey for years and I admire him a lot. He’s had real ups and downs with being a founder (huge shoutout for his transparency), and he’s winning now because he stopped asking for permission. He opened Claude Code live and showed us how the whole machine works. He does a great job digging in at and I have some free skill.md files at the end so you can build the first piece yourself.

1) Stop trying to keep up. Filter for step changes.

Mark spends most of his day on X and YouTube and still feels behind. “In a week, we’re getting 6 months’ worth of advancement sometimes.”

I tell people the same thing all the time. You’re not going to keep up. At Ai4, I heard Geoffrey Hinton and Andrew Ng both say on stage they can’t keep up either. Let go of that pipe dream and take the pressure off.

Mark’s filter is simple. Ask one question of every release: is this a small improvement, or a step change that unlocks a new kind of work (like a model suddenly good enough to edit video)?

• Small improvement: skip it

• Step change: block a weekend and build something with it

• Build anything, even something for your kids

For me personally, this past weekend my daughter drew a stick figure and I turned it into a one-minute video of her character singing and dancing. Now she wants AI videos all the time.

The one thing I tell teams is be willing to ask themselves one question when working with AI.

That is:
“I wonder if I could do this with AI?” And then start playing, iterating, and making it better.

2) Use AI to use AI. Start in plan mode.

Mark talks to Claude before he asks it to build anything. He dictates what he’s working on, the challenge, and the outcome he wants, then says “help me think through this.”

He starts almost every session in plan mode. “We spend a lot of time thinking and planning up front, and then the execution is more or less usually flawless.”

• In Claude Code (terminal): press Shift+Tab until you reach plan mode

• In the Claude app: turn on plan mode before you start

• Approve the plan, then switch to build

On terminal vs. app: Mark runs up to 12 terminal windows across 3 or 4 projects at once. The app creates a separate git worktree per session, which makes running 7 things in parallel hard for him. His advice: if you’re not building three products at a time, the app is more than enough.

3) One agent per task.

This was the most useful rule in the episode. Every agent Mark builds has one job and a clear test for success: is it working or not?

He has an agent that fetches mail. A separate agent that triages it. An agent that only edits. His content pipeline used to be one agent. Now it’s six:

• Idea generation

• Drafting

• Editing

• Hooks

• Repurposing to other platforms

• One skill that runs all of them in order

When output is weak, he knows which agent to fix. A single agent doing six jobs fails in six places and you can’t tell which one broke.

Here’s the prompt Mark would use to start:

“I want to create a set of skills that interview me on a specific topic, minimum of 10 interview questions. Then create a set of agents, each with their own skill file, that will edit, break it down, create viral hooks, and repurpose my content. Help me build this.”

4) Treat every skill like a new intern. Then coach it four times.

Mark’s analogy: if you tell a new intern “go write me a blog post,” they have no idea who it’s for, what it should accomplish, or what good looks like. Give them 5 examples, the format, and the tone, and the work gets dramatically better. AI works the same way.

His example: he scraped about 300 LinkedIn posts from Adam Robinson and built a skill around them. When he types /adam, it:

• Interviews him on a topic

• Drafts a post in that style

• Receipt-grades the numbers

• Adds a radical transparency takeaway

• Writes 5 hooks and scores them

Here’s where I see most people go wrong. They open Claude, ask for a skill in one shot, and stop. The skill ends up too broad, or it has too little context to do its one job well. In my experience it takes at least four rounds of feedback before results get really good: run it, test it, evaluate it, give feedback, run it again. That’s about 30 minutes. The results you get after that hold every time you run it.

Mark adds one more move: end every skill by asking, “What went well, what didn’t, and what can we improve next time?” The answers feed back into the skill. It improves itself.

5) Give your AI a memory it can navigate.

Every folder on Mark’s computer is backed up to a GitHub repo, and he writes markdown files as he works. The standout is a /clients folder. Every email, Slack thread, and LinkedIn message for each client lands there. When he says “help me draft a proposal for Coach K,” Claude pulls from everything.

A year and a half ago he started building a personal wiki, before Andrej Karpathy’s LLM wiki idea took off. It pulls in LinkedIn, email, Slack, CRM data, scraped company data, and news alerts, and connects them as nodes. Jonathan connects to Salesforce, so anything touching both is linked.

I asked him about hierarchy vs. graph structure, the idea Jack Dorsey pushed at Block. Mark’s view: models are now good enough that you rarely need to build your own retrieval system, but you still need to create the structure behind the scenes.

Start here: one folder per client or account, and a habit of dropping every conversation into it.

6) Build the interface you actually want to work in.

Mark hated living in a chat window. “I’m a visual person. I need something visual.” So he built Zealos, a super app, using Claude Code. The AI runs on Claude’s APIs, the app is hosted on Vercel, and Supabase handles the database and login.

• 5 calendars in one view

• Every inbox in one place

• LinkedIn, Slack, and Discord messages together (iMessage is next)

• A website snippet that identifies anonymous visitors by waterfalling several data providers

• People who engage with his LinkedIn topics get captured, enriched, or enrolled in a sequence

He started it to cut a couple hundred dollars a month in tools. After about 300 hours of fine-tuning, his consulting clients now pay for access. His pitch to them: “You can build this yourself, or I’ve been fine-tuning this across 300 hours. Do you want to pay for access?”

The receipts

Where this goes: build, buy, or hire?

Mark’s read on the market:

• SMBs are building their own tools and cutting subscriptions

• Enterprises need reliability and compliance, so they keep buying. “That’s why Salesforce isn’t going anywhere.”

• The middle gets squeezed. Sell the shovels, or sell the 99.999% uptime.

He also expects a pendulum. Companies will go build-happy for a couple of years, then realize that putting their top people on maintaining an internal CRM is a waste when $1,000 a month buys it from professionals. Then they’ll refocus on their core and put AI behind it.

I agree, and I’d add the migration reality. I’ve moved a company off a CRM. It took months and it hurt. Enterprise systems with years of data, governance, and security are sticky. My rule for leaders: build the things that are specific to how you win. Buy the things that are plumbing.

Mark’s boldest prediction, which he offered with “maybe I’m completely wrong”: within 10 years, 10 to 20 percent of people will do 20 times the work for 10 to 100 times the pay, and many others won’t need to work. You don’t have to agree to take the signal. The gap between people who use AI to multiply themselves and people who wait is widening every quarter.

Your free skill: The Content Engine

I turned Mark’s one-agent-per-task content workflow into a skill you can install today. It runs six jobs in order: Interviewer, Drafter, Editor, Hook Writer, Repurposer, and a Retro that saves your feedback so it gets better every run.

It’s seven skills: one runner plus one skill per job. The editor, hook writer, and repurposer each ship with a small script that checks the work (AI phrases, dashes, hook length, channel limits) so quality doesn’t depend on the model’s mood that day.

How to install:

• Download the suite

• Claude Code: copy all seven folders into ~/.claude/skills/

• Claude app: upload each of the seven skill zips in the Skills section of Settings

• Add a voice/ folder with 10 or more of your best posts so it matches your style

Then type: “Run the content engine on [topic].” Or use any piece alone: “Write 5 hooks for this post.”

What to do this week

• Install the Content Engine and run it on one topic you know cold

• Give it four rounds of feedback before you judge it

• Create one folder per top client or account and start dropping every conversation into it

• Pick one step change from the last 90 days and spend a weekend building with it

Mark didn’t wait for an engineer, a funding round, or anyone’s permission. As he put it at the end: “You don’t need to be a crazy genius engineer to build this stuff.” Go build.

Reminder that the Skill.md files are here from FullEnrich and the content suite from Mark!

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