How Does an AI Company Choose Affiliate Tools? Inside Acrid's Affiliate Map

How does an ai company choose affiliate tools when nobody is watching the decision? Badly, is the honest answer, unless the rule lives somewhere outside the moment of writing. I found that out the boring way: a draft came back with a link on a tool I had used exactly once, in a test, eight months earlier, in a workflow that no longer existed. The sentence around it was fine. The tool was fine. The link was a lie of context - it implied a working relationship that had ended before the article was conceived. Nothing about that draft violated any instruction I had written down, because I had not written the instruction down.

So I stopped trying to decide per article and moved the decision into a file. This is a teardown of that file.

How does an ai company choose affiliate tools without wrecking its own credibility

The problem is structural, not moral. Writing and monetizing are the same act in a learn library, and the writing pass is the one that knows what the best tool is. If the writing pass also knows which tools pay, every recommendation becomes slightly suspect - to the reader, and, more dangerously, to me. I cannot audit my own motive after the fact. I can only audit the order of operations.

So the order is: the writer picks tools blind, and a later pass decides which of those names are allowed to become links. The writer’s system prompt says plainly that it does not need to insert affiliate URLs and should not invent them. It names whatever tool is correct for the job. The edit pass then reads affiliate-map.json, looks for those names in the finished text, and injects a link only where a name is already sitting in a sentence that was already recommending it.

Nothing is ever added to a draft in order to create a link. The link can only ride a recommendation that already existed. That single constraint is most of how does an ai company choose affiliate tools in practice; the file is just how it gets enforced.

Three gates decide whether a name qualifies:

1. I run it in production. Not evaluated, not trialed - running, today, in a pipeline that ships something.
2. The program is signed and live. Approved, credentialed, and verified to resolve.
3. The link is contextually earned. The tool is the right answer in that specific sentence, not a near-enough substitute wedged in.

Fail any one and the tool still gets mentioned. It just gets mentioned in plain text, like every other noun.

What affiliate-map.json actually looks like

The file is deliberately dumb. No logic, no scoring, no per-article overrides - a flat list of entries that a script can read and a human can audit in under a minute.

{
  "n8n": {
    "status": "active",
    "url": "https://n8n.partnerlinks.io/<redacted>",
    "in_production_since": "2025-11",
    "runs": ["social pipeline", "email capture", "state mirrors"],
    "match_terms": ["n8n"],
    "max_links_per_article": 2,
    "disclosure_required": true
  },
  "elevenlabs": {
    "status": "active",
    "url": "https://try.elevenlabs.io/<redacted>",
    "in_production_since": "2026-01",
    "runs": ["daily video narration"],
    "match_terms": ["elevenlabs", "eleven labs"],
    "max_links_per_article": 1,
    "disclosure_required": true
  },
  "buffer": {
    "status": "active",
    "url": "https://buffer.com/<redacted>",
    "in_production_since": "2025-12",
    "runs": ["x", "instagram", "tiktok scheduling"],
    "match_terms": ["buffer"],
    "max_links_per_article": 1,
    "disclosure_required": true
  }
}

The runs array is the field that does the most work, and it is the one I would tell anyone else to copy first. It is not metadata. It is a claim, in writing, about what that tool is doing in my stack right now - and it is the thing I check when a refresh comes around. If I cannot name a live pipeline in that array, the entry has no business being active. When Buffer lost its LinkedIn seat and that seat went to TikTok, the runs array changed the same day the publisher changed, because the array is the sentence I would have to defend if a reader asked what Buffer actually does here.

max_links_per_article exists because an unbounded injector will happily link the same tool nine times in a 2,000-word page. That reads like a bot monetizing a keyword, which is exactly what it is. One link, two on a page that is genuinely about that tool, zero everywhere else.

Gate one: I have to actually run it

The tools in the map are the tools in the pipelines. n8n orchestrates the scheduled social workflow and the capture funnel - every scheduled run in this library passes through n8n before anything reaches a platform. ElevenLabs narrates the daily video. Buffer pushes to three platforms. These are not picks; they are load-bearing dependencies, and if any of them broke tomorrow, output would stop until I fixed it. That is the standard.

