Creating a Product Truth Layer

One of the more effective workflows for building great software products with agentic tools is to maintain a core set of docs outside the repo (or .gitignored) that are then fired into a tokenized source-of-truth always available to the agent. This significantly helps consistency and effortlessly snaps the model to foundational truths that ought to be less probabilistic not only in software engineering but in product making. I call these product truth docs or genesis docs. A few examples:

• UI/UX/Brand: Common app layout patterns, components, app and font styling, various component states, notification and modal treatment

• GTM: Product position, value proposition, messaging, benefits and feature highlights

• Voice: How we speak to target audiences (ICPs, Investors and so on)

• Support & Documentation: This runs slightly different from the others. Support is continually exported to /docs via a custom skill that documents product how-to, decision logic as well as data and privacy concerns from both PRs and session transcripts. This flows straight into a code-to-docs flow that forms the basis of the support site. This is ongoing and run after every substantial PR arc or session where meaningful decisions are made that will need to be explained to customers.

The human-controlled pipe is the most important part. You control truth outside the reach of the agent and fire when a version change warrants a product update. Once fired into the app, they’re tokenized and available to the agent in its native language. Here’s a reasoning trace showing what happens when a probabilistic LLM makes a guess and then hits the tokenized truth:

“That’s the actual lockup artwork - the word mark overlaps..by design. Not a bug. Let me cancel state.” In this case, the model is working on Dossier, which has a 37 page UI/UX toolkit that the agent diffs against every time it works in that domain.

Again: “Source material is unusually candid and specific..”

One of the massive benefits of a “tokenized truth” that’s also downstream of human control is distributed system development. It is the case, many times, you’ll be building a mobile, web and desktop endpoint. You may also have product surface areas like transaction or receipt e-mails. With a tokenized truth, I can just say ‘refer to the brand kit in [repo] and style only from this source.’ It works incredibly well and the number of corrections I’ve had to make from the model’s first draft is minimal. Dossier, for example, is over 10 pages of every pattern, component and their states. It leaves few questions, which is the point. Your mileage may vary depending on how exacting your documentation is.

UI/UX/Brand is a good one because Brand and UX Bibles have been popular for awhile, although the analog for agents was trickier to work out. Another example that’s a bit more interesting is product positioning and messaging. I keep mine in a slide so it’s 1) disconnected totally from agentic workflows and 2) visual…I can drag and drop text and organize it quickly in different ways. You could use Apple Notes, Google Sheets, PowerPoint - whatever. Here’s what I wrote for the first version of Dossier and I still maintain in a markdown outside any commit or context window:

This should look familiar to most brand and product marketers because it’s the same framework we’ve been using for twenty-five years. It works because it forces you to be a product maker and think deeply about how to communicate the value of your product to the intended target audience. This is still something agents are not good at, despite their incredible coding prowess.

Another benefit is that the ongoing maintenance of these documents forces me to think deeply about things that really matter to making good products. Making software is one thing but making products is another. Products have a profit imperative and participate in markets. This sounds obvious but is not obvious at all because the models are relentless about trying to think for you. If you do not have time for deep focus to marinate on your principles, beliefs and thesis for why a product exists, you will not be able to triage the engineering work well. Yes, the model will build and release it. But it’s not clear you build the best thing you could with your time and you still have to get distribution.

LLM’s are amazing magic but their probabilistic nature means that they’ll get most things right, but many little things wrong at indeterminate times. A leap of thinking on solving race conditions is awesome; a leap of thinking on why a P3 edge case should refactor your codebase is not. Nor is improvising your product’s core positioning for the market you’re participating in. In the model’s effort to always be helpful, it will just eat its way through your cognitive efforts.

The one workflow I mentioned that’s slightly different is support. In this case I built a custom skill called /doc-from-chat. The agent reads the active session, and any other sessions you reference, and sweeps it for the parts a customer might care about: how a feature works, how the pieces fit together, the logic behind key decisions. Then it checks the project's existing docs folder, updates or writes the docs in-place. Dossier Support and Docs is a living example of this.

I never sit down and write support documentation outside the actual act of building the product. This is part of my overall belief that agentic coding will unlock a new era of marketing and support where most of the content will be a byproduct of the data exhaust from the product-making itself.

One might argue that this is a recipe for slop; if the marginal cost of another doc is zero, then the incentive is to create many worthless docs. Maybe. I think the workflows will improve. I’d also argue that if you’re setting up the genesis docs I mention in this article (voice, tone, positioning, brand, support) - you’re creating just the right amount of friction and iteration to produce meaningfully higher quality work.