As a reminder, we will always offer this GTM AI Podcast and Newsletter with its assets or giveaways for free. We have a library of strategic and tactical video walk throughs of anything from tech guides, to connecting multiple systems together, to how to set up advanced multi agent frameworks that you can do in the paid level.

You are welcome to join us anytime!

Subscribe now

Lets dig into it with Arup on Clay.com

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.

Most Clay users are spending $2K a month to build prettier ZoomInfo clones. Same firmographic filters, same ICP lists, prettier spreadsheet. Arup Chakravarti is doing something different, and the reason has almost nothing to do with Clay.

This week on the podcast I sat down with Arup, a 20-year RevOps and enablement vet and a Fellow at the Institute of Sales Professionals. He spent the last couple of months going deep on Clay, and he told me upfront he’s not a guru. He’s right. He’s something more useful: an enablement brain pointed at a GTM tool. That framing is the whole insight.

“One doesn’t need to be a guru to actually get a bit of distance in terms of an understanding.” – Arup Chakravarti

Here’s what he showed me:

1) The column most Clay users never build, because they don’t have the lens to know it exists.

Arup’s use case was a UK healthcare sector list, built from a real ISP case study where the economic buyer was a sales leader who was, in his words, “fully vested in helping his sales team develop.” That phrase is the whole job. Not title. Not company size. Not funding stage. Emotional investment in the sales team’s growth.

Most Clay tutorials stop at firmographic filters and job title searches. Arup added a column he called PDP Advocacy. A classifier that scores every sales leader as a Strong, Moderate, or Weak advocate for professional development, based on their LinkedIn profile, posts, comments, and likes.

What it pulls in:

• Profile “about” section language around coaching, development, growth

• Post content and commentary on learning, enablement, team-building

• Likes and engagement patterns on sales development content

• A confidence score plus a written rationale per lead

The output on one prospect, Rafale Gang, came back “Rafale consistently promotes the development of people, internal progression, coaching style... his authored content explicitly frames leadership as a practice of growing others.” That’s not a firmographic. That’s a psychographic fingerprint.

The shift: stop filtering for fit. Start filtering for emotional resonance with what you actually sell.

2) The iteration that unlocked it was one word.

Arup’s first draft prompt scoped the classifier too narrowly. He was asking Clay: is this person an advocate for the sales function? The qualified pool was tiny. Then he caught himself.

“I first started off with a very, very narrow focus on ‘is this leader an advocate for the sales function?’ And then I was kind of a bit like, actually, to be fair, I’m just being too narrow here. Is this leader an advocate for professional development?” – Arup Chakravarti

One word swap. Function → development. The qualified pool expanded dramatically, and the relevance to his pitch didn’t weaken at all. Because if you sell sales development services, a leader who advocates for professional development broadly will still resonate when you reach out about sales development specifically.

Here’s what matters about this move: a GTM engineer tuning prompts might have tightened the filter further to protect precision. An enablement person knew to broaden it, because enablement people understand that coaching culture and sales development culture are the same underlying belief.

The tactical shift:

• Draft your psychographic prompt narrow

• Then widen to the upstream belief that contains your pitch

• Measure: does the broader net still pass the relevance test? If yes, keep it

3) Clay’s hidden data edge: the Google Maps integration, and better accuracy than LinkedIn.

Two things I didn’t expect.

First, the Google Maps integration pulls local businesses that aren’t on LinkedIn at all. Arup pointed at a road near his house lined with family law firms near the Watford Family Court.

“Some of your mom and pop stores in the local area are on LinkedIn. Why would they be, right?” – Arup Chakravarti

If your ICP is SMB, local services, or regional, the entire LinkedIn-first prospecting stack is blind to a chunk of your market. Clay + Google Maps sees them.

Second, employee count accuracy. Arup spot-checked Clay against LinkedIn and against published annual reports. Clay tracked closer to the actual reported figures than LinkedIn did. LinkedIn inflates headcount because third-party resellers, influencers, and tagged contractors all count toward a company page. Clay doesn’t have that problem.

Why this matters: if you’re segmenting by employee count, LinkedIn is giving you a wrong number. For any private company, cross-check against Clay before you commit to the filter.

4) The honest answer most vendor podcasts skip.

I asked Arup what results he was getting from the outreach emails Clay was generating off this stack.

“I don’t know, I haven’t operationalized any of this. I’ve been focused a little bit more on trying to get a job, so... as opposed to selling.” – Arup Chakravarti

That’s the answer I trust. He built the method. He hasn’t run it at volume yet. So the case for this approach rests on method quality, not cherry-picked reply rates.

The difficulty rating he gave Clay: about a 5 out of 10. “A little fiddly.” He had to learn JSON structures to parse nested data out of Clay’s responses. The Clay University (free) is a better onramp than most people realize.

Why this matters: if you’re evaluating Clay for your team, calibrate learning curve expectations. It’s not Zapier-easy, it’s not Databricks-hard. Someone with LLM prompting fluency gets competent in a few weeks.

The tactical shift:

The big move from this episode isn’t a Clay hack. It’s a hiring and staffing question.

Your Clay output quality is capped by the domain expertise behind the prompts. A GTM engineer builds a bigger list. An enablement, CS, or product marketing vet builds a smarter one, because they know which soft signals predict buying behavior. If your Clay seat is on someone without that lens, you’re paying for a spreadsheet.

What to do this week:

• Audit your current Clay columns. Are any of them psychographic, or are they all firmographic? If all firmographic, you’re leaving the best signal untouched.

• Pair your Clay operator with a subject matter expert for one afternoon. Let them co-write one psychographic classifier column for your top use case. See what comes out.

• Run Arup’s broadening move on an existing prompt. Take your tightest filter and widen it to the upstream belief. Test both on the same 50 leads.

The next six months of outbound winners will not be teams with the most Clay credits. They will be teams with the smartest lens pointed at Clay.

The Clay Psychographic Prospecting Playbook

The Problem Most Clay Users Don’t See

Clay is having a moment. Credits are cheap compared to the data it unlocks. Integrations are deep. The AI columns do more in 30 seconds than a BDR can in 30 minutes. Most teams roll it out, build some firmographic lists, generate outreach, and send it.

Reply rates sit at 1 to 3 percent. Teams blame the copy.

The copy is not the problem. The filter is the problem. You are reaching out to the right companies and the wrong humans.

Firmographic targeting (industry, company size, tech stack, funding) tells you who can afford your product. Psychographic targeting tells you who will actually want it. Clay is built for both, but most users only operationalize the first half.

This playbook fixes that.

What “Psychographic” Means in a Clay Context

Pull these three concepts apart.

Firmographic signal. Static company attributes. Industry. Employee count. Location. Revenue band. Tech stack. Funding stage. This is the table-stakes stuff every Clay tutorial teaches.

Behavioral signal. Recent actions the company or person has taken. Job change. Funding round. Hiring surge. Tool installation. Post engagement. This is what modern prospecting tools like Common Room and Default chase. Useful, but still surface.

Psychographic signal. What the person actually cares about. Values. Motivations. The belief system that drives buying. A VP of Sales who posts about coaching culture is a psychographically different buyer than a VP of Sales who posts about quota crushing, even if the firmographics are identical. One of them wants what you sell. The other tolerates it.

The teams winning in Clay right now are the ones extracting psychographic signal. That work is not a Clay skill. It is a domain expertise skill. You need to know which beliefs map to which buying behaviors in your specific category. Clay just makes extraction cheap.

The 3-Column Framework

You can build this on any Clay table in 20 minutes.

Column 1: The Strategic Priority Inference

What it does: Pulls the last 10 articles, press releases, or media mentions about the company, parses them, and returns a short list of inferred strategic priorities with a confidence score.

Why it matters: Outreach that references a real, recent priority gets opened. Generic outreach gets ignored. This column gives you a priority lens before you write a single word of copy.

Prompt template:

Analyze the last 10 articles, press releases, and media mentions for {{company_name}}.

Based on the language, announcements, and themes, infer the 2-3 most likely
strategic priorities for this company over the next 12 months.

Return:
- Priority 1 (with one-sentence rationale)
- Priority 2 (with one-sentence rationale)
- Priority 3 (with one-sentence rationale)
- Confidence: HIGH / MEDIUM / LOW (based on signal clarity and recency)

Only include priorities supported by concrete evidence in the source material.
If evidence is weak or mixed, mark confidence LOW and explain why.

Color code the confidence column green/amber/red and sort by green first. You will burn fewer credits on low-signal companies.

Column 2: The Psychographic Classifier (The PDP Column)

What it does: Reads a person’s LinkedIn profile, posts, comments, and likes and classifies them as a Strong / Moderate / Weak advocate for a specific belief that maps to your buying trigger.

Why it matters: This is the column that separates a smart Clay setup from a generic one. You pick the belief. Your domain expertise decides which belief is the right one.

Prompt template (swap the belief for your category):

You are analyzing {{person_name}} at {{company_name}}.

Review their LinkedIn profile summary, their last 30 posts, their comments on
others' posts, and their likes pattern.

Classify them on this spectrum regarding [INSERT YOUR BELIEF HERE]:
- STRONG ADVOCATE: repeatedly and publicly champions this belief
- MODERATE ADVOCATE: aligned with this belief, occasional public signal
- WEAK ADVOCATE: neutral or no public signal
- COUNTER-SIGNAL: active evidence they hold the opposing view

Return:
- Classification: [one of the four above]
- Evidence: 2-3 specific examples from their content (quote or paraphrase)
- Rationale: 1-2 sentences on why you landed on this classification
- Confidence: HIGH / MEDIUM / LOW

The domain-expertise step. Do not use this prompt without picking the belief first. Your belief should be the upstream conviction that predicts buying behavior in your category. Examples by function:

• Selling sales enablement? “Advocate for professional development and coaching culture.”

• Selling RevOps tooling? “Advocate for clean data and process rigor over speed.”

• Selling customer success platforms? “Advocate for retention-led growth over top-of-funnel.”

• Selling AI to marketing? “Advocate for first-party data and marketing science over paid-ads dependency.”

• Selling security tooling? “Advocate for proactive risk culture over compliance-driven spending.”

Pick the belief your best customers hold. That belief, not their title, is your real ICP.

Column 3: The Tight-Loop Outreach Generator

What it does: Takes Column 1 (company priorities) and Column 2 (individual psychographic profile) and writes a first-draft outreach email that threads both signals into a single message.

Why it matters: Most Clay-generated email is bad because it pulls one signal (usually a recent funding round or a job change) and builds a whole message around it. The result is a sentence that works and four sentences of filler. This column forces the AI to thread two signals, which is the minimum for a message that reads human.

Prompt template:

Write a cold email to {{person_name}} at {{company_name}}.

Use these two signals:
1. Inferred company priority (from Column 1): {{strategic_priority_1}}
2. Psychographic classification (from Column 2): {{pdp_classification}} with
   evidence: {{pdp_evidence}}

My product / service: [INSERT 1-SENTENCE PITCH]
My proof point: [INSERT 1 RESULT OR CASE STUDY]

Format:
- Subject line (under 7 words, no colons, no hype words)
- Opening sentence: reference the psychographic signal specifically
  (quote or paraphrase something they said or wrote)
- Middle (2-3 sentences): tie their stated belief to the company priority,
  then to what we do
- Ask: one specific, low-friction next step

Rules:
- No "I hope this finds you well"
- No "I noticed"
- No em dashes
- Under 120 words total
- Sound like a human who did the research, not a tool that scraped the data

How to Stack the Three Columns

Build them in this order, in one table:

1. Company list first. Start with a firmographic ICP filter so you’re not running AI columns on unqualified accounts.

2. Priority column next. Sort by HIGH confidence. Drop LOW confidence rows.

3. People layer. Pull the contact list from each qualified company.

4. PDP classifier on people. Sort by STRONG advocates first, MODERATE second. Drop WEAK and COUNTER-SIGNAL.

5. Email generator. Runs only on STRONG and MODERATE rows.

The math: if your firmographic ICP produces 1,000 accounts, your high-confidence priority filter typically cuts that to 300 to 400. Your psychographic classifier cuts that to 60 to 120 actually-qualified humans. That is a far smaller list than most Clay users are used to sending. It is also the list that will actually reply.

Where Domain Expertise Changes Everything

A GTM engineer without a domain background will write the PDP prompt around the most obvious belief (”advocate for growth”). That prompt will classify 80% of LinkedIn users as Strong, which is useless.

