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 what you should actually do about it. Posts go up as things develop, so check in often.

Best for: Staying current without drowning in headlines.

Under the Hood (Tuesdays)

The long-form deep dive. Every Tuesday, I publish a detailed piece that goes beyond “what happened” and into “what does this mean for how you work.” You’ll get the diagnosis for free. The prescription (frameworks, implementation details, the stuff you can take into your Monday morning) is for paid subscribers.

Best for: Going deeper on a single topic with real takeaways.

AI Education Playbook for Professionals (Paid)

Your how-to library. Step-by-step guides, resources, tools, and training materials designed for professionals learning to work with AI. We’re building this out with video training, virtual workshops, and downloadable resources. The high-level overviews are free. The full guides, templates, and tools are for paid subscribers.

Best for: Learning by doing, not just reading.

GTM AI Podcast (Thursdays, Free)

Every Thursday, a new episode drops. Conversations about what’s actually working at the intersection of AI and go-to-market. Always free.

Best for: Listening and learning on the go.

Live, Office Hours (Coming Soon)

We’re launching live events. Think office hours, hands-on-keyboard workshops, and interactive sessions where you bring your laptop and leave with something

built. Details coming soon for paid subscribers.

Best for: People who learn by building, not watching.

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 is important for you to know.

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

Subscribe now

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

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

Your CEO Doesn’t Have a Co-Pilot. This Guy Built One.

Ryan Staley grew a division from zero to $30M with four salespeople and no marketing budget. He’s taught 800+ CROs how to use AI to work less and sell more. And when he came on the GTM AI Podcast this week, he didn’t talk about any of that.

He screen-shared his entire CEO operating system. The one running his business right now. Built on Claude Code, Obsidian, and API connections to Fathom and HubSpot. No dev team. No custom software. Folders, files, and an LLM that knows more about his business than he does. His words, not mine.

Here’s what actually matters from this episode:

1) Your AI system is only as good as its foundation. Most people skip this part.

Ryan’s system doesn’t start with agents or automation. It starts with three things: principles (how the model thinks), a North Star (where the business is going), and memory (what the model has learned about you over time).

Here’s the pro tip that compounds: at the end of every strong session, ask the AI “How do you think we could work better next time? What did you learn from this session?” Then tell it to add those answers to memory.

Five seconds. Does it once, the model gets marginally better. Does it for three months, the model operates like a chief of staff who’s been with you for years.

Most people skip straight to “write me a LinkedIn post.” Then they wonder why the output is generic. Foundation first. Always.

2) He reverse-engineered his ICP from call transcripts in two minutes. Not two weeks.

Ryan connected Fathom’s API to his system. Then he told it: pull the last six months of closed deals, go through every transcript, reverse-engineer a new ICP based on how prospects actually talk, the language they use, the questions they ask, the problems they want solved. Give me a two-page briefing.

Two minutes. From untagged, transcript-level data across six months of sales conversations.

He then ran a second query: identify every epiphany moment clients have had over the last 12 months, categorize them by type (emotional breakthrough vs. new idea), and pull exact quotes. Five minutes for a full year of data.

The strategic shift here: your CRM holds surface data. Your transcripts hold the real intelligence. The teams connecting those two layers are building an information advantage their competitors can’t buy off the shelf.

3) His content system produces 10 posts from real client experiences. Not prompts.

Ryan types “weekly content” and gets 10 LinkedIn posts mapped to his exact writing style, pulled from actual client interactions, deal context, and transcript data. Not recycled frameworks. Not prompt-engineered slop. Stories from $300M and billion-dollar company engagements, automatically sanitized for confidentiality.

The part that caught my attention: he said the equivalent output would take five to six hours manually. And he’s now automating it so the system serves up content without him even asking.

Compare that to seven Clay tables and a content calendar. Same goal, fraction of the cost, and rooted in first-party intelligence instead of scraped data.

4) Pipeline reports that actually tell you what to do next.

One slash command. It pulls from HubSpot, layers in transcript context, cross-references notes in Google Drive, and outputs: high-priority accounts, next-best-action across everything, stack-ranked against your actual goals.

This isn’t a dashboard. It’s a decision engine. And it runs in seconds.

5) The monthly review that keeps you honest.

Ryan runs a monthly review through the system. It looks across everything: goals, daily check-ins, client interactions, brain dumps, pipeline activity. Then it tells him where he crushed it, where he’s behind, and what goals he’s neglecting entirely.

His quote: “It’s not all puppy dogs and ice cream. It’s also told me I’ve had a bad month.”

That’s the part most people miss. This isn’t a hype machine. It’s an accountability partner with perfect recall and zero ego. It tracks whether you’re actually doing the things you said mattered. And when you’re drifting, it says so.

He also mentioned the candidate scoring system. Upload resumes and interview transcripts, and the system stack-ranks candidates, flags red flags, and tells you exactly where to dig deeper. Every major decision in his business now runs through this architecture.

Why this matters:

Ryan said something that landed: “Executives get paid for the quality decisions they make. The big decisions. And that’s what this is helping.”

He’s not building a chatbot. He’s building a command center that makes him a better CEO. Better decisions, faster pattern recognition, zero context loss between sessions. And he’s doing it with tools that are available to you right now. Claude Code, Obsidian, a few API connections. No engineering team required.

What to do this week:

• Pick one data source you’re not connecting to your AI system (note-taker transcripts, CRM, Google Drive). Connect it.

• Start a memory system. Even if it’s just asking “what did you learn?” at the end of each session. Do it for two weeks and notice the difference.

• Run one query against your transcript data that you’ve never been able to run before. ICP analysis, objection patterns, client epiphanies. See what the data says when you actually let an LLM read it.

• Set up a daily check-in. Three questions, five minutes, end of day. Energy level, biggest win, biggest challenge. Let the patterns reveal themselves over time.

The gap between “using AI” and “operating with AI” is architectural. Ryan built the architecture. The question is whether you will.

How to Build the C-Suite AI Operating System

Ryan Staley screen-shared the exact system he uses to run his entire company. Here’s how to build your own.

Ryan Staley grew a division from zero to $30M with four salespeople and no marketing budget. He’s taught 800+ CROs how to use AI. He works with companies from $20M to $20B on AI transformation.

When he came on the GTM AI Podcast, he didn’t give a pitch. He shared his screen and walked through the actual AI operating system running his business right now. The folder structure, the memory system, the review cadence, the intelligence queries, and the outputs it produces.

This guide breaks down every component of that system so you can build your own. Not theory. Not concepts. The actual build, file by file.

“I created an entire operating system for my business... it has the ability to look across every part of my business and let me operate at the speed of thought. Which has never been possible before.” — Ryan Staley

What This System Is (and Isn’t)

This is not another chatbot workflow. This is not “10 prompts to be more productive.”

This is a centralized AI operating system where every file, every framework, every piece of data connects to a single context layer. When you ask it a question, it doesn’t just respond from a generic model. It responds from YOUR principles, YOUR goals, YOUR call transcripts, YOUR brain dumps, YOUR accumulated memory across months of interaction.

Ryan described it as having a co-CEO sitting on his shoulder who has read every conversation, tracked every goal, and remembers every decision.

The difference between “using AI” and “operating with AI” is architectural. This is the architecture.

What You Need

To start (this weekend):

• Claude Desktop (free), ChatGPT Plus, or Gemini — any model that can read files

• A folder on your computer (Obsidian is ideal, but a plain folder works)

• 2-4 hours for the initial setup

To go deeper (week 2+):

• Claude Code or Cursor — for API connections and automation

• A GitHub account (free) — to store and version your system

• Your call transcript tool (Fathom, Granola, Otter, Fireflies) — for data export

• Your CRM (HubSpot, Salesforce) — for pipeline integration

To go full agentic (month 2+):

• Claude Code with API connections to your note-taker, CRM, and Google Drive

• Automated review schedules

• Domain-specific agents (sales, content, product)

Ryan described the progression path:

Level 1: Chatbot (Claude.ai, ChatGPT) — basic conversation. Good for getting comfortable. No persistence, no file access.

Level 2: Claude Cowork (desktop app) — what Ryan called the “intermediate path.” Better memory, plugins, connectors. UI/UX that makes agentic capabilities accessible without a terminal. This is where most non-technical executives should start building this system.

Level 3: Claude Code / Cursor (terminal) — full agentic power. Connects to any API. Reads your entire file system. Executes code. Automates workflows. This is where Ryan runs his system. You can use any model through Cursor (Claude, GPT, Codex).

You don’t need Level 3 to start. You need Level 1 and a folder.

The Folder Structure

This is Ryan’s actual file index from the episode. Every file is plain markdown (text files with a .md extension). The AI reads the entire folder when you point it at the project.

