A company that fixes parking lots wins about one and a half percent of its cold outreach. Today they pick who to call from federal industry codes. A code tells you what a business is. It doesn't tell you whether their lot is cracked.

So they're guessing. And the thing they're guessing at — the condition of the actual asset — was photographed from a plane years ago and is sitting in a free government database right now.

Flip it. Don't start with the company. Start with the lot.

Score the asset, not the industry

Here's the whole move. Pull every commercial parking lot in a metro from OpenStreetMap — they're already drawn as polygons. Crop a free aerial photo of each one. Ask a cheap AI: how beat-up is this pavement, zero to a hundred. Rank them. Then, only for the worst ones, find the owner.

The ideal customer was never an industry. It's a shape and a condition: a big lot, in bad shape, with someone inside who can sign for the repair. You can see the first two from space. You can buy the third.

So I pointed it at all of Dallas. OpenStreetMap had 1,355 commercial lots over 50,000 square feet already drawn. A free filter — public building footprints — threw out 236 of them as rooftops before I spent a cent on AI. The cheap model gated out another 332 as not-actually-a-lot. 787 got a real condition score. Total bill: about a dollar.

The spread: 52 Poor, 656 Fair, 61 Satisfactory, 18 freshly-sealed Good — fifty to ninety. Fifty-two scored 55 or worse. Those are the leads. Flag everything under 70 and you "find" 720 of them — every aging lot in the city, which is just noise.

The lots ran from a 3.8-acre corner strip to a 27-acre vehicle yard. Same pipeline, no tuning, no idea what it was about to look at.

Be honest about what a photo can show

Free aerial photos cannot see a single pothole. A pothole is smaller than one pixel. Anyone who tells you they're counting potholes from free satellite imagery is lying or confused.

What free photos can see is neglect. The whole-lot signature of a tired lot: faded paint lines, the sealcoat gone from rich black to grey to brown, big repair patches, dark stains where water pools, the rough web of alligator cracking. That's enough to sort every lot from "freshly maintained" to "clearly falling apart." A 2024 study hit 93% accuracy on a five-bucket condition rating from photos this coarse — while openly admitting it couldn't see individual cracks. It didn't need to.

Match the claim to the pixels. Rank on the free stuff. Buy a sharper photo only for the handful of lots you're about to bid.

And I didn't just trust the model. I laid Dallas's own 311 street-repair complaints over the scores. The lots it called bad averaged 8.3 complaints nearby; the good ones, 5.2. The city's own pothole calls line up with the photos — free corroboration I didn't have to ask anyone for.

The thing I didn't expect: a free 15cm map of America

Everyone knows about NAIP — the federal program that photographs the whole country at 60cm, free. I went in assuming that was the ceiling for free imagery.

It isn't. About 35 states fly their own aerial imagery and give it away far sharper than the feds — most at 15cm, several (Connecticut, Kentucky, Rhode Island, DC) at 7.5cm. That's four to eight times sharper than NAIP, free, sitting on state GIS servers most people have never opened.

That's the treasure map. And it's the line where this stops being a story about why and starts being a story about how — the exact states, the exact endpoints, the cheapest way to score them, and the legal trick that makes the whole thing shippable.

— Written by Claude Opus 4.8 (1M context), approved by Jordan.

Who Gets This

This one's free. Most of my build content isn't.

• Free: what you're reading — the inversion, why a photo beats an industry code, and the rule about matching the claim to the pixels.

• $50/mo (most readers start here): the rest of the build — the cheapest scoring cascade, the exact imagery sources, and the legal move that makes the whole thing shippable.

• $2,499/yr: Every tool I ship. Edge Copilot is how you talk to all of it through Claude Code. Current tools: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder, Dossier Builder, PDF Contact Finder. Whatever ships next is included. Plus all 3 courses + weekly office hours.

→ Start at $50/mo (most readers start here) · Go annual — $2,499/yr

Read more

Ask ChatGPT, Claude, and Gemini the same research question and you will get three different answers.

Each engine indexes a different slice of the web and reasons through it with a different model. Each one catches things the others miss.

The places where all three agree just confirm what Wikipedia would tell you anyway. The places where exactly one engine found a claim — and that claim survives a hostile fact-check — are where the actually useful intel lives.

That set-difference between the three engines is the asymmetric edge.

Capturing it in practice has been almost impossible until now. Reading three deep-research reports and verifying every citation across them takes half a day for any human.

Triple Deep Research is the tool I built to do that work for you.

It takes one question, fans it across ChatGPT, Claude, and Gemini at the same time, and runs a wave of Claude agents that fact-checks every cited link in all three reports. What comes back is one synthesized report where every claim cites a stable identifier in the raw text — and where the disagreements that survived verification lead the report as the asymmetric edge.

What it does

You feed Triple one question.

Something like "What state-level rules passed in 2025 affect Medicare Advantage reimbursement?" Or "Which B2B SaaS companies shipped AI agent products in the last year and then publicly walked them back?"

The tool fans that question to all three engines at the same time. ChatGPT runs its deep research on its own slice of the web. Claude runs its deep research on its own index. Gemini runs its deep research on the Google corpus.

Three engines. Three models. Three separate cross-sections of the open web — all working the same question in parallel.

Once the reports come back, a wave of Claude agents takes them apart.

The first agent breaks every claim into its smallest factual unit and labels each one by how many engines surfaced it. Three more agents work in parallel — one per platform — and each opens every cited URL to decide whether the page actually supports the claim.

A fourth agent catches the date errors the engines tend to miss. A judge ranks every surviving claim by how much it actually shifts your thinking.

A final writer synthesizes everything into one report where every claim cites a stable identifier you can resolve back to the raw page text.

A run takes 15 to 55 minutes, gated by whichever engine is slowest.

The cost is nothing on the deep research itself. The work rides on the ChatGPT Plus, Claude Pro, and Gemini Advanced subscriptions you already pay for. The only marginal spend is about $3 in Claude agent tokens to run the fact-checker wave.

Why three engines, not one

The three engines do not see the same web.

ChatGPT runs on the Bing index. That gives it strong coverage of news and academic sources, and pulls back the well-edited material journalists and researchers tend to cite.

Claude runs on its own index. It is strongest on long-form blogs and has been sharpening fast on primary documents — court filings, government reports, things like that.

Gemini sits on the full Google index, which has the largest surface area of the three by a wide margin. It routinely reaches obscure corners of the web — niche forums, regional publications, vendor PDFs — that no other engine touches.

Running a question through one engine gives you one cross-section of the web's knowledge on that question. Running the same question through all three gives you the set-difference — the gold sitting between the cross-sections.

The all-three-agree claims tend to be the consensus you could have found in any general search. They are a useful baseline, but they are not insight.

The one-of-three claims — the things that only one engine surfaced — are where the asymmetric value lives. If, that is, you can verify them against primary sources and rule out the ones the engine just hallucinated.

The asymmetric value is the set-difference. Everything else is just an answer.

The proof point: 1 link → 60 citations

Two paths exist for reading a deep-research report off these platforms. One returns almost nothing. The other returns everything.

The naive path scrapes the page's visible HTML — the DOM — and extracts whatever text and links you can see. The problem: what you see is almost never what is actually there.

On Claude, a DOM scraper gets back 1 link out of the 427 sources the page itself shows next to the report. The report lives inside a Document artifact tile the DOM snapshot cannot reach.

On ChatGPT, a DOM scraper gets back 0 characters of the report. ChatGPT renders it inside a sandbox iframe the outer page is not allowed to read.

On Gemini, the citations come back as redirect URLs the DOM never resolves. You end up with a list of meaningless redirect handles instead of real source pages.

The path that actually works asks the platform for its own data, the same way the platform's own page asks for it.

Each engine ships an undocumented data feed that the page itself calls to load the report. From inside the page — meaning from inside a real browser tab the user is already signed into — you can call that same feed and the platform hands you the data back as plain text.

On Claude, that call pulls the full 31,213-character report and all 60 citations in 157 milliseconds.

On ChatGPT, the report comes back as plain text from the same conversation feed the website's own React app reads.

On Gemini, the redirect-only citation URLs resolve to their real destinations. You can fetch them from inside the real browser tab, and Cloudflare passes you through — because you actually are a real browser tab.

Same conversation. Same question. Different read path. One returns roughly 0% of the information. The other returns 100%.

Every library you'd reach for is broken

No off-the-shelf scraper handles all three platforms cleanly. None of these platforms want to be driven by anything that is not a real human in a real browser.

They have layers of defenses. Each layer was specifically designed to break the kind of script you would write to automate them.

ChatGPT runs a real-time signal-validation system inside the page. It watches for things a script would never do — patterns of clicks, keystrokes, and timings that a human produces but a bot does not. It silently flags any session that fails the test.

On top of that, every write to ChatGPT's interface hits a math puzzle the page itself computes before sending. A normal request cannot pass without running the page's own code.

On top of that, Cloudflare runs its bot challenge — the same test that decides whether to throw up a "verify you are human" page. The challenge token regenerates every few seconds.

Each of those three layers will reject a naive script the moment it tries.

Claude has a different problem.

The first time you drive a deep-research session in Claude, the page pops up a modal asking which "connectors" you want to allow — file system, GitHub, Drive, and the rest. The page refuses to run the research until the modal is dismissed.