A domain expert writes the prompt around the specific belief that is rare in the general population but common in their best customers. That prompt classifies 15-25% of leads as Strong, which is actionable.

Here is the test: if your psychographic classifier marks more than 40% of a broad list as Strong, your belief is too generic. Tighten it. If it marks fewer than 5% as Strong, it’s too narrow. Widen it. Target zone is 15 to 30%.

Three Pitfalls to Avoid

Pitfall 1: Using LinkedIn-only data for private companies. Clay pulls from other sources, and it is frequently more accurate than LinkedIn for private-company employee counts, revenue bands, and growth signals. Validate Clay against published annual reports when you can. Do not use LinkedIn as your ground truth.

Pitfall 2: Writing the psychographic prompt yourself without talking to your best customers first. You do not know the belief until you have heard your top 5 customers articulate why they bought. Interview them. Pull the belief from the recording. Use that language in the prompt.

Pitfall 3: Running the full stack on a low-credit plan. Clay’s credit economics punish exploration. Build your first version on a 50-row test list. Iterate the prompts until they return tight, usable output. Then run it at scale. Do not pour credits into a half-built classifier.

What To Do This Week

• Pick one upstream belief that predicts buying in your category. Write it as a single sentence.

• Interview three of your best customers. Confirm the belief. Adjust the language to match theirs.

• Build the 3-column framework on a 50-row test table in Clay.

• Run all three columns. Read the output yourself, row by row. Kick out any columns returning junk, and retune the prompt.

• Once the 50-row test looks right, scale to 500 and measure reply rates.

You do not need more Clay credits. You need sharper prompts written by someone who understands the buyer.

The Bigger Idea

Clay is not the moat. The domain expertise pointed at Clay is the moat. If your Clay seat sits on a junior BDR with a templated prompt, you are paying for a spreadsheet with extra steps. If it sits on a vet who understands the psychographic patterns of your best buyers, you are running a prospecting system the competition cannot copy without a 10-year operator.

Hire for the lens. The tool is the easy part.

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

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

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

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

Come build with us.

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

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

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

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

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

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

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

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

Shift 1. The Era Has Changed

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

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

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

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

Every interaction makes the system smarter.

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

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

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

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

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

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

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

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

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

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

I call them Aim, Army, and Assets.

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

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

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

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

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

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

Shift 3. The System Most Companies Don’t Have

Read more

As a reminder, we will always offer this GTM AI Podcast and Newsletter with its assets or giveaways for free. We have a library of strategic and tactical video walk throughs of anything from tech guides, to connecting multiple systems together, to how to set up advanced multi agent frameworks that you can do in the paid level.

You are welcome to join us anytime!

Subscribe now

For now, lets get into this weeks podcast with the CEO of Spara, David Walker.

For 20 years, your revenue was capped by how many humans you could put on a phone.

That constraint is gone.

I just recorded a podcast with David Walker, co-founder and CEO of Spara, and he did not mince words: “If you don’t have an agentic front door, you basically don’t have a front door at all.” Every buyer now starts discovery inside an LLM. They leave ChatGPT, click through to your site, and hit a form from 2008. That is not a front door. That is a dead end.

Here is what pays for your read today.

1. Stop only automating Salesforce fields. Start rebuilding the motion.

The single biggest mistake David sees in GTM leaders: “I have my old human-led motion, I just want to automate one small piece.”

His counter is a thought exercise I’m stealing immediately. He sits executives down and asks: “Your sales team just 10X’d for free, starting tomorrow. What do those 90 new people do?”

Nobody answers “update a Salesforce field.”

They answer: “Talk to every person on our website. Run every ICP research play. Follow up on every raised hand in real time. Run the 90-day upsell motion with the right signals, not blasts.”

That list IS your new GTM motion. AI agents are how you build it without hiring 90 people. The strategy unlock is not “make the old thing faster.” It is “design the motion that would have been impossible and now isn’t.”

• Run the 10X exercise on your own team this week.

• Audit each item on the list and ask “is a human the highest and best use, or is an agent?”

• Sequence the build order by revenue impact, not by what’s easiest to automate.

2. Lean INTO “this is AI.” Conversion goes up.

When Spara launched, customers were split 50/50 on whether their agent should disclose it was AI.

Today it’s 99% AI-disclosed.

The reason is counterintuitive: buyers get MORE direct when they know it’s an agent, not less. They stop performing. They drop the dance. They say: “Here are the 3 things I care about in this procurement process. Can you do them?”

Now your AE walks into the first call already holding the map of the deal. The pre-call discovery work that used to take three touches happened in 30 seconds on a call the prospect wanted.

• Default your inbound agents to disclose.

• Lead the conversation with value prop + reason: “I want to get you to the right person fast. Can I ask three questions?”

• Capture the buyer’s stated priorities verbatim and route them to the AE notes before the first meeting.

3. The Kayak vs Wedding Planner filter.

GTM leaders keep asking the wrong question: “Will buyers want to talk to AI?”

Reframe it. Every moment in your funnel is either a Kayak moment or a Wedding Planner moment.

Kayak moments are high-frequency, low-consequence, I-want-an-answer-right-now moments. Form fills. “Do you have voice AI?” replies. Pricing questions. Usage-based upsell triggers. Buyers 100% want an agent here, because the alternative is waiting 8 hours for a human to email back and the buyer has already context-switched.

Wedding Planner moments are low-frequency, high-consequence, I-want-a-human-physically-present moments. Executive business reviews. Enterprise procurement. The close call on a seven-figure deal. Keep humans on these.

The fatal error is mushing the whole funnel into one answer. Deploy humans in high-leverage, high-consequence moments. Deploy agents everywhere else. The customers David shared results from are not running “AI-only” or “human-only” motions, they’re running hybrid motions with every moment mapped.

• Map your inbound funnel moment by moment.

• Tag each as Kayak or Wedding Planner.

• Deploy the right instrument to each.

4. The results are not incremental.

David shared two case studies on the show. Both are instructive because they attack different sides of the funnel.

The first: a company with a flood of low-tier free users clogging the “Contact Us” form and starving the sales team of real enterprise MQLs. Spara was deployed on inbound. Qualified MQL rate went up 3X. Unqualified junk dropped 80%. The low-tier users actually left happier because they got their answer immediately instead of being disqualified by an SDR. The sales team got more of the right conversations. Win-win-win.

The second: a company that deployed a chat agent and started booking 50% more qualified meetings on the same traffic. The result was not that they fired reps. They hired more reps because the pipeline outgrew the team. The AI expanded the business; it didn’t shrink the headcount.

Two different failure modes solved by the same move: put a conversational agent where there used to be a dead end.

The tactical shift:

• This week: Walk your own inbound journey as a buyer. Every moment you hit a dead end, flag it.

• This month: Run the 10X Horsepower exercise with your leadership team. Write down the motion the new people would build.

• This quarter: Stand up ONE conversational agent at the highest-intent dead end on your site. Measure qualified meeting lift + AE notes richness.

Don’t try to boil the ocean. Pick the single moment where a buyer today raises their hand and nobody’s there. Put an agent there. Watch the KPIs move.

My challenge to you this week: stop optimizing the old motion. Redesign the one you’d have built if capacity was never the constraint. Because starting now, it isn’t.

To help you run this yourself, I built a free 10X Horsepower Workshop kit down below which is a complete 90-minute facilitated session for your leadership team. Pre-work, agenda, prompts, worksheets, facilitator notes, 30-day commitment template. Works whether you use Spara, a competitor, or nothing at all. Download in the link below.

The 10X Horsepower Workshop

A 90-Minute Strategic Reset for GTM Leadership Teams

Stop optimizing the motion you have. Design the motion you’d build if capacity was never the constraint.

By Jonathan “Coach K” Kvarfordt | GTM AI Academy Inspired by David Walker, CEO of Spara

Why This Workshop Exists

Most GTM leaders are stuck in constraint thinking.

You inherited a sales motion that was designed for 10 reps. You hire faster. You add tools. You optimize calls per day. You ask AI to “automate one small piece” of the existing motion. The math gets slightly better. The motion stays the same.

Meanwhile, the company that out-executes you next year is not running your motion 10% faster. They’re running a different motion. They redesigned what good looks like the moment they realized capacity was no longer the constraint.

This workshop is the forcing function.

It comes from a conversation with David Walker, CEO of Spara, who runs this exercise with executive teams every week. The prompt is simple. The shift it creates is not.

“Your sales team just 10X’d in size, starting tomorrow, at zero additional cost. You went from 10 reps to 100 reps. Headcount, comp, ramp — all free. What do those 90 new people do?”

Nobody answers “update Salesforce fields.” That’s the point. The answers reveal the motion you would build if you weren’t trapped by today’s headcount math.

This kit gives you everything to run that exercise with your leadership team in 90 minutes and includes an agenda, prompts, worksheets, facilitator notes, and a 30-day commitment template.

Who This Is For

• CROs and VPs of Sales rethinking GTM strategy

• CMOs aligning marketing motion to a redesigned sales motion

• RevOps leaders building the operating system that supports the motion

• Founders preparing for the next stage of GTM scale

• Heads of CS thinking about expansion as a discipline, not an afterthought

You’ll get the most value running this with 4-8 cross-functional GTM leaders in one room (or one Zoom), with a sharp facilitator and the agreement that nothing is feasibility-gated until Round 4.

The Setup (Read Before You Run It)

Why this exercise works.

Constraint thinking is invisible. You don’t know you’re inside it. When asked to “improve the sales motion,” your brain auto-generates ideas that fit within today’s capacity envelope. The prompt is pre-filtered. The answers are incremental.

When you remove the capacity constraint explicitly and dramatically, the brain has to reach for ideas that were previously impossible. Those ideas are not random. They are the highest-value moves you’ve been quietly suppressing because there was no one to do them.

Your job in this workshop is to surface those moves and then translate them into a real motion using AI agents and humans in the right roles.

The four most common executive responses (and what to do).

1. “That’s not realistic.” Cut them off politely. Round 2 is not for feasibility. They get to push back in Round 4. Until then, force imagination.

2. “We’d just have them do more of what we do today.” Probe twice. “More what? Calls to whom? Saying what?” Specificity surfaces the real wishlist.

3. “AI can’t actually do that.” Park it. Round 4 handles the human-vs-agent split. Round 2 is purely about identifying the work.

4. “This is just a thought exercise.” Yes. And the output is a real 90-day motion. Stay disciplined and they’ll see it by Round 5.

What you need.

• 90 minutes (60-minute express version included below)

• A whiteboard or shared doc

• One participant per cross-functional GTM lead (4-8 people total)

• A facilitator who will keep rounds tight and protect the no-feasibility rule

• Pre-work sent 24 hours in advance (Part 1 below)

Part 1 — Pre-Work

Format: Async, 15 min per participant Send: 24 hours before session

Drop this into a Slack DM or email to each participant:

Subject: Pre-work for our GTM strategy reset (15 min)

Before we meet, please complete the worksheet attached. Two parts:

(a) Baseline. In 3 sentences, describe your team’s current motion. What do reps actually spend their time on? Be honest, not aspirational.

(b) The graveyard. List 5 things you wish your team did but they don’t have time for. Examples: “follow up on every doc-page view,” “run discovery on every dormant account quarterly,” “respond to every inbound at 9pm.” No filter. No judgment.

Bring both to the session. We’ll start there.

The pre-work matters because it gets everyone past the warming-up phase. They arrive with a baseline AND a wishlist, which means Round 2 has fuel from the first minute.

Pre-Work Worksheet

Question Answer (a) In 3 sentences, what does your team’s current motion actually look like day-to-day? (b1) Wish-list item #1 — what would you have your team do if they had time? (b2) Wish-list item #2 (b3) Wish-list item #3 (b4) Wish-list item #4 (b5) Wish-list item #5

Part 2 — The Imagination Round

Format: Solo writing → group share-out Duration: 20 min (8 min solo + 12 min share)

This is the David Walker prompt. Read it out loud, exactly:

“Tomorrow, your sales team is 10X bigger. You went from your current headcount to 10 times that, at zero additional cost. No ramp time. No comp impact. They show up tomorrow ready to work.

The only rule: don’t tell me about Salesforce field updates or admin tasks. I want to know what those new people actually DO with customers and prospects.

You have 8 minutes. Solo. Write 10 answers. No filter, no feasibility, no thinking about AI yet.”

