Often the race to AGI is compared to the atom bomb. But that analogy misses how hard it is to see the thing I used to generate a cycling training plan last night as the thing that might one day kill me.

I was thinking about this as I was writing today’s edition of the Second Shift Club.

I have built a lot with AI in the last few years and I’ve enjoyed it immensely. But I am also very concerned about the potentially devastating impact of AI on employment, inequality, the climate, and, well, the very fate of humankind. Unlike Peter Thiel, I'm unequivocal in my hope that the human race survives.

I don’t think it helps that the discussion tends to be quite reductive. Either AI is a shiny autocomplete or we’re sleepwalking into the apocalypse.

I find myself awkwardly in the middle. I’m genuinely excited about AI and what it makes possible. I’m also very worried about where it could lead.

I don’t think those positions are necessarily contradictory. If anything, the more time I spend building with AI, the more strongly I feel both of them. ¯\_(ツ)_/¯

So anyway…

Ask a model about the Treaty of Westphalia and it’ll tell you everything you need to know. Ask a model about something closer to home like your product and you often get claims that are almost right. Almost being the operative word.

It will describe features that were deprecated years ago. It will quote stale pricing. It will attach random stats and make claims about your positioning, uptime and customer success stories that sound so plausible nobody catches them.

It’s the kind of thing that kills an AI program, because it costs you credibility.

When I started back in marketing people were fond of saying content is king. Now context is.

The problem is that context is a squishy, co-created thing. It often lives in people’s heads and is rarely codified in a way that is actually useful to a colleague, never mind an agent. It also tends to depreciate over time as operating and market environments change. It’s worth the upfront investment, but also less glamorous, and dare I say a little boring to manage.

I’m lucky to have two wonderful marketers who also happen to also be detail- and systems-oriented at Sinch—Heather Dileepan and Nathan Ellering—who have driven this project. At an enterprise level, that’s no small feat, given the number of product lines, audiences, industries, and other moving parts involved.

For startups / single-product brands, the task is a tad easier. Here’s what a simple truth layer could look like for your business that you could build in less than a day.

Eight markdown files in a GitHub repo

The V1 of a truth layer boils down to eight markdown files that I recommend live in a GitHub repo. You can see the structure and full templates here.

1. Guardrails. This is the "don't get sued" file for something your AI wrote. It makes sure no capability is over-claimed and sets out the words you use and the words you don't. It might state plainly that you never claim the software is HIPAA compliant unless it is.

2. Positioning. This includes your positioning statement, who you compete with, how you win, and some mutations based on things like industry.

3. Facts. These are the hard numbers you publish about yourself. They might include things like customer count, review ratings, geographical availability, and what languages your platform is available in.

4. Pricing. Plans, prices, what’s included, and a worked example for “what would it cost me.”

5. Features. If it isn’t in this file it doesn’t exist. This should include a status per feature: live, beta, coming, deprecated with a date. And a short section of things people assume you might have and you don’t. This can help stop a model filling them in.

6. Who buys. Not personas with names like “Finance Fred”. This should be built from evidence using your customer list, churn notes, and Gong transcripts. It’s also important to state who you don’t sell to.

7. Objections. What buyers push back on, verbatim, with honest answers.

8. Voice. Aim for mechanical rules a linter could check (sentence case, no em dashes, second person), a say/don't-say vocabulary table, X number of sentences that sound like you and X number that could be any competitor. You should also include channel overrides only where a channel differs (landing page copy vs email copy vs blog copy).

Why this truth layer structure (or why eight files and not three)

Think of it like rules at a school.

1. There’s the law (you can’t assault someone)

2. The school rules (no phones in class)

3. Your teacher’s preferences (she likes essays double-spaced).

They’re kept separate for a reason: when they clash, everyone knows the law beats the school rules, and the school rules beat the teacher’s rules. If you stapled all three into one booklet, nobody could tell which line wins.

Same with these files. The “don’t get sued” file is more important than the “how we sound” file, so it can’t live inside it.

They also change at different speeds. The law rarely changes; the teacher’s preferences might change every term. If they’re in one booklet, it can be a little harder to manage.

Finally, and to really belabour the metaphor, you don’t carry the whole booklet everywhere. You memorise the short, important rules and look the rest up when you need it. Keeping them apart keeps the important ones short.

Context decay is your enemy

The problem with context is that it’s a pretty dynamic thing. For example, you build a new feature and suddenly your feature.md is stale. You launch in a new country and now your facts.md is no longer accurate.

Overtime it’s death by a thousand cuts if you don’t build a system or cadence to update it. I recommend:

• Tying updates to events or automations where possible. A release workflow should diff the code, cross-reference the ticket tracker, and update the features.md automatically. You could set an automation to pull customer numbers quarterly from your system of record. And so on.

• Putting a 'last verified' date at the top of every file, and reviewing on a regular cadence.

Putting your truth layer to work

For any marketing skill I create, I have agents read it as a pre-read. The wiring file (CLAUDE.md) also says: before any task, read these files in this order.

To me the above is very much the minimum viable product. Anything you find yourself re-explaining to a model is a truth layer file waiting to be written.

That could include your:

• Metric definitions

• Marketing design system

• And so on

Having well-defined sources of truth is the difference between an AI program that earns trust and one that is accused of being a slop cannon.

So if you do one thing, build the truth layer first. Everything else you build on top of it will be easier.

It was very much of its era. We were heavily focused on dominating the SERPs and delighting customers; we could probably have called ourselves “Mickey Mouse’s preferred texting tool” without doing much damage to growth.

Businesses found us because they wanted to text. We often showed up first, we were affordable, the product was solid, and it was easy to get started.