ceo-personal-os/
│
├── README.md                        # System identity + instructions
│
├── foundation/
│   ├── principles.md                # Your operating principles
│   ├── north_star.md                # Your ultimate direction
│   └── memory.md                    # System memory of key insights
│
├── frameworks/
│   ├── annual_review.md             # Gusto-style annual reflection
│   ├── vivid_vision.md              # Robbins-inspired future visualization
│   ├── ideal_life_costing.md        # Ferris-style lifestyle design
│   ├── life_map.md                  # Lieberman-inspired life domains
│   └── strategic_thinking.md        # CEO decision-making frameworks
│
├── interviews/
│   ├── past_year_reflection.md      # Guided year-in-review interview
│   ├── identity_and_values.md       # Deep identity exploration
│   └── connection_interview.md      # Conversation with future you
│
├── reviews/
│   ├── README.md                    # Reviews system overview + automation
│   ├── brain_dump_analysis.md       # Running synthesis of all insights
│   ├── brain_dump.md                # Raw thoughts (as needed)
│   ├── daily_template.md            # Daily check-in template
│   ├── weekly_template.md           # Weekly review template
│   ├── monthly_template.md          # Monthly review template
│   ├── monthly_template_auto.md     # Automated monthly review
│   ├── weekly_synthesis_example.md  # Example of auto-generated output
│   └── annual_template.md           # Annual review template
│
├── goals/
│   ├── 1_year.md                    # 12-month objectives
│   ├── 3_year.md                    # 3-year targets
│   └── 10_year.md                   # Decade vision
│
├── uploads/
│   ├── post_annual_reviews/         # Previous year reflections
│   └── notes/                       # Misc documents for analysis
│
└── outputs/
    ├── reviews/                     # Generated review outputs
    ├── content/                     # Generated content batches
    └── reports/                     # Pipeline, ICP, analysis reports

Create this entire structure first, even if most files start empty. The structure itself tells the AI how the system is organized. When you point Claude Code, Cursor, or Cowork at this folder, it reads everything and reasons across all of it simultaneously.

That’s the leverage. Not a single prompt. An entire context architecture.

Layer 1: The Foundation

This is where 90% of people skip, and then they wonder why their AI outputs feel generic.

Ryan said it directly:

“Models work the best when you work at a principles level because it understands philosophically what you’re trying to do versus a memory list.”

Three files. These inform everything else in the system.

README.md — The System Identity

This is the first file the AI reads when it opens your project. It’s the job description for your AI chief of staff. Write it in plain language. Tell the model who you are, what this system is, and how you want it to behave.

What to include:

• Who you are. Name, role, company, one sentence about what you do.

• What this system is. “This is my personal AI operating system. It contains my principles, goals, frameworks, and accumulated context. Use everything in this system to give me the most informed, personalized response possible.”

• How to behave. Be direct. Tell me what I need to hear. Check my goals before suggesting priorities. Don’t hedge. If I’m drifting from my goals, flag it.

• Key context. Your market, your business model, your biggest current priority, how you think best.

• System map. One-line descriptions of each folder so the AI knows what lives where.

This takes 10 minutes. It fundamentally changes how the AI interacts with you.

principles.md — Your Operating Philosophy

Not a mission statement. Not corporate values on a poster. These are the actual rules you use to make decisions. When the AI recommends a strategy, it checks it against your principles first.

The difference between an instruction and a principle: an instruction says “write me a cold email.” A principle says “I believe in earning attention, not demanding it. Outreach should provide value before asking for anything.” The instruction produces one email. The principle produces every email, every piece of content, and every strategic recommendation through the right lens.

How to build this file: Run an interview with your AI. Tell it to ask you one question at a time about how you make decisions, what you optimize for, what you refuse to compromise on, how you think about risk and speed and quality. After 10-15 questions, have it synthesize your answers into 5-8 operating principles, each written as a directive with a one-paragraph explanation.

This is the most important 30 minutes of the entire build.

north_star.md — Where You’re Going

This document grounds every recommendation in your actual direction. When Ryan asks for a pipeline report, the system stack-ranks accounts against his goals. When it does a weekly review, it checks his actions against his stated priorities. Without a North Star, the AI has no way to tell you if you’re drifting.

What to include: Your 3-year vision. This year’s top 3 priorities (ranked, with measurable targets). Quarterly focus. Strategic bets you’re making before the data proves it. Explicit trade-offs: what you’re choosing NOT to do, and why.

Run the same interview process. Have the AI ask you questions, then synthesize. Be specific. “Grow the business” is useless. “Reach $2M ARR by Q3 by closing 4 enterprise deals at $150K+ ACV” is useful.

memory.md — The Compound Layer

This is what turns a tool into a partner. Principles and North Star are relatively static (updated quarterly or annually). Memory updates every session.

“At the end of a long session that went really well, a great tip: you say, ‘How do you think we could work better next time? What did you learn from this session?’ And then say, ‘Add that to the memory.’ It helps get better and more fine tuned.” — Ryan Staley

Seed it with: Your communication preferences (bullets vs. prose, level of detail). How you make decisions. Your known blind spots. When you do your best thinking.

Then grow it: After every strong session, ask: “What did you learn about how I work? Be specific. Not ‘you prefer brevity’ but ‘you pushed back when I gave a 5-paragraph answer and asked me to cut it to 3 bullets, which tells me you prioritize density over completeness when reviewing options.’ Add it to memory.”

Five seconds per session. Over 30 days, the AI starts operating like a chief of staff who’s been with you for years. Over 3 months, it knows your patterns better than your business partner. That’s not hyperbole. That’s what Ryan described:

“These things know more about my business than probably I do even because they can look at all the data simultaneously.”

Layer 2: Frameworks

These are the thinking models your system uses to help you with big decisions, annual planning, and life design. Ryan’s system pulls from multiple proven sources. Each file teaches the AI how YOU think about these areas.

annual_review.md — Gusto-Style Annual Reflection

A structured year-in-review. Not “what went well / what didn’t” but a deep assessment across every domain: business scorecard (targets vs. actuals), top wins and why they mattered, top misses and what you’d do differently, relationship audit, health and energy trends, financial review, personal growth, and forward-looking priorities.

How to build it: Have the AI interview you through each domain at year-end. Push for specific numbers, dates, names, stories. Save the output. The AI uses this to calibrate its understanding of what a “good year” looks like for you.

vivid_vision.md — Robbins-Inspired Future Visualization

A detailed, present-tense description of your life 3 years from now, written as if it’s already happened. Tony Robbins’ method. Cover every domain: business (revenue, team, clients, daily rhythm), financial (income, net worth, freedom), relationships, health, lifestyle, impact, learning.

The key: be absurdly specific. Not “I have a successful business” but “I run a $5M ARR company with 8 team members, work 35 hours a week, and close my laptop by 5pm every day.”

When your AI has this document, it can evaluate whether your daily actions are moving you toward this vision or drifting away from it.

ideal_life_costing.md — Ferris-Style Lifestyle Design

Tim Ferris’ framework. Calculate the actual monthly cost of your ideal lifestyle (housing, transportation, food, health, travel, education, experiences, giving, savings), then work backwards to what your business needs to generate. This grounds your revenue targets in something real rather than arbitrary growth numbers.

Most people have never done this math. When you do, you often find you’re either overshooting (grinding for no reason) or undershooting (building a business that can’t fund the life you want).

life_map.md — Lieberman-Inspired Life Domains

A framework for mapping every domain of your life and scoring how you’re doing in each one. Prevents the “crushing it at work, everything else is on fire” problem. Your AI uses this to flag when your reviews show you’re neglecting non-work domains.

strategic_thinking.md — CEO Decision-Making Framework

How you evaluate big decisions: investments, hires, partnerships, pivots. Have the AI interview you with real examples from your recent decisions. Codify it into a framework: your decision principles (ranked), a rapid-decision template for reversible choices, a deep-decision template for irreversible ones, your known biases and the questions that counteract them, and kill criteria for when to stop investing in something.

When you ask the AI for a recommendation, it applies YOUR decision-making logic. Not generic pros and cons.

Layer 3: Interviews

You run these once (maybe annually). They produce the deepest context documents in the system. Think of them as giving your AI chief of staff a multi-hour onboarding about who you really are.

past_year_reflection.md — Guided Year-in-Review

Different from the annual review framework (which is a structured scorecard). This is a conversational interview. The AI asks you open-ended questions about your year: what was this year about, what surprised you most, what was your bravest decision, your lowest point, which relationships changed, what patterns kept showing up, what belief did you update.

The AI follows up on interesting answers. Goes where the energy is. Then synthesizes it into a narrative document that captures themes, patterns, and contradictions between what you said you valued and how you actually spent your time.

identity_and_values.md — Deep Identity Exploration

A multi-round interview that maps who you are at a level most people never articulate. Where your drive comes from. Your actual non-negotiable values (not aspirational ones). How your identity has changed. What you’re afraid of. What you’d build if you couldn’t fail. What you want to be remembered for.

The AI uses this to understand the “why” behind your decisions, not just the “what.”

connection_interview.md — Conversation With Future You

A guided visualization where the AI plays the role of your future self (5 years out, based on your vivid vision and north star) and you have a conversation. Future-you describes a typical day, and present-you asks questions.

The output captures: the identity shift required, the key decisions future-you made, the sacrifices, the daily habits that mattered, what future-you wishes present-you would stop doing immediately, and what future-you wants to give you permission to do.

