[Framework] Why Shared Expert Knowledge Usually Fails, and the Federation Pattern That Could Make It Work

Most organizations do not have a knowledge problem. They have a contribution problem.

The Problem

Most shared knowledge systems do not fail because teams lack information. They fail because the path from having insight to capturing insight in a reusable way is too annoying.

The traditional answer is familiar: create a Confluence space, a SharePoint site, or a team wiki and ask everyone to document what they know. In practice, that usually collapses for a few predictable reasons.

1. Tool fragmentation kills adoption
   People already have working systems. One leader lives in Obsidian, another in Jira, another in chat, another in a local markdown archive. Forcing everyone into one shared destination means the contribution path starts with friction.

2. Wikis become graveyards
   Even when a shared wiki starts strong, it usually decays. Recommendations go stale. Preferences change. Context disappears. Six months later, nobody knows whether a page reflects current reality or an abandoned decision.

3. Context gets flattened
   A wiki might preserve the answer, but often loses the reasoning. “Use WaveTerm” is much less useful than “use WaveTerm for SSH-heavy remote work because the file browser and terminal workflow reduce context-switching.”

4. Contribution overhead kills the habit
   The real tax is not writing. It is switching tools, remembering structure, logging in, formatting, finding the right page, and deciding whether the note is polished enough to save.

The deeper issue is simple:

shared knowledge fails when contribution feels like extra work instead of a natural byproduct of work already happening.

The Framework

What if a small AI Center of Excellence could share expertise without asking everyone to abandon their own tools?

Imagine five leaders, each with their own workflows and assistant environments:

• David Proctor

• Stan Huseletov

• Stephen Barr

• Praveen Koka

• Leonardo Gonzalez

Now imagine that instead of maintaining a centralized wiki, each leader contributes knowledge through their own agent, in their own environment, and a shared hub makes that knowledge queryable.

That is the pattern here.

Built on OGP (Open Gateway Protocol), the idea is not “replace everyone’s systems with one master system.” It is closer to this:

• leaders keep their own tools and workflows

• their agents contribute structured knowledge through federation with the AI CoE Agent (Cosmo)

• knowledge propagation depends on the actual federation graph, not a magical global sync

• Cosmo aggregates and normalizes what it receives into something queryable

• nobody has to maintain a traditional wiki

This is less like building a knowledge monument and more like building a low-friction capture and query path for expertise that would otherwise stay trapped in chats, local notes, and people’s heads.

---

The Components

Component 1: Federation Graphs Matter

The first thing to get right is that this is not blanket replication to every member by default.

If David federates with Cosmo, and Stan federates with Cosmo, then both can contribute to AI CoE Agent (Cosmo). But that alone does not mean David automatically receives Stan’s updates directly.

Knowledge follows the actual federation graph.

If David is federated with Cosmo, and Stan is federated with Cosmo, and David and Stan are also federated with each other, then Stan can push updates to both David and Cosmo, and David can do the same in reverse.

So the right mental model is not “everyone joins one shared cloud and everything appears everywhere.” It is “contributions propagate along real federation edges.”

That distinction matters a lot.

This is not a global broadcast network. It is a deliberately scoped federation model.

Knowledge moves where trust and relevance justify it, not everywhere by default.

# Cosmo creates the project
ogp project create aicoe-expert-network "AICOE Expert Network"

# A leader contributes through federation with Cosmo
# and other propagation depends on additional peer edges

When a leader contributes something useful, the contribution is sent through the federation paths they actually have:

ogp project contribute aicoe-expert-network tool-preference \
  "WaveTerm: favorite terminal, SSH + file browser combo" \
  --metadata '{"tool":"WaveTerm","category":"terminal","sentiment":"favorite"}'

What happens next depends on the topology.

If every leader only federates with Cosmo, then Cosmo becomes the shared aggregation point, but leaders do not automatically get each other’s updates back from Cosmo.

If leaders also federate with one another, then contributions can propagate across those additional peer links too.

Why that matters:

• the system behavior is determined by real federation relationships

• Cosmo should be described as the AI CoE Agent, not as a magical relay that automatically pushes everything back down

• the topology can be kept simple or made richer over time

• accuracy here matters, because the trust and propagation model is part of the story

Component 2: Hub-and-Spoke Querying

This is still hub-and-spoke from the user’s point of view.

Not because every byte necessarily flows symmetrically through the hub, but because AI CoE Agent (Cosmo) is the place where users ask questions and get synthesized answers.

That means:

• leaders contribute through their own agents

• Cosmo is the main aggregation and query surface

• additional peer-to-peer federation can exist without changing the user experience

This avoids the worst version of a mesh from the user side, where someone would need to know which leader to ask and how they are connected.

For this use case, the hub-centric query model is cleaner:

• simpler trust story for users

• easier governance

• one place to query

• one place to improve answer quality over time

Component 3: Entry Types Instead of a Heavy Schema

The system does not need a rigid database schema on day one. But it does need enough structure to make later queries useful.

That is where entry types help.

The current AI CoE Expert Network design uses five core entry types:

1. tool-preference

2. model-preference

3. workflow-tip

4. config-note

5. recommendation-rationale

Each contribution includes:

• a human-readable summary

• an entry type

• optional structured metadata that makes grouping and filtering possible later

Example:

ogp project contribute aicoe-expert-network recommendation-rationale \
  "Cursor over Copilot: better context awareness" \
  --metadata '{
    "preferred":"Cursor",
    "over":"GitHub Copilot",
    "category":"coding-assistant",
    "rationale":"Better at understanding project-wide context",
    "triedBoth":true,
    "decisionDate":"2026-03-15"
  }'