Run it solo first. Group brainstorm corrupts the output. You want individual lists.

The Imagination Worksheet

# If I had unlimited rep capacity, my 90 new people would… 1 2 3 4 5 6 7 8 9 10

After 8 minutes, share round-robin for 12 minutes. Each person reads their list. Capture every unique answer on the whiteboard. Don’t debate. Just capture.

Facilitator watch-fors:

• Anyone says “automate” immediately flag it. That’s constraint thinking. Push them.

• Multiple people say the same thing, then note the cluster. That’s signal.

• Someone is stuck, feed them a category prompt: “What about your dormant pipeline? Your free users? Your inbound at midnight?”

You should end Round 2 with 30-60 unique items on the board.

Part 3 — The Synthesis Round

Format: Group clustering Duration: 20 min

Now you cluster the answers into a small number of categories. Walk the board with the team and group items into 5-7 buckets. The categories almost always emerge as some version of:

• Discovery & Research (account, persona, intent, competitor signals)

• Real-Time Engagement (inbound response, in-product chat, after-hours)

• Long-Tail Coverage (dormant accounts, free tier, second-tier ICP)

• Expansion & Retention (usage signals, upsell triggers, renewal prep)

• Content & Enablement (custom proposals, follow-ups, demo prep)

• Signal & Intelligence (competitive moves, buyer behavior, deal risk)

Synthesis Worksheet

Category # items in cluster Highest-value example Estimated leak today (gut, 1-5) Discovery & Research Real-Time Engagement Long-Tail Coverage Expansion & Retention Content & Enablement Signal & Intelligence (Other)

This output IS your new GTM motion. The categories with the highest cluster count + highest leak score are the parts of your motion you’ve been silently writing off because nobody had time to do them.

Reframe — read out loud:

“Look at the board. None of you said ‘automate one Salesforce field.’ You said ‘talk to every buyer,’ ‘follow every signal,’ ‘engage every dormant account.’ This is the motion you’ve been wanting to build for years and have been blocked from building by capacity. Today we’re going to build it.”

Part 4 — The Human vs Agent Translation Round

Format: Pair work or full group Duration: 20 min

Now you re-introduce a constraint, but it’s a new one. Not “how many humans can we afford” but “which moments demand a human vs which can be done better, faster, and 24/7 by an agent?”

Use the Kayak vs Wedding Planner filter (David’s framing):

• Kayak Moment — high-frequency, low-consequence, “answer me right now.” Buyer’s willingness to wait is near zero. Build for AI agent.

• Wedding Planner Moment — low-frequency, high-consequence, buyer wants a human present. Build for human.

• Hybrid Moment — AI first touch + human handoff at qualification.

Translation Worksheet

One row per high-value item from Part 3.

Item from synthesis K / W / H If AI: what tool category does this require? If Human: what lower-value work do they STOP doing to make room?

The reveal. When the team finishes this worksheet, two patterns will jump out:

1. 70-80% of your wishlist is Kayak or Hybrid. Those are the items where AI agents make the previously impossible motion possible.

2. The 20-30% that’s pure Wedding Planner is what your humans should be exclusively doing. Most teams currently have humans doing 80% Kayak work and 20% Wedding Planner work. That’s the inversion.

This is the moment the room shifts. Executives stop debating “if” and start debating “in what order.”

Part 5 — The Build Order

Format: Group scoring + ownership assignment Duration: 15 min

You have a list. Now make a plan.

For each AI-tagged item in Part 4, score 1-5 on three dimensions:

• Volume: How many buyers/accounts does this affect per month?

• Intent: How qualified is the buyer at this moment? (5 = ready to buy, 1 = casual reader)

• Pain: How obvious is the leak today? (5 = AEs visibly losing deals here, 1 = nobody notices)

Priority Score = Volume × Intent × Pain

Build Order Worksheet

Item Volume (1-5) Intent (1-5) Pain (1-5) Score Owner Build by

Take the top 3. Assign an owner. Assign a 30-day deadline.

The discipline: only three. Teams that try to launch six AI agents in week one do not get 3-5X conversion lift. Teams that ship one carefully tuned agent in 30 days, then learn from it before shipping the second, do.

The 90-Day Rhythm

• Days 1-30: Build, deploy, and tune Agent #1. Measure baseline lift.

• Days 31-60: Build Agent #2 using prompting + tone learnings from #1. Begin A/B testing #1.

• Days 61-90: Build Agent #3. Re-run this entire workshop with the team. Identify next 3.

Part 6 — The Cadence

Duration: 5 min

This is not a one-time exercise. It’s a quarterly reset.

Every quarter, capacity unlocks somewhere — a new agent ships, a manual process gets eliminated, a team member moves up. The motion you can build keeps expanding. If you only run the 10X Horsepower exercise once, you’ll re-anchor to your new constraint within a quarter.

The commitment to make in the room (read it out loud, get verbal yes):

“We will re-run this exercise on the first Tuesday of every quarter. Same prompt. Same imagination round. We will re-build the motion every 90 days because our capacity envelope keeps changing and our motion should change with it.”

Put it on the calendar before the meeting ends. Without the cadence, you’ll regress to constraint thinking by next quarter.

The Express Version (60 Minutes)

If you can only get 60 minutes:

Round Time Notes

Part 1 — Pre-work Async Mandatory. Skip and the session collapses.

Part 2 — Imagination 15 min Cut to 5 min solo + 10 min share

Part 3 — Synthesis 15 min

Part 4 — Translation 15 min

Part 5 — Build Order 12 min

Part 6 — Cadence 3 min

Same outputs. Less debate room. Use only if executive calendars don’t allow 90.

What to Do With the Output

Within 24 hours of the session, the facilitator should:

1. Send the build order table to all participants with owners + deadlines locked in

2. Schedule the 30 / 60 / 90-day check-ins on calendars

3. Schedule the next quarterly reset (90 days out)

4. Identify a single executive sponsor for each of the top 3 agents — usually the leader whose function is most affected

5. Capture the synthesis board as a photo or doc — this becomes the artifact you reference for the rest of the year

Common Failure Modes

• The room debates feasibility in Round 2. Facilitator’s job: “We’ll get there in Round 4. Right now, write what you’d do.”

• Everyone defaults to “more outbound.” Probe: “More outbound to whom? Saying what? Triggered by what?” Specificity wins.

• No one writes 10 answers. Time pressure helps. Hard 8-minute timer.

• The team picks 6 priorities instead of 3. Cut. Ruthlessly. Three or fewer in the first 90 days, every time.

• No quarterly cadence is scheduled. This is the single most common failure mode. Without a calendared re-run, the motion ossifies.

My Challenge to You

Run this in the next two weeks. Not next quarter. Not after planning season. The teams that out-execute you in 2026 are running this exercise right now, and they will have shipped their first three agents before your next QBR.

Block the 90 minutes. Send the pre-work tonight. The first time you watch a CRO write “talk to every person who lands on our site” and realize that’s now a 30-day deliverable, the room changes.

That’s when you stop optimizing the old motion and start building the new one.

— Coach K

© 2026 GTM AI Academy. Free to use and share. Attribution appreciated.

Revenue is engineered, not hoped for. The same thing is true for agentic systems. More agents don’t produce more intelligence if the underlying system has no memory.

What I Got Wrong The First Time

I’ll save you the lecture and lead with the confession. My first version of this system was genuinely embarrassing.

I had a folder of agent files. I had prompts I was proud of. I had a handful of skills wired into Claude Code. What I did not have was any way for those agents to know what any other agent had ever done, said, or learned. Every session started at zero. Every question got researched again. The CMO agent would produce a positioning brief on Monday. The sales enablement agent would ask the same positioning questions on Wednesday. I was paying in tokens and time for work I’d already done.

The deeper failure was that I couldn’t see it. The individual outputs looked great. Each agent, on its own, produced a useful artifact. It was only when I tried to chain them that the gaps showed up. A research agent would cite a stat. A writing agent would misquote it by 15%. A review agent would miss the misquote because it had never seen the original. Each agent was locally competent and globally incoherent.

That’s the failure mode nobody talks about when they show off their agent count. Agents that can’t share memory are not a system. They are a cast.

The Extended Analogy, Then The Twist

Most people think about agents like hiring. You’ve got a CMO, a CRO, a controller, a research analyst. Each one is a specialist. Each one has a job description. You build your org chart, you set goals, you run 1:1s, and the work gets done.

That framing is almost right, and the “almost” is the part that kills companies.

A real hire has shared context by default. They sit in the same meetings. They hear the same hallway conversations. They read the same Slack threads. They remember what happened last quarter because they lived through it. An agent has none of that. An agent is a contractor on their first day, every day, forever, unless you build the substrate that gives them continuity. Your org chart of agents is not 104 hires. It is 104 contractors walking into a building with no elevator. They can each do great work on floor 7. They just can’t get to floor 8.

The knowledge graph is the elevator.

Why Memory Is A Layer, Not A Feature

The Revenue Nervous System has six layers: Data, Intelligence, Context, Memory, Orchestration, Execution. I get asked all the time why Memory is a layer and not a capability inside Orchestration or Context. Because Memory is what makes the other layers cooperate.

Data without Memory is a warehouse that forgets yesterday. Intelligence without Memory is a model that re-derives the same pattern every morning. Context without Memory is a retrieval step that never learns which retrievals worked. Orchestration without Memory is routing that treats every request like it’s the first one. Execution without Memory is a writeback that nobody reads.

Memory is what turns a stack of cooperating services into a system that compounds. Without it, every run is independent. With it, the week after produces better answers than the week before, because the week before left a trace.

The shape of the fix is a knowledge graph with four layers that stay in sync whenever anything gets written. Visual, context, vector, temporal. Each answers a different question. Together they are the Memory Layer. Agents that can’t share memory are a cast. Agents that can share memory are a team.

That is the framing. The next question is the only one that actually matters for operators: what does this look like on disk, what runs when, and how do you build it yourself without hiring a platform team.

How You Actually Build It

Read more

A real kitchen has a line. Ticket comes in, the expediter reads it, it goes to the station that can cook that plate, the plate comes back, it ships. The cook doesn’t read every label every time. The expediter does. The cook cooks.

That’s the difference between a prompt library and an orchestrated system. It’s also why most AI rollouts stall the second the novelty wears off.

This guide is how you build the expediter. Three working layers by the end: a registry that lists your specialists, a router that picks the right one for a given task, and an orchestrator that coordinates handoffs when the job needs more than one pair of hands.

You don’t need to be technical. You need to be able to write a clear one-sentence job description and name the things your team actually ships. That’s the whole skill. If you can run a team, you can build this. The parts that look like code (the registry, the instruction files) are patterns your AI can generate for you once you tell it what each specialist does. Your job is the thinking. The typing is automatable.

If you’re a founder, a GTM operator, or an exec who has been watching your people bounce between ten tools and ten chat windows, this is the piece that makes the mess coherent.

The Problem With One Giant Prompt

You’ve probably tried the one-giant-prompt approach. A single system prompt that says “you are a world-class marketer and salesperson and engineer and legal advisor.” It kind of works. Until it doesn’t.

Three things break it:

1. Context dilution. Every capability you bolt on makes every answer a little blurrier. The model can’t specialize in ten things at once, because specialization is depth of frameworks, not just knowledge of terminology.

2. No composability. You can’t hand off a sub-task. It’s one persona, so every task starts from zero context.

3. No accountability. When the output is wrong, you don’t know which part of the prompt failed. You tune the whole thing and hope.

Orchestration fixes all three. Each agent gets a narrow job, a clear handoff interface, and a visible mandate that either works or needs rewriting. The system becomes diagnosable. Diagnosable is the precondition for improvable.

Read more

As a reminder, we would love to make sure you subscribe below, you can get every weeks podcast and assets for free after subscribing.

If you need or want help deep diving into AI tech, guides, walk throughs and live meetups, we would love to have you join as a paid member, but no pressure!

Subscribe now

We have a few goodies today, the first one is a Claude Code guide based on todays podcast you can access the guide here

The second one is below and is the Build vs Buy framework inspired by todays podcast.

Our guest is Marchelle Mooney, VP of Sales at Mangomint

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.

A former hairstylist built a custom LMS, automated post-call workflows, and analyzed 212 cold call transcripts in 3.5 minutes. No Python. No engineering degree. Just Claude Code and the refusal to wait for someone else to solve the problem.

