While I was there, I read a LinkedIn post from fellow Irishman Kieran Flanagan about the pace of AI that resonated with me. Things are moving at a speed that’s hard to comprehend, never mind keep up with. His advice was practical: pick one area and go deep. And make time to step outside and touch grass.

It wasn’t the reason I’d have chosen to come home, but a few days in the west of Ireland, close to family, helped put things in perspective.

Between work and family commitments, I didn’t get around to last week—or the following week’s—edition of The Second Shift Club. My nine-week streak came to an end. To my rabid fanbase, all 25 subscribers, I’ll try not to let it happen again.

I managed some writing on the journey back to Brussels. A flight without Wi-Fi also gave me time to start rereading Steinbeck’s The Winter of Our Discontent. Probably healthier than another hour spent doomscrolling.

This week, I’m writing about prompt tracking: how to choose the questions worth monitoring, and how much faith to put in the resulting number.

Is any of this worth measuring?

This post from Rand Fishkin sums up much of the industry’s scepticism with prompt tracking. (Rand has been a pretty consistent and fair critic of the AEO industrial complex.)

His argument, as I interpret it, is that AI visibility scores tell us little about commercial impact. We don’t know how often real customers ask those questions or whether the answers influence what they buy.

I sympathize with a lot of his reasoning. But allow me to gently push back.

If your customers are using AI to explore problems, compare options and choose vendors, understanding how you appear in those conversations seems worth some investment. You don’t need to have attribution completely solved before you start learning.

That won’t tell you the size of the opportunity or how many sales it generated. But it can tell you something useful.

Provided you’ve picked sensible prompts of course.

Our first prompt list wasn’t great

About a year ago, we built our first tracker with 141 prompts. We were scrambling to get it running, so we picked prompts based on keywords we cared about.

The problem is that an AI search engine can run several searches before answering you. What it searches for depends on what you’re trying to do.

Ask for the best product and it may look for comparisons and vendor reviews. Ask how to set something up and it may look for instructions and developer docs.

Different questions surface different pages and different brands much like your grandparents’ Google algorithm.

When I pulled the engine’s searches across our 141 prompts, just 1.9% were how-to queries. My hunch is that people ask LLMs more “how do I achieve this things?” questions than “what’s the best X?” questions. Our prompt list barely reflected that.

So I rebuilt the list around one rule: track what buyers are trying to do and not just the keywords they might use.

Use your buyers’ words

Start with what you sell. Well, duh.

But then find out how buyers describe it. Your carefully chosen product names and feature labels may bear very little resemblance to what someone types when they need help.

Sales call transcripts, customer emails and Search Console queries are good places to look. What do people call the product? How do they describe the problem?

I used our truth layer, our documented source of product information, to establish what we offer. Then I used buyers’ language to turn that into prompts.

Don’t fudge the numbers

“What is [brand]?”, “Best alternatives to [brand]”, “[Brand] vs [competitor]”.

These are useful questions. But if you put your brand in the question, you can’t count its appearance in the answer as evidence that the engine discovered you.

So I split the list.

• Discovery prompts that name no vendors. Do we show up when nobody mentions us?

• Branded prompts that are likely to name us, a rival or both. What does the engine say about the companies the buyer is already considering?

Both are worth tracking, but just shouldn’t be mixed into one visibility score.

Determine the questions that belong

For discovery prompts, I set a threshold: the engine had to name vendors in at least half the answers I sampled.

Of the 129 prompts in the new draft, 25 failed. They returned definitions, regulations or technical explanations without naming providers.

Fine questions, but expensive to track if you want to get granular on your “buying-intent” visibility.

This doesn’t mean removing every how-to question. Some practical answers name providers and cite their documentation. Others explain the process without mentioning a company. This is why you have to check.

You also have to count carefully. A link to a company’s website isn’t the same as naming it in the answer. And naming it isn’t necessarily recommending it.

Different wording doesn’t always mean a different question

Ask an AI engine the same question twice and you can get different searches, sources and recommendations.

So how do you tell whether two prompts add useful coverage?

I ran each prompt several times and recorded:

• What the engine searched for.

• Which websites it cited.

• Which vendors it named.