In a world in which a 17-year-old in their parents’ basement can vibe code your product in a weekend, I am not nearly so relaxed about positioning.

It’s probably one of the most important things a business can get right, and also one of the hardest because you only know if you got it right ex post.

To help you I’ve spent time testing how AI engines recommend products. Here are a few thoughts on what to do, and what not to do.

Methodology

Before you come at me, this is not a rigorous research project and there are flaws, lurking variables, and other concepts I learned in Econometrics that I vaguely remember.

Everything here comes from three small studies I ran, with about 1,100 controlled answers, cross-checked against a month of real tracked answers for a group of brands I monitor.

I’m also aware that:

• I used an API model with no product memory or personalization

• It’s one model family (gpt-5.2), one day, US English

Like many things in the world of AEO it is directionally interesting, but I’m not presenting it as gospel.

(If you’re interested in sponsoring a larger, more rigorous study, do come at me. 😉)

A quick word on positioning

I’ve done my fair share of positioning workshops over the years but I don’t pretend to be an expert’s expert. I have one particular observation that is important for the AI era.

Positioning work tends to fail because it is inherently about tradeoffs and companies (especially software companies) are reluctant to close doors that might lead to future revenue.

The latter is particularly problematic because LLMs will force these tradeoffs on you, and they may be sub-optimal.

So if I were parachuted into a positioning workshop I’d still ask everyone to:

1. Pick a category buyers already recognize

2. Name the alternatives inside it

3. Say what makes then different

4. Say who it's for

That much hasn’t changed.

The problem is that LLMs make positioning incredibly sticky and hard to pivot. That's hard on a startup still hunting for traction, and on an established business trying to reposition itself.

Lesson 1: Categories > jobs-to-be-done

My hunch is that buyers using LLMs talk less in categories and more in jobs (some data supports this thesis).

It makes sense to me that somebody opening ChatGPT is less likely to type “best digital adoption platform.” Instead you’d expect them to type: “half the people who sign up for my product never come back after day one…what should I use to fix it?”

It might be tempting then to recommend leaning on jobs-to-be-done positioning where you market to the job the buyer is trying to get done rather than the category they’d shop in.

To test this I ran matched pairs: the same buying question phrased as the category versus the job.

What I learned is that the AI doesn’t answer the job question directly. In 92% of answers it searched for the nearest category, then recommended those brands.

Take hiring. It’s a gerund market. Hiring, recruiting, screening, interviewing, sourcing, onboarding. These are things people do, and not things people buy.

So when someone asks ChatGPT for candidate screening tools, it doesn’t search for that. It takes the verb, guesses which nouns the verb usually lives inside, and goes looking for those.

Then it opens the answer with “if by candidate screening you mean...” and builds a table with an ATS row, an assessment row, an engineering-tests row. Every brand in the table is heavily associated with one of those category nouns.

Takeaway

Ask the engines your buyers’ actual questions, job wording and all, and watch which category nouns the answers land on. Those lists represent your real competitors.

Win a spot in one of them, then keep writing for the jobs; job pages get quoted in answers, but only the category gets you recommended as an option.

Lesson 2: Changing categories is really hard

Chug enough coffee and burn enough Claude tokens and you will eventually think I should just create a new category.

I looked at twelve well-known companies that rebranded into new, broader categories over the past few years. Intercom is now “the AI customer service company.” Klaviyo is a “B2C CRM.” Airtable builds “AI apps.”

I pulled LLMs’ descriptions of all twelve. Across 72 answers, the new category appeared without the old one exactly twice.

Intercom got called live chat software six times out of six. Klaviyo is still email marketing. Airtable is still a spreadsheet-database.

The reason is simple. The AI’s memory was built from years of everyone else’s writing. “Intercom does live chat” is a thousand pages across many years.

It’s really, really hard to reorient LLMs.

Takeaway

Ask the engines “what is [your company]?” The phrase in their answer is your real category, not whatever your internal decks say. Dominate that one first.

And if you’re set on inventing a category or changing your existing category, be honest about the job: it isn’t just an update to your homepage, it’s getting thousands of other people’s pages to repeat it. Budget years and bucketloads of cash.

Lesson 3: The fastest-growing categories are people-shaped

You can always latch onto rapidly growing categories.

I checked 2,302 Y Combinator one-liners across a decade of batches from 2015. What exploded in recent years is positioning as a role: AI SDR, AI recruiter, and AI engineer went from 1% to 20%, almost all since 2023.

And buyers followed. “AI SDR” went from ~12 searches a month in 2022 to ~2,400 now, sixteen times the volume of “SDR tools.” These phrases became categories in about eighteen months.

While people might roll their eyes at AI in every H1, there is meaningful demand for these categories.

Notice what they have in common with the categories that held up in Lesson 1. They’re nouns. A role is a thing you can hire, so an LLM can put it in a table without translating it into something else.

Takeaway

New categories can be minted fast these days when the internet writes about them in unison. It’s easier to spot a trend than to create one.

The four states of a phrase

All this means the question you need is to answer is what state is your category phrase in (as far as the engines are concerned). Here’s how I think about it:

• Shelf. The engines answer in this noun without translating it. The table exists, the rows are taken, and the only move is a cell inside it: a segment, a price point, a mechanism nobody else has. This is most established categories.

• Forming. The phrase is in circulation, the engines use it as a modifier or a “best for” label, but no brand owns it as a category yet. This is where the people-shaped categories were in 2023. It’s the cheapest shelf to claim, and the window is short.

• No shelf. The engines rewrite the phrase into another noun before answering. The first-sentence test fails. You can rank for it on Google and still never be named. Most gerunds live here.