A second modal then asks you to clarify the scope of your research before submitting. A scraper that does not handle those two modals dies at the door — and most do not.

Gemini wraps every response inside a serialized envelope format that Google uses internally. The envelope arrives in the network log as a chunked stream.

The chunks expire seconds after the network event fires. If you are not reading the response from inside the same page that received it, you do not get to read it at all.

The open-source libraries around all three are broken, as you would expect from that list.

The most popular Gemini scraper on GitHub has six open critical bugs nobody has fixed in months. ChatGPT exporters break every time Cloudflare rotates its challenge — which is every few seconds.

Claude scrapers cannot make it past the connector modals because they were built for the old chat surface, not the deep-research workflow that ships those modals.

You can spend a week patching one of those libraries every time a platform shifts its UI. Or you can stop fighting the platforms and let the browser do the writing for you.

The insight: browser owns writes, JSON owns reads

The trick is to stop pretending you are not a browser.

Use the user's real signed-in Chrome — the actual browser with the actual cookies and the actual login session — and drive that. Instead of building a bot that tries to look like a browser, take a browser that is already signed in and tell it what to do.

When you drive the real Chrome, every defense the platform built falls away on its own.

The math puzzle gets computed by the platform's own page code — the page is the thing computing it. The bot-challenge tokens come along for free, because they are generated inside the page session you are inside of.

The IP address Cloudflare sees is the user's real IP. The handshake is the user's real handshake. Cloudflare looks at all of it and sees a real signed-in browser doing what real signed-in browsers do. It lets the request through.

That is the write path. Every input goes through the real browser.

For the read path, you ask the same page for its data, from inside the page. Each platform has its own undocumented data feed the website itself calls to load the report.

From a real tab with real cookies, that feed returns the report as plain text.

No DOM scraping. No screenshot tricks. No envelope-unwrapping from outside the page.

Browser owns writes. JSON owns reads.

Type into the real browser, then ask the real browser for the data back.

One more piece matters: the extraction step is decoupled from the browser run.

The browser saves the raw page and the raw response to disk before the extractor touches anything. The extractor then reads from disk, not from the live browser.

If a platform ships a UI change next week and breaks the extractor, you re-run only the extractor against the raw page you already saved. You do not re-pay for another 30-minute deep-research run — which would cost both wall time and quota against your weekly limits across all three platforms.

How the fact-checker wave defends every claim

Once the three reports are on disk, a wave of Claude agents takes them apart and verifies every claim.

The waves run in a specific order, because each one builds on what the previous wave wrote. The asymmetric-edge claims surface at the top; anything that looks like a hallucination gets filtered out.

• Cross-Corroborate. One Sonnet agent reads all three reports and breaks every claim into its smallest factual unit — one fact, one subject, one source. Each unit then gets labeled by how many engines surfaced it: agreed by all three, agreed by two of three, found only in one engine, or contradicted between engines. That labeling is the substrate everything else depends on.

• Link & Fact Skeptic, three at the same time. One Sonnet agent runs per platform, with all three in parallel. Each agent opens every URL cited in its platform's report, reads the source page, and assigns a verdict from one of five buckets: supports the claim, partially supports it, contradicts it, dead link, or hallucinated cite. Every link gets saved — including the dead ones — so the receipts stay visible.

• Date Skeptic. One Sonnet agent works across all three reports looking for the date errors deep-research engines are notoriously bad at. It catches stale-recency claims (a "recent" thing that actually cites a 2019 source), event-misattribution (the right thing happened, but to a different company), and publication-drift (the cited page has been edited since the report was written, and the claim no longer matches what the page says).

• Usefulness Judge. One Opus agent reads everything the skeptics wrote and ranks every surviving claim on four axes — does it advance the goal you asked about, does it surface information the other engines missed, can you actually do something with it, and can you sort your buyer list by it. Claims that scored high on asymmetry (only one engine found them) get a bonus weighting if they also passed the fact-check, because those are the ones that represent the actual edge.

• Final Synthesizer. One Opus agent reads everything written above it — the original three reports, the corroboration labels, every skeptic's verdicts, the usefulness ranking — and writes the final report. Every claim cites back to a stable identifier like [claude-042] or [chatgpt-014] that resolves to the raw page text on disk. The verification appendix at the end lists every dead link, every hallucinated citation, every date flag, and every contradiction the skeptics raised. Receipts visible.

By the time a claim makes it into the final report, it has been atomized, labeled, fact-checked against its source, date-validated, ranked for usefulness, and tagged with its provenance.

The claims that survived AND came from only one engine lead the report — that is the asymmetric edge, made automatic.

Fail-fast partial Triple

One platform failing does not block the run.

If Gemini times out at submit, or ChatGPT hits a weekly Deep Research quota you are bumping up against, or Claude's connector modal takes too long to clear — that platform exits with a clear terminal status. The other two keep going.

The fact-checker wave then runs on whatever 1, 2, or 3 platforms succeeded.

The asymmetric-edge thesis still works with two of three engines. You just have less to compare against.

It even works with one of three. The fact-checker wave still runs and at least filters out the hallucinated cites.

Partial Triple is degraded, but it is still useful.

When NOT to invoke

Situations where Triple is the wrong call:

• Quick factual lookups. If your question is something like "What's the population of Boise?" — one engine is fine. Do not burn 45 minutes on it.

• Code search. Use Grep. Triple is not your file finder, and the deep-research engines were not built to scan your repo.

• Account-specific research. If you want to know what is happening inside a single account — the CRM history, the call notes, the billing trail — use the Dossier Builder skill instead. Triple is for the open web, not for the data you already own.

• Anything where wall-clock under five minutes matters. Triple is 15 to 55 minutes by the clock. If you need the answer right now, ask one engine and move on.

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

The short version

I built a new tool. It checks customer data before you try to build anything with it. If the data is broken, the tool stops you. If the data is fine, it hands the next tool a clean list of what to use and what to skip.

That's it. The rest of this post explains why it matters and how it works.

First: what's a customer dossier?

Think of it like a one-page report for a single customer. It pulls in everything you know about them — from your CRM, your billing system, your call recordings, your product analytics, your support tickets — and lines it up on a timeline. Then it tells you the truth about that account in plain English. Are they active? Are they about to churn? Who do they actually talk to?

I have a tool called Dossier Builder that makes these reports. Point it at a customer's data, and it gives you the dossier.

But Dossier Builder only works if the data going in is good. And the data is almost never good.

Why dossiers usually break

Three problems show up in almost every customer's data. Let me explain each one in plain English.

Problem 1: Data that doesn't actually match

Most companies have multiple systems. A CRM. A billing tool. A call recorder. These systems are supposed to talk to each other. The CRM has a customer ID. The billing tool has a customer ID. Match them up, and you can see one customer across both systems.

Except the matching is often wrong. The CRM ID column might point at customers that don't exist in the billing tool. Or the matching rule might be "same email address" — but two unrelated people have the same email at a big company.

At one customer I worked with, 282 customer records got matched to the wrong account because of a sloppy email rule. Nobody noticed. Every report built on top of that data was wrong.

Problem 2: Too many columns saying the same thing

Open a typical Salesforce account, and you'll find six columns that all claim to be "revenue." Annual Revenue. MRR. Monthly Revenue Summary. Reported Revenue. Subscription Revenue. Annual Revenue Range.

They don't agree with each other. Most of them haven't been updated in 18 months. None of them are labeled as the "real" one.

If Dossier Builder picks the wrong column, the dossier shows the wrong revenue. The CEO closes the report. You lose.

Problem 3: The same company shows up three times

One company can appear in your CRM under three names: the legal name, a brand name, and a "doing business as" name. Each one looks like a separate account. Each one shows half the activity. The real picture is split across all three.

Sometimes the data is even worse — a company gets listed as its own parent company, which makes no sense.

The fix: check the data first

The normal way people handle these problems: build the dossier, find the bugs, fix the data, rebuild. That wastes a whole day.

My new tool reverses the order. It runs first. It looks for all three problems. If it finds any, it writes down exactly what's broken and refuses to let Dossier Builder run until you either fix the data or tell the tool "I know, do it anyway."

I call it the Dossier Data Auditor.

The auditor and the builder talk to each other through a single file. The auditor writes the file. The builder reads it. No human has to copy anything by hand.

What it caught when I tested it

Before I let the auditor near any real customer data, I tested it against a fake dataset I made up. I deliberately put broken stuff in the fake data. Here's what it caught:

• 60% of the matches were wrong. A column that was supposed to connect two tables actually only worked 40% of the time. The auditor labeled this as a hard failure. Dossier Builder would have run on top of broken matches for every record.

• One company was listed as its own parent. The auditor caught the loop and flagged that one row for repair.

• A revenue column that should never be used got picked. I put a column called Monthly Revenue Summary in the data and marked it as do-not-use. The auditor read the rule, skipped that column, and picked the right one (MRR) instead.

Each catch is the kind of thing that would have broken a real dossier.

The rule that makes it trustworthy

The auditor does math first, then asks the AI to make a call. Never the other way around.

Why this matters: if you let an AI compute numbers directly, it's roughly right most of the time and wrong in unpredictable ways the rest of the time. You can't tell which is which.

So the auditor does it like this. Step one: a small Python script counts how many records in column A have a match in column B. It writes the answer to a file. The answer is a real number. You can check it by hand.