Marchelle Rooney is the VP of Sales at Mangomint, a $25M ARR vertical SaaS company serving salons and spas. Her team runs a 2-day sales cycle (down from 5), closes 20-30 new logos per month per AE, and just posted an 8% win rate increase in under a year. Her stack: Momentum for call intelligence and deal signals, Nooks for dialing and outbound sequencing, Avara for AI role-play simulation, Notion for SOPs and knowledge, and Claude Code as the glue that connects everything the vendors don’t. The tools she showed on this week’s GTM AI Academy podcast aren’t theoretical. They’re in production. Built by non-technical operators who decided “everything is figureoutable.”

Here’s what stood out:

1) Her Director of Onboarding (a former hairstylist) built a full LMS in Claude Code.

Mangomint looked at buying an LMS. Then they realized their product changes too fast for a traditional tool to keep up. Marissa, who came from behind the chair, built a custom product training platform connected to Notion via MCP. It tracks progress by module, submits certifications to managers, and breaks learning into weekly complexity tiers. Their engineering team asked: “Wait, did you actually code any of this?” She didn’t. She told Claude what she needed.

The strategic shift: When your product moves fast, the people closest to the customer should own the training tooling. Not a vendor. Not IT. The operator.

2) They analyzed 212 BDR transcripts in 3.5 minutes to rebuild their cold call playbook.

Marchelle couldn’t export call data from Nooks (their BDR dialer and outbound sequencer). Old approach: copy-paste until your head falls off. New approach: she used Claude’s browser extension to scrape all 212 transcripts into a JSON, then fed them into Claude Code for analysis. Out came:

• Top objections (and which ones were actually overcome)

• Pattern interrupts that booked demos vs. ones that didn’t

• Battle card gaps where reps were getting caught flat-footed

• Regrettable vs. non-regrettable lost conversations

This is the same playbook they used with AEs 6 months earlier, where a frontline manager named Noah pulled transcripts, found the patterns, rebuilt the golden script, layered it into Avara (AI role-play simulator), and required passing scores to stay in the round robin. The result: 8% win rate increase from 29% to 37%.

3) A junior data analyst solved an import problem in one week that a senior engineer said was impossible.

The senior engineer had deep API experience and knew all the ways this import had failed before. The junior analyst didn’t know what couldn’t be done. She just asked Claude Code to help her figure it out. One week later, the problem was solved. Marchelle called it “the blessing of not knowing too much.”

This is the build vs. buy unlock: your revenue team prototypes with AI, the best solutions bubble up, and then engineering hardens what actually moves revenue. The people closest to the customer become the product feedback loop.

4) They built a post-call automation layer on top of Momentum that handles what Momentum doesn’t.

Momentum captures call signals and pushes tasks to Salesforce and Slack. But Marissa’s onboarding team needed more nuance: specific hardware orders based on what was discussed, action items beyond CRM field updates, and multi-step implementation workflows. So she built a Claude Code tool that takes a Momentum transcript, extracts every action item, and generates one-click hardware shipping orders from the conversation details (address, stand color, card reader type). The gap between what your call intelligence tool captures and what your team actually needs to execute? That’s the bridge AI builds.

5) “Micromanage the data, not the people” is her operating system.

Marchelle’s managers know: if she starts jumping back into the details on something, that’s the signal to go build a solution. She doesn’t tell them what to build. She watches the data, finds the friction, and her team reads the pattern. It’s management by visible obsession with the metric, not the task. When her team sees her harping on one thing, they know: that’s the thing to go solve.

Why this matters:

The companies winning right now aren’t waiting for vendor integrations or perfect API coverage. They’re giving non-technical operators Claude Code and a mandate: find the friction, build the MVP, prove the revenue impact. Then decide if engineering needs to harden it.

What to do this week:

• Have every frontline manager record their full day, then feed it to Claude and ask what can be automated (credit: Jordan Crawford)

• Identify the one data export or analysis you’ve been putting off because the tool doesn’t support it. Use Claude’s browser extension to get the data out

• Stop hiring for problems you haven’t tried to solve with AI first. Build the case, then make the hire

The people closest to the revenue are the ones who should be building. Not because they’re technical. Because they know what actually matters.

BUILD VS. BUY GUIDE: THE NON-TECHNICAL OPERATOR’S PLAYBOOK

How to Decide What to Build, What to Buy, and How to Make Everything Work Together (Regardless of Tech Stack)

WHY THIS GUIDE EXISTS

A VP of Sales with zero technical background just built tools that made her engineering team ask: “Wait, did you actually code this?”

She didn’t. Her team talked to Claude Code. They built a custom LMS connected to Notion, analyzed 212 cold call transcripts from Nooks in 3.5 minutes, automated post-call workflows that extend what Momentum captures, and created a golden script system trained through Avara (AI role-play simulator) that drove an 8% win rate increase.

This guide isn’t about Marchelle’s specific tools. It’s the decision framework and execution playbook behind what she did, so you can do the same thing with whatever stack you run. Gong or Momentum. Outreach or Nooks. Confluence or Notion. Salesforce or HubSpot. The framework is stack-agnostic. The principle is universal: the people closest to the customer should be the ones building solutions, and AI just made that possible without writing a single line of code.

THE CORE FRAMEWORK: BUILD, BUY, OR BRIDGE

Every revenue team hits the same wall: your tools don’t do exactly what you need. You have three options, and most teams only consider two of them.

BUY: Purchase a point solution that solves the problem out of the box. This is the right call for stable, infrastructure-level needs (CRM, dialer, email platform, core call intelligence). You don’t build your own Salesforce. You don’t build your own dialer. Buy the foundation.

BUILD: Create a custom solution using AI tools like Claude Code. This is the right call when the problem is unique to your business, changes frequently, or sits in a gap no vendor covers. Marchelle’s team built a custom LMS because Mangomint’s product changes too fast for any off-the-shelf LMS to keep pace. That’s a build.

BRIDGE: Use AI to connect existing tools and fill gaps between them. This is the most underused option, and it’s where the fastest wins live. You’re not replacing tools. You’re filling the seams. Marchelle used Claude Code to bridge Nooks (which doesn’t have bulk transcript export) to her analysis workflow. She bridged Momentum transcripts to automated hardware ordering. She bridged Notion content to a tracking and certification layer.

The mistake most teams make: they default to Buy or they wait. They wait for the vendor to ship the feature. They wait for engineering to have bandwidth. They wait for budget approval. Meanwhile, the problem compounds, reps run outdated playbooks, and deals slip.

The new playbook: Bridge first, validate the impact, then decide whether to Buy or Build permanently.

STEP 1: IDENTIFY THE FRICTION (THE “RECORD YOUR DAY” METHOD)

Before you decide what to build or buy, you need to know where the real problems are. Not where you think they are. Where the time actually goes.

The exercise (credit: Jordan Crawford of Cannonball):

1. Every frontline manager records everything they do for one full day. Every task. Every copy-paste. Every manual lookup. Every “I wish this tool did X.” Every toggle between tabs. Every time they say “I’ll just do it manually.”

2. Feed that list into Claude (chat, not code) and ask: “Which of these tasks are repetitive, don’t require deep judgment, and could be automated or accelerated?”

3. Rank the output by two criteria: (a) time consumed per week, and (b) proximity to revenue impact.

The filter question Marchelle uses: If I do this one thing, does it impact the downstream metrics that drive revenue?

Her team at Mangomint calls this the MIT (Most Important Thing). Every manager identifies one thing per week. Not five priorities. One. The thing where solving it unlocks everything downstream.

What this looks like in practice across different roles:

For a Sales Manager: “I spend 3 hours per week manually reviewing call recordings to check script adherence.” That’s a bridge. Your call intelligence tool (Momentum, Gong, Chorus) captures the calls. Claude Code can analyze transcript patterns against your golden script and flag deviations automatically.

For a RevOps Leader: “I can’t get the data out of Tool A in the format Tool B needs.” That’s a bridge. Claude’s browser extension or Claude Code can extract, transform, and load data between tools that don’t natively integrate.

For a BDR Manager: “My reps cherry-pick from the prospect list based on gut feeling instead of the scoring model.” That’s a build. You need a tool that surfaces why each prospect is scored the way it is, so the rep trusts the data instead of second-guessing it.

For an Enablement Lead: “Our training content is outdated within two weeks of publishing because the product moves so fast.” That’s a build. You need training infrastructure that pulls directly from your live knowledge base, not a static LMS.

For a CS Manager: “I manually check 15 dashboards to build my weekly at-risk account list.” That’s a bridge. Claude Code can pull from your existing data sources and build the consolidated view you actually need.

STEP 2: RUN THE BUILD-BUY-BRIDGE DECISION TREE

For each friction point you identified, run it through this:

QUESTION 1: Does a tool already exist that solves this well?

• Yes, and it integrates cleanly with our stack → EVALUATE BUYING

• Yes, but integration is limited, incomplete, or the tool does 80% of what we need → BRIDGE (see Step 3)

• No, this is unique to our business or workflow → BUILD (see Step 4)

QUESTION 2: How fast does this problem change?

• The requirements shift monthly or faster (scripts, playbooks, competitive intel, product training) → BUILD or BRIDGE. Vendors update quarterly at best. Your competitors aren’t waiting.

• The requirements are stable (CRM, dialer, email infrastructure, core analytics) → BUY. Don’t reinvent infrastructure. That’s ego, not strategy.

QUESTION 3: Who understands the problem best?

• The people closest to the customer (AEs, BDRs, CSMs, onboarding, frontline managers) → BUILD or BRIDGE. They should prototype it because they know the nuance no product spec will capture.

• A technical team with no customer context → BUY a tool that abstracts the complexity away from them.

QUESTION 4: What’s the cost of waiting?

• If the vendor ships the feature in 6 months, what do you lose in the meantime? Marchelle’s team didn’t wait for Nooks to build a transcript export. She scraped 212 transcripts in 3.5 minutes with Claude’s browser extension. Six months of waiting would have meant six months running outdated battle cards and an old golden script while competitors adapted.

QUESTION 5: Can a non-technical person prototype this in under a week?

• Yes → BRIDGE or BUILD it now. Validate with real data. Then decide if it needs engineering investment.

• No, it requires deep infrastructure work (database migrations, security layers, production-grade API integrations) → BUY or put it on the engineering roadmap with the prototype as the spec.

Decision Tree Summary:

FRICTION IDENTIFIED
    │
    ├── Stable, infrastructure-level need? → BUY
    │
    ├── Gap between two existing tools? → BRIDGE
    │       (Claude Code / browser extension fills the seam)
    │
    ├── Unique to your business + changes fast? → BUILD
    │       (Operator prototypes with Claude Code)
    │
    └── Not sure? → BRIDGE first (fastest to validate)
            Then decide: Buy, Build permanently, or let it ride as-is

STEP 3: HOW TO BRIDGE (CONNECT WHAT YOU ALREADY HAVE)

Bridging is the fastest path to value. You keep your existing tools. You keep your existing workflows. You just fill the gaps between them with AI.

Real examples from Mangomint’s stack:

Gap: Nooks (BDR dialer + sequencer) doesn’t support bulk transcript export for analysis. Bridge: Claude’s browser extension scraped 212 transcripts into a JSON file in 3.5 minutes. Claude Code then analyzed them for objection patterns, successful pattern interrupts, and battle card gaps. Impact: New BDR golden script and updated live battle cards, derived from actual call data instead of manager opinion.

Gap: Momentum (call intelligence) captures signals and pushes tasks, but the onboarding team needs more nuanced post-call actions than field updates and task creation. Bridge: Custom Claude Code tool takes a Momentum transcript, extracts every action item, identifies hardware needs discussed on the call (stand color, card reader type), and generates one-click shipping orders using the customer’s address from the transcript. Impact: Post-call execution went from “read the notes and figure it out” to “one-click and it’s done.”

Gap: Notion holds all SOPs and training content, but tracking who learned what, testing comprehension, and reporting progress to managers was a mess. Bridge: Claude Code + Notion MCP built a custom LMS that pulls content directly from Notion, breaks it into weekly modules of increasing complexity, includes certification quizzes, and submits progress to the frontline manager. Impact: No more stale LMS content. No more “did they actually learn it?” ambiguity. Training updates the moment Notion updates.

How to find bridge opportunities in YOUR stack (regardless of tools):

Think about the places where you manually move information between two systems. That’s the bridge.