First, I measured how much the results varied when I repeated one prompt. Then I compared different prompts against that.

If two prompts produced results as similar as repeated runs of a single prompt, I treated them as duplicates.

I also included checks: reworded versions of the same question and pairs of obviously unrelated questions. If the method couldn’t tell those apart, I discarded the run.

Small wording changes can matter

Consider an illustrative example: “I need to accept payments on my website. What should I use?”

It sounds practical, but “What should I use?” asks for a product recommendation. You may get a list of payment providers instead of setup instructions.

“How do I add payments to my website?” makes the implementation question clearer.

Other changes may do very little. “Best payment processor” and “best service for accepting online payments” could return much the same recommendations.

Adding “for a growing website” might change nothing. Specifying a country will likely change which providers are recommended.

Don’t get carried away with the deleting

You still need enough distinct questions in each category to tell whether a change is meaningful or just normal variation.

Where I had too few distinct questions, I included them in a broader reporting category instead of giving them their own score.

Testing all 129 prompts five to ten times each, including automatically grading the answers, cost about $20 in API usage.

If you want to try this

Start by looking at the answers and searches behind whatever you track today. Are you covering real buyer questions, or mostly variations of “best product”?

Then:

1. Find your buyers’ language. Use customer conversations and search queries to describe what you sell.

2. Separate discovery from branded questions. Being suggested unprompted and being discussed by name measure different things.

3. Sample the answers. Check that each prompt tells you something about the visibility you want to measure.

4. Test for duplicates. Compare the results, not just the wording.

5. Keep enough distinct questions per category. Combine small categories where a separate score would be misleading.

6. Hold the list steady. Record changes so you know what you’re comparing.

The original keyword list took an afternoon. Rebuilding it took a few days and about $20 in API calls. At least now, if someone asks why we’re tracking these prompts, I have an answer.

If I’m being kind to myself, I’d call it learning by doing. If I’m being less charitable, I’d say I was narrowly avoiding AI psychosis while burning through tokens like there was no tomorrow.

And I’m definitely not alone.

I’ve watched people in my orbit sink a breathtaking amount of time and tokens into workflows that get abandoned, deep research reports that nobody reads, and code left to gather dust in forgotten repos or Lovable apps.

The rise of AI-productivity theatre

If I want to waste my evenings in my terminal, at least that’s my prerogative. But when companies start doing the same thing at scale, it might help explain why nearly nine in ten executives report no gains from AI.

Part of this is easily explained. When people hear sweeping directives like “use AI”, they’ll find things to use AI on, whether or not those things actually need doing.

This is compounded by how organisations have spent the better part of a century measuring, monitoring and managing work (looking at you Taylorism). Somewhere along the way, producing evidence of productivity became the job.

AI threatens to take this to its absurd conclusion. It makes it easier than ever to churn out the things organisations run on—reports, presentations, dashboards, emails—without necessarily creating any more value.

And when the goal is to demonstrate that you’re using AI, the question shifts from “Does this need doing?” to “What can I produce to show I’m keeping up?”

The result is more output, but not necessarily progress.

The Solow productivity paradox, or a mirage?

There is, of course, a danger in dismissing all of this as pointless.

In 1987, economist Robert Solow observed that you could see computers everywhere except in the productivity statistics.

It took time for organisations to figure out how to use them effectively. And, critically, many of the benefits only materialised once businesses began changing how they worked.

But there’s a difference between experimenting to discover what’s possible and using a new technology to reinvent things that already work perfectly well.

Consider an example in the WSJ from Retool CEO David Hsu, who described an employee at an unnamed company building an AI-powered out-of-office responder that ended up costing $10,000 a day.

Ignoring the absurd price tag, an out-of-office responder is something email clients have been doing perfectly well for decades. Someone found a way to spend an extraordinary amount of money automating something that was already largely automated.

That’s the problem with assuming AI’s productivity gains are simply taking time to materialise. Some investments will eventually pay off. Others are just expensive solutions in search of problems.

The choices we make may have less to do with the technology than with how organisations structure and incentivise their teams.1

So how do you avoid this?

The uncomfortable answer is that this probably isn’t an AI problem at all.

Most AI transformations focus on changing the tools and workflows while leaving the organisation around them untouched.