• Held. A niche you already win: a specific prompt or segment where the engines name you consistently. Small, but it’s proof the mechanism works, and it’s the corner you expand from.

Run the tests from Lessons 1 and 2, sort your candidate phrases into those four states, and the decision mostly makes itself. Take the held niche as the anchor.

The goal is to claim the empty cell on a shelf, or move early onto a forming noun. Never stand on a no-shelf phrase and wait for a table to appear.

If you move at all, move with a current, not against one. When the whole internet starts repeating a phrase at once, a category is created in months and the earliest names get glued to it.

The tells: search demand rising, other people’s pages using the phrase, and, ideally, a phrase your name already plausibly sits next to.

Having interviewed 50+ marketers in the first half of the year for roles from marketing coordinator to VP, I see people fall into three broad buckets:

1. I use ChatGPT/Claude to help me do tasks.

2. I’ve automated a task (competitive monitoring, reporting, dashboards, alerts, research, etc.) that helps me do my job more efficiently.

3. I’ve built a system that can execute work, observe the result, learn from it, and only pull me in where judgement is required.

I saw lots of two, but never really came across three. (I’m not alone. Matt Swulinski (Growth at Viktor AI) says fewer than 1% of candidates he meets demonstrate that level of depth.)

So I wanted to do something a little more meta: try to articulate what actually blocks people from getting to bucket three, and illustrate a different way of thinking about your work that may make it possible.

Why most teams can’t get to three, even when they want to

One thing that gets my goat is the tendency to treat AI adoption as an enablement or individual employee problem. Teach people Claude, run a hackathon, hand out a skill library, and adoption will follow.

I think this gets the problem backwards.

If I’m a solo marketer at a seed-stage startup, I’m going to automate as much as I can because I need every edge. More importantly, I have the autonomy to do it because I own the outcome.

If you own the outcome, you tend to own the path towards it.

Nobody particularly cares how you get there, only that you do. Given enough autonomy, most rational people will gravitate towards the most efficient path.

The dynamic changes inside established organizations, where the real impediment to agent adoption is often less individual capability and more culture and operating structure.

A few examples:

• Agents can’t align stakeholders or make compromises. At least not yet. The more consensus, approval, and compromise required to get something done, the harder it becomes to build a genuinely autonomous system around it.

• Fragmented ownership creates handoffs. Someone owns copy, someone else owns design, another person owns messaging, another owns the CMS. But every human-to-human handoff breaks the loop.

• The incentives often punish experimentation. The very ingrained “nobody got fired for buying IBM” mindset matters here. Agentic systems are inherently iterative. They will make mistakes. They will occasionally produce something embarrassing. It’s a tradeoff that few leaders are willing to acknowledge.

• Security and data constraints are real. Established companies have legitimate reasons to be cautious about what systems can access, what they can change, and where data can flow. (This is probably the most understandable constraint of the lot; you don’t want to end up on the news.) But free access to data and systems is how most systems add value.

Which is why hosting an AI hackathon or running another training session can feel a little like giving a multivitamin to someone who eats junk food every day, never leaves the couch, and hasn’t drunk water in two years.

Instead I think marketing leaders should spend less time asking, “How do we get our people to use AI?”

A better set of questions is:

Who owns the outcome? How much of the path do they control? Where are the handoffs (are they necessary?)? What decisions genuinely require a human? What permissions would an agent need to close the loop? And what level of failure are we prepared to tolerate while the system improves?

Because if you want people to build systems, you have to give them an environment in which systems can actually exist.

What differentiates automating systems from tasks

Normal task automation is a pipeline. It takes something in, does something, and produces something out. Tomorrow, if you built it well, it does essentially the same thing again.

This can be incredibly valuable. Most of the workflows I’ve described in this newsletter fit this description, with some additional intelligence layered on top.

But the real transformation happens when you start thinking in systems.

Task automation:
Input → AI → Output

System automation:
Input → AI → Action → Result → Measurement → Memory → Better next action

The key difference between the two is that a task ends when the output is produced. A system exists to achieve some outcome, which means the system has to know whether it’s on track or not.

If an AI writes an ad, its job is done. If an AI is helping run paid for you, writing the ad is only one step. It needs to know whether the ad ran, how it performed, what that performance means, what should change, and whether the next iteration did any better.

In other words, the output of one run becomes context for the next.

Questions as the design tool

The classic way of thinking about a job is that it’s a set of tasks. I think that applies to some work, but it’s a dangerous framework for modern knowledge work because:

1. It confuses the means with the end

2. It leads to the problematic output > outcome thinking

Anyone who has ever been responsible for something fuzzy (grow trials, reduce churn, increase ARPA, increase efficiency) knows this especially well. There are so many variables, inputs, and factors at play that you need to become very good at asking the right questions so you know what to do.

In other words, questions expose the decision-making structure of the job while tasks often hide it.

Here’s how you might apply this content.

This is also why outcome ownership matters. If your job is “write the blog post,” the natural thing to automate is writing the blog post.

If your job is “grow qualified organic acquisition,” suddenly the relevant system includes deciding what to publish, creating it, distributing it, measuring it and changing what you do next.

If this all sounds super fuzzy, here’s a more practical/detailed example.

1. What should we work on? Back in my day (old man yelling at clouds) I built content calendars based on keyword data from Semrush and feedback from sales. Now several agents run on their own schedules and write into one shared backlog: search decay, competitor pages outranking us, People-Also-Ask, customer language from sales calls and support. Then a routine ranks them against each other so I’m looking at one ordered list instead of a bunch of dashboards.