The three-step bridge pattern:

1. Identify the gap between two tools (where manual work or lost context lives)

2. Use Claude Code or Claude Chat to prototype the connection

3. Validate: Does it save time? Does it improve data quality? Does it accelerate the workflow?

If yes, keep running it. If the volume or complexity grows, decide whether engineering should harden it into a permanent integration.

STEP 4: HOW TO BUILD (THE NON-TECHNICAL OPERATOR’S PATH)

You do not need to know how to code. You need to know three things:

1. What problem you’re solving (be specific: “I need to analyze 200+ cold call transcripts to find which objections we overcome vs. which ones we lose to”)

2. What the input is (transcripts, CSVs, Notion databases, CRM data, exported spreadsheets)

3. What the output should look like (a ranked list, a dashboard, a training module, an automated workflow, a Slack alert)

The tools, in order of complexity:

Level 1: Claude Chat (zero technical skill)

• Ask questions, get analysis, brainstorm approaches, process text

• Best for: one-off analysis, content creation, strategy thinking, cleaning up data you’ve pasted in

• Example: Paste 5 call transcripts and ask “What are the top 3 objections and how were they handled?”

Level 2: Claude Chat + Browser Extension / Cowork (minimal technical skill)

• Claude can interact with web apps you’re logged into, read pages, click buttons, extract data

• Best for: scraping data from tools that don’t have export, filling forms, navigating UIs at scale

• Example: This is exactly how Marchelle pulled 212 transcripts from Nooks. The tool doesn’t export. Claude’s browser extension went in and pulled them one by one. 3.5 minutes.

Level 3: Claude Code (moderate comfort with a terminal)

• Build actual applications, analyze data at scale, create tools with UIs

• Best for: custom apps (like the LMS), bulk data analysis, workflow automation, anything that needs to process more data than you can paste into chat

• You don’t write code. You describe what you want. Claude writes and runs the code. You review and iterate.

• Example: “I have a JSON file with 212 call transcripts. Analyze each one for: objections raised, whether they were overcome, pattern interrupts used, and competitor mentions. Give me a summary with rankings.”

Level 4: Claude Code + MCPs (connecting to your live systems)

• MCP (Model Context Protocol) lets Claude Code connect directly to tools like Notion, Slack, Google Drive, databases, and more

• Best for: building tools that read from and write to your existing systems in real time

• Example: The Mangomint LMS pulls content from Notion via MCP, so when SOPs update in Notion, the training modules update automatically. No re-upload. No version mismatch.

Level 5: Claude Code + MCPs + Browser Automation (the full stack)

• Combine all of the above: code-level analysis, live system connections, and browser-based interaction with tools that don’t have APIs

• Best for: end-to-end workflows that span multiple tools, some with APIs and some without

• Example: Scrape transcripts from the browser (Level 2), analyze them in Claude Code (Level 3), push the resulting golden script updates to Notion via MCP (Level 4), and trigger a Slack notification to the team.

The mindset shift Marchelle described: “There’s definitely a moment where I have to switch my brain from trying to muscle through things to letting the intelligence push me along. Letting go of the idea that I have to do it all manually doesn’t mean I’m not doing something right.”

What you need to succeed (the real prerequisites):

• Relentlessness. Marchelle said it directly: “There’s zero technical skill needed aside from the fact that you have to be relentless.” Things will break. You’ll restart 3 times. That’s normal.

• Clarity on the problem. If you can’t explain what you need in plain English, Claude can’t help you. The better your description of the problem, the better the output.

• Willingness to iterate. Your first attempt won’t be perfect. Neither was Marchelle’s. She rebuilt analyses, switched between chat and code, restarted when things broke. That’s the process.

• A bias for “good enough” over “perfect.” The MVP that runs today beats the perfect tool that ships in 6 months.

STEP 5: THE GOLDEN SCRIPT PLAYBOOK (DATA-DERIVED SALES EXECUTION)

This deserves its own section because it’s the project that drove Mangomint’s 8% win rate increase, and it’s replicable by any team with call recordings.

The problem: Sales scripts are usually built on opinion, institutional memory, and “what the top rep does.” That’s a start, but it’s not scalable and it drifts as the market changes.

The Mangomint approach:

Phase 1: Extract the data. Noah (frontline AE manager) pulled transcripts from closed-won and closed-lost deals. Initially done manually with ChatGPT. Later, Marchelle replicated this at scale with Claude Code, pulling 212 BDR transcripts from Nooks in 3.5 minutes.

Phase 2: Analyze for patterns. Fed transcripts into Claude Code and asked for:

• What objections came up most frequently?

• Which objections were successfully overcome, and what language was used?

• What pattern interrupts led to booked demos vs. dead air?

• Where did reps go off-script and still win? (This is gold. It reveals what the playbook is missing.)

• Where did reps go off-script and lose? (This reveals training gaps.)

• What battle card gaps exist? (Competitor mentions where reps had no prepared response.)

Phase 3: Build the golden script. Took the winning patterns, synthesized them into a structured script, and documented it in Notion. The script isn’t a word-for-word read. It’s a framework: opening pattern interrupt, discovery structure, objection responses, and closing sequence, all derived from what actually works in real calls.

Phase 4: Train with simulation, not slides. Loaded the golden script scenarios into Avara (AI role-play simulator). Every AE and BDR must pass the simulation with a qualifying score before they enter the demo rotation. This builds muscle memory, not just knowledge. Knowing the objection response is different from delivering it smoothly under pressure.

Phase 5: Monitor adherence and evolve. Momentum captures call signals in real time. Marchelle’s frontline managers use those signals to identify when reps go off-script. But here’s the nuance: off-script isn’t always bad. When a rep goes off-script and wins the deal, that’s a signal to update the script. When they go off-script and lose, that’s a coaching moment. The script is a living document, not a stone tablet.

Phase 6: Repeat for every motion. They did this for AEs first. Now they’re running the same playbook for BDRs. Different motion, different objections, different pattern interrupts. Same framework.

STEP 6: THE BUBBLE-UP PROTOCOL (HOW MVPs BECOME REAL PRODUCTS)

This is the part most teams skip. Building the MVP is step one. What happens next determines whether it creates lasting value or dies in a forgotten browser tab.

Marchelle’s model:

1. Non-technical operator builds the MVP with Claude Code. They know the problem. They know the customer. They know the workflow. They don’t need to know Python.

2. They test it in production with real workflows, real data, real reps. Not a sandbox. Not a demo. Production.

3. Results are measured against the metric that matters (win rate, ramp time, conversion, time saved, deal velocity).

4. If it works, engineering reviews it to harden, scale, optimize, or integrate into the core product. The MVP becomes the spec. No more writing 10-page PRDs that describe a problem the engineer has never experienced.

5. If it doesn’t work, it cost nothing but time and the team learned something about the problem that informs the next attempt.

The “blessing of not knowing too much”:

The junior analyst at Mangomint solved a data import problem in one week that a senior engineer said was impossible. The senior engineer had years of experience with painful API integrations and knew all the ways it had failed before. The junior analyst had none of that baggage. She asked Claude Code to help her figure it out. One week later: solved.

This isn’t an argument against expertise. It’s an argument against expertise-as-blockers. The junior person’s prototype proved the problem was solvable. Engineering then had a working model to refine, not a theoretical debate about whether it could be done.

The rule: The people closest to the customer prototype. Engineering hardens what proves revenue impact. Not the other way around.

Why this changes hiring:

Mangomint doesn’t start the year with a headcount plan. They use what Marchelle calls “selective hiring.” The logic: it takes so long to ramp a technical hire to understand the nuance of their customer (salon and spa owners with specific workflows) that the existing team, armed with Claude Code, can solve most problems faster. Then, when a hire is needed, the job description is specific because the prototype already exists. You’re not hiring someone to “figure out the problem.” You’re hiring someone to scale the solution.

STEP 7: HOW TO MAKE EVERYTHING WORK TOGETHER (THE STACK PHILOSOPHY)

Regardless of what tools you use, these principles apply:

Principle 1: Don’t wait for integrations. If two tools don’t talk to each other, build the bridge yourself. Marchelle’s team wanted Nooks integrated with Momentum. It isn’t. Rather than waiting for a vendor roadmap, she used Claude Code to fill the gap. Waiting is a choice to lose months of value. The bridge you build today might be temporary. That’s fine. Temporary solutions that work beat permanent solutions that don’t exist yet.

Principle 2: Your training and enablement must move as fast as your product. If your product ships features monthly, an LMS with quarterly content updates is already behind. Mangomint’s Director of Onboarding built a training system that connects directly to Notion via MCP. When the knowledge base updates, the training updates. When new product features ship, the certification modules reflect them. This is why they built instead of bought. No off-the-shelf LMS could keep pace with their product velocity.

Principle 3: Every script, playbook, and battle card should be data-derived, not opinion-derived. Pull transcripts. Analyze patterns. Find what your top closers actually say vs. what the playbook says they should say. Then update the playbook. Marchelle’s golden script project didn’t start with “what do we think works?” It started with “what does the data say works?” The 8% win rate increase came from aligning the script to reality, not theory.

Principle 4: Measure the muscle memory, not just the knowledge. Mangomint uses Avara (AI role-play simulator) to practice scripts before going live. Knowing the objection response is not the same as executing it under pressure with a skeptical prospect on the phone. Build practice infrastructure into every rollout. Require passing scores. Make simulation a gate, not an optional exercise.

Principle 5: Micromanage the data, not the people. This is Marchelle’s operating philosophy. Watch the metrics. When something is off, drill in until you find the solvable thing. Your team will learn to read your focus areas and build solutions around them. When her managers see Marchelle harping on a specific metric or problem, they know: that’s the thing to go build a solution for. It’s management by signal, not micromanagement by task.

Principle 6: Let the non-technical people surprise the technical people. When Marchelle’s team showed their Claude Code builds to the engineering team, the engineers asked: “Did you actually code this?” They didn’t. The value of this moment isn’t the tool. It’s the organizational signal: the revenue team can now prototype solutions that previously required an engineering ticket and a 6-week wait. That changes the speed of the entire company.

Principle 7: The best tools in 6 months will be different from today. Build for adaptability. Marchelle said it plainly: “Probably 4 months ago, we could not have done this.” The MCP integration with Notion, the browser extension capabilities, the enterprise plan features, all of it evolved. Build your processes around the framework (find friction → prototype → validate → harden), not around any single tool. The tools will change. The framework won’t.

THE TOOL STACK MAP: WHAT TO BUY, WHAT TO BRIDGE, WHAT TO BUILD

Here’s how Mangomint thinks about their stack. Adapt the categories to your own tools.

QUICK-START CHECKLIST

This week:

• Have every frontline manager record their full workday and feed it to Claude

• Identify the #1 manual task that sits between two tools (that’s your first bridge)

• Try Claude’s browser extension on one data extraction you’ve been putting off

• List every place in your workflow where you manually move information from Tool A to Tool B

This month:

• Run the Build-Buy-Bridge decision tree on your top 3 friction points

• Build one MVP tool with Claude Code that solves a real friction point

• Pull your last 50-100 call transcripts and run them through Claude Code for pattern analysis

• Measure the before/after on the metric the MVP was designed to move

• Share the result with your engineering team. Watch their reaction.

This quarter:

• Establish the bubble-up protocol: operator prototypes → validate → engineering hardens

• Move from opinion-based playbooks to data-derived golden scripts (full golden script playbook)

• Build practice infrastructure (Avara, Second Nature, or any AI simulator) into every script rollout

• Map your full stack using the Buy/Bridge/Build framework

• Create a recurring cadence: re-analyze transcripts monthly. Scripts evolve. So should yours.

The mandate Marchelle gives her team: Find the things that are annoying, repetitive, and don’t require deep nuance. Then go build a solution. If you even come up with the MVP that shows your head of engineering the signal, you’ve created more value than waiting 6 months for a feature request.

FINAL THOUGHT

Marchelle’s team didn’t ask permission to build. They didn’t wait for a budget cycle. They didn’t submit a Jira ticket. They opened Claude Code and started talking to it about their problems.

The tools you use don’t matter as much as the willingness to fill the gaps between them. Every stack has seams. The teams that win are the ones that bridge those seams instead of waiting for someone else to do it.

Everything is figureoutable. Start there.

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

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

The Garage Problem

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

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

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

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

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

The Market Map Illusion

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

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

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

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

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

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

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