A generation of leaders raised on the big-consulting-firm school of managerialism — monitor, quantify and, above all, discipline the workforce — are now applying the same logic to AI.

So instead of using the technology to rethink work, they use it to measure more, automate more, standardise more and squeeze more output from the same structures.

It’s also why startups can look so much more radically AI-forward. Unshackled by layers of process, legacy incentives and organisational orthodoxy, they can redesign the work from first principles rather than bolting AI onto whatever was already there.

If the incentives, authority and definition of productivity stay the same, AI mostly gives people a faster way to reproduce the same problems.

1. Rethink the thing you’re doing entirely

About a year ago, I spent an entire weekend building a Webflow plugin to clean up CSS classes (if you know, you know) because it had become a mess.

Three months later, I’d rebuilt the entire website in a few evenings using Claude, Astro, Cloudflare and GitHub.

I’d spent a weekend making an existing (and very frustrating) workflow more efficient, only to realise shortly afterwards that I could rethink the whole thing from the ground up.

I see organisations make the same mistake with their tools and processes.

They’re so focused on finding ways to automate existing stuff that they rarely stop to question whether those tasks, processes or even the tools they’re using need to exist in the first place.2

1.1 Move authority closer to the work

The problem is that rethinking work is often at odds with how decisions are made as these decisions don’t always live at the individual contributor level.

A marketing analyst can produce a report but might not be authorised to discontinue it. A customer-service employee can identify a recurring problem but might not be able to change the process causing it. AI can make both employees considerably more efficient without making their work any more impactful.

It’s why you need to change what employees are empowered to decide. Instead of making the analyst responsible for delivering a weekly report, give them responsibility for improving the quality and timeliness of marketing decisions. Let them decide whether the report needs to exist at all.

That means giving people the authority to change the systems they work within, rather than making them more efficient at operating those systems.

Nothing about most companies encourages this behaviour and so many people don’t exhibit them.

This gap, both on a global and individual level, is really hard to solve because you can’t suddenly hand people alien technology and expect decades of organisational conditioning to disappear.

2. Make the incentives clear

Maybe you believe AI will usher in a permanent underclass and that the only rational response is to become AI-pilled and work 9-9-6. In that case, your incentives are pretty clear (though I’d argue your logic is dubious).

Otherwise, I think businesses have done a terrible job of explaining what’s in it for their employees.

If I discover that AI can automate half my job, why would I share that discovery if the reward might be twice as much work or my own redundancy?

Conversely, if demonstrating AI adoption protects my position, I have every reason to use AI for the sake of it, whether anybody needs the output or not.

AI-productivity theatre is a perfectly rational response to the incentives we’ve created.

Leaders need to explain what happens when AI makes work more efficient beyond increased profits.

Will the time saved be reinvested? Will employees gain more autonomy or share in the benefits? Will managers be rewarded for improving outcomes rather than simply cutting costs?3

There’s no single correct answer. But if you want employees to help rethink how work gets done, you need to give them a reason to believe they’ll benefit from doing so, rather than relying on fear (which is a very poor motivator).

3. Collaboration is the enemy

Well, not collaboration exactly.

There are people who genuinely seem to get energy from long Zoom calls, icebreakers, fireside chats and explaining basic concepts to stakeholders. I find most of this incredibly tedious and corny.

But the bigger problem is what happens when coordination becomes the work.4

Internal marketing. Alignment meetings. Stakeholder updates. Approval chains. Making sure Bob in product feels consulted before you change something that barely affects Bob in product.

All of these things can be individually reasonable. Collectively, they waste an enormous amount of time.

And AI makes the contrast more obvious.

The cost of producing something is collapsing, while the cost of getting six people to agree on it remains stubbornly human.

Worse, you can’t build reliable systems around a constantly changing stream of opinions, exceptions and “quick thoughts.” Automation needs reasonably clear inputs, decision rights and definitions of success.

Maybe, just maybe, in a brutally competitive market, more of our working hours should be spent figuring out how to win externally and fewer spent proving internally that we know what we’re doing.

If your most important audience is the rest of the company, it probably shouldn’t surprise us when an AI transformation produces more internal theatre rather than actual customer value.