This document creates emotional connection to where you’re building toward. It’s not a goal doc. It’s a motivation and clarity doc.

Layer 4: The Reviews System

This is the operating rhythm. The heartbeat. Ryan does daily check-ins, weekly reviews, monthly assessments, and annual planning, all through his AI system.

reviews/README.md

An operating manual for the review system. It tells the AI:

• How each review level builds on the previous one (daily feeds weekly, weekly feeds monthly, monthly feeds annual)

• When to automate and when to run manually

• The rules: always check goals first, read the actual files (don’t summarize from memory), be honest, always end with forward-looking priorities

Daily Check-in (3-5 minutes)

Ryan’s replacement for journaling:

“Instead of journaling, I’ll do it. It’s kinda like my version of journaling.”

Five questions, asked one at a time:

1. Energy level today (1-10) and what drove it

2. Biggest win

3. Biggest challenge or frustration

4. Anything that surprised you or shifted your thinking

5. Anything unresolved that’s weighing on you

After your answers, the AI writes a 2-3 sentence pattern note connecting today to the last 7 days. Flags if a frustration is recurring. Notes if your activities misaligned with your quarterly priorities. Updates memory.

You can set a calendar reminder or just do it at end of day or before bed. “There’s days that I miss,” Ryan said. But the habit matters. Over time, it detects energy patterns, recurring blockers, and goal drift you can’t see in the moment.

Weekly Review

Ryan described this:

“I can say, ‘do my weekly review process,’ and it’ll pre-plan my next week, review my past week, and give me insights on things that I’m doing really good at, or goals I’m neglecting and missing.”

The weekly review reads all daily check-ins from the week plus any brain dumps. Output:

• Week summary: Top 3 wins, top 3 challenges, energy trend

• Goal scorecard: For each active goal, ahead / on track / behind / neglected. How many weeks dormant if neglected.

• Pattern alert: What’s recurring, positive or negative

• Brain dump synthesis: Themes from any brain dumps uploaded that week

• Next week priorities: Top 3, ranked by impact, with specific actions

• Blind spot check: Something you should be thinking about that you’re not

“It’s proactively giving me advice on blind spots that I have, or goals I’m tracking. It says if I’m ahead of goals too. It’s not just negative.” — Ryan Staley

Monthly Review

Ryan runs this on the 1st. It reads everything: all daily check-ins, all weekly reviews, brain dumps, transcripts, pipeline data, goals, memory.

“I said, ‘do a monthly review.’ It looked across all that context and gave me some really good insights. I’ve had a killer month and this is why. And it’s also told me I’ve had a bad month. It’s not puppy dogs and ice cream all the time.”

Output:

• Honest verdict. Good month or bad month. Evidence first, not cheerleading.

• Goal scorecard. Month-over-month trends. Accelerating, maintaining, or decelerating.

• Top wins and top concerns. With specific evidence from the data.

• Decision quality. Major decisions made, reasoning, and hindsight assessment.

• Biggest unasked question. The strategic question you should be asking but aren’t.

• Next month focus. Top 3 priorities, ranked.

Brain Dumps

“Sometimes I get my best ideas when I’m walking down the street or I just get out of the shower. So I’ll click on my phone, I got a Google Doc, and then I’ll just talk whatever I’m thinking. It doesn’t need to be structured.” — Ryan Staley

The workflow: Open phone. Open a Google Doc (or any notes app). Talk via voice-to-text. Don’t edit. Don’t structure. Just dump. Upload the text into your system weekly.

The AI processes it: extracts themes, connects ideas to goals, flags emotional signals (what you’re energized about, frustrated about, avoiding), identifies action candidates, and catches contradictions between what you said this week and what you said last week.

The brain_dump_analysis.md file maintains a running synthesis across ALL brain dumps over time. You can read it anytime and see the major themes of your thinking over months.

Layer 5: Goals

Three time horizons. Every review references these files.

1_year.md — 12-Month Objectives

For each goal: specific measurable target, deadline, why it matters (connection to your north star), leading indicators (what signals you’re on track before the lagging metric moves), current status (updated monthly), last update date.

Include quarterly checkpoints: what success looks like at end of each quarter.

Include trade-offs: what you’re explicitly NOT pursuing this year, and why.

“Goals are really hard to track because things are moving so fast and then update and align. And so this is what keeps me on track.” — Ryan Staley

3_year.md — 3-Year Targets

Business targets (revenue, team, clients, market position). Personal targets (lifestyle, financial, health, relationships). Strategic bets you’re making now that you believe pay off in 3 years. And the critical question: what has to be true about your business, skills, and market for these targets to happen?

10_year.md — Decade Vision

Written in present tense, narrative form. A day in your life 10 years from now. What you’ve built. Your impact. The numbers (net worth, income, time freedom). Your non-negotiables. What you’re willing to sacrifice to get there. What you’re not.

Layer 6: Data and Uploads

Your system is only as powerful as the data it can access. The foundation tells the AI who you are. The data layer shows it what you’re actually doing.

Call Transcripts

This is the highest-value data source. Ryan connected Fathom’s API so transcripts flow in automatically. For a simpler start: export weekly as text files, drop them into your uploads folder.

What this unlocks:

• ICP reverse-engineered from how buyers actually talk (Ryan did this in 2 minutes from 6 months of untagged transcripts)

• Client epiphanies extracted with exact quotes (5 minutes for 12 months of calls)

• Objection patterns mapped with resolution data

• Upsell and expansion signals detected across all client conversations

• Content generated from real stories, automatically sanitized

“I said, ‘Identify every epiphany that my clients have had over the last 12 months and put those into categories.’ It did all that, pulled it up in five minutes with exact quotes and examples. That’s the shit that’s like, whoa.” — Ryan Staley

CRM Data

Ryan types “pipeline report” and gets HubSpot data layered with transcript context, Google Drive notes, and next-best-action recommendations stack-ranked against his goals.

Connect via read-only API key. Start with Deals and Contacts. The magic isn’t CRM data alone. It’s combining deal data with what the prospect actually said on the call.

Brain Dump Files

Already covered in the Reviews section. Phone, voice-to-text, upload weekly.

Notes and Documents

Proposals, strategy docs, board decks, research. Don’t dump everything. Pick the 10-20 documents that represent your current strategic reality. Update quarterly.

Layer 7: Outputs and the Agent Layer

Once the system has context (foundation + frameworks + interviews + reviews + goals + data), it produces intelligence that no generic AI can match.

What Ryan’s System Outputs

Pipeline intelligence. One slash command. HubSpot + transcripts + Google Drive + goals = high-priority accounts, next-best-action, stack-ranked against his quarterly targets. In seconds.

Weekly content. One command. 10 LinkedIn posts in his exact voice, rooted in actual client interactions at $300M+ companies, automatically sanitized. He said the manual equivalent takes 5-6 hours.

“People doing seven Clay tables to try and get that customization where you could just do that.” — Ryan Staley

ICP briefing. 2 minutes. From 6 months of untagged transcripts. The way prospects talk, the language they use, the questions they ask, the problems they want solved. A 2-3 page briefing doc.

Monthly honest review. Full assessment against goals, with evidence from daily check-ins, transcripts, pipeline, brain dumps. “You made a major leap this month” or “you had a bad month” with the data to back it up.

Blind spot detection. “Tell me three things I should be focused on that I’m not right now, and why.” Cross-references everything in the system to surface what you’re missing.

“There’s nothing else in the world that could give me that data that fast with that much context. Not even another person on my team.” — Ryan Staley

Candidate scoring. Upload resumes + interview transcripts. Stack-ranked, red flags identified, specific follow-up questions recommended.

The Agent Org Chart

Ryan mapped out specialized AI agents across his entire business. The CEO operating system (what we’re building here) is the hub. Additional agents branch from it:

• Sales agent — reads pipeline + transcripts + goals. Produces deal intelligence.

• Content agent — reads transcripts + brand voice + memory. Produces content in his exact style.

• Product agent — reads client feedback + usage data. Surfaces feature priorities and upsell signals.

• CMO, Chief Counsel, Chief HR Officer — Ryan has AI “executives” that complement him across every function.

Each agent reads from the same centralized context but focuses on a specific domain. That’s why he called it “interconnective tissue” rather than separate tools.

Build the CEO agent first. Add domain agents once the foundation is running and accumulating context.

The Build Sequence

You don’t need to build everything at once. This sequence gets you running fastest with real output at each stage.

Weekend 1: Foundation (2-4 hours)

1. Create the folder structure. Every folder from the diagram above, even if files are empty. 5 minutes.

2. Write README.md. System identity and instructions. 10 minutes.

3. Run the Principles interview. Have the AI ask you 10-15 questions about how you make decisions. Save as principles.md. 30 minutes. This is the most important step.

4. Run the North Star interview. Vision, priorities, targets, trade-offs. Save as north_star.md. 20 minutes.

5. Seed memory.md. Fill in what you already know about your working style. 5 minutes.

At this point you have the three foundation files. Your AI interactions are already fundamentally better than 95% of users.

Week 1: Start the Rhythm