What This Actually Costs

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

But the indirect costs are worse:

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

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

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

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

The Question Nobody Asks

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

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

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

It is not the only architecture available anymore.

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

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

Read more

Here’s how everything is organized.

Signal v. Noise (Free)

The news feed. When something happens in AI that matters to your business, we’ll break it down here. What’s signal, what’s noise, and wha…

Read more

They should be looking over the other shoulder. Because what’s coming for CRM doesn’t even have a sales team yet.

Redpoint surveyed CIOs across the Fortune 500 and mid-market on which software categories they’d be most open to replacing with AI-centric vendors. The results, ranked:

Salesforce Automation: 83%.

Not 83% who are mildly curious. Eighty-three percent who ranked CRM in their top two categories most open to AI-native replacement. Customer service management came in second at 56%. ITSM third at 55%. ERP and procurement tied at 50%.

CRM isn’t just the most vulnerable category. It’s 27 points more vulnerable than the second-place category. That’s not a gap -- it’s a canyon.

The Two Numbers That Tell the Whole Story

Two numbers. The tension between them is the entire strategic picture.

Number one: 19% of CIOs have seriously considered replacing their CRM in the last twelve months. That’s the action metric. One in five enterprise buyers has already done the work -- evaluated alternatives, run cost analyses, maybe even started a POC.

Number two: 83% are open to AI-centric CRM alternatives. That’s the intent metric. Five in six would switch if the right product showed up.

The gap between 19% and 83% is 64 percentage points. That gap is the most important number in enterprise software right now.

Think of it like housing. Nineteen percent of homeowners are actively listing their house. Eighty-three percent would sell at the right price. The market hasn’t moved yet. But here’s the twist the housing metaphor misses: in real estate, sellers wait for the right price. In software, sellers wait for the right replacement. And unlike houses, software replacements get better every quarter.

The 83% aren’t waiting for motivation. They’re waiting for a product good enough to justify the migration pain -- something that makes a rep’s morning pipeline review feel like talking to a colleague instead of clicking through 14 Salesforce tabs. That product is getting built right now.

What’s the catalyst? I think it’s already happened: it’s the public failure of Agentforce.

Agentforce and the Credibility Collapse

Salesforce bet big on Agentforce as the answer to the AI-native threat. Agents inside the CRM. Autonomous workflows. The pitch was: you don’t need to replace Salesforce, because Salesforce is becoming AI-native.

The market’s response has been more damaging than any competitor could have engineered.

That auto OEM executive again: “Agentforce has been oversold. It’s not a game changer. It’s a smart chatbot. If I just look at Agentforce as a chatbot, then there are much better chatbots out there, and the price at which Agentforce is coming in, I expect a miracle.”

This isn’t a random critic. This is a buyer who wanted it to work. Who probably championed the Salesforce relationship internally. Who went to Dreamforce and got excited about the demo. And then deployed it and found a chatbot.

The pattern across all three mega-vendors is identical. ServiceNow: “I wouldn’t even think twice about switching” if a startup offered better at a better price. Microsoft Copilot: pricing “is not going to stick” because it “literally doubles your E3.”

Every major platform tried the same play -- bolt AI onto the existing product and charge more. Every major platform is hearing the same thing back: not good enough, too expensive, feels like a tax on our existing contract.

This is the credibility collapse. The incumbents had one shot to prove that AI-native meant “we evolved” rather than “we added a feature.” They missed. And now that 83% open-to-replacement number has a tailwind of disappointment behind it.

The Salesforce Moat -- What It Actually Is

The bearish case is easy. The nuance matters more.

Salesforce’s moat was never the product. The CRM itself -- contacts, opportunities, pipeline views -- is a database with a UI. It’s been replicable for a decade. HubSpot proved that. What made Salesforce untouchable wasn’t the software. It was three things:

Data gravity. Twenty years of customer interaction data sitting in Salesforce orgs. Every call logged, every email tracked, every deal stage recorded. Migrating that data isn’t just a technical project -- it’s a political one. Sales leaders built their reporting on Salesforce. CFOs built their forecasting models on Salesforce data. Ripping it out means rebuilding institutional knowledge.

The admin ecosystem. There are over 200,000 certified Salesforce administrators. These people built careers on Salesforce expertise. They influence buying decisions. They resist platform changes because platform changes threaten their livelihoods. It’s not a conspiracy -- it’s rational self-interest at scale.

The AppExchange. Thousands of ISV integrations. CRM isn’t a standalone product -- it’s a platform wired into every other system. Replacing Salesforce means replacing or rebuilding every integration point.

That’s a real moat. It’s held for twenty years. The question is whether AI dissolves it. I think the answer is yes.

Read more

As a reminder, we have a TON of free options for you to subscribe to:
GTM AI podcast and newsletter with associated assets, apps, AI tools, etc

We also have Signal vs Noise which is more of a short and to the point update that …

Read more

That’s not a market correction. That’s the market telling you that “works everywhere” was never a moat. It was a vulnerability with good branding.

Redpoint’s 2026 market update puts the number on what a lot of operators have been feeling for months. Horizontal SaaS didn’t just underperform. It got repriced as a category.

The last twelve months, indexed: vertical SaaS up 2-3%. Infrastructure up 2%. Horizontal SaaS down 35%. That’s not a correction. That’s a reclassification. The market looked at three categories of software and decided one of them has a fundamentally different risk profile than the other two.

The question isn’t whether the market is right. It’s why.

The Three Layers, Three Fates

Redpoint breaks the software universe into three layers and explains why AI hit each one differently. This is the slide I keep sending to founders who ask me “is my category safe?”

Vertical SaaS (+2-3%). Owns the irreplaceable moat: data plus compliance. When you’re the system of record for a dental practice or a property management company, AI is a feature you add, not a threat you face. The switching cost is existential, not cosmetic. Nobody is ripping out their EHR because a startup has a better chatbot. They might add the chatbot on top, but the vertical platform stays.

Infrastructure (+2%). AI is a tailwind, not a displacement risk. More AI means more compute, more data pipelines, more observability. Every agent someone deploys needs to run somewhere, log somewhere, fail somewhere. Infrastructure companies sell picks and shovels to both sides of the AI war. Their multiples compressed a bit, but their thesis got stronger.

Horizontal SaaS (-35%). And here’s the line that hit me: “Accidentally optimized for replaceability.”

That phrase is doing more work than any three-word description has a right to. Let me unpack it.

Horizontal SaaS was designed -- intentionally, deliberately, as a strategy -- to serve every industry equally. That was the pitch to investors. “We don’t need to build vertical-specific features. Our platform is flexible enough to work everywhere.” And it was true. Horizontal tools do work everywhere. The problem is that “works everywhere” and “integrated deeply with none” are the same statement.

I’ll be honest -- I’ve pitched “works everywhere” as a strength in past roles. I’ve sat in the room and said “we don’t need vertical-specific features, our platform is flexible enough.” It sounded like a moat. It was a vulnerability with good branding.

When your product is a coordination layer -- moving information between people, triggering workflows, displaying dashboards -- you’re doing exactly what AI does natively. You’re a middleman between humans and data. And AI just cut out the middleman.

The coordination problem that horizontal SaaS was built to solve? AI solves it natively. Not by being a better tool for coordination, but by eliminating the need for coordination in the first place. When an agent can pull data from six systems, synthesize it, and take action, the dashboard that displayed data from those six systems becomes a loading screen nobody needs.

Two Playbooks for Eating the Incumbents

So the horizontal giants are vulnerable. Who’s coming for them? Redpoint maps two distinct startup playbooks, and the distinction matters enormously for which incumbents should be scared and which have time.

Playbook 1: Augment the Enterprise. Sell alongside the incumbent. Own the AI layer on top. Don’t replace Salesforce Service Cloud -- sit on top of it. Sierra and Decagon are doing this in customer service. Moveworks is doing it on ServiceNow. Legora on LexisNexis. Lovable on Figma.

This playbook is smart because it doesn’t require the customer to rip and replace. It’s additive. The incumbent barely notices until the AI layer is handling 60% of the workload and the customer starts asking why they’re paying full price for a platform that’s mostly a data store now.

Think of it like ivy on a building. Looks decorative at first. Even charming. The building owner likes it -- adds character, doesn’t cost anything, and guests compliment it. Then one year you realize the ivy is load-bearing and the building is just a frame. That’s the moment the incumbent realizes the “AI integration partner” owns 60% of the customer’s workflow and they’re just the database underneath.

Playbook 2: Attack the SMB/Mid-Market. Rebuild from scratch for the segment the incumbent under-serves. Attio vs. Salesforce. Serval vs. ServiceNow. Linear vs. Atlassian. Rillet and Everest vs. NetSuite.

This one is the classic disruption pattern -- go downmarket where the incumbent’s cost structure can’t follow. But AI accelerates it because the rebuild is 10x faster. What used to take a startup three years and $20M in funding to build (a credible CRM alternative) now takes 12 months and $3M. The attack surface expanded because the cost of building enterprise-grade software collapsed.

Both playbooks are dangerous, but in different timeframes. Playbook 1 is a slow squeeze -- the incumbent keeps the account but loses the value and eventually the pricing power. Playbook 2 is a fast grab -- the startup takes the customers the incumbent never prioritized and works upmarket.

If I’m a horizontal SaaS CEO, I’m worried about Playbook 1 in my enterprise accounts and Playbook 2 in my mid-market. Which means I’m worried about everything.

Read more

Redpoint’s 2026 deck says every software company is standing at that same fork right now. I agree. I’ve spent the last year inside a 20-year-old healthcare software company with thousands of customers trying to force exactly this kind of reinvention. And I can tell you the hardest part isn’t the strategy. It’s not even the technology. It’s the moment someone in the room says “but our margins are fine” and everyone exhales, because that sentence is the most comfortable way to avoid the uncomfortable conversation.

“Have a re-founding moment” is investor language. Operators need a playbook.

The Incumbents Are Telling On Themselves

Before we get to the how, let’s sit with the why. Redpoint surveyed executives at Fortune 500 companies and the quotes are devastating -- not because they’re surprising, but because they’re specific.

An auto OEM exec on Salesforce’s Agentforce: “I think Agentforce has been oversold. It’s not a game changer. It’s a smart chatbot. If I just look at Agentforce as a chatbot, then there are much better chatbots out there, and the price at which Agentforce is coming in, I expect a miracle and that’s not happening.”

A Fortune 500 exec on ServiceNow: “If there’s a startup that came along and said, ‘We can do this better at a better price,’ certainly they’ll beat the price of ServiceNow because ServiceNow is always going to be the highest. I wouldn’t even think twice about switching.”

Another Fortune 500 exec on Microsoft Copilot: “Microsoft recognizes that the pricing that they released for Copilot is not going to stick because it literally doubles your E3.”

These aren’t analysts speculating. These are buyers -- the people writing checks -- saying out loud that the emperor’s AI clothes don’t fit. When your biggest customers describe your flagship AI product as “a smart chatbot” and your pricing as “expecting a miracle,” you don’t have a product problem. You have a credibility problem.

And credibility, unlike software, can’t be patched in a sprint.

The Rosetta Stone

The most useful slide in Redpoint’s entire 60-page deck is page 43. It’s a simple two-column comparison: Traditional SaaS vs. AI-Native. I’ve stared at it for weeks now, and every time I look, I see a different failure mode in my own organization.

Let me walk through what this actually means when you’re sitting in the chair.

Executive Team. Traditional: “been there done that.” AI-Native: “First-principles thinkers. No playbook exists. Speed matters.” I’ve been in rooms where the most senior person’s primary qualification is having scaled a SaaS company in 2014. That experience is now a liability dressed up as a resume line. The playbook they ran -- PLG motion, land-and-expand, seat-based pricing -- was built for a world where software was deterministic and customers needed training. That world is gone.

Product Development. Traditional: customer-led (listen, build to spec). AI-Native: possibility-led (understand models, build ahead). This one cuts deep. I spent years building the muscle of “talk to customers, build what they ask for.” It’s good practice. It’s also a guaranteed way to build yesterday’s product. When your customer asks for a better dashboard, they’re not asking for the agent that could eliminate the need for the dashboard entirely. Customer-led development in an AI world means your roadmap is always one paradigm behind.