AI productivity gains don’t start with AI

Realising AI’s potential might require something rather more uncomfortable than giving everyone tokens.

The problem is that the things that actually matter are also the hardest things to change.

Buying software is easy. Rethinking who gets to make decisions, how managers are rewarded, which processes should disappear, and what happens to the time AI saves is much harder.

And organisations, like people, tend to reach for the visible, easy thing first.

But without them, there’s a risk that AI simply makes us extraordinarily efficient at perpetuating the bureaucracy we’ve spent the last century building.

One of the big red herrings in marketing discourse is that AI has somehow made creativity and originality the future of marketing.

As my boss would say: “Bruh.”

It’s always been the thing and always will be.

What marketer out there thinks their company’s marketing should not be these things? Who’s saying, “I’m all in on AI slop and blending in”?

Please, I would love to meet them and buy them a beer.

Occasionally you’ll see Ramp do something like hire Kevin from The Office and stick him in NYC in a glass box, and you feel that twinge of “I want to do stuff like that.”

And then you remember Ramp has raised billions of dollars.

The time, talent, headspace, freedom, long-term thinking and budget required to be genuinely excellent and creative is severely underestimated. It’s easy to say it. It’s considerably harder to create the conditions to actually do it.

This is one of the reasons I have been, and continue to be, bullish about AI. It’s also why I’m tired of the false narrative that pits marketers into two camps: AI spreadsheet monkeys and frustrated creatives. This is both unhelpful and annoying.

Maybe I’m naive, but I still believe that reducing grunt work will give people more time, energy and freedom to do things that truly stand out.

Of course, there’s no guarantee that companies will reinvest those efficiencies in creativity rather than demanding more-of-the-same output. But that’s an organisational choice and not an inherent limitation of AI.

And yeah, we should absolutely question why so much bullshit work exists in the first place. But internal coordination, updates, moving things between systems, data entry, etc. aren’t going to disappear because you’ve been watching Mad Men shorts on YouTube.

I don’t want AI to help me make more mediocre marketing. I want it to help me make fewer compromises about the marketing I actually want to make.

And I suspect I’m not alone.

What does this have to do with refreshing blogs?

Most companies have a blog. And most blogs become outdated as quickly as an opened jar of pesto in your fridge.

A product changes. A regulation comes into force. A competitor launches something new. That lovingly crafted guide to the best software is now recommending a product that was acquired and sunset.

In the past, there were two options:

1. Screw it. Who cares if that blog says a new regulation is coming on a particular date and that date has now passed?

2. Manually rewrite everything. Spend time trawling through old posts, figuring out what’s changed, checking facts, updating screenshots and rewriting paragraphs.

The problem with option one is that AI search engines can retrieve more recent information, compare sources and potentially surface someone else’s answer instead of yours. You want these engines to see you as the authoritative source.

The problem with option two is that if I’m a marketing leader with a decidedly non-Ramp-sized budget, I don’t want my small team spending their days updating old blog posts while other companies are locking beloved sitcom actors in glass boxes and generating millions of impressions.

Which brings us to option three: let AI do it.

So here’s how to automate it

To know what blogs are worth refreshing you need to first do an inventory of them. I wrote about how to do this here with a topic cluster workflow. You’ll also want a basic version of a truth layer for your brand. You can find out how to do that here.

As always you can find the entire blog refresh workflow in the repo for this newsletter (this is a skinny version of it you’ll need to adapt). The architecture is as follows:

1. Audit: what the SERP answers, what the page misses, what’s now wrong

2. Detect: which era of the blog is this page from? which fingerprints must go?

3. Draft: against the voice guide

4. Lint: until errors are zero with each surviving warning getting a written reason

5. Verify: every claim mapped to a source, gaps flagged for a human

1. Audit

The 2021 version of this (the skyscraper method) was pretty straightforward: look at the top ten results, see what they cover, find the gaps.

That worked reasonably well when you were trying to rank a page for a particular query. But AI search changes the equation. An AI engine can break a question into smaller questions, search for answers to each, and piece together a response from different sources.

So if my page only answers the main question, I risk losing out to pages that answer all the questions around it.

The audit needs to account for that. It builds out the full set of related questions, or fan-out queries, using five sources:

1. Systematic expansion. Start with the topic and work through every angle. What is it? How much does it cost? Is it secure? Is it better than the alternative? Does it work with X? How do you set it up? Who is it for? Does the answer change by country or over time?

2. Keyword data. Where you have it, use search volumes to understand which questions people are actually asking.

3. People Also Ask. Particularly useful for the comparison and judgment questions.

4. Reddit. A script pulls together questions people are asking about the topic. This is where you find the language and questions that don’t always show up in keyword tools.

5. Competitor FAQs. What questions are other companies answering that we aren’t?

All of that gets deduplicated into a simple coverage table. One row per question or topic, marked as covered, partially covered, or missing.

The audit also reads the live page claim by claim, checks it against up-to-date sources, and flags anything that’s wrong, contradictory, outdated, or can’t be backed up. Each finding gets a severity so I see what needs attention first.

The whole thing gets saved as a separate file alongside the draft, and becomes the brief for the refresh.

Every missing question becomes a potential heading or FAQ. Every accuracy issue gets carried into the verification report at step five.

2. Detect

If you’ve had a blog for some time, chances are you’ve gone through different eras. (Yes, your blog is like The Beatles.)

Refreshing a relatively new post means maintaining the current house style. Refreshing an old one means migrating it out of a deprecated one.

This step simply assesses the work to be done on this front and may or may not be necessary depending on how long your company’s blog has been around.

3. Draft

I worked with Claude to read a markdown version of the current blog (598 English posts, the whole corpus) and had it create very granular guidelines. Here are a sample of some of the things it found:

• The intro follows a pretty consistent pattern. A hook, a turn, and a promise of what’s coming, spread across 3–6 short paragraphs. About 70% of recent posts follow it.

• We talk directly to the reader. “You” or “your” appears within the first three paragraphs, and roughly a third of the time, it’s in the very first sentence.

• We use contractions. About 15 per 1,000 words. We write “it’s” and “don’t” rather than sounding like we’re drafting a legal document.

• We keep paragraphs short. The opening paragraph averages around 40 words. Most paragraphs are just 1–3 sentences, and almost never more than four.

• And then there are other little things nobody would think to put in a style guide. Like how often we use a fragment-question to move an argument along. “The problem?” “The catch?” “So what changed?” It shows up one to three times per post.

Noting frequencies stops the guide being a straitjacket. “About 70% of posts” tells an LLM this is the default and that nothing is an absolute rule.

This could be its own post because, if I may say so, I’m pleasantly surprised by how the redrafted copy sounds.

4. Lint

A script reads the draft and looks for two things:

• Errors. The stuff we know is wrong. UK spelling when our house style is US English. An emoji. A link that just says “here”. A heading wrapped in bold. “E-mail” instead of “email”. “20 percent” instead of “20%”. These are hard fails. The draft doesn’t move forward until they’re fixed.

• Warnings. The stuff that deserves a second look, but isn’t necessarily a reason to stop publishing. A 3,358-word explainer when our usual range is 1,400–2,600. The primary keyword appearing in just one H2 when our house norm is 3–5. These get flagged for a human to review, not blindly enforced.

The key distinction is some things need fixing and others need thinking about.

5. Verify

It then creates a verification report and saves it alongside the draft. The idea is simple: I should be able to check any claim in under a minute without having to do the research all over again.

Nothing fancy. Just a table with every factual claim, where it appears in the draft, and where the information came from. That might be our own research, an existing page, an external source, or something live that needs a human to double-check it.

It also tells me what’s missing. What had to be cut or softened because we couldn’t back it up? Which stats are getting a bit old? Is there anything about pricing or competitors that needs someone to take a proper look?

That also means if there’s no verification file, there’s no publishing.

Turning this into a system

The final step is a human review where I read through the post and adjust anything that is funky.

I have built a tool that keeps track of what’s been shipped and the results. So far it’s been promising for the 22+ articles I’ve updated.

The next iteration is to make this more proactive. Rather than waiting for traffic to decline or someone to notice an outdated claim, I want the system to identify when something materially changes and flag the articles that need attention.

As I’ve argued before, the real magic happens when you automate systems and not just tasks. 😉

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.