2. Is this ours to write? Does it match our positioning and who we sell to, and have we already covered it. The second question was a little trickier to solve. I needed to build an index of everything published that returns “we own this,” “new angle on something we own,” or “genuinely new.”

3. Make the thing. Here there are separate flows that generate a first draft that I then work through and adjust depending on the topic.

4. Should it go out? These ship on a schedule unless I type HOLD and the slug into Slack.

5. Did it work? A routine goes back two to six weeks later and asks what happened to those specific pages. Did Google index them, did clicks hold, what does GA4 tell us, are they being cited by LLMs.

6. More or less? On Sundays, one routine reads the answer to question 5 and rewrites the volume limits every other routine runs at.

7. What did we learn? Every correction I make becomes a written rule.

The last routine to build is the one that watches the other routines and alerts you in Slack when something is off.

Rome wasn’t built in a day

The temptation is to perfect one part of the system before moving on.

Having done both, my advice is to build the thinnest possible version of the entire loop first, even if half the steps are crude or still involve you.

What matters is that an action produces an outcome, the outcome gets measured, and that measurement changes what happens next.

That makes it easier to improve the weakest parts of the loop.

Will slop be the word of 2026? First there was LinkedIn’s accusatory button. Then there was the news that Claude is watermarking content. All this caused a lot of consternation, glee, and a painful volume of “I told you so” LinkedIn takes.

What the broader reaction tells me is that the penny hasn’t dropped for the vast majority of folks and that people need to go read Ryan Law’s article from 2021, “You’re a Content Marketer, Not a Writer.”

The discourse has been obsessing over em dashes, tell-tale sentence structures, and an LLM’s tendency to create whacky and awkward analogies. I get it! It’s fun to dunk on super lazy AI copy.

But my view is that the obsession with copy assumes that people are hanging on every word of your blog, report, or FAQ. I don’t believe that’s the case for a myriad of reasons, but mostly because the way many of us consume information is undergoing a radical shift.

Put in very simple terms: I spend a chunk of my day interfacing with LLMs and while I chuckle at their AI-isms, I don’t really care about their phrasing because I’m (mostly) getting tons of value when it comes to doing things.

So the question is does your content provide value beyond what someone could get from interfacing with ChatGPT. If I want to read beautiful, human-constructed prose I have a stack of novels that I’ve been meaning to get through (currently reading Flights by Olga Tokarczuk which I can’t recommend enough).

Anyway I built a way to check your content for you. Paste a link, it reads the page and answers one question: could an LLM have written this?

Check for slop

And here are the results for a page I recently refreshed. (Most of the value, IMO, comes from the suggestions on how to de-slopify it.)

I have also included a separate skill if you want to run this as part of a broader workflow in a new Github repo: https://github.com/secondshiftclub/workflows/. It includes past workflows from previous editions of this newsletter. Have at it!

Just like my jump shot, I recently dusted off something else from my past: topic clusters.

I think the AI-era is exposing two things:

• That website traffic as a metric is/was stupid and that most content is/was corporate navel-gazing with zero impact on the bottom line.

• That commodity content (what is X, how to do Y) is dead.

I have no well-formed answer yet on how to navigate this beyond #tryyourbest and fight the urge to start dancing on TikTok.

All of that said I do think there is value in thinking about your website as an entity (and how your content feeds the entity’s reputation). And also that it should be easy for any bot to identify the page on your website for a specific topic.

And because I’m not ready to dance.

First, the results

I’ve run this pipeline for two topic clusters. It’s helped me identify:

• 79 pages that need to be retired or merged into existing pages.

• The 16% of pages that drive 93% of the clicks.

• Eleven pages splitting 107K impressions for one keyword at a collective 0.1% CTR

• And a host of other things!

I have now rewritten/published seventeen pages off the back of it, with plans to scale production. It’s a little soon to declare victory, but early signs are promising.

What you need to run this

• You need to enable the Search Console API and create credentials. This is free and if you ask your LLM of choice it will explain the steps. (Note: it’s a bit of a pain in the ass though, tut-tut Google.)

• Ahrefs API (or similar SEO tool).

• Claude Code (or Codex) to write scripts.

• I also use AirOps for fan out queries and to understand what articles are getting cited.

The workflow architecture

Seven scripts, run in order. Every output is a CSV, every API response is cached, and the final deliverables (a decision workbook and the stakeholder deck itself) are generated from the data, so a re-run refreshes every number in every slide.

[Inventory: markdown corpus scan]
      |
      v