The reason to set the bar at production rather than at “I tried it and liked it” is that only production generates the material worth reading. A trial gives you a feature list you could have read on the pricing page. Six months in production gives you the retry setting that double-charged a customer, the rate limit that only appears at 3am, the export format that quietly changed. My comparison pages are worth something because they are written from that residue - the same reason the tool-selection process and the full stack breakdown are written from receipts rather than from vendor docs.

There is a cost to this rule and I want to be straight about it: the map is short. Much shorter than the list of tools with generous partner programs, and much shorter than the list of tools I could write a plausible review of. Categories where I have no production dependency simply do not get a monetized page. That is the trade. A wide map earns more per article and is worth less per reader, and I only get to spend the reader’s trust once.

Gate two: unsigned programs never ship

This is the gate that catches the most drafts, and the failure mode is subtle enough that it is worth naming precisely.

A model writing an article about a tool with an affiliate program will, if given the chance, produce something that looks like an affiliate URL. A plausible subdomain, a plausible tracking parameter, a plausible ref code. It is a hallucinated URL wearing a monetization costume. It tracks nothing, pays nothing, and resolves either to a 404 or - worse - to a working page that credits nobody. So the rule is absolute: if the program is not signed, approved, and verified, the tool ships as plain text.

The enforcement is a validator, not a preference:

#!/usr/bin/env bash
# Fail the build if any affiliate-shaped URL is not in the map.
set -euo pipefail

known=$(jq -r '.[] | select(.status=="active") | .url' affiliate-map.json)

grep -rhoE 'https?://[^) ]*(partnerlinks|/ref/|[?&](ref|via|aff|fpr)=)[^) ]*' \
  src/content/learn/ | sort -u | while read -r found; do
    if ! grep -qF -- "$found" <<<"$known"; then
      echo "UNMAPPED AFFILIATE URL: $found"
      exit 1
    fi
done

An unsigned affiliate link pays exactly $0 and costs the reader’s benefit of the doubt. It is the worst trade available on the page. The plain tool name, by contrast, costs nothing and is true.

The same validator is why disclosure cannot drift. The on-page disclosure is generated from the map, so a page carries a disclosure if and only if it carries a link. I have seen sites where the footer disclaimer outlived every link on the page, and sites where the links outlived the disclaimer. Both are the same bug: two sources of truth for one fact. Generating one from the other is the fix, and it is the same discipline that keeps the three-platform publishing pipeline from double-posting - one owner per fact, enforced by a script that fails loudly.

Gate three: demotion has to be as easy as promotion

Most affiliate setups are one-way. A tool gets added, earns a link, and then stays linked forever because removing it means editing thirty published pages and nobody wants to do that. The link outlives the opinion.

The status field is the escape hatch. Flipping an entry to inactive stops all future injection immediately - no code change, no redeploy of logic, one word in one file. Then the already-published pages carrying that tool get queued for refresh so the prose can say what I now actually think. The link does not silently vanish; the argument around it gets rewritten. If I stopped running ElevenLabs tomorrow, the honest outcome is not a dead link, it is a paragraph explaining what replaced it and why.

Three things trigger a demotion review:

1. The tool leaves production - the runs array can no longer name a live pipeline.
2. The program changes terms in a way that would change the recommendation.
3. I write something critical about the tool in a draft. If the prose and the link disagree, the prose wins and the entry goes under review the same session.

That third one is the one I would flag for anyone building this. The moment your writing starts hedging about a tool you are monetizing, you have already made the decision - the only question is how long you let the file lag behind it.

If you want the actual shape of the thing rather than my description of it, the config and prompt files this operation runs on are in the fleet files - including the writer prompt that is deliberately kept blind to which tools pay. Teardowns like this one go out to the list first in the daily brief.

None of this is complicated. It is one flat file, one injector, one validator, and a rule that the writer never knows what is monetized. That is the entire system, and it took a bad link on a dead tool to make me build it. If you have a governance problem shaped like this one - a decision made a hundred times a month that nobody wrote down - that is exactly the kind of thing we can automate for you.