6. Start daily check-ins. End of each day, 3-5 minutes. After each one, ask: “What did you learn? Add to memory.” This is the compound interest habit.

7. Set up goals/1_year.md. Specific targets, deadlines, leading indicators. Without this, reviews have nothing to score against. 20 minutes.

8. Run your first weekly review. Even with just 3-5 daily check-ins, it produces useful output. Gets dramatically better each week.

9. Start brain dumping. Phone, voice-to-text, 2-3 minutes, upload weekly.

Week 2: Connect Data

10. Connect your first data source. Start with call transcripts. Export from your note-taker, drop into the uploads folder.

11. Run your first intelligence query. ICP reverse-engineering, client epiphany extraction, or blind spot detection. Pick one. This is the moment that converts skeptics.

Weeks 3-4: Deepen the System

12. Run the deep interviews. Identity and Values, Past Year Reflection, Future Self Connection. One per session, 30-45 minutes each. These happen once a year but produce the deepest context in the system.

13. Build your frameworks. Decision-making framework, vivid vision, ideal life costing. One per session.

14. Connect additional data sources. CRM, Google Drive, more transcript history. Each source multiplies every other source.

Month 2+: Automate and Expand

15. Run your first monthly review. Now you have 4 weeks of dailies, 4 weeklies, brain dumps, and connected data. It will be substantive.

16. Start automating. Move from “I ask for the weekly review” to “it runs on schedule.” Ryan is at the point where content generates without him asking.

17. Build domain agents. Content, sales, product. Each reads from the centralized context. This is the agent org chart.

The Compounding Timeline

Day 1: You have principles and a north star. AI interactions feel different immediately.

Week 2: Daily check-ins accumulating. The AI knows your energy patterns and recurring frustrations.

Month 1: Connected data sources. First intelligence queries producing insights you’ve never had access to.

Month 3: 60+ debriefs, 12 weekly reviews, months of transcripts, memory that knows your preferences deeply.

Month 6: Automated outputs, domain agents, fully autonomous reviews. The system runs your business alongside you.

“Executives get paid for the quality decisions they make. The big decisions. And that’s what this is helping.” — Ryan Staley

The gap between “using AI” and “operating with AI” is architectural. This guide gives you the architecture. What you build with it is up to you.

Ryan Staley is the founder of Whale Boss, host of the Scale Up Show (top 1% global podcast), and works with C-suite executives at companies from $20M to $20B on AI transformation. Connect with him on LinkedIn.

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

Let me walk through what the deck actually shows, and why it matters more than the panic.

The Infrastructure Is Real This Time

The first thing Redpoint establishes is that this isn’t the dotcom bubble. AI capex as a percentage of GDP is now a distinct investment wave, comparable to railroads, telephony, and the internet buildout (Slide 2). Hyperscaler CapEx is going from $309B in 2024 to $779B by 2027, a 36% CAGR (Slide 3). That’s real capital, not speculative fiber.

The part that kills the bubble narrative: OpenAI and Anthropic are each generating $20B+ in ARR. Over 90% of buildout capacity is pre-committed. Near-zero data center vacancy rates. 1B+ monthly active users four years post-ChatGPT (Slide 4). As Logan Bartlett, who co-wrote the deck, put it on LinkedIn: “The infrastructure isn’t running ahead of demand. Demand is pulling the infrastructure forward.”

This is the opposite of 2000. In 2000, you had Cisco trading at $0.37 EPS while fiber sat at 3% utilization. Today, Nvidia is at $4.06 EPS and capacity is oversubscribed. That distinction matters because it tells you the correction in software stocks isn’t about the AI thesis being wrong. It’s about the AI thesis being right, and software being on the wrong side of it.

The Three-Layer Divergence

Software is down 20% YTD, the worst-performing sector in the S&P 500 (Slide 12). Public SaaS median NTM multiple is at 4.1x, the lowest since Redpoint started tracking in 2007 (Slide 13). But the selloff didn’t hit evenly. And the unevenness is where the real signal lives.

Redpoint breaks it into three layers (Slide 16-17):

Vertical SaaS: +3% LTM. These companies own the irreplaceable moat: proprietary data plus compliance infrastructure. AI can’t displace Veeva in life sciences or Toast in restaurants without re-acquiring years of industry-specific data, regulatory relationships, and transaction embedding. For vertical SaaS, AI is a feature, not a threat.

Infrastructure: +2% LTM. More AI deployment means more compute, more data, more observability. Snowflake, Datadog, MongoDB, Cloudflare all get AI tailwinds. The multiple compressed, but the thesis didn’t.

Horizontal SaaS: -35% LTM. This is the kill zone. These companies, as Redpoint puts it, “accidentally optimized for replaceability.” They built to serve every industry equally, which meant integrating deeply with none. Their core value prop was answering “who is doing what and when,” which is a coordination problem. AI solves coordination natively.

That -35% isn’t panic. It’s the market correctly pricing the fact that horizontal SaaS moats were always an illusion. The switching cost was familiarity, not dependency. And familiarity is worthless when a new tool is 10x better on day one.

The Agent Maturity Curve Changes the Math

Here’s where the Redpoint deck gets genuinely important. Slide 7 maps the agent maturity curve:

• Copilots (where we’ve been): TAM is ~$0.5T, the existing US software spend

• Task Agents (where we are now): TAM grows to ~$1.2T, adding services automation

• Workflow Agents (next 18-24 months): TAM hits ~$2.8T, adding operational payroll

• Autonomous (the endgame): TAM reaches $6.1T+, unlocking knowledge worker payroll

We’re at Task Agents. Minutes of independent runtime. Human oversight still required. But even at this stage, the TAM has already doubled beyond software. The companies winning here aren’t selling seats. They’re selling outcomes against labor budgets.

This is why 58% of CIOs say AI features are the #1 driver of software spend increases (Slide 19), and simultaneously, 54% are pursuing vendor consolidation and 45% of AI budgets are replacing existing software (Slide 20). Only 3% of CIOs expect AI to lead to more vendors. The market is converging, not expanding.

Read those numbers together. CIOs are spending more on software, but only when that software has AI capabilities baked in. And they want fewer vendors, not more. The pricing model is shifting underneath everything: 46% of CIOs expect usage or outcome-based pricing to become more common, while 35% expect flat subscriptions to decline. The per-seat model that built the SaaS industry is unwinding in real time.

AI spending is going up. Software vendor count is going down. Pricing is shifting from seats to outcomes. If you’re a horizontal SaaS company selling per-seat licenses for coordination software, those three facts are a death sentence unless you pivot fast.

The Newspaper Analogy (Why Quarterly Beats Don’t Matter)

Redpoint draws a chilling parallel on Slide 22: US newspaper stock returns started collapsing around 2002, but consensus forward earnings held up until 2007 before falling off a cliff. Stock prices led earnings by roughly five years.

Apply that to SaaS. Companies are still posting decent quarters. Revenue is still growing. But 85-95% of SaaS enterprise value is terminal value, not explicit forecast period (Slide 23). A strong quarter moves less than 5% of the value. You can’t disprove a 10-year existential question with a 90-day result.

The market sees this. In three months, the implied long-term growth rate for a representative SaaS company collapsed from 4.7% to 1.1% (Slide 24). The near-term estimates didn’t change. The terminal value did. Public investors are telling you they believe SaaS growth asymptotes to near-zero over the long term.

Even if a company beat estimates, the stock can drop the next day. Now they know why.

Where the Vulnerability Is Highest

The CIO survey data on Slide 30 tells you exactly where to worry. When asked which categories they’re most open to replacing with AI-centric vendors:

• Salesforce Automation: 83% (this should terrify Salesforce)

• Customer Service: 56%

• ITSM: 55%

• ERP: 50%

And the incumbents are, in Redpoint’s assessment, “missing the boat” (Slide 42). One auto OEM executive on Agentforce: “It’s been oversold. It’s not a game changer. It’s a smart chatbot.” A Fortune 500 executive on Microsoft Copilot: the pricing “literally doubles your E3” and they’ve decided against enterprise-wide rollout. A global industrial executive on ServiceNow: “If there’s a startup that came along and said, ‘We can do this better at a better price,’ I wouldn’t even think twice about switching.”

The AI-native companies are operating at a fundamentally different efficiency level. Cursor generates $6.1M in ARR per employee. Lovable: $3.4M. Compare that to the incumbents they’re disrupting: Salesforce sits at $0.54M. Atlassian: $0.46M (Slide 55). Cursor is producing 11x more revenue per human than Salesforce. That’s not a marginal improvement. That’s a structural cost advantage that compounds every quarter. It means AI-native companies can undercut incumbents on price, outspend them on R&D as a percentage of revenue, and still generate better margins.

As one commentator on the deck noted: the incumbents can’t decouple revenue from headcount. They sell seats. They staff with humans. Their entire economic model assumes that revenue scales linearly with people. AI-native companies broke that assumption on day one.

Three Questions to Ask Monday Morning

1. Are you vertical or horizontal? If you can’t name the specific regulatory framework, industry data set, or transaction type that makes your product irreplaceable in your market, you’re horizontal. Start the re-founding conversation (Redpoint’s term) now. Not next quarter.