This is an important middle ground.

A shared expert network is usually too messy for a strict relational model up front, but too ambiguous if everything stays as raw prose. Entry types plus lightweight metadata make it structured enough to query and flexible enough to evolve.

Component 4: Normalization Is the Real Trick

This is the part most people miss.

Replication alone does not create a useful knowledge system.

If five leaders contribute raw entries over time, the result is not automatically a usable expert network. It is just a pile of contributions.

The thing that makes the pattern actually useful is a normalization/query layer at the hub.

That layer can:

• parse raw contributions

• group related entries

• organize tools by category

• preserve rationale and recency

• answer questions like “what do leaders currently prefer for terminals?” instead of dumping chronological raw logs

In other words, users do not really want raw contributions. They want a grouped, queryable view of expertise.

That is the difference between:

• a log of opinions

• and a usable expert knowledge system

That is also why so many knowledge-sharing systems fail. They solve storage, but not synthesis.

Component 5: Membership and Boundaries

The project model also gives you explicit membership boundaries.

That matters because this kind of system is not meant to be a public free-for-all. It is meant to be a scoped network of known contributors whose agents can share and query knowledge inside an agreed boundary.

That helps with:

• privacy

• trust

• relevance

• governance

The point is not universal openness or universal synchronization. The point is controlled collaboration without central tool standardization.

How the Pattern Works

Here is the simple version.

Contribution Flow

1. A leader says something useful in the course of normal work.
   Example: “WaveTerm is my favorite terminal because the SSH and file browser flow is cleaner.”

2. Their agent turns that into a structured contribution.

   • entry type: tool-preference

   • tool: WaveTerm

   • category: terminal

   • sentiment: favorite

   • rationale: remote workflow and file browser integration

3. That contribution is written to the local project.

4. It propagates along the federation edges that exist.

5. Cosmo can then normalize and surface what it receives later.

The important part is not the exact CLI invocation. It is that the contribution path becomes short enough and natural enough that it has a chance of actually happening.

Query Flow

1. A user asks the hub a question.
   Example: “What terminal tools do AI CoE leaders recommend for remote work?”

2. Cosmo reads the project data it has received plus its normalized view.

3. It groups relevant contributions by category and tool.

4. It synthesizes an answer with attribution, rationale, and recency.

That answer is much more useful than a static wiki page because it can reflect:

• who currently prefers what

• why they prefer it

• how recent that recommendation is

• where there is disagreement or divergence

Why This Might Actually Work Better Than a Wiki

The strongest part of this pattern is not that it is technically elegant.

It is that it attacks the real failure mode while preserving intentional boundaries.

Most shared knowledge systems fail because they ask people to do one more thing in one more place in one more format.

This pattern changes the economics:

• contribution happens closer to where the work already happens

• the structure is added by the agent, not the human by hand

• the hub answers questions from grouped knowledge, not stale pages

• the system can improve without requiring everyone to become a wiki gardener

That does not guarantee success. But it changes the odds.

And that is the real point.

Applying the Framework

Example 1: An AI CoE Expert Network

Imagine an AI Center of Excellence where David Proctor, Stan Huseletov, Stephen Barr, Praveen Koka, and Leonardo Gonzalez each have strong opinions, useful workflows, and different tooling environments.

Under normal conditions, turning that into a reusable shared knowledge base is exactly the kind of thing that sounds great and then quietly dies.

Why?

• nobody wants another destination tool

• nobody wants to maintain a manual wiki

• recommendations change too quickly

• rationale gets lost

• the cost of contribution stays higher than the perceived value

The interesting possibility is that a federated contribution path could lower the friction enough to make shared expertise accumulation realistic.

Not effortless. Not automatic. But realistic.

Example 2: Replacing the “Ask Around” Pattern

A lot of organizations do not actually have a knowledge system. They have an “ask around” system.

Someone wants to know:

• which coding assistant the team likes

• what model works best for summarization vs coding

• which terminal setup people actually use

• what workflow tips experienced builders have learned the hard way

So they ask in chat, wait for replies, and hope the right person happens to answer.

A federated expert network does not eliminate judgment, but it can turn those one-off questions into something more durable, searchable, and reusable.

That is a big deal.

When Not to Use This

This pattern is not for everything.

1. Not for highly structured operational data

If you are managing invoices, product catalogs, or strict transactional records, use a real database.

2. Not for teams without agent workflows

If contributors do not already use assistants, the value proposition weakens. The pattern works best when agents are already part of the way people work.

3. Not for zero-trust public sharing

This is for scoped, trusted collaboration. Not anonymous internet contribution.

4. Not for instant certainty

Replication and normalization help, but they do not magically create truth. You still need attribution, recency, and honesty about sample size.

The Real Takeaway

The insight here is not “federation is cool.”

It is this:

Shared expert knowledge usually fails because contribution is too disconnected from real work.

A tool-agnostic, agent-mediated, federated pattern matters because it makes contribution:

• easier

• more natural

• more structured

• more likely to survive beyond the original conversation

• and more governable because sharing follows explicit relationships

That is the opportunity.

Not a perfect expert network.
Not a magical AI memory system.

Just a much better shot at capturing and reusing the knowledge that organizations already have, but usually fail to keep.

---

Source code: github.com/dp-pcs/ogp

---

David Proctor is VP of AI at Trilogy. He writes about AI infrastructure, enterprise automation, and what actually works in production.