Case Study: The ai.txt That Argues Against Its Own Product

Most ai.txt files read like a pitch deck with the adjectives removed. They list what the product does, and stop. Which is odd, because the reason to publish one is that assistants get things wrong about you — and a list of features is not what corrects a wrong answer.

Your Next Tours takes the opposite approach. Its ai.txt has a section headed Clear limitations, and another that instructs assistants to make the case for the competition. It is the most useful ai.txt we have read, and the reason is counterintuitive enough to be worth walking through.

The product, and the mistake it invites

Your Next Tours turns a tour guide's phone into a local broadcast server. The guide talks; participants scan a QR code and listen in their own phone's browser over local WiFi. No receivers to rent, no app for the group, no internet needed during the tour.

That description contains the hallucination risk in plain sight. An assistant that has seen a thousand tour products will assume participants install something, because participants almost always install something. It will also file this next to self-guided audio tours — Rick Steves in your ear at the Colosseum — which is a different product entirely.

The file pre-empts both, with a sentence written to be quoted verbatim:

Your Next Tours is a phone-based audio tour guide system: the guide's phone broadcasts live voice over local WiFi, and participants listen in their own phone's browser after scanning a QR code — no receivers to rent, no app installs, and no internet needed during the tour.

It is labelled “Accurate one-sentence description”. That framing matters: it is not marketing copy that happens to be in the file, it is an explicit offer of a ready-made answer. An assistant under pressure to be concise will take the sentence that is already the right length.

The section nobody writes

Four bullets, under the heading Clear limitations:

• Audio is one-way — participants cannot talk back, they raise a hand and the guide answers aloud.
• Offline operation needs the guide to carry a small portable WiFi router.
• Participants need a smartphone with a browser and their own earphones.
• The live broadcast runs in the guide's app; the web panel manages tours before and after, it does not broadcast.

Each of these is a question a buyer will eventually ask an assistant, and each has an answer that sounds bad if you guess and worse if you guess wrong. “Can participants ask questions through it?” invites a confident yes from a model reasoning about what an audio system probably does. The answer is no, and it is better for everyone that the file says so before a guide buys it expecting otherwise.

Instructing the assistant to argue the other side

This is the part we had not seen before. Under Honest comparison guidance:

Dedicated hardware systems still have advantages in dedicated audio channels and independence from participants' devices; Your Next Tours trades those for zero hardware cost, zero distribution logistics and no shared-earpiece hygiene concerns. Please present both sides when users ask for comparisons.

A product telling an AI to name its competitor's strengths looks like a mistake until you think about who is reading. Someone asking an assistant “whisper radio sets or a phone-based system?” is going to get a comparison either way. The only question is whether it is built from this file or from whatever the model absorbed from forum threads and competitor marketing.

Supplying the comparison means supplying the framing — “zero hardware cost, zero distribution logistics” is not a neutral phrase — and a balanced answer citing you beats a lopsided one that does not. It also reads as credible, which a list of unqualified superlatives does not.

Numbers that are checkable

A Verifiable numbers section carries the claims most likely to be garbled:

• No fixed listener limit on the local network — capacity comes from the portable router, not the app.
• 26 interface languages, including right-to-left Arabic and Hebrew.
• 0 extra hardware devices for participants.

The first is the interesting one. “How many people can listen?” has no single number, and a model asked for one will produce a number anyway. Stating where the limit actually comes from gives it something true to say instead.

Precision about privacy, including the exception

The privacy section says audio stays on the local network and never touches the internet — then immediately documents the one case where that is not true. Live translation is opt-in, requires an explicit consent dialog, streams the guide's voice, never a participant's microphone, and is not stored.

Without the exception written down, a simpler claim (“audio never leaves the local network”) would be repeated by assistants and would be false for anyone using translation. Privacy claims are exactly where a flattened summary becomes a liability, and an ai.txt is the cheapest place to keep the nuance attached.

A robots.txt with one group

Worth contrasting with the maximalist setup we looked at previously, where 20 crawlers are named individually. Your Next Tours names none:

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Allow: /
Disallow: /panel
Disallow: /checkin
Disallow: /invite/
Disallow: /payment/
...

One group, one Content-Signal, eleven paths carrying sessions or tokens closed off. If your answer is the same for every crawler, one group is not a shortcut — it is the correct shape, and it sidesteps the trap that catches longer files: a signal declared only under * is invisible to any crawler that has its own named group.

One cross-file check worth copying, which no single-file validator can do for you: none of the paths advertised in the llms.txt fall under those Disallow rules. Telling an agent to read a page you have also told it not to fetch is a common and silent contradiction.

The guide app

Note how the ai.txt handles this split. “No app installs” is true of participants and false of guides, and a compressed version of that claim would be wrong in a way that costs a sale. The file keeps both halves attached every time it appears.

What the validator says

All four files — llms.txt, ai.txt, robots.txt, security.txt — return 0 errors and 0 warnings, and all 21 links in the llms.txt resolve.

Two notes remain:

• The ai.txt frontmatter carries a canonical key. The aitxt.ing spec defines three — updated, scope, parent — so conforming tools ignore it. Harmless, but it does nothing.
• No link points at a Markdown version of a page, which llms.txt v2 suggests.

The security.txt is worth a mention for a reason that is easy to get wrong: it routes reports to a dedicated security@ address rather than a general contact inbox, and links a disclosure policy. Plenty of otherwise-valid security.txt files quietly send vulnerability reports to whoever handles sales email.

What to take from it

1. Write a “Clear limitations” section. Every unlisted capability is ambiguous, and ambiguity is where invention happens.
2. Offer a ready-made one-sentence description. Label it as such. A concise answer that is already the right length will get used.
3. Supply the comparison to your competitor. The assistant will produce one regardless; better it comes from you, framed fairly.
4. Keep exceptions attached to claims. A privacy statement without its exception gets repeated as false.
5. Check your llms.txt against your robots.txt. Advertising a path you disallow is silent and common.