2. Can your revenue decouple from headcount? The AI-powered P&L model Redpoint outlines (Revenue +25-35%, headcount costs -15-20% across every function) only works if you can deliver more value with fewer people. If your revenue model is fundamentally tied to the number of humans on your team or your customer’s team, you’re on the wrong side of the curve.

3. What happens at Workflow Agents? We’re at Task Agents today. The jump to Workflow Agents (hours of independent runtime, multi-step business processes across systems) is coming in the next 18-24 months. That jump takes the addressable market from $1.2T to $2.8T. But it also means AI goes from executing discrete tasks to orchestrating entire workflows. Every product that exists primarily as workflow orchestration software becomes a feature of the agent, not a platform the agent runs on.

The Window

Slide 67 is the one I keep coming back to. Across three platform shifts (internet, cloud, mobile), the durable winners were founded in years 4-5 after the shift began. ChatGPT launched in November 2022. We’re in year 4. 2026-2027 is the window.

That’s not a VC pitch. That’s a pattern backed by three decades of data. The companies that will own the next era of business software are being built right now. Some of them are incumbents who execute a genuine architectural reset. Most of them are AI-native startups running at $3-6M ARR per employee while the incumbents are stuck at $500K.

The prescription starts with one honest question: when AI agents can orchestrate entire workflows, what part of your product is still irreplaceable?

If you can’t answer that clearly, the market already has.

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 internal files through a CMS misconfiguration. Forget the model for a second. The company whose entire brand is “we’re the responsible ones” just demonstrated that operational security is harder than alignment research. The model itself might be genuinely dangerous. The leak proving Anthropic can’t secure its own CMS? That’s a different kind of dangerous. Consumer subs doubling and an $18B revenue target tell you the business is working. The question is whether “too dangerous to release” becomes a moat or a liability.

OpenAI Killed Sora. Nobody Should Be Surprised.

The noise: AI’s first major product death. The end of an era. Video generation dreams dashed.

The signal: $15M per day in inference costs against $2.1M in total lifetime revenue. That’s not a product death. That’s a math problem that finally got solved. Sora was always a demo dressed up as a product. The real story: OpenAI at $850B valuation and $20B+ ARR can afford to kill things that don’t work. That’s a sign of discipline, not failure. Video generation stays in ChatGPT for subscribers, which is exactly where it belongs: a feature, not a platform.

The White House Wants to Preempt Every State AI Law

The noise: the National AI Policy Framework is either “pro-innovation” or “regulatory capture,” depending on which side of the aisle you read.

The signal: this framework has already failed legislatively twice. It’s sector-specific, creates no new regulatory body, and preempts state laws. Translation: the federal government wants to prevent a patchwork of 50 state regulations without actually regulating anything itself. Industry loves it because the alternative is California writing the rules for everyone. Whether you think that’s good or bad depends on whether you trust sectors to regulate themselves. (History says no.)

Claude Code’s Auto Mode Changes the Developer UX Game

The noise: incremental product update. Classifier-based permissions. Less clicking.

The signal: the approval loop was the single biggest friction point in AI-assisted coding. Every time a developer had to click “yes, proceed” for an obvious action, the tool lost momentum. Auto mode is Anthropic betting that the classifier can distinguish between “rename this variable” and “delete the production database” well enough to remove the human from routine decisions. If it works, this is the kind of UX shift that changes daily adoption numbers, not quarterly strategy decks.

OpenAI Bought Six Companies in 2026. That’s Not a Model Company.

The noise: OpenAI acquired Astral (uv, Ruff) and Promptfoo. Smart picks. Developer tooling. Evaluation infrastructure.

The signal: six acquisitions in a single year. Add the $50B Amazon partnership for stateful agent runtime on Bedrock. This is a platform company building distribution, not a research lab building models. Sam Altman is running the Microsoft playbook: own the developer toolchain, own the cloud runtime, own the ecosystem. The model becomes the kernel nobody thinks about. Whether that’s good for the industry depends on how tightly they lock the stack.

MCP Hit 97 Million Monthly SDK Downloads

The noise: protocol adoption numbers go up. Good for Anthropic.

The signal: 4,750% growth in 16 months. That’s not adoption. That’s infrastructure. When a protocol layer hits this kind of trajectory, it stops being a feature and starts being a standard. MCP is becoming the USB-C of AI agent connectivity. The companies not building MCP integrations today will be retrofitting them in six months.

Atlassian Cut 1,600 People and Blamed AI

The noise: another round of tech layoffs dressed up as strategic transformation.

The signal: “AI pivot” is becoming the “blockchain strategy” of 2026. When a company lays off 10% of its workforce and leads the press release with AI, the community calls it correctly: cost-cutting with better PR. The real AI pivots are happening at companies that are hiring into new roles, not cutting existing ones. Watch what companies build, not what they say during layoff announcements.

Google Went From 5.4% to 18.2% Chatbot Market Share in a Year

The noise: Gemini is catching up. Google is back in the AI race.

The signal: the fastest growth trajectory in the market, driven by the most aggressive pricing anyone has seen. Gemini 3 at $2/$12 per million tokens is a price that forces everyone else to respond. Google is doing what Google always does: subsidize adoption with infrastructure advantages nobody else can match. DeepMind’s research pipeline feeding directly into products that run on Google’s own chips and cloud. The 114 model price changes across the industry in March alone tell you this pricing war is unsustainable for everyone except the company that owns the data centers.

Meta Shipped Open-Weight MoE Multimodal Models

The noise: Llama 4 Scout and Maverick are here. Open source wins again.

The signal: Meta keeps commoditizing the model layer, and every release makes the gap between open-weight and proprietary models smaller. Mixture-of-experts architecture in open weights means smaller companies can run competitive models on reasonable hardware. LlamaCon on April 29 will likely accelerate this. The strategic play is clear: if models are commoditized, the value moves to applications, data, and distribution. Meta has all three.

Robotics Got $1.2 Billion in March Alone

The noise: LeCun’s AMI Labs raised $1.03B. Physical AI is the next frontier.

The signal: JEPA architecture (Joint Embedding Predictive Architecture) is LeCun’s bet that the path to general intelligence runs through world models, not language models. A billion dollars says he’s not alone in that belief. The robotics funding surge is the market saying that software-only AI is approaching diminishing returns for certain problem classes. Moving atoms, not just bits, is where the next decade of value creation lives. And unlike software agents, physical robots need real-world training data that can’t be synthesized from the internet. That data moat is why the money is moving now, before the window closes.

Perplexity Launched a “Personal Computer.” Yes, Hardware.

The noise: a search company is selling an always-on Mac mini AI agent. Quirky pivot.

The signal: Perplexity is testing a thesis that matters. The browser is a bad form factor for AI agents that need persistent context, local file access, and always-on availability. An always-on device that runs your AI agent locally solves the context window problem by never closing the session. It’s early, probably too early. But the insight underneath is correct: cloud-based chat interfaces are a transitional form factor. The companies thinking about what comes after the chat window will define the next generation of AI UX.

OpenAI Foundation Pledged $1B for 2026

The noise: OpenAI is serious about safety. Zaremba is leading. Big number. Good optics.

The signal: context matters. This is the same organization that made six acquisitions, partnered with Amazon for $50B, and killed Sora when the economics didn’t work, all in the same quarter. A billion dollars in safety funding against that backdrop is either genuine commitment or the cost of maintaining a narrative while you scale as fast as possible. The proof will be in what the foundation actually funds, who has independence to publish findings that embarrass the parent company, and whether any of it slows down the commercial roadmap. I’ll believe it when I see a safety finding delay a product launch.

The Pattern

Two forces defined this week. The first: the split between “too dangerous” and “too expensive.” Anthropic won’t ship Mythos because of safety concerns. OpenAI killed Sora because the economics didn’t work. These are fundamentally different reasons for products not reaching users, and the industry needs to stop conflating them. Safety decisions and business decisions require different frameworks, different oversight, and different public accountability.

The second: the platform war is over before most people realized it started. OpenAI’s six acquisitions, Amazon’s $50B partnership, MCP’s infrastructure trajectory, Google’s pricing aggression. These aren’t companies competing on model quality anymore. They’re competing on ecosystem lock-in, developer toolchains, and distribution. The model layer is being commoditized from above (proprietary platforms) and below (open-weight releases from Meta). The winners will be decided by who owns the integration points, not who has the best benchmark score.

If you’re building on AI right now, the question isn’t which model to use. It’s which platform you’re willing to be locked into for the next five years.

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 for you to know.

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

Subscribe now

Free or paid, we will give as much value as possible. Now, on to the podcast:

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

Account planning used to take 2 quarters. Now it takes 90 seconds.

Justin Driesse, Director of Sales Enablement at Legora, built a Notion AI agent that generates account plans so detailed his CRO asked, “Is this real?” Not one good plan. Hundreds. Every single one with tiered stakeholder maps, competitive intelligence, inline footnotes linking to source press releases, and strategic recommendations. The reps’ most common question: “That’s it? I just type ‘yes, chef’?”