Engineering. Traditional: deterministic. AI-Native: probabilistic. This isn’t just a technical distinction -- it’s a hiring filter, a QA philosophy, and a product liability question all wrapped into one word. I watched a team spend three months trying to make an LLM-powered feature pass the same regression test suite they use for their REST APIs. The tests kept “failing” because the outputs varied. The outputs were supposed to vary. That’s the whole point.

Sales. Traditional: packaged product sold as-is. AI-Native: Forward-Deployed Engineer model. You know what FDE means in practice? It means your first 50 customers each get a slightly different product. It means your sales team needs to understand what the technology can do, not just what the current SKU does. I watched a sales rep demo our traditional product for 45 minutes and then spend 5 minutes on the AI features because -- his words -- “I don’t want to promise something that might work differently next week.” He’s not wrong. But that instinct will kill you.

Pricing. Traditional: seat-based, predictable ARR. AI-Native: consumption or outcome-based, experimental. This is the one that makes CFOs break out in hives. Seat-based pricing is beautiful. It’s predictable. It makes forecasting easy. It also has nothing to do with value delivery in an AI world. When one agent can do the work of ten seats, you’re either charging for outcomes or you’re watching your TAM collapse. We tried floating outcome-based pricing internally. Finance asked how to model it. I said, “You can’t, not yet.” That meeting ended early.

The Re-Founding Moment

Redpoint frames this as an architectural shift comparable to the cloud transition. They point to historical parallels: Microsoft and Adobe embraced cloud and outperformed. IBM and Oracle resisted and lost share.

That framing is correct and completely unhelpful.

Here’s why: when Microsoft went to cloud, Satya Nadella had a $400 billion balance sheet and could afford to cannibalize Office for a decade. When Adobe moved to subscriptions, they had a near-monopoly in creative tools and could weather the transition dip. The lesson isn’t “be brave like Satya.” The lesson is “you probably don’t have Satya’s margin of error, so you need a different plan.”

Read more

Read more

The Stories

Anthropic Accidentally Leaked Its Most Dangerous Model

The noise: breathless coverage of “Mythos,” the secret model tier above Opus that Anthropic says is too dangerous to release. Cybersecurity exploitation capabilities. Pentagon contracts. $380B valuation. The mystery box is doing its job.

The signal: A safety-focused company exposed 3,000 in…

Read more

That’s not a feature. That’s a fundamentally different relationship with AI.

Most people use Claude the same way they use Google — reactively. They have a problem, they open the app, they type something. Claude answers. Session ends. Claude forgets it happened. You come back tomorrow and start over. The model is sitting idle 23 hours a day, waiting for you to remember it exists.

Claude Schedule breaks that pattern. It turns Claude from a tool you pick up into a system that runs alongside your work — processing, monitoring, reporting — whether you’re in the room or not. Cowork has /schedule for recurring task cadences. Claude Code has /loop for tight operational cycles. Together they give you something most executives don’t think to build: a Claude that works the night shift.

Here’s how to set it up.

Step 1: Understand What Schedule Actually Is

Before you configure anything, get the mental model right, because the failure mode here is treating Schedule like a calendar reminder. It’s not.

A calendar reminder says “do this at 9 AM.” Schedule says “run this entire Claude workflow at 9 AM, with no human in the loop.” That’s a different thing. It means the prompt you write today will execute — unchanged — on Tuesday, next Tuesday, and the Tuesday after that. The output quality scales directly with the prompt quality. A lazy prompt produces lazy recurring output. A sharp prompt produces sharp recurring intelligence.

There are two implementations.

Claude Cowork /schedule is designed for business cadences — daily briefings, weekly reports, Monday morning pipeline summaries. You set a natural-language schedule (”every weekday at 7 AM”), attach a prompt or task, and Cowork runs it on that interval. Output lands wherever you’ve configured it: in the conversation thread, in a connected integration, in a document. Think of this as your recurring content and intelligence layer.

Claude Code /loop is designed for operational monitoring — tighter cycles, often measured in minutes rather than days. The syntax is direct: /loop 5m /check-deploy runs the /check-deploy command every five minutes until you stop it. This is your CI/CD babysitter, your deploy watcher, your PR queue monitor. It’s built for the terminal, not the boardroom.

Both share one critical constraint you need to internalize before you build anything on top of them: the computer has to stay awake and the app has to be running. These are not cloud-scheduled jobs. There’s no server executing your tasks while your MacBook is in a bag at 35,000 feet. If your machine sleeps, your schedule sleeps. If you quit the app, the loop dies.

This isn’t a bug you need to work around — it’s a design constraint you need to plan around. Set your energy settings to prevent sleep when these workflows matter. Or run them on a machine that stays on. The executives who get the most out of Schedule have a designated machine — an old MacBook, a Mac Mini, something that never closes — where Claude runs continuously. That’s the move.

Step 2: Set Up Your First Scheduled Task in Cowork

Open Claude Cowork and type /schedule in any conversation. Cowork will walk you through the configuration in natural language. You’ll set three things: the timing, the task, and the output.

Timing. Cowork accepts plain English. “Every weekday at 7 AM.” “Every Monday at 9 AM.” “Daily at 6:30 AM.” Don’t overthink the syntax — it’s genuinely conversational. If it misreads your intent, it’ll confirm before saving.

The task. This is your prompt. Write it like you’re writing for a future version of yourself who forgot everything about this project. Include the context you’d normally carry in your head. If you want competitive intel, don’t just say “check on competitors” — tell it which competitors, what signals matter, how you want the output framed. A good scheduled prompt is more explicit than a live prompt, because there’s no back-and-forth to course-correct.

Output. Where does the result go? By default it surfaces in the conversation thread. If you’ve connected integrations, you can route output to email, Slack, or a document.

For Claude Code /loop, the setup is in the terminal. Navigate to your project directory, make sure you have a /check-deploy skill (or whatever command you want to loop) defined, and run:

/loop 5m /check-deploy

That’s it. Claude Code will execute /check-deploy every five minutes, print the result, and run again. Hit Ctrl+C to stop. You can loop any skill, any slash command, or any plain prompt.

The key discipline with /loop: keep the looped command tight and stateless. It should be designed to run in isolation, give you a clear status in a few lines, and complete cleanly. Don’t loop long analytical tasks — that’s what /schedule is for. Loop status checks, monitors, and watchers.

Step 3: Build a Daily Morning Briefing

This is the first scheduled workflow worth building, because you’ll feel the value immediately and it trains you on what good scheduled prompts look like.

Here’s the prompt structure that works. In Cowork, schedule this for every weekday at 6:30 AM (or whenever you actually look at your phone before your first meeting):

Good morning. Give me a daily briefing covering:

1. What's on my calendar today (if calendar is connected) — key meetings and prep I need to do
2. Any open threads or unresolved questions from our recent conversations
3. One thing I should be thinking about that I probably haven't looked at in the last 48 hours

Keep it under 200 words. Be direct. If there's nothing notable, say so.

Adjust the three bullets to match your actual priorities. The point is specificity. “Daily briefing” without structure produces a vague summary. “These three specific things” produces something you can act on in 90 seconds.

After it runs for a week, you’ll start to notice what’s missing and what’s noise. That’s the signal to edit the prompt. Scheduled prompts are living documents — refine them the same way you’d refine any process that runs repeatedly.

What changes when this is working: you stop starting your day in reactive mode. You come into the morning with a frame already built, which means the first hour of work produces more than the next three would have without it.

Read more

That’s what Claude Dispatch makes possible. And it matters more than it looks like at first glance.

The premise is simple: your desktop is always on. You’re not always at it. Dispatch closes that gap. It’s a feature inside Claude Cowork — Anthropic’s desktop app — that lets you remote-control your Claude session from your phone. You send an instruction from mobile, your desktop Claude executes it. You don’t need to be sitting there. You just need to have left the app running.

Launched March 17, 2026, currently in research preview on Max and Pro plans. Here’s how to get it running and, more importantly, how to actually use it.

Step 1: What Dispatch Is and Why It Changes How You Work

Most people treat AI tools as synchronous. You sit down, you prompt, you wait, you read, you iterate. Everything happens in the same session, at the same desk, in the same window of time. That model made sense when AI was a search replacement. It doesn’t make sense when AI can execute multi-hour research tasks, draft entire documents, or process large datasets without you doing anything.

The problem isn’t that Claude is too slow. It’s that you can’t always be at your desktop when you want to start work — and by the time you get there, you’ve lost the window to queue something meaningful before a meeting, before a flight, before the end of the day.

Dispatch solves the activation gap. The instruction you couldn’t send because you weren’t at your desk can now be sent from wherever you are. Your desktop — which is running anyway — picks it up and executes it.

The practical shift this creates: you stop thinking about AI tasks as things you do at your desk and start thinking about them as things you deploy. You’re in a cab, you remember you need a summary of last quarter’s earnings calls before the board meeting. You send it from your phone. By the time you’re through security, it’s done. You’re in a meeting that runs long, and you want Claude to start pulling together the market sizing you need for your next call. You excuse yourself, send the instruction from the hallway, and it’s running before you’re back in the room.

This is the remote work angle that most coverage of Dispatch misses. It’s not just for people working from home or on the road — it’s for anyone whose best thinking about what they need happens when they’re away from their keyboard. Which is most people, most of the time.

The only hard requirement: your desktop must be running Claude Cowork and connected to the internet when the instruction arrives. Close your laptop and you’ve closed the connection. Leave it running and the desktop becomes a persistent compute resource you can trigger from anywhere.

Step 2: Setup — Enabling Dispatch and Linking Your Mobile

You need Claude Cowork installed on your desktop and the Claude mobile app on your phone. Both need to be signed into the same Anthropic account on a Max or Pro plan. That’s the full requirements list.

On desktop:

Open Claude Cowork. Go to Settings. Under the Cowork section, find Dispatch — it’ll be labeled as a research preview feature. Toggle it on. You’ll see a confirmation that your desktop session is now reachable from your mobile device when this machine is running and connected.

That’s the full desktop setup. No API keys, no configuration files, no webhooks to configure. Cowork handles the connection layer.

On mobile:

Open the Claude app on your iPhone or Android device. In the bottom nav or the menu (varies slightly by platform), look for the Dispatch icon — it appears after you’ve enabled it on desktop. Tap it. You’ll see the connection status: either your desktop is online and reachable, or it isn’t.

If your desktop is running and connected, the status shows green. If you turned off your laptop without leaving Cowork running, it’ll show as offline.

Permissions to know about:

Dispatch respects the same permissions and tool access your desktop Claude session has. If you’ve connected Claude Code, file system access, or any MCP integrations to your Cowork session, those tools are available to instructions you send via Dispatch. If you haven’t, Dispatch can still execute any task that doesn’t require local file access — research, drafting, analysis, synthesis.

One thing worth knowing upfront: Dispatch sends your instruction to your existing desktop session. It’s not spawning a new session — it’s sending a message to the Claude instance already running on your machine. If you had an active conversation open when you left your desk, Dispatch picks up in that context unless you specify otherwise. If you want a fresh task to run without prior context, note that in your instruction.

Step 3: Your First Remote Instruction

Before building out power workflows, run one task end-to-end. This is the step that makes Dispatch real rather than theoretical.

Leave your desktop running with Claude Cowork open. Walk away from it — go to another room, or step outside. Pull out your phone and open the Claude app.

Tap into Dispatch. Confirm your desktop shows as online.

Send this instruction:

Summarize the current competitive landscape for [your industry]. I need: the three most active competitors right now, what each one is doing that’s working, and the one move any of them could make in the next six months that would be a real threat to us. We are [one sentence description of your company]. Use publicly available information. Have this ready when I get back to my desk.

Send it. Put your phone away. Go back to your desk in ten or fifteen minutes.

What you’ll find: Claude executed the task against your instruction, in your desktop session, without you sitting there. The output is waiting for you.

This is the moment that reframes how you use the tool. The instruction you couldn’t send because you weren’t at your keyboard can now be sent from anywhere. The gap between “I need this” and “I’m at my desk to start it” disappears.

Run this once on something real. The mechanics become obvious in one use.

Read more

As a reminder, we have a TON of free options for you to subscribe to:
GTM AI podcast and newsletter with associated assets, apps, AI tools, etc

We also have Signal vs Noise which is more of a short and to the point update that is important…

Read more

Old world: you find out in the morning, do triage over coffee, and the fix ships mid-afternoon. The pipeline was broken for twelve hours before anyone touched it.