[GSC pull: page metrics]───[GSC pull #2: top 250 queries PER URL]
      |                              |
      v                              v
[Ahrefs pull: you + competitors]   [Intent classification]
      |                              |
      v                              |
[Embeddings: local bge-small]        |
      |                              |
      +──────────────┬───────────────+
                     v
              [Join → master.csv]
                     |
            +────────+────────+
            v                 v
   [Decision workbook]   [Deck, generated]

Step 1: Inventory what actually exists

Get your site into a markdown corpus first (crawl it once; ours is ~6,600 pages of markdown). Shoutout to my awesome web devs who did this for me (it now runs weekly). You can also figure it out with Screaming Frog if you don’t have awesome web devs at your disposal.

Then a script scans it for pages materially about the topic. The topic has to be the page’s primary subject and not a passing mention. After it writes a CSV: URL, slug, title, page type, word count.

This sounds trivial, but is probably the most important step of the process. “How many pages do we have about X” is a question most content teams can’t answer easily if they’re managing a large-ish site.

It’s also where the skeletons surface. I saw the wrong-language pages on English URLs; debris from a platform migration eighteen months earlier, sitting there cannibalizing the English pages for their own keywords.

Step 2: Pull the queries, not the clicks

Two Search Console scripts. The first pulls standard page-level metrics for a 90-day window. Everyone has this.

The second is the one that matters: top 250 queries for every significant URL — about 9,000 rows for one cluster's 43 top pages.

The GSC UI actively discourages this view, which is why nobody has it, which is why page-level click counts survive as a KPI despite being largely meaningless.

I then classify every query into intent buckets. This is an LLM-shaped task; the prompt is roughly:

Classify each search query into exactly one bucket for [COMPANY],
a [CATEGORY] company:

- JUNK: hack/spy/surveillance intent, prank tools (”bomber”),
  pirated/modified apps, anything with zero legitimate buyer intent
- CONSUMER: legitimate but non-commercial (”is [app] down”,
  “[app] usage by country”)
- BUSINESS: API/developer, business accounts, pricing, features,
  OTP/verification, marketing use cases, branded queries

Return query, bucket, confidence. When unsure between CONSUMER
and BUSINESS, look at whether the query implies operating an
account at scale.

Roll the buckets up per page and every URL gets an honest label. Ours ranged from 95% business intent (keep, obviously) to 96% craptacular on the biggest traffic page in one cluster (kill, obviously).

Step 3: Competitor keyword universes

One Ahrefs script pulls the keyword universe for your domain and each competitor in the category, caching every response so re-runs are free. This feeds two things: evidence for the cannibalization calls, and expansion opportunities. These are keywords where a competitor ranks #1 and you don’t have a page at all.

Step 4: Embeddings, locally, for free

Embeddings get a lot of hate as a nerdy SEO thing that people use to sell expensive agency engagements. That said, content cannibalization is mostly a machine problem and therefore benefits from a machine-based analysis:

• Strip each page to its main content. Kill the nav, footer, CTA blocks, and related-posts modules before you do anything else. Skip this and every page on your site scores as similar to every other page.

• Chunk into ~250-word passages with 40-word overlap; embed every chunk with BAAI/bge-small-en-v1.5 via sentence-transformers. This runs on a laptop, no API (1,239 passages took a couple of minutes).

• Mean-pool chunks into one normalized vector per page, and keep the chunk vectors. You want two similarity numbers per page pair: whole-page cosine, and the max similarity between any chunk of one page and any chunk of the other. The first catches twin pages. The second catches the sneakier case, like a 3,000-word guide whose middle section duplicates another page wholesale, which mean-pooling averages into invisibility.

• Flag thin pages (under ~200 words of real content) rather than scoring them.

• Compute all pairwise similarities; keep pairs ≥ 0.70 as a triage list, not a verdict list. Agglomerative clustering over the page vectors gives you topic groups — useful for organizing the review, but clusters shift with the linkage settings, so treat them as folders and not findings.

Step 5: Join and generate

A join script merges inventory + GSC + intent + Ahrefs + AI-citation data into one master table, one row per URL. Two generator scripts then build the human-facing outputs: a multi-sheet Excel decision workbook and the PowerPoint deck itself.

Note: You need to look over this stuff manually. I have caught mistakes. (People love to call out LLMs for making mistakes, I also catch my own mistakes.)

Making the calls

The pipeline assembles evidence and then it’s up to me to pour over them and sanity check the whole thing. Every URL gets KEEP / KEEP+REWRITE / MERGE / KILL / CHECK-FIRST (that last one for anything that might be in active campaigns). Three rules of thumb from two rounds of this:

• Kill your winners when the queries say so. I’ve killed a cluster’s #1 traffic page. Ranking top-10 for a term that is spammy isn’t something to brag about.

• Keep despite similarity when the citations say so. Figure out how to reangle or rework if valuable and being cited.

I’ve struggled a bit with how to manage these across multiple languages, so it’s something I’m still working through.

What happens to the keepers

Every kept page then goes through a rewrite discipline that will get its own post soon, but the shape is: a query fan-out audit before outlining (enumerate the sub-queries an AI engine decomposes your topic into — attributes, comparisons, tasks, regions — and score the current page against each one), the rewrite grounded in a verified internal fact base (truth layer) rather than whatever the old page claimed, and a verification report mapping every factual claim to its source.

Important caveats

• The intent classification is only as good as your buckets. Spend time reading raw queries before you define them; our “junk” category was invented after seeing all the junk queries.

• Small embedding models are fine for near-duplicate detection at page level. They are not fine for judging content quality which is a very subjective, very human job.

• The similarity threshold does not transfer between corpora. Calibrate every time; it’s ten minutes.

• GSC’s per-URL query API caps what it returns and samples long-tail queries.

Either way, I’ve stopped treating these tools as dashboards and started treating them as a CRM import file.

A lot of AEO advice makes it sound like becoming the best-known brand in your category is something you simply forgot to do between breakfast and lunch.

So how do you do it as a smaller startup? The glib answer is: do a million things well. But one of them you can set up in a single morning — a simple citation outreach workflow that gets you listed, hopefully, in the articles already being cited by the all-powerful models that determine your fate, somewhere between the coffee and the daily pang of existential dread about whether cricket farming or tilapia farming is the safer career in the age of AI.

This workflow could be applied to broken backlinks, pitching website’s on new data studies your brand launches, and a hundred other things.

First, the results

I’ve been running this for about six weeks, and it’s netted 7 inclusions so far. The emails achieve about a 10% conversion rate, which seems reasonably strong. (I do expect it to decline over time as the easier targets bite first.)

What you need to run this

On top of Claude Code or Codex, for the most basic version of this to run you need:

Peec Starter                      $95/mo
Apollo Free                         $0
Notion + Gmail + Slack              $0
Node scripts                        $0
─────────────────────────────────────────
                                  $95/mo

This also works with AirOps, but their pricing is a lot less startup friendly.

A caveat: this is the logic and the prompts, not a copy-paste repo. The two Node scripts are a few hundred lines each and tuned to my category, so I’ve described what they do rather than pasting them. Hand any section here to Claude or ChatGPT and it’ll write you the script… that’s how mine got written. 😅

The architecture

This flow consists of several cloud routines that run on a weekly basis. I considered writing a post about setting up Claude Code and cloud-based routines, but there are tons of helpful resources out there (here’s a 19-minute video on the subject) and Codex/Claude will also walk you through it.

The workflow is as follows:

[Discovery: 3 sources] → [Dedupe vs cache] → [Verify on the LIVE page]
      → [Score by leverage] → [CRM row] → [Draft — human sends] → [Closed loop]

I made the decision early-on to separate the two agents.

• Radar (weekly + a daily fresh-listicle pass): this is discovery only. This finds and verifies targets and writes Notion rows. No contact database and no mailbox access. Those connectors are switched off on this agent.

• Drafter (weekly): picks up rows marked ready, finds the human, writes the pitch, leaves it as a draft in a Gmail account.

Source 1: AI prompt tracking tool

Start here, because it needs no scripts at all. Your AI-visibility tool's MCP can provide the data. The agent just asks it two questions in order.

PRIMARY SOURCE — [AI-VISIBILITY TOOL], project “[COMPANY]” ([PROJECT_ID]):


STEP 1 — Gap domains. get_domain_report, last 90 days, filters

domain_classification in [Editorial, Reference], having gap >= 2 ([COMPANY] absent

but >= 2 competitor brands present), order_by citation_rate desc, limit 50. Then run

a second pass restricted to the ICP topics ([TOPIC A], [TOPIC B] — resolve topic ids

via list_topics) with gap >= 1: lower volume, highest buyer fit. Ignore

academic/irrelevant domains (nih.gov, sciencedirect, springer, *.edu).


STEP 2 — Exact pages. Top ~15 domains: get_url_report per domain, filter

url_classification in [Listicle, Comparison, Alternative]. Skip competitor-owned and

our own domains. Note each page’s retrieval_count and mentioned_brand_ids.

Note: Your tracked-prompt list is the radar’s aim. The scan can only ever surface domains that get cited for prompts you’re actually tracking. So if you point it at the wrong questions, it will diligently find you the wrong pages. Make sure queries map to buying-intent and are likely to surface multiple brands.

Source 2: The backlink link-gap

I use Ahref’s API for this step. (A good example where Claude can write you a script to pull the key information.)

The logic is simple subtraction. I pull each competitor’s backlinks with aggregation: 1_per_domain, pull my own, subtract mine out, and keep whatever links to two or more of them. Write it to CSV sorted by competitor count first and domain rating second, then send the URLs straight into verification.

Source 3: Firehose API

This is useful for finding articles that have just been published. These have been some of the most receptive recipients of outreach. (Its API works very nicely with your LLM of choice.)

const LISTICLE_SIGNALS = [
  "best ", "top ", " vs ", "vs.", "alternative", "alternatives", "comparison",
  "compare", "roundup", "tools for", "software for", "platforms for",
  "options for", "solutions for", "list of", "reviewed", "buyer", "guide to",
];
const CATEGORY_TERMS = [
 INSERT YOUR TERMS
];

const isListicle = LISTICLE_SIGNALS.some(s => hay.includes(s));
const inCategory = CATEGORY_TERMS.some(t => hay.includes(t));
return isListicle && inCategory;   // BOTH, not either

Check and score the list

The next step is to vet the URLs you’ve pulled to ensure they’re the right ones for you to target.

You find CITATION OPPORTUNITIES for [COMPANY] ([DOMAIN]), a [CATEGORY] company.
The lever is being listed in the third-party roundups, listicles, and comparison articles that AI engines
cite. Your job: from web pages just published, keep only the ones where [COMPANY]
could realistically be pitched for INCLUSION.

KEEP if the page is a third-party listicle / roundup / "best X tools" / "top software" /
"[competitor] alternatives" / comparison article in the [CATEGORY] space — i.e. a page
that lists multiple vendors and a writer or editor could add [COMPANY] to.

SKIP if: a single-vendor product/pricing page; a competitor's OWN domain; a job posting;
generic industry news with no vendor list; off-topic; or low-quality auto-generated spam.

For each item return: keep (bool), topic (short), tools_listed (array of vendor names
you can see), company_listed (bool — are we already in it), authority ("high"/"medium"/
"low" guess from domain + writing), pitch_angle (one line: why we fit this list), reason.

Return ONLY valid JSON, no fences:
{"results":[{"index":0,"keep":true,"topic":"...","tools_listed":["..."],
"company_listed":false,"authority":"medium","pitch_angle":"...","reason":"..."}]}

The next step is to rank the pages.

live_score = retrievals × competitors_on_the_live_page

Boost:   page frames the category the way your ICP does
         fresh last_updated
         stale vendors present (hook)
         submission route found
Demote:  pay-to-play directories
         wire-service aggregators

Taken together it looks like this, running on a schedule with three connectors: the AI-visibility tool, the CRM, and Slack.

You find where [COMPANY] ([DOMAIN]) should get CITED to improve AEO visibility.
DISCOVERY ONLY: you write verified targets to the Outreach CRM. The outreach-drafter
routine handles contacts and emails. Never draft or send email here.

STEP 1 — Gap domains. Pull the domain report, last 90 days, filters
domain_classification in [Editorial, Reference], having gap >= 2 (we are absent but
>=2 competitor brands are present), order by citation_rate desc, limit 50. Run a
second pass restricted to the ICP topics with gap >= 1 — lower volume, highest buyer
fit. Ignore academic/irrelevant domains (nih.gov, sciencedirect, springer, *.edu).

STEP 2 — Exact pages. For the top ~15 domains, pull the URL report, filter
url_classification in [Listicle, Comparison, Alternative]. Skip competitor-owned and
our own domains. Note each page's retrieval_count and mentioned_brand_ids.

STEP 3 — SECOND SOURCE (backlink link-gap):
  node scripts/ahrefs-linkgap.mjs --limit 500 > /tmp/linkgap.csv
Take the top ~25 pages (>=2 competitors linked). Skip cleanly if the key is unset.

STEP 4 — THIRD SOURCE (fresh listicles):
  node firehose/citation-radar.mjs --since 24h
Take every keeper. These are hours old — they will have NO citation history, which is
expected. Do not drop them for zero retrievals; floor the score at 1.

STEP 5 — Dedupe BEFORE verifying (cheap first): check every candidate domain against
data/crm-domains.csv. Only for cache misses, double-check the CRM by domain. Work
only NEW domains/URLs.

STEP 6 — VERIFY against the live page:
  node scripts/verify-targets.mjs --json candidates.json
Keep only verdict=LIST_CONFIRMED. Drop NOT_A_LIST (advice articles — the big-publisher
trap). If we're already present, record it as a WIN in the run log, not a target.
BLOCKED pages: retry once via WebFetch and judge manually; if EVERYTHING is BLOCKED,
it's the egress policy, not dead targets — stop and report.

STEP 7 — Score + tier. live_score = max(retrievals,1) x competitors_on_page. Boost
ICP-framed pages, fresh last_updated, stale vendors present, submission route found.
Demote pay-to-play directories and wire aggregators. Rank the batch.

STEP 8 — Write each verified NEW target to the CRM: Name (domain), Target Page,
Outlet Type, # competitors present, AI Citations (90d), Pitch Angle (the script's
hook_hints + why we belong on this specific page; ground every claim in
brand/positioning.md), Status = "Ready to contact", Source ([AI tool]/ahrefs/firehose),
Notes = leverage math + run date. Then APPEND the same domains to
data/crm-domains.csv and commit + push.