That’s it.

Here’s what makes this worth your next 3 minutes:

1) The “Yes, Chef” agent runs on 5 chained prompts inside Notion. No code. No engineering resources.

Justin used Notion AI itself to write the prompts. He told it what he wanted, what he didn’t want, and iterated until the output consistently hit the bar. The agent reads the account name from the page title, pulls from product marketing pages, competitive intel, and industry data stored in Notion, then generates the full plan in 90 seconds.

The unlock: Notion IS the RAG. If your org already lives in Notion, your knowledge base and your agent system are already meshed together. No separate vector database. No upload workflow. You add a new product page to Notion, add one line to the prompt, and every future account plan includes it automatically.

2) Enablement is leaving the content business. The new job is plugging leaks.

Justin dropped out of a PhD in adult learning 40% of the way through because AI made the degree irrelevant. His thesis: learning used to be labor-intensive. You’d hunt and peck on Google for maybe 3 nuggets an hour. Now you tell Claude to explain Roman mythology like an episode of SpongeBob and it just does it.

The implication for enablement: if any concept can be explained to anyone in any format on demand, content creation stops being the job. The job becomes having the widest panorama lens on the GTM org and spotting where the process leaks are. Everyone moves faster now. Leaks will be more frequent. The enablement teams that preempt those leaks with agentic solutions become indispensable. The ones still building e-learnings become irrelevant.

3) Change management collapses when you remove the friction instead of training through it.

Old world: CRO says “we need account planning.” That’s 2 quarters minimum. Needs analysis, team training, QBR workshops, manager follow-up, hoping reps keep doing it after the first pancake phase. The emotional energy alone is massive.

New world: Justin launched account planning at their Stockholm kickoff. Pre-work was “spin up account plans for your top accounts.” Type “yes, chef.” Done. Hundreds of account plans generated in a week. The change management tax dropped to near zero because there was nothing to change manage. The reps weren’t learning a new behavior. They were typing two words.

4) The real payoff is macro intelligence, not just individual plans.

With hundreds of rich account plans in a Notion database, Legora can now run agents across the entire portfolio. Trend analysis across deals before they close. Competitive patterns across accounts. Real-time learning that used to only happen in post-mortems. Pre-sales to post-sales handoff went from “let me find the doc” to “it’s all in the account plan, already.”

Justin’s line that landed hardest: “How do we drive insights out of our deals before they’ve already closed?”

Why this matters for you:

The pattern here isn’t “use Notion AI.” The pattern is: stop training people to do work that an agent can do for them. Build the solution into the workflow where the work already happens. Remove the friction instead of coaching through it.

What to do this week:

• Identify your team’s highest-friction admin task (account plans, handoff docs, call prep)

• Build a single agent that does 80% of it using chained prompts in whatever tool your org already uses

• Measure: what was the old timeline vs. the new one? What’s the adoption rate when friction drops to zero?

Enablement and content are about to have a breakup. The teams that see it coming will build agents. The ones that don’t will build another e-learning module nobody finishes.

The Agentic Enablement Playbook: How to Replace Training with Solutions Your Team Actually Uses

From the GTM AI Podcast with Justin Driesse, Director of Sales Enablement at Legora

I Built a step by step guide to create the same AI Agents that Justin created with Perplexity Computer, check it out here

The Shift in One Sentence

Stop training people to do admin work. Build agents that do it for them. Then train them on what actually matters.

That’s the thesis from Justin Driesse, who built a Notion AI agent that generates account plans so detailed his CRO thought they were hand-crafted. They weren’t. They take 90 seconds.

This playbook breaks down the exact approach, the mental model behind it, and how you can apply it to your own enablement org this quarter.

Part 1: The Old World vs. The New World

Old World: Account Planning (or any high-friction enablement initiative)

Here’s what it actually looked like before:

1. CRO says “we need account plans”

2. Enablement does a needs analysis (2-4 weeks)

3. Stakeholder interviews with sales managers (2 weeks)

4. Define what “good” looks like (1-2 weeks)

5. Build the template, the training deck, the e-learning module (2-4 weeks)

6. Find a slot at the next QBR to train the team (wait 4-8 weeks)

7. Train. Hope people are paying attention and not hungover from the night before.

8. Push through the “first pancake” phase where the first attempts are bad

9. Lean on managers to reinforce (they have 47 other things on their plate)

10. Hope reps keep doing it after the initial push

Total timeline: 2 quarters. Maybe more.

The hardest part wasn’t the training. It was the change management. Getting people to do a new thing they know is valuable but feels like more admin work on top of an already full plate.

New World: What Justin Built at Legora

1. Built 5 chained prompts in a Notion AI agent (using Notion AI to help write the prompts)

2. Loaded product marketing pages, competitive intel, and industry data as context sources

3. Rep creates a new account plan page, types “Yes, Chef” as the trigger

4. 90 seconds later: full account plan with tiered stakeholder maps, competitive analysis, strategic recommendations, and inline footnoted sources

Total timeline: Built in days. Deployed at kickoff. Hundreds of plans generated in the first week.

The change management tax dropped to near zero. There was nothing to change manage. The reps weren’t learning a new behavior. They were typing two words.

Part 2: The 5-Step Framework for Building Agentic Solutions

You can apply this pattern to any high-friction enablement initiative. Account plans are just one use case.

Step 1: Identify the Highest-Friction Admin Task

Look for the work everyone knows is valuable but nobody wants to do. The telltale signs:

• Leadership mandated it but adoption is low

• Reps have good intentions but “the clock hits zero every day”

• You’ve tried training, coaching, and manager reinforcement, and it still doesn’t stick

• The output quality varies wildly because some reps invest time and others don’t

Common examples: account plans, handoff docs, call prep, competitive battle cards, QBR prep, territory plans.

Step 2: Map the Knowledge Sources

Before you build anything, identify where the information already lives. Justin’s key insight: “Notion is your RAG.”

Ask yourself:

• Where does your product information live?

• Where does competitive intel get documented?

• Where are customer notes, call summaries, and deal history?

• Where does the knowledge your agents need already exist?

The best agent implementations don’t require building a new knowledge base. They tap into the one your org is already maintaining.

Step 3: Build Chained Prompts (Not One Giant Prompt)

Justin’s agent uses 5 prompts chained together, not a single massive prompt. Each prompt has a specific job:

• Prompt 1-4: Research and synthesis (pulling from different data sources, structuring different sections of the output)

• Prompt 5: Overlay proprietary company information (product pages, competitive positioning, talk tracks)

The key prompting principle: be clear about what you want, but be twice as clear about what you don’t want. That’s how you raise the floor of the output quality.

Use the AI itself to help write your prompts. Justin used Notion AI to go back and forth on prompt design. Tell it what you need, review the output, refine, iterate.

Step 4: Set the Trigger Low Enough That Adoption Is Inevitable

Justin’s “Yes, Chef” trigger is brilliant for three reasons:

1. It requires zero cognitive overhead (type two words)

2. It ties to the team’s internal culture and kickoff theme

3. It makes the friction of NOT doing it higher than the friction of doing it

When your team asks “That’s it?” you’ve won the adoption game.

Step 5: Design for Macro Intelligence, Not Just Individual Output

This is where most people stop: they build a tool that helps one person do one task faster. Justin went further.

With hundreds of account plans in a Notion database, Legora can now:

• Run agents across the full portfolio to spot trends

• Analyze competitive patterns across all accounts simultaneously

• Extract insights from active deals before they close (not just in post-mortems)

• Give post-sales teams complete context from day one

The individual account plan is the product. The database of account plans is the strategic asset.

Part 3: The Bigger Thesis (Enablement’s Breakup with Content)

Justin’s strongest take: enablement and content are going to completely detach from one another.

His logic:

Content is a vehicle for breaking down complex information. E-learnings, one-pagers, infographics, training decks. All of these exist because you can’t get in a room with every person and walk them through it.

AI just removed that constraint. Anyone can now get any concept explained to them, in any format, at any depth, personalized to how they learn best. You can literally ask ChatGPT to explain world finance as if it were the WWE. And it will.

So what’s left for enablement? Process. Having the widest lens on the GTM organization. Spotting where things break. Plugging leaks with agentic solutions before they become problems.

The teams that move faster will spring more leaks. The enablement teams that preempt those leaks become indispensable. The ones still running content factories become irrelevant.

Part 4: Your Action Plan This Week

Day 1-2: Audit your current enablement backlog. List every initiative that involves training people to do admin work. Rank them by: how much time the old approach takes, how low adoption currently is, and how much knowledge already exists in your tools.

Day 3-4: Pick one and build a prototype agent. Use whatever tool your org already lives in (Notion, Slack, your CRM). Chain 3-5 prompts. Load the relevant knowledge sources. Test it on 5 real accounts or scenarios.

Day 5: Demo it to your team the way Justin did. Show a real output. Click into the footnotes. Let the quality speak for itself. The “is this real?” reaction is your adoption catalyst.

Ongoing: Measure the shift. Track: old timeline vs. new timeline. Adoption rate (when friction drops to zero, this should spike). Output quality compared to manual efforts. And most importantly: what macro insights are you now able to extract that you couldn’t before?