New world with Claude Channels: the failure hits Telegram, Claude Code wakes up, investigates the logs, traces the error, pushes a fix, runs the build again, and messages you back with a three-sentence summary of what happened and what it did. You wake up to a resolved incident instead of an open one.

That’s not a demo scenario. That’s the literal capability Anthropic shipped on March 20, 2026 — and it fundamentally changes what “agentic” actually means in practice.

Step 1: What Channels Is (and Why the Reactive vs. Proactive Problem Matters)

Every AI workflow until now has been pull-based. You open a session, describe what you need, Claude does the work, you close the session. It’s powerful — but it’s still you initiating every single action. Claude sits idle until you show up.

Channels flips that model. It lets external events — a CI failure, a GitHub notification, a Telegram message from a teammate, a Discord mention in your dev server — push directly into a running Claude Code session as triggers for autonomous action. Claude isn’t waiting for you to ask. It’s listening for events, and when they arrive, it works.

The technical implementation is MCP. Channels are MCP servers — specifically, servers that connect Claude Code to messaging infrastructure. Telegram and Discord are the launch integrations, but the protocol is open, which means the surface area will expand fast.

What this unlocks is a different category of automation. Not “Claude helps me do a thing faster” but “Claude handles a class of things without me.” The reactive vs. proactive distinction sounds academic until you experience the difference in your actual operational cadence. Then it’s obvious.

What you need to get started:

• Claude Code v2.1.80 or later (check with claude --version)

• Bun runtime installed (curl -fsSL https://bun.sh/install | bash)

• A claude.ai account (login required — Channels uses your claude.ai identity for the MCP connection)

• Either a Telegram bot token or Discord bot token depending on which channel you’re connecting

Step 2: Setup — Installing the MCP Server and Configuring Your Channel

The Channels MCP server is what bridges your messaging platform to Claude Code. You’re adding it the same way you’d add any MCP server — a JSON configuration block that tells Claude Code where to find it and how to run it.

Step 1: Install the Channels server via Bun

bunx @anthropic-ai/claude-channels install

This installs the server binary and sets up the local runtime. Bun handles the dependency resolution — the reason Bun is required over Node is startup speed. Channels needs to respond to inbound events fast, and Bun’s cold-start time is roughly 4x faster than Node for this workload.

Step 2: Add the MCP configuration to Claude Code

Open or create ~/.claude/claude_desktop_config.json and add the following under mcpServers:

{
  "mcpServers": {
    "channels": {
      "command": "bunx",
      "args": ["@anthropic-ai/claude-channels", "serve"],
      "env": {
        "CLAUDE_CHANNELS_AUTH": "your-claude-ai-token"
      }
    }
  }
}

Your CLAUDE_CHANNELS_AUTH token is available in your claude.ai account settings under Developer → API Tokens. Generate one scoped to Channels if you want to limit surface area.

Step 3: Configure your first messaging platform

For Telegram, you need a bot token. Get one from BotFather — open Telegram, search @BotFather, send /newbot, follow the prompts. Copy the token it gives you.

claude channels add telegram --token YOUR_BOT_TOKEN --name "claude-ops"

For Discord, you need a bot token from the Discord Developer Portal (discord.com/developers/applications). Create an application, add a bot, copy the token.

claude channels add discord --token YOUR_BOT_TOKEN --guild YOUR_SERVER_ID --name "claude-ops"

Step 4: Restart Claude Code

claude restart

On startup, Claude Code will initialize the Channels server and establish the connection to your configured platform. You’ll see a confirmation in the terminal output: Channels: connected (telegram: claude-ops).

Step 3: Your First Channel — Send a Message, Watch Claude React

With the server running and Telegram connected, you have a live two-way bridge between your phone and a Claude Code session.

Open Telegram. Find the bot you just created — search by the username you gave it during BotFather setup. Send it a message:

@yourbot what's the current state of my project?

Watch your terminal. Claude Code receives the message as an injected prompt, runs against your current working directory, and responds — both in the terminal and back to you in Telegram.

That first response will feel underwhelming if you ask something generic. The capability reveals itself when you send it something with real operational context.

Try this instead:

@yourbot run git log --oneline -10 and tell me what's been committed in the last 48 hours

Claude executes the command, reads the output, and sends you a clean summary in Telegram. You just ran a terminal command from your phone via a chat message. That’s the primitive. Everything else in this guide builds on it.

A few things to understand about how the two-way messaging works before you go further:

Claude Code sends messages back through the same channel that triggered it. If the message came from Telegram, the response goes to Telegram. If it came from Discord, it goes to Discord. The session stays alive between triggers — Claude maintains context across multiple messages in the same channel thread, which means you can have a real back-and-forth from your phone without typing a single character in a terminal.

Message length is capped at Telegram’s standard 4096 characters per message. For longer outputs — log analysis, full reports — Claude will chunk the response automatically. You can override this with an instruction in your trigger message: “respond in under 200 words” keeps things clean for quick status checks.

Read more

Most people accept this as the cost of the tool. It’s not. It’s a design problem, and it has a design solution.

Claude’s memory isn’t missing — it’s distributed across five different mechanisms with completely different persistence characteristics. Once you understand which layer does what, you stop losing context and start building memory that compounds. This guide is the map.

Step 1: How Claude’s Memory Actually Works — The Five Layers

Most people interact with exactly one layer of Claude’s memory: in-conversation context. The rest are either unknown or underused, which means they’re leaving most of the infrastructure untouched.

Here’s the full picture.

Layer 1: In-Conversation Context

Everything in your current session. The model processes everything in the context window — every message, every file you’ve pasted, every response it’s generated — and uses it when responding. This is why Claude can refer back to something you said 40 messages ago in the same conversation.

The catch: when the conversation ends, this layer is gone. Not archived somewhere retrievable. Gone. Claude cannot access a previous conversation’s content when you start a new one. This is the layer most people treat as the only layer, which is why they spend the first five minutes of every conversation re-briefing an AI that has no idea who they are.

Layer 2: Projects Memory (Cowork)

Available on Claude.ai Pro and Team plans. Projects give you a persistent context layer that loads automatically at the start of every conversation inside that project. You write Project Instructions once — who you are, what you’re working on, what constraints apply — and every subsequent conversation inherits that context.

The important nuance: this is not transcript memory. Claude doesn’t read your previous conversations before responding in a new one. It has your instructions and your uploaded files, not a running log of what you’ve discussed. This is a crucial distinction when you’re deciding what to put there.

Layer 3: CLAUDE.md / Instruction Files

The most reliable memory mechanism available if you’re using Claude Code. CLAUDE.md is a markdown file in your project root that Claude Code reads at every session start. It’s not a prompt — it’s persistent instruction infrastructure. Changes you make to CLAUDE.md are available in every future session without any setup.

This is where system-level behavior lives: how you’ve structured your project, what agents you’re using and why, how work should be routed, what constraints apply across the entire environment. In a well-configured Claude Code setup, CLAUDE.md is the brain that orients every session.

Layer 4: Memory Files

Explicitly written markdown files Claude reads as part of its session orientation. The MEMORY.md pattern — writing structured context into a file that gets surfaced at session start — is the closest thing to persistent episodic memory Claude Code has. You write down what Claude needs to remember: key decisions made, current state of active projects, important context that would take 10 minutes to re-establish from scratch.

The difference between Layer 3 and Layer 4: CLAUDE.md holds behavioral instructions (how to work), MEMORY.md holds factual context (what’s been done, what’s true). Both load at session start. Both persist across sessions. Together, they close the gap between “AI that starts fresh every time” and “AI that picks up where you left off.”

Layer 5: MCP-Based Memory

External memory stores connected to Claude via the Model Context Protocol. Vector databases, knowledge graphs, retrieval systems — any structured store that can receive a query and return relevant context. This layer enables semantic memory: Claude can search your accumulated knowledge by meaning, not just by keyword, and retrieve relevant context dynamically instead of dumping everything into the context window at once.

This is the most powerful layer and the most complex to set up. It’s the right tool when your memory store has grown beyond what fits in a context window, when you need semantic retrieval across hundreds of notes or documents, or when you’re building a system where accumulated insights need to compound across a team.

The summary: Layer 1 handles your current session. Layers 2-4 handle what persists across sessions through structured files. Layer 5 handles what scales beyond files. Most people only use Layer 1. The good setup uses all five intentionally.

Step 2: Projects Memory — Setting Up Persistent Context in Cowork

The first thing to understand about Projects is what they’re not: they’re not a memory system that learns from your conversations. They’re a context injection system that ensures every conversation starts from an informed baseline. The distinction matters because it changes what you put there.

Projects Instructions should contain context that is true and stable across many conversations: who you are, what you’re working on, your ICP, your voice, your constraints, your company’s competitive position. Not your current active tasks. Not the status of a specific deal. Not what you discussed with a prospect last Tuesday. Stable context, not dynamic state.

Here’s the test: if the information would still be true six months from now, it belongs in Project Instructions. If it’s the current status of something that changes week to week, it belongs in a specific conversation.

What to write in Project Instructions:

Start with four blocks in this order.

First block — who you are and what this project is for:

You are a [role] assistant for [Name], [Title] at [Company].
[Company] is [one-sentence description].
This project is for [specific type of work — writing, GTM strategy, client work, etc.].

Second block — domain knowledge Claude needs to give specific rather than generic advice:

ICP: [Specific description — industry, size, role, trigger events, not just "SMB"]
Primary competitors: [Names and the one key differentiator against each]
Value props ranked by ICP priority: [Specific outcomes, not category claims]
Sales motion: [How you actually sell — PLG, outbound, channel, hybrid]

Third block — output requirements:

Voice: [Specific constraints — first person, short paragraphs, no passive voice]
Format: [What a good response looks like — length, structure, when to use headers]
When to push back: [Where you want Claude to challenge you, not just comply]

Fourth block — what NOT to do:

Do not: [Re-summarize what I just said. Add caveats I didn't ask for.
Give generic advice when specific context is available in uploaded files.
Use passive voice, jargon, or hedged language.]

That fourth block is the one most people skip. Instructions that only tell Claude what to do don’t prevent the default behaviors that frustrate you. Constraints are what make instructions actually change behavior.

What to upload to a Project:

Upload your reference materials — documents Claude would otherwise need you to paste every time. Brand guide. ICP definition. Competitor battlecards. Past content samples (especially important for writing projects — three to five of your best pieces teach voice better than any description). Case studies. Pricing structure. Product documentation.

The upload is permanent context. The paste is per-conversation context. Move anything you paste in more than three times to a file and upload it.

Step 3: CLAUDE.md — The Most Reliable Memory Mechanism in Claude Code

If you’re using Claude Code and you don’t have a CLAUDE.md, you’re running the most powerful version of the tool without its most fundamental memory infrastructure.

CLAUDE.md is read at the start of every Claude Code session. Not sometimes. Every time. It’s the one memory mechanism with zero maintenance overhead — write it once, and it loads in perpetuity. This makes it uniquely reliable compared to every other layer.

What belongs in CLAUDE.md:

The behavioral architecture of your entire working environment. Not task lists. Not current status. The stable structure of how you work.

Three categories to cover:

How work gets routed. If you’ve built specialized agents, CLAUDE.md is where you define the routing rules. Which agent handles which task type, how to classify ambiguous requests, what the tiers of routing complexity look like. Without this, Claude defaults to doing everything itself, which means it ignores the specialized agents you built.

How the vault and file system are organized. Where notes live. Where inbox items go. Where output goes. What the processing pipeline looks like (inbox → distill → notes, not directly to notes). If the architecture is documented in CLAUDE.md, Claude can navigate and maintain it correctly without you re-explaining it.

What the constraints and guardrails are. Things that should never happen regardless of what’s requested: don’t write directly to notes without processing, don’t commit sensitive files, don’t skip quality gates. Hard constraints belong in CLAUDE.md because they apply to every session.

What doesn’t belong: anything that changes frequently. The current status of a project. Your active tasks. What you worked on last session. That’s what memory files are for.

The principle: CLAUDE.md holds behavior. Memory files hold state. The distinction keeps CLAUDE.md clean and stable while allowing your actual working context to evolve without cluttering your behavioral instructions.

Read more

“7.5 million AI agents. 75,000 humans.”

That’s 100 agents per person. At NVIDIA. Not in a pitch deck. Not in a research paper. At one of the most operationally sophisticated companies on the planet.

Analysts heard a headline. VCs heard a …

Read more