STEP 9 — CLOSED LOOP (first run of each month): pull CRM rows with Status = Added.
For each, pull the URL report for that exact URL, last 30 days: does mentioned_brand_ids
now include us? Write the verdict into Notes (cited-after-add / added-but-not-cited-yet)
and summarize conversion rate BY OUTLET TYPE in the Slack digest.

STEP 10 — Post the top 10 to Slack: target page, competitors on it, live-verified hook,
pitch angle. Include how many candidates each source contributed, how many died in
verification, and the monthly conversion report when STEP 9 ran.

HARD RULES: discovery only — no contact lookups, no mailbox, no sending. Never log an
unverified page as a target. Never claim [PRODUCT GAP A] or [PRODUCT GAP B] — those are
gaps, not features. Commit the crm-domains.csv update every run.

Contacts and drafts

As mentioned, generating outreach is a separate routine with separate connectors: contact database (Apollo), mailbox (Gmail), CRM (Notion).

Since the volume is relatively low and all emails are reviewed by me, I simply have Claude write the drafts to Gmail directly, where I do a light edit and send on a weekly basis.

You are the outreach drafter. Pull CRM rows with Status = "Ready to contact", highest
live_score first, firehose-sourced rows first within that, max 12 per run.

1. FIND THE HUMAN. Use the page's byline first. Search the contact DB by DOMAIN in
   batches of 10 — domain search is free; NEVER bulk-match individual people, that
   burns a credit each. Save the person_id on the CRM row; reveal the email only at
   draft time (1 credit). No contact found → mark channel = LinkedIn or web-form and
   move on. Do not guess email patterns.