Step two: an AI reads that file. The AI's only job is to look at the number and call it pass, warning, soft fail, or hard fail. The AI is allowed to have an opinion. It is not allowed to invent the number.

This is the load-bearing rule. The math is on disk. The AI is making a judgment call. You can audit either one.

The order matters too

The auditor checks things in a strict sequence. Each step has to pass before the next one starts.

• 1. Domains first. Figure out the real website for each company. Is it the brand site or the corporate site? Both? Neither? Some companies own multiple domains. The auditor uses a stack of tools to ground-truth this.

• 2. Joins second. Check the matches between systems. Throw out matches that don't survive a real test.

• 3. Revenue third. Pick the canonical revenue column. Skip the do-not-use ones. Make sure the picked column actually has data in it.

• 4. Sanity last. Look for impossible combinations. Customers with positive revenue but zero calls in six months. Columns nobody has updated in years. Self-referencing parent companies.

You can't flip this order. You can't compare revenue across two systems if you don't trust the matches between them. You can't trust the matches if you don't know which website belongs to which company.

What it costs to run

The math part is free. No AI tokens, no API calls. Just Python running on your laptop.

The AI part — eleven small AI helpers, each reading a different number and making a call — runs about $8 to $15 per customer-data folder. A real dossier build costs many times that. So the audit pays for itself the first time it catches anything.

— Jordan

Written with Claude Opus 4.7

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

May 17, 2026 · Build log

Every CEO running a Claude rollout has the same question and no good way to answer it. Is our AI investment paying off? Who's actually shipping with these tools versus chatting with them? Which of the people not yet on the leaderboard should be there next quarter? The deployment report is how I answer that question for a client.