The Bottom Line

The best enablement programs in 2026 won’t be measured by training completion rates or content produced. They’ll be measured by the number of friction points eliminated and the quality of intelligence generated.

Build the agent. Remove the friction. Let your team do the work that actually requires a human.

This playbook is based on the GTM AI Podcast episode with Justin Driesse. Subscribe at gtmaipodcast.com for weekly episodes with GTM leaders building the future of revenue.

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 thesis. I heard someone finally put a number on the thing I’ve been arguing from the field for the last year: the AI-native org doesn’t add agents to the existing structure. It replaces the structure entirely.

I run a 103-agent system. Not as a proof of concept. As my actual operating architecture for GTM work — content, research, competitive intelligence, sales enablement, revenue operations, the whole stack. And what Huang described isn’t science fiction from where I’m sitting. It’s Tuesday.

The ratio itself isn’t the insight. It’s what the ratio demands of the humans who remain.

The End of “Managing” as a Job Description

The typical VP of Sales manages 8-12 people. Maybe 20 if the span is wide. The job is 1:1s, coaching, pipeline reviews, conflict resolution, career development. It’s relationship-intensive, time-intensive, and — let’s be honest — it doesn’t scale.

Now imagine that same VP orchestrating 100 agents. The skillset inverts completely.

You don’t coach agents. You configure them. You don’t do 1:1s. You review output quality and adjust routing logic. You don’t resolve conflicts between personalities. You resolve conflicts between competing optimization functions.

This isn’t an incremental change. It’s a different job. And most leaders I talk to haven’t internalized that yet.

I was on a call two weeks ago with a CRO at a $400M SaaS company. Smart guy. Aggressive growth targets. He told me he was “exploring AI agents for the team.” When I asked what that meant, he described giving his reps access to a chatbot that could draft emails.

That’s not a 100:1 org. That’s a 0.1:1 org with better autocomplete.

Which Human Roles Survive (And Which Don’t)

These are the human roles that get more valuable at 100:1, not less:

Architects — Someone has to design the system. Which agents exist, how they connect, what data flows between them, where human judgment gates sit. This is the new org design. When I built my routing table — literally mapping task patterns to specific agents across 9 departments — that was architecture work. No agent did that for me.

Governors — At 100:1, one misconfigured agent creates cascading failures. Someone has to set guardrails, monitor for drift, audit outputs, and decide when the system’s confidence threshold requires human override. I run drift detection on my agent specs. If the source material changes but the agent hasn’t been updated, I get flagged. That governance layer is a human job.

Relationship holders — Agents don’t build trust. They don’t read the room in a board meeting. They don’t know that your champion at the prospect company just went through a divorce and needs you to be a human being before you’re a seller. The judgment calls — when to override the system, when to ignore the data, when to just listen — those stay human.

Taste-makers — Agents can generate a hundred variants of a LinkedIn post. Someone has to know which one sounds like you. The editorial judgment, the brand instinct, the “that’s not quite right” feeling — that’s irreplaceable. I review every piece of content my writing agent produces. The agent gets me 80% there. The last 20% is taste.

What gets absorbed into agent workflows? Research. First-draft creation. Data analysis. Competitive monitoring. Lead scoring. Email sequencing. Meeting prep. Follow-up cadences. Report generation. Most of what a typical BDR, SDR, or marketing coordinator does today.

That’s not a prediction. That’s what’s already happening in my system.

What Managing Agents Actually Requires

Let me be specific about what my day looks like orchestrating 103 agents, because the “100:1 ratio” sounds clean and the reality is messier.

Routing is the new management. Every task that enters my system hits a routing layer. Is this a Tier 1 obvious match — a writing task that goes straight to the content writer? Or is it Tier 3 — a novel cross-domain problem that needs multiple specialists in sequence? Getting the routing right is 60% of the job. Bad routing wastes more time than bad agents.

Memory is the new moat. My agents share a knowledge graph. When the competitive intelligence agent discovers something, the content writer can reference it. When the product marketing agent updates positioning, the sales enablement agent adjusts its playbooks. This compound learning is the actual competitive advantage — not any individual agent’s capabilities.

Context windows are your bottleneck. Every agent has a finite amount of information it can hold at once. Managing what goes into that window — and what gets folded, summarized, or archived — is a genuine operational discipline. I built a context management system with token budget tiers. It sounds like infrastructure. It’s actually the difference between agents that hallucinate and agents that produce.

Observation beats instruction. The best agents in my system aren’t the ones with the most detailed prompts. They’re the ones where I’ve built feedback loops — tracking what works, what doesn’t, and adjusting the system. I have a proactive monitor that checks 9 conditions across the system: inbox age, content staleness, queue status, agent freshness, orphan notes. The system tells me where to look. I decide what to do about it.

The Token Salary Signal

One more thing Huang said that deserves separate attention: NVIDIA plans to offer engineers $100K-$150K in AI compute tokens on top of their cash compensation.

Read that again. They’re not offering a perk. They’re offering capacity.

An engineer with $150K in compute tokens can spin up more agents, run more experiments, train more models than an engineer without them. The gap between the two isn’t about money. It’s about leverage. One engineer ships the output of ten. The other ships the output of one.

This is where the 100:1 ratio meets compensation design. If your agents are your workforce, and tokens are what powers those agents, then token access IS workforce capacity. The companies that figure this out first will attract and retain the engineers who can actually operate at 100:1 scale.

What To Do This Week

If you’re leading a GTM team and the 100:1 number made you feel something — excitement, anxiety, skepticism — channel it into one action:

Audit your current ratio.

Not “how many AI tools does my team use.” That’s the wrong question. The right question is: how many autonomous workflows run without a human in the loop?

Count them. Be honest. If the answer is zero, you’re not behind on AI adoption. You’re behind on architecture. The tools are available. The system design is what’s missing.

Huang didn’t announce new technology at GTC. He announced a new operating model. The technology has been here. The question is whether your org structure has caught up.

The leaders who build their 100:1 architecture in 2026 will own their categories by 2028. The ones waiting for it to “mature” will be buying the playbook from the first group.

Start with one agent. Then five. Then the ratio will tell you where to go next.

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

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

The Block Signal and What It Actually Means

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

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

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

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

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

• Only 11% are actively running AI in production

• 76% are deploying or implementing agentic AI in theory

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

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

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

The 65-Point Gap Nobody Is Talking About

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

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

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

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

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

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

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

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

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

Click Here

What the AI-Native GTM Org Actually Looks Like

Read more

Here’s what happened, and what it actually means.

Read more

Claude agents change what’s possible. Not because they’re technically impressive — because they restructure how work actually gets done. The difference between researching five competitors one at a time over an afternoon and having five parallel conversations that all finish in fifteen minutes is not incremental. It’s a different category of output. Same effort, different throughput.

You don’t need to write a single line of code to do any of this.

What You’ll Build

• An understanding of how Claude agents actually work — and why sequential use is leaving throughput on the table

• Your first parallel research project running across multiple Claude conversations simultaneously

• The orchestrator + worker pattern for complex, multi-part projects

• Role specialization techniques that produce better output by giving each conversation a specific job

• Background agent workflows for Claude Code users who want to run projects while doing other work

Step 1: What Claude Agents Actually Are

An agent, in Claude’s context, is a Claude instance with a specific role and task running autonomously. Not a different product. Not a plugin. The same Claude — given a defined job, enough context to do it, and the instruction to complete it and report back.

Here’s the insight that changes how you work: Claude Code — Anthropic’s CLI tool — can spawn multiple agents simultaneously. Each one works on a different piece of a larger project at the same time, then reports back to a coordinating conversation that synthesizes the outputs. A project that would take you three hours of sequential Claude sessions takes forty-five minutes because the work runs in parallel.

But you don’t need Claude Code to apply agent thinking. In Claude.ai, you can run multiple browser tabs — each one a separate Claude conversation with a distinct role and task. It’s the manual version of the same pattern. Same principle. Available to any Claude Pro subscriber today.

The core insight is this: most knowledge work isn’t sequential. The five competitor research briefs you need for Monday’s strategy meeting aren’t dependent on each other. The three draft angles you’re evaluating for a content piece can be written at the same time. The four sections of a long document you need reviewed don’t have to wait in line. Once you see which tasks are genuinely interdependent and which ones just feel sequential because you’ve been doing them one at a time, the pattern becomes obvious.

Sequential vs. parallel isn’t about being faster at the same work. It’s about doing fundamentally more work in the same window of time.

Step 2: Your First Parallel Workflow

Open Claude.ai. Open four browser tabs — each one a new Claude conversation.

You’re going to run a competitive research project. The goal is a research brief on four competitors, all finished at the same time rather than one after another.

In each tab, paste this prompt — swapping the competitor name:

You are a competitive intelligence analyst. Research [Competitor Name] and give me:

(1) Their core product offering — what they do and for whom.
(2) Their primary positioning — how they describe themselves, what problem they claim to solve.
(3) Their pricing model — how they charge (if publicly available).
(4) Their most obvious strengths — what they do well based on reviews, case studies, or public evidence.
(5) Their most obvious weaknesses — where customers complain, where they're thin, where they overstate.
(6) One thing about this competitor that most people in my industry underestimate.

Be specific. Cite what you're observing from publicly available information. Don't summarize — give me the analysis.

My company does [brief description of what you do]. Frame the competitor assessment relative to us.

Run all four tabs simultaneously. You’re not watching them in sequence — you’ve started them all and you’re doing something else while they run.

When they finish, open a fifth tab. Paste all four outputs and run this:

I have four competitor research briefs. Synthesize them into one competitive landscape summary:

(1) Where are these competitors positioned relative to each other — what's the map?
(2) Where is there an uncontested or underserved space in this landscape?
(3) Which competitor should we worry about most and why?
(4) Given my company's positioning [describe it], where do we have the clearest angle of attack?

That fifth conversation is the orchestrator. The four research conversations were the workers. The synthesis is the output you actually use.

Total time: fifteen to twenty minutes. The same work done sequentially would be sixty to ninety minutes with the usual momentum loss between sessions.

Step 3: The First Result

Here’s what changes when you run this for the first time.

The parallel output isn’t just faster — it’s structurally different from sequential output. When you research competitors one at a time over an hour, your framing shifts as you go. By the time you get to competitor four, you’re unconsciously filtering what you notice based on what you already found in the first three. The analysis is path-dependent in a way that introduces bias you don’t notice.

Four simultaneous conversations run with the same prompt and the same framing. The starting point is identical. The synthesis conversation gets genuinely comparable inputs — four analyses built from the same brief, not from four sessions of incrementally shifting context.

This is what makes the orchestrator conversation useful rather than just convenient. When the fifth conversation synthesizes four consistent briefs, the gaps it surfaces are real gaps — not artifacts of the order you happened to research things in.

One pattern I’ve seen consistently: the synthesis step surfaces a competitive insight that none of the individual briefs flagged, because the insight only exists in the comparison. Competitor A and Competitor C are both going after the same adjacent segment. That’s not visible in either brief alone. It shows up immediately when someone reads all four at once.

Run this pattern once on a real project. The structural advantage becomes obvious in the first use.

Read more

Not wrong as in incorrect — wrong as in slow. They’re typing the same complex prompts over and over, hoping they remember the exact framing that worked last time, and losing 10–15 minutes per workflow because there’s no repeatability built into how they work.

Skills fix that. They’re the feature most Claude Code users don’t know exists — and once you build a few, you won’t work without them.

This guide walks you through exactly what Skills are, how to use the ones that ship with Claude Code, and how to build your own custom workflows triggered by a single slash command.

Step 1: What Skills Actually Are

A Skill is a markdown file that defines a reusable workflow. Store it in .claude/skills/ inside your project (or globally), and it becomes a slash command you can invoke from anywhere in Claude Code.

Type /commit and Claude doesn’t just write a commit message — it follows a specific workflow: checks staged changes, reads recent commit history to match your style, drafts a message, and creates the commit. That entire workflow is defined in a Skill file.

Here’s what a Skill file looks like:

---
name: review
description: Check content against house style guide and flag issues
---

You are reviewing content against the following style guide rules:
[your style guide here]

When invoked, ask for the content to review if not already provided.
Then check against each rule and return a structured report:
what passes, what flags, and specific suggested edits for each flag.

That’s it. A YAML header with a name and description, followed by whatever instructions you want Claude to execute. When you type /review in Claude Code, Claude loads those instructions and runs the workflow.

The .claude/skills/ directory is just a folder. Files in it become commands. The command name is the filename without the .md extension — so review.md becomes /review.

Skills can include:

• Multi-step workflow instructions

• Specific output formats Claude should produce

• Domain knowledge and context Claude should carry into the task

• Tool use patterns (read these files, run these commands, check this)

• Conditional logic — “if the content type is X, apply format Y”

• Parameters — /competitive-brief Salesforce passes “Salesforce” as an argument to the skill

They’re not macros. They’re not shortcuts. They’re saved playbooks — the same level of precision you’d give a new hire walking through a task for the first time, available on demand, every time.

Step 2: Your First Skill (Built-In)

Claude Code ships with several built-in Skills. The most useful one to understand first is /commit — not because it’s the most impressive, but because it demonstrates exactly what makes Skills valuable.

Before Skills: you’d manually stage your files, think about what changed, write a commit message that may or may not match your project’s conventions, and hope it was good enough.

With /commit: you type one command. Claude checks what’s staged, reads your recent commit history to match the style, drafts a message, and executes. The whole thing takes about 10 seconds instead of 2 minutes.

Try it now. Make a change to any file in a project, stage it with git add, then type /commit in Claude Code.

Watch what happens. Claude doesn’t just string words together — it follows the workflow defined in its Skills file. It checks git status, runs git diff, reads git log to see how you’ve written messages before, then drafts something consistent with your history.

That’s a Skill doing its job.

Step 3: Understanding the Mental Model

Here’s the shift that makes Skills click: stop thinking about prompts and start thinking about workflows.

Every repetitive task you do in Claude Code has a shape. A content review has the same steps every time: load the content, check against the rules, flag the issues, suggest edits. A competitive brief has the same structure every time: company overview, product positioning, pricing, strengths, weaknesses, how to beat them in a deal. A weekly summary pulls from the same sources every time: commit history, notes, decisions made.

The problem isn’t that Claude can’t do these things. The problem is that every time you describe the workflow from scratch, you’re introducing variability. You’ll forget a step. You’ll frame it slightly differently. You’ll get a slightly different result.

A Skill locks the workflow down. The instructions are the same every time. The output format is the same every time. The quality floor doesn’t move.

Think of it this way: you don’t explain to a good employee how to do the same task from scratch each time they do it. You document the process once, they follow it reliably. Skills are that documentation — except Claude executes it automatically every time you call it.

Built-in Skills give you the pattern. Custom Skills give you the leverage.

Read more

Not because they’re writing bad prompts. Because they’re spending half the conversation copying and pasting content that already lives somewhere — a Google Doc, a Notion page, a GitHub repo — just so Claude can read it.

MCP fixes that. And almost nobody outside of developer circles knows it exists.

Here’s what changes once you understand it: Claude stops being a tool you feed information and starts being a tool that goes and gets it.

Step 1: What MCP Actually Is (and Why It’s Not a Developer Thing)

MCP stands for Model Context Protocol. Anthropic released it as an open standard so that Claude — and any other AI — can connect to external tools and data sources in a consistent, predictable way.

Without MCP: Claude only knows what you paste into the chat window. Period.

With MCP: Claude can read a file from your Google Drive, pull up a Notion page, check the status of a GitHub issue, fetch a webpage — all without you touching a single thing. You just ask.

The connectors that make this work are called MCP servers. Each one handles a specific tool. Google Drive has an MCP server. Notion has one. GitHub has one. Slack has one. There are hundreds of them built already, and more appear weekly.

The part nobody tells business professionals: Claude.ai has several MCP integrations built directly into the interface. They call them Connectors. Zero technical setup. You connect your account, and Claude can access your data.

That’s where we’re starting — no command line, no config files, no developer required.

What you need before Step 2:

• A Claude.ai account (Pro or Team tier — Connectors are not available on the free plan)

• Access to at least one of: Google Drive, Notion, GitHub

Step 2: Connect Your First Tool (Google Drive or Notion)

Go to Claude.ai. In the left sidebar, look for Integrations or the connector settings — the exact label has shifted in recent UI updates, but it’s in the main navigation. As of early 2026, it lives under your account settings or the project settings panel.

If you’re using Google Drive:

1. Click the Google Drive connector

2. Authenticate with your Google account — standard OAuth flow, same as connecting any app

3. Grant the requested permissions (read access to Drive files)

4. That’s it

If you’re using Notion:

1. Click the Notion connector

2. Authenticate with your Notion workspace

3. Select which pages or databases Claude can access — I’d recommend starting broad and narrowing later if privacy is a concern

4. Done

Once connected, Claude can see those files. You don’t have to paste anything. You just reference them in your prompt.

One important thing to understand: Claude doesn’t browse your entire Drive proactively. It reads what you point it to. The connection enables access — you still direct it.

Step 3: Get Claude Reading One of Your Files

This is where it clicks.

Open a new conversation in Claude.ai. Make sure you’re in a project that has your connector enabled (if you set it up at the project level) or that you’ve enabled it at the account level.

Try one of these prompts exactly as written — just substitute your actual file or page name:

Google Drive:

“Read my file called [exact file name] in Google Drive and give me a one-paragraph summary of the main argument.”

Notion:

“Pull up my Notion page called [page title] and tell me the three most important decisions documented there.”

Watch what happens. Claude fetches the file, reads it, and responds — without you touching a single thing.

If you get an error, the most common fix is re-authenticating the connector. Occasionally the OAuth token expires and needs a refresh. Go back to connector settings, disconnect, reconnect.

Once that works, you’ve crossed the threshold. That’s MCP. That’s what the rest of this guide builds on.

Read more