Yet another Anthropic researcher quit, and on his way out stated there’s a non-trivial chance AI kills us all within the next 10 years. Gulp.
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.
There’s the law (you can’t assault someone)
The school rules (no phones in class)
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.