2. VERIFY THE HOOK ON THE PAGE. Before writing a line, re-fetch the target page and
   confirm the hook is really there — the dead vendor, the stale date, the competitor
   slot. If it's been fixed since discovery, pick a new hook or drop the row. Never
   write a pitch from cached data.

3. WRITE THE DRAFT (template below). Sender = the founder for founder-to-founder
   targets, or the regionally-matched teammate for regional outlets.

4. LEAVE IT AS A DRAFT. Never send. Post a Slack summary listing each draft, its
   recipient, and the verified hook, so a human can review and send in one sitting.

HARD RULES: never offer money to an editorial listicle or any journalist. Never invent
an on-page detail. Every product claim must trace to positioning.md. LinkedIn connection
notes cap at 300 characters — count them.

The pitch template:

Subject: [the specific thing that's wrong on their page]

Hi [name] —

[ONE verified, specific on-page detail. "Your best-X roundup still lists [defunct
vendor], which shut down in [year]." / "The list was last updated [date] and
[competitor] has since [changed thing]."]

[ONE sentence: the gap you fill on that specific page, in their framing, not yours.]

[SOMETHING YOU GIVE: a mention from your own cited guides, an integration, first-party
data, a startup deal — pick per segment.]

Happy to send a 40-word blurb in your format if it's useful.

[Sender]

Let me know how you get on

I like this use case because it’s a repetitive research task with a clear definition of done. Pull the report, check the page is really a list, count who’s on it, find the byline. This is exactly the kind of work that is tedious and never gets done manually the minute more pressing stuff comes up and that an agent does happily.

The competitor list, the category terms, the prompt universe, the blocklists… all of that is specific to a category, and I got a lot of it wrong on the first pass. Yours will be wrong somewhere elses so be patient as you play around with it.

Step 1: Find the right subreddits

Two questions get you to better sources:

• Where does your buyer hang out for reasons unrelated to your product? If you sell to restaurant owners, r/restaurantowners will outperform any software subreddit. People tend to be more honest when it’s peer-to-peer.

• Where do people go to complain about the job your product does? The frustration is the raw material.

Practical ways to find them:

• Google site:reddit.com “your problem in plain words” and note which subreddits keep appearing

• Open three or four posts you like and check what else those commenters post in

• Search Reddit for a competitor’s name and see where it comes up

Step 2: Pull the data

Don’t scrape, and don’t rely on Reddit’s own search. Reddit’s search caps out at roughly 1,000 results with no way past it, so anything beyond the most recent slice is invisible. Third-party scrapers hit the same wall.

Use an archive instead. Arctic Shift has the full history, stays current to about yesterday, and has a browser tool that requires nothing technical:

1. Go to https://arctic-shift.photon-reddit.com/download-tool

2. Type the subreddit name (no r/)

3. Choose posts and comments

4. Set a date range; the last three to six months is a good first pass

5. Download, then open the file in Google Sheets or Excel

That’s the whole thing. If you’d rather not click through it, any AI assistant with web or code access can do this for you. Just describe what you want:

“Pull posts from r/restaurantowners over the last six months that mention PoS, and pull out the recurring complaints.”

There’s an appendix at the bottom with the API details if you or someone on your team wants to automate repeat pulls.

Step 3: Read it properly

Feeding the file to an AI assistant works well. Ask for recurring themes, common objections, and the phrases that appear most.

Step 4: Incorporate it into workflows

The next step is to turn this into a small set of durable files that every copy task reads from, refreshed on a schedule.

1. The language bank

Verbatim phrases, bucketed by who said it and what set them off.

Don’t cluster by topic. Grep for the grammatical markers of unmet need: “I wish,” “if only,” “I’m drowning in,” “tired of,” “the problem is,” “my biggest problem,” “nobody understands.”

Bucket by persona first. “The schedule is a mess” is a labour-cost problem from an owner, a workload problem from a GM, a fairness problem from a server. One bucket each, or it averages into mush.

Feeds: Headlines, ad copy, hero sections, subject lines. You stop writing copy and start selecting it.

2. The objection index

Every reason people give for not buying something like yours, counted and dated.

Store the count, the average score, the best quotes, and the trend. Restaurants: the staff won’t use it. The processing fees eat whatever you saved on hardware. Menu setup took three weeks. Now I’ve got the tablets and the paper tickets.

The trend is the point. An objection that’s growing earns a section on the page. One that’s shrinking is a solved category problem (answer it and you sound dated).

Feeds: FAQs, objection blocks, comparison pages, battlecards.

3. The gap report

Your messaging, audited against the corpus. What you claim that the data backs and what the data is full of that you never mention.

The gaps are the half worth having, and they’re rarely about your product. A restaurant corpus is thick with anxiety about staff turnover, food costs, delivery-app commissions, and one bad Google review. None of it is a PoS feature. All of it is what your buyer is chewing on the day they hit your page.

Feeds: The blog calendar, top-of-funnel, campaign themes.

4. Competitor sentiment

Not share of voice. Specific failure modes.

“We left [X] because…” is the most valuable sentence in the corpus, and there are hundreds of them. It hands you the switching trigger, the breaking point, and the exact words a switcher uses to justify the move, which is the copy that converts the next one.

Feeds: Comparison pages, switcher campaigns, sales decks.

RAW CORPUS
  posts + comments, refreshed monthly
      |
      v
EXTRACTION PASS
  segment by persona, then
  match on trigger phrases
      |
      +--> LANGUAGE BANK
      +--> OBJECTION INDEX
      +--> GAP REPORT
      +--> COMPETITOR SENTIMENT
      |
      v
SYNTHESIS
  ranked priority list
  voice-of-customer brief
      |
      v
EVERY COPY BRIEF
  pages, ads, blog, decks
      |
      v
MEASURE WHAT SHIPPED
      |
      +--> feeds the next refresh

Important caveats

• It supplements customer conversations, it doesn’t replace them

• Reddit skews younger, more US, more English-speaking, more technically inclined.

• Competitors and their agencies post too. “We switched to X and never looked back” is often marketing.

• A growing share of Reddit text is bot output, karma farming, and reposted old threads.

• People post when something hurts. Status, ambition, and identity motives — often the real reason for a purchase — are nearly invisible in a complaint corpus.

Appendix: Automating the pull

Arctic Shift has a public API for repeatable pulls:

https://arctic-shift.photon-reddit.com/api/posts/search
  ?subreddit=<name>
  &after=<unix-timestamp>&before=<unix-timestamp>
  &sort=asc&limit=100
  &fields=id,created_utc,author,title,selftext,score,num_comments,link_flair_text

Swap /posts/ for /comments/ to pull comments. Notes for whoever wires it up:

• Paginate by setting after to the last item’s created_utc and deduping on id. Bump forward a second when a batch shares a timestamp, or the loop stalls.

• permalink is not a valid field — requesting it returns a 400 that kills the whole call. Rebuild links as reddit.com/r/<sub>/comments/<id>/.

• query=<terms> does full-text filtering and ANDs the terms — the fastest way to cut a huge subreddit down to relevant posts.

• Be polite: a short pause between requests and a real User-Agent string.

Once you’re past a few hundred thousand rows, load the corpus into SQLite rather than re-parsing files. Extraction passes become queries, monthly refreshes become an insert, and the whole thing still fits on a laptop.