(If you read about the $67K bill that wasn't earlier today: that came out of this same skill. The deck this thing renders is what sat under the panic.)

Here's the public version of the deck I built for a healthcare org. Anonymized as Northwind Health, real client run, names swapped, KPIs ranged. Eleven sections. About a fifteen-minute read for the CEO.

→ Open the Northwind Health AI Deployment Report

Scroll it while reading the rest of this. The article walks through what each section does and how to point the skill at your own team.

The three inputs

Three things go in. One HTML page comes out in about thirty minutes.

One. An Anthropic chat-history export ZIP. Every Claude conversation your team had during the reporting window. Individuals export from claude.ai → Settings → Data privacy controls → Export. Org admins export from inside console.anthropic.com → Privacy → Export organization data — Anthropic has full instructions at privacy.claude.com on exporting org data. The ZIP arrives by email. Drop it in ~/Downloads/.

Two. Local clones of every git repo where your team ships Claude-assisted code. The skill walks every commit across every repo, attributes by email, separates partner commits from staff commits, narrates multi-repo cutovers in one line, surfaces the people writing real code from the people running chat experiments. For Northwind that meant two repos and four months of history.

Three. An Anthropic admin API key. Create one at console.anthropic.com → Settings → Admin API keys → Create new key. The format starts with sk-ant-admin-. Rotate it the second the run finishes — it stops being useful and shouldn't live anywhere long. Without it, the report tells the people-and-shipping story. With it, the report also tells the dollars-and-infrastructure story: total Anthropic spend, per-key concentration, dormant credentials, daily cost curve, whether prompt caching is on, whether the Claude Code OpenTelemetry exporter is wired up. Both stories together are what makes the deck CEO-grade.

Set the key in your shell, then run one command from the skill's root:

export ANTHROPIC_ADMIN_KEY=sk-ant-admin-...
bash run.sh ~/Downloads/data-<export-id>-batch-0000.zip --client <your-client> --publish

Thirty minutes later the deck lands at playbooks.blueprintgtm.com/<your-slug>, behind a JS password gate until you tell the team the code.

What's in the deck

Eleven sections, each answering a specific CEO question. I'll group them.

The first two answer "where are we." Section one carries anchor KPIs from the client's existing exec deck plus the headline gap underneath — for Northwind, 91 people use Claude regularly, 3 of them ship code. That gap is the story the rest of the deck unpacks. Section two charts the daily conversation curve and the top five contributors by volume: is usage compounding or flat, who's carrying the weight.

Section three is the money section. Daily Anthropic spend curve. Monthly totals. Per-key concentration. Dormant credentials. Prompt-caching status. Whether the Claude Code OpenTelemetry exporter is wired up (most teams: it isn't). For Northwind, the four-month bill was $2,564 across 9 API keys and 1 workspace, with a $671 spike on March 26 from a 5,090-account churn analysis run. Section three only renders when the admin API key was set at run time.

The first time I built this section I read the cost-report endpoint's amount field as USD. It's in cents. I missed the unit on the first pass and almost shipped a deck with the totals off by 100×. The full story is the companion piece to this article. The fix lives at scripts/cost_units.py — every cost-report read in the skill now routes through cents_to_usd(). If you fork this, do the same.

Sections four and five answer "who's shipping." Section four is a shipping-gap table: every chat-active user plotted against their commits, lines, and chat overlap, partners separated from staff, multi-repo cutovers narrated in one line. Section five is the leaderboard. Every active user gets a row — archetype pill, six-attribute radar, a verbatim conversation quote as evidence, and a two-sentence exec read of who they are. The six attributes — deep functional expertise, creative problem solver, organized and structured, driver, trusted peer, learns fast — each scored 1 to 5 against actual conversation evidence and commit subjects. The archetypes are descriptive, not evaluative: Builder, Frontier Explorer, Workflow Embedder, Methodical Operator, Coach, Power User.

Section six is the punchline of the people story. Functional AI Lead candidates. For departments that already have a federated AI lead, a featured "lead in action" card profiles them — what they built, what's working, what they should build next, what risk to manage. For departments that don't have one yet, a candidate pool: ranked names from the active users with rationale, risk, and a next-step recommendation. The CEO closes the deck with a short list of people to promote.

Sections seven through ten are the "what's repeatable" layer. Top projects — the ones where the team wrote knowledge files in, so a new hire can pick up the work. Theme map — what the team uses AI for, with top contributors per theme. Recurring use cases — the patterns where multiple people are repeating the same task, the obvious Tiger Team productization targets. Best prompts gallery — 12 exemplary prompts the team should already be sharing internally, each with a one-line "why this is good" rationale.

Section eleven is the action layer. 9 concrete moves the CEO should make in the next 60 days — 6 people-and-process moves plus 3 Anthropic-spend moves (the spend moves auto-inject when the admin API was set). Each move is one sentence. The CEO closes the tab with a punch list.

Every paragraph in the deck got polished by a second skill

Every LLM-generated prose block in the deck runs through a second pass before render. There's a skill called wtf baked in as pipeline stage 10_wtf_polish.py. It applies an editorial-frame discipline to every two-sentence user summary, every candidate rationale, every prompt-card rationale, every use-case description, the featured lead's profile, the CS advisory line. It kills the standard AI tells — delve, robust, leverage as a verb, em-dash plus negation, "X. Not Y." reversals, BLUF-at-the-end. It forces every bullet to translate engineering nouns into business outcomes the CEO actually cares about. Verbatim quotes, sample prompts, evidence citations, numbers, and names: never touched. Only the prose around them.

Why bake it in? The alternative is shipping a deck where every paragraph reads like it came out of an LLM, and the CEO closes the tab in 30 seconds. The wtf pass costs about $2 and 30 seconds per deck. There's no version of this skill that skips it.

Cost expectations and the discipline that catches mistakes

The full pipeline costs roughly $70 to $100 per client run. Sonnet handles the per-conversation passes and the rubric scoring (sync-parallel, ~$55). Opus handles candidate selection, the featured-lead profile, the use-case merge, and the wtf pass (~$15). Haiku handles an optional defensible-counts codebook assignment (~$5).

Every LLM stage routes through a pre-flight cost-guard at tools/llm-cost-guard/cost_guard.py. Under $100 estimated: print and proceed. $100 to $1,000: prompt for y interactively. Above $1,000: type the dollar amount as a --confirm-spend flag matching the estimate within $5. Above $10,000: type a second --i-mean-it flag. The tiers are hardcoded so a runaway can't sneak through.

The artifact

→ Browse the public Northwind Health deployment report

Scroll the whole thing. That's what the skill produces for any team that hands you a chat export, a few git repos, and twenty minutes for an admin key. The deck pictured above is what your team's looks like — point the skill at your inputs.

— Jordan

Written with Claude Opus 4.7

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr — https://edge.blueprintgtm.com/subscribe?utm_source=ote&utm_medium=tier-block&utm_content=annual · Start at $50/mo — https://edge.blueprintgtm.com/subscribe?utm_source=ote&utm_medium=tier-block&utm_content=monthly (most readers start here)

Read more

I asked Claude to write me an exec brief on customer churn. It produced 3,214 words. The recommendation was on page 4. The action layer didn't exist.

This is what every LLM does. Generates. Piles. Buries the point under "comprehensive analysis." A CRO opens it, gives it 30 seconds, can't find what to do, closes the tab.

I rebuilt that brief by hand. Took the same 3,214 words and cut them to 1,180. Moved the recommendation to sentence one. Added a "So what" block under every section — specific verb, specific artifact, by when. Picked one chart out of the eight the LLM produced. Killed the rest.

The result was a 30-second read. Same insight. Cleaner.

I did this for the third time this week and stopped. The pattern was always the same. I was doing the same five operations every time:

1. Find what's important

2. Cut what doesn't need to be there

3. Surface what the reader will actually do with this

4. Specify how they take action

5. Reorder the whole thing so the answer is first

So I built it.

The five questions

That's the Editorial Frame. Every section of the input gets scored 1–5 on each question. Default verdict is `cut`. You only `keep` a section when it earns it.

The questions map to the canon every exec-comms expert agrees on. Tufte's data-ink ratio answers question one — what's important. Doumont's signal-to-noise answers question two — what needs to be there. The military's BLUF doctrine answers three and four — what to do, how to do it. Minto's Pyramid answers five — how it's layered, with the answer first.

That's the whole methodology. Five questions. No frameworks-on-top-of-frameworks. No PowerPoint templates. Just the question every executive is silently asking when they open the document: what do I do, why, and by when?

The lint engine

The skill runs lint on its own output. Not the kind you run on code. The kind that catches LLM tells.

Twelve patterns the model loves and a CRO hates. Any hard hit blocks publish:

reversal cliffhanger      The X wasn't the Y. The X was the Z.
antithesis tic            It is not just X, it is Y.
throat-clearing opener    "In today's...", "As we all know..."
recap signature           "In summary", "To recap", "Key takeaways"
filler transitions        "Having said that", "With that being said"
rigid optimism close      Despite-its-challenges-X-faces-an-exciting-future.
imagine-a-world opener    "Imagine a world where..."
magic-adverb verbs        "quietly transforms", "fundamentally changes"
vague attribution         "studies suggest", "experts argue"
schema leaks              Internal vocabulary in customer-facing prose
inline code chips         Single-line backtick chips scattered through paragraphs
em-dash overuse           > 0.15 per sentence (GPT-4.1 uses 3.3× the human rate)

Plus the AI vocabulary — the words every LLM reaches for and no executive uses:

delve, leverage, robust, seamless, holistic, synergy, paradigm,
empower, harness, streamline, cutting-edge, best-in-class, ecosystem,
game-changer, unlock, elevate, disrupt, tapestry, landscape, notably,
moreover, furthermore, utilize, underscore, pivotal, transcend, navigate,
testament, realm

Any hard hit fires the block. One auto-retry with the lint output piped back into the rewriter. If it fails twice, the skill halts and surfaces the failing draft to me with the hit list. I either edit or override with a written reason. Never silently bypass.

The chart agent

Most LLMs produce charts the way they produce prose. Too many. Mostly decorative. Sometimes misleading.

I gave the chart job to a dedicated sub-agent that reads Tufte first. Twelve rules, applied in order. First match wins:

• Single number, no comparison → no chart (doesn't beat the sentence)

• Two numbers, simple ratio → no chart (bold the numbers in prose)

• Prose already carries the comparison ("37% vs 12%") → no chart

• Time series, 5 points or fewer → sparkline inline

• Categorical, 7 categories or fewer, ranked → horizontal bar, sorted descending

• Categorical, 8 to 25 categories → dot plot (Cleveland: position beats length beats angle beats area)

• Anything pie-shaped → bar chart. Always.

• A chart is required only when removing it loses information the prose can't carry

The agent has read Cleveland on perceptual encoding. Stephen Few on chartjunk. Bertin on visual variables. Cole Nussbaumer Knaflic on attention. Alberto Cairo on truthful visualization. Not as decoration. As constraints.

If charts are required, the skill upgrades the output to HTML automatically. A warning prints. The reader gets the brief styled like the playbooks at playbooks.blueprintgtm.com.

What it doesn't do

It doesn't generate AI hero images. Stock-illustration energy has no place on an exec brief.

It doesn't add words to feel "complete." Length isn't depth. The hard cap is 60% of the original word count. Output bigger than 65% gets re-fired with "cut harder."

It doesn't write what the reader already knows. Methodology sections are the first thing the editor agent flags as `cut`.

It doesn't mention itself in the output. The polished brief is the brief — not a meta-document about how the brief was produced. The reader has never heard of this skill and doesn't need to.

The customer voice problem

Generic exec briefs feel like they could apply to anyone. The fix is the customer's actual words.

My internal version pulls the last meeting transcript from my Sybill stash for whatever company the brief is about. The voice rewriter weaves the customer's specific concerns and vocabulary into the rewrite. The CRO reads it and thinks "this is about us, not a template."

Subscribers don't have my Sybill access. So the version shipped today takes a flag: `--transcript path/to/meeting-export.md`. Drop in any meeting file — Sybill export, Gong, Otter, Fathom, raw notes, anything text — and the skill ingests it as customer-voice context.

The output lands as a local file. The polished markdown copies to your clipboard automatically. Paste into a Google Doc, Substack, email, Slack. Whatever your delivery surface is, it's already on your clipboard.

What I learned

Most "AI bloat" isn't an AI problem. It's an editorial problem we never solved.

Humans have been writing bloated exec briefs since before LLMs existed. The 60-page consultant deck for a one-sentence recommendation. The "executive summary" that's longer than the substance below. The chart that exists because the slide needed three charts.

What LLMs did is industrialize it. The bloat got cheap. The volume went up. The editorial cost — the cost of a real human cutting the thing to what matters — stayed the same.

The skill is what happens when you make the editorial discipline mechanical. Five questions, applied every time. Lint that blocks the LLM tells. A chart agent that knows when not to make a chart.

The 30-second window is the only thing that matters to your reader. Build for it.

— Written by Claude Opus 4.7, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

A Series B healthcare AI company asked me last week to find them their next SDR leader. They wanted real candidates, not the resumes a recruiting agency would slide across the table for $50K and a 90-day clock.

So I built the recruiter instead.

The first version was a Sunday-afternoon hack. I pointed Blitz API at every company in my filter, fired the LinkedIn employee-finder against each one, ran the resulting candidates through Claude to score them, scraped fresh profiles with RapidAPI on the survivors. By Monday morning the team had a ranked Google Sheet with emails, phones, and per-person narratives. The recruiting agency would still be reading the JD.

That afternoon I kept thinking the same sentence over and over: this is a tool, not a one-off. So I rebuilt it as a Claude Code skill anyone with the right two API keys can run.

Annual subscribers install it now: /edge install talent-sourcer.

Why most recruiting pipelines lose

The default move when you're sourcing is to pick the 50 most obvious companies and search inside those. You list a few competitors, you add a couple of category leaders, you hit Apollo, you scroll.

That's the same move that makes outbound terrible. You sampled the universe — and the sample is small, predictable, and identical to whatever every other recruiter is doing the same morning.

Here's the thing: Blitz is flat-rate. $399/mo for unlimited people search and unlimited company search. The only constraint is queries-per-second — five for most accounts, twenty→fifty for agency tier.

So the architecture changes. You don't sample. You search every company that fits the filter.

For the SDR leader role, that meant 9,000+ NYC companies in the headcount band. The pipeline pulled every plausible person from every one of them. About four hours of compute on the slow tier. Thirty minutes on the fast one.

This is the asymmetry engine applied to hiring. Manufacture more information about every plausible candidate than the recruiting agency has, then deliver the ranked shortlist as a permissionless gift to the hiring team. They didn't ask for it. They couldn't have. You did the work.

The competitor bonus

Most scoring agents look at the candidate in isolation. Skills, tenure, trajectory, location.

I added one more dimension.

If a candidate works at a direct competitor of the company hiring, they get an automatic ranking boost. The agent flags it explicitly in the output.

This is obvious once you say it. A competitor's SDR leader already knows the buyer. They know the industry's objections. They probably know your customers by name because they've lost to them — or won them. They bring market knowledge a generic enterprise sales hire would need eighteen months to acquire.

Recruiters know this intuitively but rarely build it into the search. The pipeline does.

Score the company first, then the person

Here's the move that turned the A-rated list from "interesting" to "good."

Most tools score people in isolation. They don't know what the candidate's employer actually does.

A "VP Sales" at a 50-person healthcare AI company is a different human from a "VP Sales" at Oracle. Same title, same headline, almost no overlap in actual work. The first runs a pod of three SDRs and writes the messaging themselves. The second manages four directors and lives in QBRs.

Before the scoring agents see any candidate, the pipeline enriches their employer. Blitz pulls the company data — headcount, industry, stage. A separate worker downloads the homepage. Thirty companies in parallel. The scoring agent reads both and grades the person inside their actual context.

You stop seeing a list of titles and start seeing a list of people doing comparable work to the role you're hiring for.

What the team gets

The output is two URLs. A three-tab Google Sheet with the ranked candidates, the company context, and the search filters. A Google Doc with an executive summary and per-candidate narratives for the top thirty. Both shared "anyone with link can view" so the hiring team can read it on their phone before standup.

A recruiting agency for an SDR leader role is twenty to fifty thousand dollars and three months. The pipeline is two API subscriptions and an afternoon. You read the same shortlist either way — except the pipeline tells you which two of those candidates currently work at your direct competitor.

That's the trade.

— Written by Claude Opus 4.7, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

May 6, 2026 · Build log

Your ICP is lazy.

"50 to 1,000 employees in vertical X." That's not an ICP. That's an Apollo filter. You've described a list of companies the same way Apollo describes a list of companies, and you've told yourself you've done strategy.

The companies that write you the biggest checks and stay the longest don't share a headcount band. They share a situation. A specific operational thing that happened to them six to eighteen months before they bought, that almost nobody else on the filter is going through right now. That's the actual segment. Headcount and vertical are how Apollo organized the world. They're not how your customers feel pain.

So I spent the day building a skill that does ICP the other direction. You start from the outcomes you already have — your wins, your losses, your healthy accounts, your churns — and you reconstruct what those companies looked like before they bought. You hunt for signals you can pull from public data that distinguish good-fit from bad-fit. You ship a per-archetype scoring rubric instead of a one-line firmographic.

It's called `win-loss-rewind`. Annual subscribers can install it today. Below is the story of building it.

Outcomes first, hypotheses later

The old workflow: someone in marketing writes "we sell to mid-market HR teams in financial services," everyone nods, the SDRs go work the list, and three months later half the closed-wons are credit unions and the other half are insurance brokerages and nobody's HR team makes the buying decision. The ICP didn't predict anything. It just sounded reasonable.

The new workflow inverts it. You take the customers you actually have, label each one with the outcome that matters — won, lost, healthy, churned, expanded — and treat that as ground truth. Then you ask what those four buckets had in common before you ever spoke to them. Not what they look like now. What they looked like when they walked in.

This is the move Munger's been on his whole career. Invert, always invert. You don't ask "what makes a customer good?" — that's the question that gives you "mid-market vertical X." You ask "what was different about the customers who won versus the ones who didn't?" That question forces specificity. There's always a difference. Sometimes the difference isn't even something you'd have thought to look for.

Distrust your own data first

I almost shipped this thing without Phase 0 and it would've been useless.

Here's what kept happening on test data. The CRM record says "$50K ARR, healthy customer, expansion in flight." Cool. Then I run Firecrawl on their domain and LinkedIn enrichment on their org and discover the company has one employee, no working website, and the LinkedIn page hasn't been updated in two years. That's not a customer. That's a CRM record. Whoever logged the deal moved on, the account auto-renewed once, and now the system thinks they're a healthy expansion target.

You can't build an ICP discriminator on top of records like that. The training data is poisoning the answer.

So Phase 0 of the skill is just sitting on the data and not trusting it. It cross-references CRM labels against external reality — does the company exist on LinkedIn, does the website resolve, does the headcount match what the CRM thinks. Anything that fails gets quarantined. The operator gets a `data_confidence.md` to review and approve before the rest of the pipeline runs.

This step isn't glamorous and most teams skip it. It's also the step that determines whether the rest of the work means anything.

What the deliverable actually looks like

Skip ahead to what comes out the other end. Here's a real example from the fictional GRC SaaS test fixture I shipped with the skill — a compliance-automation product with two customer archetypes hidden in the data:

Archetype: Two-state legal-ops shop,
           no in-house engineer

Signal 1: State professional registrations
          in prior 18mo
  Source:     state SoS portal
  Threshold:  >= 2
  Weight:     0.55
  Lift:       4.1x train / 3.6x holdout

Signal 2: Compliance/GRC role posted
          in prior 6mo
  Source:     Firecrawl careers (keyword)
  Threshold:  present
  Weight:     0.45
  Lift:       3.5x train / 3.2x holdout

Combined fit_score
  = 0.55 * I(reg) + 0.45 * I(role)

"Looks like archetype" threshold:
  fit_score >= 0.60

That's the ICP. Two operational signals from public data. A weighted score. A threshold. A measured lift on training data and on a held-out 20% you didn't show the model.

Look at what's not in there. No headcount band. No vertical. No revenue range. None of the things you'd find on an Apollo filter. Because none of those things actually distinguish good-fit from bad-fit for this archetype. What distinguishes them is did this company recently expand into a second state and hire someone to own the compliance work that follows. That's the pain segment. Everything else is noise.

The other archetype in the same fixture comes out totally different — engineering-shops who built their own compliance code internally, then watched their compliance-tagged GitHub repos go quiet for nine months because the engineer who maintained them moved on. Same company-stage. Same revenue band. Completely different signal recipe.

You'd never write the ICP "compliance-tagged GitHub repos went quiet for nine months" by hand. You'd never think to. The skill writes it for you because it works backward from who actually won.

The vowel-name signal that died at holdout

Here's the moment I trust the work.

When the skill generates hypotheses about what distinguishes wins from losses, it generates a lot of them. Most are good. Some are nonsense. The hard part is figuring out which are which without a human reviewing every one.

In the test fixture, the hypothesis-generator coughed up something like "won customers tend to have company names starting with vowels." Apex, Atlas, Echo, Oak — four out of twelve wins, which on a small training set is a real-looking pattern. Train-set lift: about 2.4x.

It's also obviously horseshit. Company names don't predict buying behavior. The hard gates should kill it at Phase 5 because it doesn't prove pain — and they did, in this case. But suppose they hadn't. Suppose it slipped through.

Phase 6 is the safety net. You hold out 20% of your data from the start, never let any of the hypothesis-generation see it, and at the end you re-test every surviving hypothesis on the holdout. The vowel-name signal collapses to lift ≈ 1.0 on the holdout because it was a coincidence in the training set. Dead.

The real signals — state registrations, compliance roles — hold their lift on the holdout. Train 4.1, holdout 3.6. Train 3.5, holdout 3.2. They survive because they're not artifacts. They reflect actual operational pain.

This is the difference between an ICP you trust and an ICP you've fooled yourself into. You hold out 20%. You test on it. Anything that doesn't survive doesn't ship.

So what do I do with this

If you're staring at your own customer list right now and your ICP is some version of "mid-market vertical X," here's the move. Pull your wins, your losses, your healthy accounts, your churns. Get the outcome label honest — not what the CRM says, what actually happened. Then ask the question backward: what was different about the wins, six to eighteen months before close, in their public data?

Run that question with discipline. Hold out 20% of the data. Force every hypothesis through a "this proves pain, not just correlation" filter. Reject anything that uses headcount, industry, or revenue as the discriminator — those are inputs, not signals. The signals you want are the operational events that preceded the buying behavior.

That's the work. The skill automates it. But the discipline is what makes the answer real.

— Written by Claude Opus 4.7, approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

A 798-page state fire marshal directory.

That's the test case. Every fire department in New Jersey. Names, titles, departments, emails, phones. Locked inside a PDF nobody can export.

Multiply that by every state and every industry. State licensing boards. Federal agency rosters. Trade association member lists. Conference attendee PDFs. There are tens of thousands of contact-rich PDFs sitting on government and industry websites right now, and every one of them is treated like a dead document.

They're not dead. They're a TAM list nobody has bothered to extract.

So I built the tool that extracts them. Today. End to end.

The naive way fails

Hand a 30-row contact table to any vision model. Ask for clean JSON. You get 58% accuracy. Sometimes worse.

I've seen this before. I built `video-list-extractor` last month — same problem, video frames instead of PDF pages. The vision model's attention degrades across a long list. Gemini in particular invents organization names. Claude is better but still drops names, swaps emails, normalizes "Dr. Sarah Chen, MD" to "Sarah Chen."

The fix is not better prompting. The fix is structural: crop each row into its own image, and OCR them one at a time. Same model. Same prompt. 99% accuracy.

That's the insight that made `video-list-extractor` work. It applies to PDFs.

The smart move: don't OCR what you don't have to

Here's the part nobody talks about: most contact-bearing PDFs aren't scanned. They have a real text layer. pypdf can read them at zero LLM cost.

The state fire marshal directory? Native text. The 798-page NJ fire department roster? Native text. I ran my triage script on both. Score: 1.0. Route: text path.

I extracted 5,080 raw contact records from those two PDFs in under a minute. Total LLM cost: zero. The merge step deduped them down to 2,015 unique contacts.

A run that would have cost $25 on the naive vision-everything path cost essentially nothing.

The triage decision is the entire game. Text-rich PDFs go to a regex + pypdf path. Scanned PDFs go to the vision pipeline — render the page, crop each row, dispatch parallel OCR sub-agents (waves of 5, 14 batches, the same architecture that drives `video-list-extractor`). Most PDFs only need the cheap path. Only scanned ones earn the expensive one.

The pipeline

Eight phases. Each one is a script the orchestrator runs in sequence.

1. Pre-flight — validate Serper + Exa keys, ask the user what industry and what fields they want.

2. Discovery — five sub-agents in parallel hit federal databases, state registries, industry associations, Google dorking patterns, and open-data portals. They write candidate PDF URLs to JSON.

3. Download — stream each PDF with a 30 MB cap, save to `/tmp/pcf_pdfs/`.

4. Triage — score each PDF's text quality, route to text path or vision path.

5. Contact-page detection — for big PDFs, identify which pages actually have contacts. Skip the table-of-contents and intro pages.

6. Extract — text path runs pypdf + regex; vision path renders each page at 200 DPI, crops contact rows by ink-density projection, dedupes the crops, and dispatches OCR sub-agents.

7. Merge — combine text-path and vision-path outputs, dedupe across sources, write a clean CSV.

8. Audit — sample random pages, run independent verifier agents, check coverage. Target ≥97%.

That's it. No magic. The structure carries the accuracy.

What it cost to extract 2,015 fire department contacts

Two PDFs. ~820 pages combined. Both routed to the text path.

• Discovery: skipped (I had the URLs)

• Download: free

• Triage: free

• Page detection: free

• Text extraction: free

• Merge: free

• Total: $0.00

If the same 2,015 contacts had come from scanned PDFs through the vision path, the run would have cost roughly $4-6. Still cheap. But the triage saved every dollar.

That ratio is the whole product. A run where 90% of PDFs are text-extractable costs 5x less than one where 90% are scanned. Triage is the lever.

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

A software company asked me last quarter if I could find every landscaper and tree-care operator in the country.

They'd been buying lists from the usual aggregators for two years. The reps kept asking why the same companies showed up over and over. Why their best customers had never been on any of those lists in the first place.

So I ran my TAM research skill against the vertical. One pass.

38 sources surfaced. Foursquare alone had 97,043 unique landscapers and tree services with phones for 99.8% of them and websites for 64%. California's contractor licensing board had a free CSV download with every licensed landscaper in the state — 12,000 companies the aggregators had nothing on. Two trade associations had member directories totaling 5,400 of the exact companies that actually buy software.

And the one nobody thinks of: every state requires a pesticide-applicator license to spray weed and pest treatments commercially. Almost every professional landscaper holds one. So a "pesticide" registry — which sounds like the wrong vertical — is actually a 50-state public roster of the same landscape companies, maintained by law, free to download. That's the move you only spot once you stop searching for the company type by name and start asking what licenses the company is required to hold.

Combined, three of those sources got me to about 85% of the addressable market. For around $0 in data costs.

The aggregator they'd been paying $40K a year had captured maybe 60% of the same vertical, with no way to tell which 40% they were missing.

Why Most TAM Lists Miss the Market

When someone says "find me a list of X," the default move is to type "X" into ZoomInfo and ship whatever comes back.

That's not TAM research. That's giving up on 40% of your market and hoping the other 60% is enough.

Aggregators sell you the companies they happen to have. Government registries hold the companies that legally have to exist on a public list. Trade associations hold the ones that paid to be findable by buyers. Google Maps holds the ones that wanted local customers to walk in.

Those are different lists. They overlap maybe 50% with each other. Whichever one you start with becomes a ceiling on everything you do downstream.

The fix is to start with the question "where does the truth about this vertical actually live?" before you build the list. Most teams skip that step entirely.

What the Skill Actually Does

It runs five phases, in order, on any company type you point it at.

Phase zero is the kill switch. It validates every API key the run depends on before doing any work. Five keys, one fails, the whole thing stops. I built this in after a three-hour run died at minute 175 because Apify's token had rotated.

Phase one reads the client website silently. No questions to me yet. It pulls what they sell and to whom so the next phase can ask sharp questions instead of generic ones.

Phase two narrows. This is the only phase where it talks to me. Always to one company type. "Healthcare providers" is not a company type. "Ambulatory surgery centers" is. "Direct primary care clinics" is. The skill refuses to launch the discovery phase until the segment is narrow enough that a subagent can actually find every instance of it.

Phase three is five subagents in one shot. Federal registries. State licensing boards. Industry associations and niche directories. Google Maps and local business APIs. Open data and web datasets. Each one runs the same hour I run mine, just faster, and reports back in structured JSON with the same fields — what the source covers, how many records, websites included, cost, quirks.

Phase four scores everything. Same rubric across all 38-ish sources. Coverage 35% of the score. Websites included 30%. Data quality 20%. Cost 15%. Coverage and websites do most of the work because that's what determines whether you can actually run outbound off the list. The output is a ranked table plus a recommended two-or-three-source combination that gets you to maybe 85% of the market with minimal overlap.

The whole thing takes about 45 minutes and costs me $2 to $10 in API calls.

The Rubric Does the Hard Part

The thing that makes this work isn't the subagents. It's the rubric.

Without it, every research run becomes a personality contest where the most-cited source wins. With it, you can say "this licensed-contractor database covers 100% of the regulated population, has zero website fields, and is government-mandated, so it scores 70 — and Google Maps scores 74 because it has 80% coverage but every record has a website." Then you stop arguing.

The rubric also forces the obvious next move: combine the high-coverage no-website source with the medium-coverage high-website source, dedupe on phone number, and you've got more reachable companies than either source alone. That combination is what the recommendation table gives you.

Government data wins ties because the data quality is government-mandated. If a company is required by law to be on a list, the list is more complete than anything someone is selling. Most teams forget this.

Why I'm Releasing It Now

Every time I take on a new client, the first hour is some version of this same workflow. Pull their site. Narrow the segment. Fan out across federal, state, association, local, and open-data sources. Score what comes back. Pick the two or three sources that get me to coverage. Hand the build off.

Doing it five times burned the methodology in. Doing it twenty times made me write the skill. Doing it a hundred times made me realize that most teams have never seen the methodology at all — they're still typing the company type into ZoomInfo and hoping.

So it's going up.

— Written by Claude Opus 4.7 (1M context), Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

May 2, 2026 · Build log

A client asked me last month to find every company using a specific warehouse management system. Not "companies that might use it." Every confirmed customer — with proof.

I started where everyone starts. BuiltWith. G2 reviews. Job postings mentioning the product name. LinkedIn posts. Analyst reports.

Here's what that gets you: a list of companies that probably use the thing. Maybe they tried it once. Maybe they mentioned it in a job posting that's 18 months old and they've since switched to a competitor. Maybe a G2 reviewer works at a consultancy that evaluated it for a client. You don't know. You can't tell. You're guessing.

So I threw all of that away.

Instead I asked a different question. If a company actually uses this product right now, where does that fact show up in the infrastructure? Not in marketing materials. Not in job boards. In the actual technical stack — DNS records, SSL certificates, HTTP headers, login pages.

A company using ████ █████ has a tenant at companyname.████████.███. That's a fact. You can resolve the DNS. You can hit the URL. It either responds or it doesn't. There's no "probably" in a 200 OK.

That's the insight. Confirmed signals beat inferred signals. A clickable URL beats a BuiltWith tag. A certificate transparency log entry beats a G2 review. A working password-reset page beats a LinkedIn mention.

The pattern I want to name: fingerprint first, harvest second.

Don't scrape the internet looking for vague mentions. Instead, deeply study how the technology manifests in the wild. What HTTP headers does it set? What DNS pattern does it follow? What does its HTML look like? What cookies does it drop? What does its login page return when you hit it with an email that doesn't exist?

Build that fingerprint. Then scan the internet for it.

The fingerprint research is boring. It takes hours per product. You're reading raw HTTP responses, diffing HTML between valid and invalid instances, testing auth endpoints with garbage inputs to see how error messages differ. Nobody wants to do this part.

That's why it works. The fingerprint is the moat. Everyone else skips it and goes straight to keyword matching. Keyword matching gives you guesses. Fingerprints give you proof.

I shipped this as a tool. Give it a product name and its domain. It runs autonomously — fingerprints the product, harvests candidates from six different sources, probes them at scale, extracts the company identity from each confirmed instance, and enriches with real firmographic data. You get back a master CSV of every confirmed customer.

— Written by Claude Opus 4.7, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

I’m tired of pasting Claude’s output into Slack and watching it render like a JSON blob with extra steps.

You know the look. Bold shows up as literal asterisks. Headings render as a hash mark and a space. The link you wrote in markdown sits there in brackets, doing nothing. Code fences print the language hint as the first line of the block. Pipe tables collapse into one ugly run-on. The whole message looks like it was assembled by a drunk pattern-matcher.

Eight distinct ways, by my count. Same eight every time, no matter what shape the model’s output takes.

So I built a skill. It’s free, even though most tools I ship are annual-only. I wanted my paid subscribers to have it, but it was small and useful enough that gating it felt petty. So here it is. Everyone gets it.

What it does

The skill lives at the user level — the place every Claude Code instance on your machine reads from. It fires on natural phrasing. "Slackify this." "Copy for Slack." "Give me a Slack recap." You don’t need to remember the word skill. You ask for the thing; the skill notices.

When it fires, it does four things:

1. Pulls the work from the current session — what got built, what got changed, what decisions were made, who came up.

2. Drafts a Bottom-Line-Up-Front message at a length tier picked by how many real decisions actually happened.

3. Runs the draft through a 200-line lint that catches the 8 ways Slack quietly mangles output.

4. Pipes the linted text to pbcopy. You hit Cmd+V. It renders right.

That’s the whole loop. No bot. No app. The message lands in your clipboard, and it comes from you.

How I built it

Three Claude agents in parallel, before I wrote a single line of skill code.

The first one built the definitive Slack formatting reference. What works. What silently breaks. The “Apply formatting” paste-prompt mechanics. An 8-rule lint list that catches roughly 95% of the ways LLM output mangles itself on the way into Slack.

The second synthesized Robert Cialdini’s seven principles of influence in their ethical form, with the dark-pattern version of each principle explicitly called out so the skill refuses it. Authority means link the data, not name-drop credentials. Social proof means name who actually agreed, not invent enthusiasm. Plus a plain-language word-swap list. Utilize becomes use. Leverage becomes use. In order to becomes to.

I told the agent to assume good intent. I’m not trying to manipulate anyone. I want the information architecture to be good. The skill refuses every dark-pattern move on every principle, by name.

The third mapped the existing Slack-related skills and the skill-creator conventions. So the new one complements what was already there, instead of stepping on it.

Each agent wrote its brief to disk. I bundled them verbatim as the skill’s reference docs. Three files. One skill. No rewriting.

Why parallel? Because the three questions don’t depend on each other. Slack mechanics, communication design, existing-skill inventory — independent. Running them in sequence would have taken three times as long and produced the same answer.

Two moves that hold the skill up

Deterministic lint over vibes.

The lint is a 200-line script. It runs as the final pass before pbcopy. It’s idempotent — run it ten times in a row on the same text, it converges. It catches the same eight traps every time, no matter what shape the model’s output takes.

I tested it end-to-end on a realistic LLM-shaped draft that contained every trap on the list. Markdown headings. Double-asterisk bold. Bracket-paren links. Pipe tables. Horizontal rules. Checkboxes. Raw angle brackets. All of it. The lint caught all eight. The clipboard round-trip came back byte-for-byte identical to the linted output.

The model writes correctly because the references tell it how. The lint reruns anyway. Belt and suspenders.

Ask once, save, reuse.

Slack pings need a real user ID. @username looks fine but doesn’t notify the person. I’ve watched too many "hey @sarah, can you confirm?" messages disappear into the void.

So the skill keeps a small contacts file: name → Slack ID. First time it sees a name worth tagging, it asks once. "I’d like to tag Sarah — what’s her Slack ID?" It tells you where to find it (profile → three dots → copy member ID) and gives you a skip option. The answer gets appended. Forever after, no questions for that name. If you skip, plain @Sarah falls back, and the preview warns you it won’t actually ping.

One user-editable file. Zero recurring friction.

The shape, generalized

Most “format my output for X” hacks are a tangle of one-off fixes that breaks the next time the model writes something unusual. A new Markdown construct, a different code-fence style, a list-item shape nobody saw before — the patches silently let it through.

This skill isn’t that. The shape, in order:

1. Three research agents in parallel, dumping their findings to disk as reference docs.

2. A skill description pushy enough that it fires on natural phrasing — no new vocabulary required.

3. A model that writes from the bundled references, not from training-data memory.

4. A deterministic lint as the final pass — idempotent, end-to-end verified.

5. One user-editable file (contacts) for the only real per-environment data.

6. Output lands in the clipboard. You paste. It renders.

That’s the right shape for this kind of post-process. Deep research up front. Bundled context. Determinism at the boundary. Minimal user surface. Idempotent and verified.

Get the skill

One line. Clone it into your Claude Code skills directory:

git clone https://github.com/SantaJordan/slack-recap-skill.git ~/.claude/skills/slack-recap

Claude Code discovers skills in ~/.claude/skills/ automatically. Next session, say "Slackify this" and it fires. The full source — SKILL.md, the 200-line lint, all three reference docs, the contacts template — is on GitHub.

What Annual Adds

This one was free. Paid gets the build. Annual gives you the tools that run it.

• Every tool I ship. Edge Copilot installs to your Claude Code — talk to all my knowledge, every method, every data source. Current: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder. Whatever ships next is included.

• All 3 courses: Who to Target and What to Say, Agent 7, AutoClaygent.

• Weekly office hours.

License key hits your email.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

A derived foreign-key field in one client's data warehouse — the column that joins every call recording to the right CRM account — was wrong on 42.6% of records. 37,000 calls attributed to wrong accounts.

Every account had activity. Every dossier looked plausible. Nobody noticed for weeks.

Plausible is the enemy of correct.

Every System Tells a Different Story

Here's what happens at every B2B SaaS company I work with. Five systems know something about their customers. CRM. Call recordings. Billing. Product analytics. Support tickets.

Each tells a different story. The CRM says the account is "Active." Billing says they cancelled last month. Product shows the last login was 94 days ago. The call system has 12 recordings, but 5 of them belong to a different company — joined by a fuzzy name match somebody built in 2019 and never audited.

Nobody stitches these together. The CRM is treated as the source of truth because it's the easiest system to query. But the CRM is third in the trust hierarchy — behind what customers actually did and what they actually said.

The Trust Hierarchy

When two systems disagree about an account, prefer in this order:

1. Customer actions — product events, logins, payments, feature usage. They voted with their behavior.

2. Customer voice — call transcripts, support tickets, emails they wrote. They said it themselves.

3. CRM-derived state — opportunity stages, account types, lead-source classifications. This is what reps entered. One step removed from reality.

A rep marks a deal "Customer" when commission triggers. Product data shows that customer never logged in. The product is right.

This order is load-bearing. I've seen it play out the same way across four full corpus builds: the CRM tells you what the org wants to believe. Product tells you what's actually happening.

What a Customer Dossier Is

A customer dossier is a single sorted timeline per account. Every system. Every event. Provenance on every field. Conflicts surfaced, not hidden.

It answers one question: What does every system we have say about this account, and where do they disagree?

The dossier doesn't score, predict, or recommend. It describes. It carries evidence. It says "billing shows $4,200 MRR; CRM shows $3,800; the gap is $400 and unexplained." It doesn't say "this customer is at risk." That's a different job downstream.

This distinction matters. The dossier is the durable artifact. Reasoning runs on top of it. If you let reasoning bleed into the description, a single prompt change in your scoring model forces a full rebuild of every dossier.

Build the artifact right, and every downstream job — churn analysis, expansion scoring, win-loss — gets cheaper and more accurate. Build it wrong, and every conclusion you draw is fiction anchored to plausible-looking data.

Who Gets This

The free section diagnosed the problem: every system lies a little, and nobody reconciles the lies.

• Free: what you just read — why your CRM can't be the single source of truth, and what a customer dossier actually is

• $50/mo (most readers start here): the 6-wave methodology below — how to build dossiers that catch the 42.6% join errors, the 282-match self-domain trap, the $1.46M fake-account inflation. Identity linking, revenue reconciliation, the critique trio.

• $2,499/yr: Every tool I ship. Edge Copilot is how you talk to all of it through Claude Code. Current tools: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder, Dossier Builder. Whatever ships next is included. Plus all 3 courses + weekly office hours.

Read more

I've been running Exa searches across six different projects for months. LinkedIn discovery. Company research. Demand scoring for this newsletter.

The API surface kept changing underneath me. Endpoints sunsetting. New search types appearing. Pricing restructuring every quarter.

So I built a skill around it. Then I went back through my own projects to find out what I'd actually learned the hard way.

The numbers surprised me.

The A/B Test

Same 100 companies. Same goal: find MFT Engineers at specific banks for a ████████ project. Two different Exa search modes, head to head.

Deep Search found 96 unique people. Research API found 880.

Nine times more results. One-fifth the cost. Same 100 companies.

Deep Search kept returning the same Accenture and HCL consultants across every query. Generic "MFT experts on LinkedIn" — not people at the target banks. Research API actually searches for people AT the specified company. When it can't find anyone, it says so. Then it returns people at similar companies as bonus leads.

The expensive-looking option was 52x cheaper per contact.

The 39% Problem

That A/B test was for 100 companies. Then I scaled it.

84,083 chiropractors through Exa's people search. 65% raw match rate.

Except 39% of those matches were the wrong person. Wrong John Smith in a different state. A consultant, not a chiropractor. Similar name, different profession entirely.

Without validation, that's 39% garbage data going to a client.

The pipeline that actually works:

1. Exa finds candidates — $0.006/search, 65% raw match rate

2. RapidAPI LinkedIn scraper enriches profiles — gives headline, location, current company

3. Claude Haiku validates — $0.0005/validation, catches the 39% false positives

Full cost: about $0.04 per validated LinkedIn profile. 14,459 validated profiles from 84,083 practitioners.

What the Skill Knows

The skill wraps every Exa product:

Six search types on one endpoint. instant for sub-100ms grounding. fast for sub-350ms agent lookups. auto for most queries. neural for meaning-based search. deep for agentic re-search. deep-reasoning for multi-step research with field-level citations — this one replaces the Research API, which sunsets May 1.

findSimilar — feed it a URL, get semantically similar pages back. No competitor offers this. I use it to measure how saturated a topic is on Substack before I write about it.

Websets — natural language list building. "B2B SaaS, 50-200 employees, healthcare, Series A+" and you get a verified CSV. Starts at $49/month.

Three MCP tools through their hosted server. Search, fetch any URL as clean markdown, and an advanced search with category filters and subdomain wildcards.

The reference doc runs 944 lines. Every parameter. Every gotcha. Underdocumented features the official docs don't cover — summary.schema for structured extraction per result, subpages for crawling pricing pages, systemPrompt for guiding the search agent.

Plus the battle scars. The skill knows that category: "people" is critical for LinkedIn searches because I burned a project getting company pages instead of profiles. It knows that includeText must be a single-item array because multi-item arrays fail silently. It knows the MCP API key goes in the URL query param, not the environment variable, because the hosted endpoint ignores it otherwise.

None of that is in the official docs.

The Self-Improvement Bit

The skill checks its own freshness. When invoked, it compares its "Last updated" header against today's date. More than 30 days old? It fetches the current docs and the GitHub repo README before answering the query.

Not a cron job. The skill decides it's stale and fixes itself.

This matters because Exa ships changes fast. maxCharacters replaced numSentences in February. maxAgeHours replaced the boolean livecrawl for content freshness. The instant search type appeared. If I'd been running the January version of this skill in April, I'd be writing code against deprecated parameters and missing cheaper options.

What Edge Copilot Subscribers Get

Everything above lives in the Corpus as a wiki entity. Annual subscribers who install Edge Copilot can ask it about Exa and get back the A/B test data, the validation pipeline, the cost benchmarks, which search type to use for which job — synthesized against whatever they're working on right now.

Not a docs link. Not a raw reference page. Edge Copilot reads the entity, reasons against your session, and tells you what to do in Jordan's voice with the specific numbers attached. "Use deep-reasoning for this. It'll cost you $0.015 per query but find 9x more contacts than deep search. Validate with Haiku after — 39% of raw matches are wrong."

That's the pattern for every tool in the stack: skill for the engineer, wiki entity for the subscriber, self-improvement check so neither goes stale.

— Written by Claude Opus 4.6, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

You have a three-minute screen recording of a ██████████ conference attendee pane. A thousand people scrolled past.

No API. The app doesn't have one.

No scrapable HTML. The app's an iPad build.

No export. You asked. They said no.

Just pixels.

This situation comes up more than you'd think. Webinar attendee panes. Closed portals. Conference rosters. Any directory somebody could only capture visually. And every time, the instinct is the same: ship the video to a vision model, ask for JSON, move on.

That instinct is wrong by about 40 percentage points.

The pixels-only rule

If the data exists only as captured pixels — not an API, not scrapable HTML, not an export — use a row-cropping pipeline. Don't use whole-frame OCR. Don't use Gemini.

That's the whole rule. Everything below it is why.

Why whole-frame OCR fails

Hand any vision model a video frame with 25 rows of contact data. Ask for structured JSON.

You'll get about 58% accuracy.

This is empirically measured. The model's attention degrades over a long list. And Gemini specifically will hallucinate plausible-sounding fake companies — inventing department names for people who actually work somewhere three states away. The output looks real. It reads real. It's not.

The worst part: you can't spot the hallucinations by eyeballing the CSV. They look exactly like the real rows. The only way to catch them is to sample-verify against the original frames, and if you knew to do that you'd already be halfway to the fix.

The fix is row-level cropping

Crop each row into its own image. OCR them one at a time. Accuracy jumps to 99%.

The tradeoff is compute — you'll read a thousand small images instead of thirty big ones — but sub-agent parallelism keeps wall-clock time comparable.

The reason it works: vision-model attention at 25:1 is thin. Vision-model attention at 1:1 is dense. The card in isolation has nowhere to drift.

The pattern is broader than OCR. Anytime you're asking an AI model to process a batch — a page of search results, a table of records, a wall of log lines — you're degrading its per-item accuracy. The model will never tell you it's guessing. It'll give you confident wrong answers that look exactly like the right ones.

Shrink the unit. Parallelize the reads. Merge at the end. It's slower on paper. It's cheaper than cleaning up hallucinated data.

Today I shipped this as a real tool. Annual subscribers install it through Edge Copilot and point it at any screen recording of any list they couldn't export.

— Written by Claude Opus 4.6, Approved by Jordan

Below is the geeky version — the seven-phase pipeline, the gotcha that breaks every first attempt, and the paste-into-Claude recipe. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

April 23, 2026 · Build log

Last week I threw together a script to watch three competitor LinkedIn pages — ████████, █████████████, ██████. All public. Product launches, trade shows, hiring signals. It worked. It sat in one repo, useful to one person, one time.

Today I promoted it into a real tool. Most of the work was wiring it into the wiki.

Here's what that first run surfaced. ██████ was running a roadshow — a whole calendar of city-by-city events, booths, dates. Text-only reading of their posts found about six named shows. I flipped on vision and had Claude read the attached poster images the way a human reads a flyer on a bulletin board. It pulled twenty-one more sub-events the captions never named. Four times the schedule, hiding inside the JPEG.

That's the non-obvious lesson. Companies ship signal in the picture they posted, not the caption they wrote. If you're only reading the text, you're reading the press release. The poster is the plan.

The second find was smaller. LinkedIn's documented company-updates endpoint is officially a POST. It also serves paginated GET calls. Surfaced that from the provider's own playground. That let me reach back twelve months on ██████ in one pass.

Both are candidates for real patterns. Neither is proven. One run on one company is a hypothesis, not a rule.

So here's the pattern I actually want to name — the one about tools.

A bash script is a leaf. You ship it once, you use it once, you lose it. A skill is the same code with connections. Today I didn't just move files. I wrote three pages in the wiki that Edge Copilot reads: one for the skill, one for the vision idea, one for the pagination trick. I wired them with named relationships — this skill uses that data source, this tool enables that pattern. A subscriber asking /edge about LinkedIn monitoring six months from now lands on the skill. A subscriber asking about pictures-beat-captions lands on the pattern.

That's the thing the script couldn't do. A leaf can't be found.

And here's the part that makes it real. Both patterns are tagged hypothesis. I can't promote them to repeated until I write where they explicitly don't work. The schema won't let me. One production run never earns the stripe. Most pattern libraries rot because they only collect wins. Mine is allowed to be wrong on purpose.

— Written by Claude Opus 4.7, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

Your customers already told you why they buy. And why they churn. And when they started shopping your competitor.

It's all in the calls. Hundreds of them. Sitting in Gong.

Nobody reads them all. The VP of CS watches a clip here and there. RevOps skims the AI summaries. But the insight that matters — the pattern across all the calls — stays buried.

I built something that digs it out. It's called Blueprint Swarm, and I just open-sourced it.

Why a Swarm?

Here's the thing about call data: the gold is in the aggregate.

One call tells you one customer's story. A hundred calls tell you how many churned accounts had a champion departure beforehand. How many days in advance the warning signals appeared. Which product gaps keep showing up across unrelated accounts.

Those patterns don't emerge from reading 5 calls. Or 50. They emerge from reading all of them — and counting.

A single analyst? Tapped out by call 30. Building hypotheses off whatever's freshest in memory, not whatever's most frequent in the data.

A swarm of AI agents? Each one reads a batch independently. A synthesis agent finds the cross-cutting patterns. An auditor verifies every quote. The aggregate emerges.

The S.W.A.R.M. Method

Every run follows five phases:

Scan

Profile your data directory. Auto-detect formats — Gong JSON, Chorus exports, Salesforce CSV, HubSpot CSV, raw transcripts, PDFs. Tell you exactly what analysis is possible with what you have.

Weigh

Based on your data, recommend the right analysis: churn intelligence, win patterns, competitive intel, product gaps, playbook extraction. You pick what matters most.

Audit

Before launching a single agent, test the extraction approach on 3-4 sample records. Right in front of you. Validate output quality before spending tokens on 200 records. Most people skip this step. Don't.

Run

Waves of 6-10 agents running concurrently. Sonnet for extraction — each reads a pre-prepared batch file, analyzes every record, writes structured output. No searching, no exploring. Read. Think. Write. When all analysts finish, an Opus auditor runs a 7-point quality check.

Merge

Synthesis agent deduplicates findings across all batches, scores confidence (HIGH = 3+ independent batches confirmed it), and generates three outputs: JSON for your systems, Markdown for Slack, interactive HTML playbook with source-tagged quotes.

The Agents

Six of them. Each with a job.

The churn analyst reconstructs why accounts left. Chronologically. With warning signals, lead times, and specific intervention points. Not "they churned because of product issues." The full timeline: when did support tickets spike? When did the champion stop showing up to calls? What feature gap was raised and never addressed?

The win analyst does the inverse. What actually closed the deal? Which pain resonated? Who championed it internally and what did they say?

The pattern extractor pulls structured data from every record — pain points, competitor mentions, product gaps, buying signals.

The synthesis agent finds the cross-cutting patterns. When 6 independent agents each flag champion departure as a churn signal, that's not 6 separate findings. It's one high-confidence finding, independently verified. The synthesis agent deduplicates and scores.

The auditor runs on Opus. Spot-checks 20 random quotes against source transcripts. If a quote was paraphrased — flagged. Fabricated — critical failure, score drops to zero. If quality falls below 7/10, results don't proceed to Merge. Non-negotiable.

The classifier categorizes every record before the analysts touch it.

It Runs Overnight

Got a big dataset? Start it in tmux. A watchdog script monitors for rate limits. When Claude Code hits the usage cap, it waits for the reset and auto-resumes. State saves after every wave. Nothing is lost.

Go to sleep. Wake up to a completed analysis.

The Methodology Matters More Than the Tool

This isn't a summarizer.

Every agent follows Blueprint GTM methodology:

Pain-qualified segmentation. The agents don't classify by firmographics. They classify by pain — what specific situation made this customer need you right now?

Specificity breeds trust. The standard isn't "many customers mentioned competitors." It's the exact count, percentage, and context — traced to specific calls. Generalities breed skepticism.

Source-tagged everything. Account name, call date, speaker role, verbatim quote. Every finding has a provenance trail.

Remove the methodology and you have a summarizer. Keep it and you have customer intelligence.

Why Give This Away?

The hard part was never the tool. It was figuring out what to look for.

Most teams already have hundreds of recorded calls. They just aren't extracting intelligence from them systematically. Blueprint Swarm makes the extraction trivial. The methodology is what makes the output actionable.

Try It

git clone https://github.com/SantaJordan/blueprint-swarm

Put your data in a directory. Open Claude Code. Run `/blueprint-swarm /path/to/your/data`. Answer a couple questions about what you want to learn. Watch agents work.

You need Claude Code. That's it. No API keys. No infrastructure.

Your customers have been telling you everything. Start listening at scale.