Your product moved. Your content didn't.

If you want to know what your product does today, not what the roadmap says and not what the deck says, there has only ever been one way to find out. Engineers even had an acronym for it: RTFC. Read the code. Which is exactly why marketing, support and sales have always been a release or two behind. They were never going to read the code. Now they don't have to. Agents read the code, and they read it every time it changes. Everything in this article follows from that.

Your content is about your product

Every organization serves people through content. For a product company, nearly all of it is about one thing: the product, the community that forms around it, and the movement the product makes possible. The help center explains it. The sales deck promises it. The onboarding guide teaches it. The community forum argues about it.

And the product is not a fixed thing. It is alive. It changes every week, sometimes every day, and now that agents write a growing share of the code, it changes faster than any team of people has ever had to describe.

In the last article, I argued that knowledge is the new code: that what each role sees and what agents may do for them is decided by knowledge, so knowledge needs the rigor we give code. This one is about the product company specifically, where the relationship runs the other way too. The knowledge is about the code.

The truth is in the code

Ask what your product does right now, today, and there is exactly one honest answer: whatever the code does. Not the roadmap, not the brochure, not what the sales engineer remembers from the last demo. At any moment, the truth of the product is in the code.

You may not want to share the code. Most companies don't. But even if you do, and plenty do, sharing the code solves nothing here, because code does not push anything to anyone. A merge changes what the product does. It does not update the brochure, the help center, the sales deck, or the answer a support agent will give tomorrow. Open or closed, the code sits there, true and silent.

What people actually run on is what the code does: the capabilities it gives them, the user stories it fulfills, the value it delivers. That is a projection of the code, and it is the part the whole organization depends on. Marketing projects it onto buyers. Support projects it onto customers with a problem. Sales projects it onto a prospect's situation.

A capability on its own means nothing. It only means something against a problem someone has. That is why the natural carrier of the projection is an agent for each role: something that knows what the product can do and meets a person inside the problem they actually have.

Every release moves the truth

Here is the problem. The code moves and the content does not. A release ships approvals on mobile, and the help center still says approvals are desktop only. A pricing page describes last quarter's tiers. A support agent, human or otherwise, answers from a procedure that no longer matches the screen.

Nothing errors. Nothing warns. The content is simply less true than it was yesterday, and it gets a little less true with every merge. That is drift, and in a product company it is the default state of all content that is not actively being pulled back toward the code.

Until now, people carried that burden. A product manager wrote the release notes. A content manager updated the pages they remembered to update. A support lead noticed the same question five times and filed a ticket. It worked, roughly, when a product changed a few times a month. It does not work when agents are shipping to the code every day.

If agents are building the product, agents have to find the drift between the product and everything that describes it.

It runs both ways

The code informs the content. That part is obvious once you see it. The less obvious part is that the content informs the code.

Every question a customer asks the support agent, every search that returns nothing useful, every conversation where a prospect asks for something the product does not do yet: that is engagement with the knowledge, and it is the best product signal you have. It is already in your organization's own words. It just never reaches the backlog, because the people who could carry it there are busy.

So the loop looks like this. The code becomes capabilities. The capabilities become content. People engage with the content, and where they ask, search and miss becomes the backlog. The backlog becomes code. Every product company already lives inside this loop. The question is how fast it turns, and who carries each hop.

Every hop in that loop used to be a person's job. The point is not to remove the people. It is to let agents carry the hops so that people can review what the agents propose: a page that no longer matches the release, a ticket drafted from fifty variations of the same question, a note that the roadmap item customers keep asking about is three sprints out.

What one change looks like today

This is what we are building into Sharely, and most of the top of the loop is already running. It builds on what was there: the governed core that holds what each role may see, in each language, with its structure intact, and the sync from where content lives. Sharely for Drupal and Sharely for WordPress. Google Drive and OneDrive. Your website, which Sharely re-crawls and notices when a page changes or disappears.

The new part is the truth side. Sharely for GitHub connects as a read-only app. It reads each push, pull request, release and tag through GitHub's API and keeps no copy of your code. The first connection creates a role in your workspace, and we named it what it is: Product truth.

For every change, an agent reads the diff and writes down what it means in product terms: which capabilities it touches, which surfaces, and which gates stand in front of it, the plan, the flag, the permission. That is the projection from the previous section, made by a machine, from the code, every time the code moves. Then it checks that projection against every page it touches.

Each related page gets a finding: contradicted, stale, incomplete, or consistent, with the excerpt, a proposed edit, and a citation back to the lines of code that make it so. Where nothing related exists at all, that is a gap, and it comes with the nearest page and a draft paragraph. A person reviews each one: accept and assign it, edit it, or dismiss it as internal, not yet, or intentionally undocumented. Grouped by release, it answers the question every product marketer has before a launch: what has to change on the site before we announce this?

Jira and Asana connected this week. They bring the intent: the story behind the change. When a Jira issue reaches done or an Asana task completes, the agent compares what was planned with what the code actually did, and records where the two differ. That is the backlog talking to the code, and it is the first half of the bottom of the loop.

The second half is next. Searches that found nothing. Questions the agent could not answer. The same request asked fifty different ways. Sharely already measures all of it. Carrying it into the backlog, drafted for a person to accept, is where the agents go from here, and it is what closes the loop.

The truth is in the code. Pull everything else toward it, and pull the backlog toward the people.

Not only reacting. Composing.

Everything so far is about catching up. The code moved, so the content has to move. That alone is worth a great deal. But once you hold the three things together, the product truth as a vocabulary of capabilities, the content, and the problems people bring, something else becomes possible. You can get ahead of the code.

Most solutions are not one capability. They are a combination. Works offline, plus approval workflows, plus role-based access is not three features. It is a field technician getting a change signed off from a basement with no signal, which is a solution, and possibly one nobody else can offer. The interesting content lives in those combinations, and they are exactly what a team never has time to find. There are too many of them, and the ones worth writing about are rarely obvious from inside the product.

Agents can search that space. With the vocabulary in hand, they can enumerate the combinations, ask which ones solve a real problem for a real role, check which ones no competitor can match, and draft the page. A person accepts the proposal and publishes it. Then the loop does its work faster than it ever could. Within days you know, from search, from who lands on the page, and from what people and agents ask next, whether that combination mattered.

This is the part that feels like an explosion the first time you see it run. The product truth, the content, the problems, the backlog, and agents on every hop do not just keep the content true. Together they generate it, test it against the world, and feed what they learn back into what gets built next.

Agents keep the content true. Then they get to make it interesting.