Track 2: Knowledge Architecture

Process encoding gives an agent a procedure. Knowledge architecture gives it a world. Both are necessary. Neither is sufficient on its own.

This chapter is about the world part. What your organization knows, how that knowledge is structured, and what it would take to make the structure something an AI can actually use.

Why a flat wiki isn’t a knowledge architecture

Most companies that think they have organizational knowledge have a wiki. The wiki is full of pages. The pages are searchable. From a human’s perspective this looks like adequate organizational memory.

From an AI agent’s perspective it is essentially noise. There is no signal about which pages are authoritative. There is no signal about which pages are stale. There is no signal about how concepts on one page relate to concepts on another. There is no signal about which decisions depend on which evidence. The agent has to rediscover the structure on every query, badly.

A knowledge architecture is structurally different. It is closer to a graph than a list. Topics connect to other topics. Decisions connect to the evidence that supported them. Features connect to the customer problems they solve. Authority is explicit. Dependencies are explicit. Ownership is explicit. The agent traverses the graph the way a knowledgeable human would, because the graph reflects how the org actually thinks.

This sounds like a heavyweight thing to build. It isn’t. The right starting size is small. The right starting structure is obvious. The work is not in the size; it’s in the discipline.

The three things a knowledge architecture has to specify

Topics. What are the core subjects the organization needs to reason about? For most companies, the answer is between fifteen and forty. Product surfaces, customer segments, competitive landscape, pricing model, technical architecture, hiring philosophy, operating cadence. Resist the temptation to enumerate everything. The point is to capture what an outsider would need to know to make any reasonable decision in the org. If your topic list is over fifty, you’re listing pages, not topics.

Relationships. How do the topics connect? A pricing-model topic relates to the customer-segment topic and the competitive-landscape topic. A specific product-surface topic relates to the customer-problem topic it serves and the architectural-component topic it depends on. These relationships are the part that makes the structure useful for an agent. The relationships are also the part that almost no flat wiki captures.

Authority. For each topic, what is the authoritative source? When two documents disagree, which one wins? If you cannot answer this for a given topic, the topic is not yet covered by your architecture, no matter how many pages exist about it.

That’s the entire structural specification. Topics, relationships, authority. Fifteen to forty topics, each with its connections mapped, each with a designated source of truth. The artifact that captures this is sometimes called an ontology. Don’t be put off by the word. It’s a list and a graph and an owner-table.

Where to start

Don’t try to build the whole architecture at once. Pick the three or four topics your team references most often when making decisions, and map those first.

For most product companies, the first three are some flavor of:

• Who the product is actually for. Customer segments, the sharpness of the segmentation, the evidence behind it.
• What the product actually is. The surfaces, the value props, the boundary of “in scope” vs. “not in scope.”
• How the product is sold and priced. The model, the historical pricing decisions, the segments and their sensitivities.

These three topics have the property that almost every important decision in the org touches one or more of them. If your encoded processes (Track 1) are running against a coherent representation of these three topics, the quality of the output goes up immediately. If they’re running against your existing wiki, you’re putting the agent in the position of inferring all of this from scattered source material — and the agent will infer wrong, because it has no signal about which parts of the source material to trust.

Map these three topics. Make explicit the relationships between them. Assign an owner for each. Then move on to the next three. Within a quarter you’ll have a real architecture for the topics that matter most. Within a year, you’ll have one for everything that matters at all.

What “compiled” knowledge looks like

The best knowledge architectures don’t just store source material. They produce a compiled artifact — a clean, structured summary that the agent reads instead of the raw source.

This is the core insight in the Karpathy LLM-knowledge-base architecture from Chapter 1, applied at organizational scale. Source material is messy: emails, slides, transcripts, half-finished docs. The compiled layer is what your agent should actually be reading. It’s a maintained, owned, versioned summary of what the source material says, with explicit links back to the underlying evidence.

For each topic in your architecture, the compiled artifact has the same shape:

• The current position. What the org believes today, in tight prose.
• The evidence. The source material that supports the current position, linked.
• The decisions. The major decisions the org has made about this topic, with dates.
• The dependencies. Other topics this one depends on, and other topics that depend on it.
• The owner. One name. Not a team. A person.
• The review cadence. When was this last reviewed? When is it next due?

A compiled topic page like this is a small artifact — usually two to five pages. It’s not the full picture of the topic. It’s the picture of the topic that the org has explicitly chosen to be authoritative. That is what makes it useful to an agent, and that is what makes it possible to keep current.

The two failure modes to watch for

The first failure mode is over-modeling. A team gets excited about the structure, builds an enormous topic ontology, fills it with placeholder pages, and never gets to the part where any of it is actually maintained. Six months later the architecture is more out of date than the wiki it was supposed to replace. Avoid this by enforcing a small starting set — three to five topics — and not adding the next batch until the first batch is being actively maintained.

The second failure mode is under-authority. The team builds compiled topic pages, but doesn’t designate them as the authoritative source. The wiki keeps existing in parallel, with conflicting information, and nobody knows which one to trust. The architecture becomes one more place to look. Avoid this by being explicit, in writing, that the compiled topic page is the source of truth — and by being willing to delete or archive the parallel sources that contradict it.

What success looks like in 60 days

Sixty days from now, if knowledge architecture is going well:

• Three to five compiled topic pages exist, each with a named owner and a review cadence.
• The relationships between those topics are mapped, even if loosely.
• At least one encoded process from Track 1 is now drawing from a compiled topic page rather than from raw source material, and the output quality is visibly better.
• The team has started referring to the compiled pages as the source of truth in conversation, not just in theory.

That’s a real foothold. The next chapter — Track 3 — is about how to keep that foothold from collapsing. Without governance, encoded processes drift, compiled topics rot, and the architecture you just built becomes a liability instead of an asset within a quarter.