Home
Trilogy AI CoE

Why Shared Expert Knowledge Usually Fails — and the Federation Pattern That Could Make It Work

A framework for capturing and reusing organizational expertise without asking anyone to change how they work.

FrameworkAI CoEKnowledge Systems

Most Organizations Don't 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.

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.

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.

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."

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 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

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.

  • Leaders keep their own tools and workflows
  • Their agents contribute structured knowledge through federation with AI CoE Agent (Cosmo)
  • Knowledge propagation depends on the actual federation graph
  • Cosmo aggregates and normalizes what it receives into something queryable
  • Nobody has to maintain a traditional wiki

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

The Components

Five core components make the federation pattern work — and understanding each one is essential to understanding why this approach succeeds where wikis fail.

1

Federation Graphs Matter

This is not blanket replication to every member by default. Knowledge follows the actual federation graph — contributions propagate along real federation edges, not a global broadcast network.

2

Hub-and-Spoke Querying

AI CoE Agent (Cosmo) is the place where users ask questions and get synthesized answers. Leaders contribute through their own agents; Cosmo is the main aggregation and query surface.

3

Entry Types Instead of Heavy Schema

Five core entry types — tool-preference, model-preference, workflow-tip, config-note, recommendation-rationale — provide enough structure to make queries useful without requiring a rigid database schema on day one.

4

Normalization Is the Real Trick

Replication alone does not create a useful knowledge system. The normalization/query layer at the hub parses raw contributions, groups related entries, and answers questions like "what do leaders currently prefer for terminals?"

5

Membership and Boundaries

The project model gives you explicit membership boundaries — scoped to known contributors whose agents can share and query knowledge inside an agreed boundary. Privacy, trust, relevance, and governance all depend on this.

Contribution Flow

01

A leader says something useful

Example: "WaveTerm is my favorite terminal because the SSH and file browser flow is cleaner."

02

Their agent structures the contribution

Entry type: tool-preference · Tool: WaveTerm · Category: terminal · Sentiment: favorite · Rationale: remote workflow and file browser integration

03

Contribution is written locally

The entry is written to the local project and propagates along the federation edges that exist.

04

Cosmo normalizes and surfaces it

Cosmo can then normalize and surface what it receives, making it queryable across the network.

Query Flow

01

A user asks the hub a question

Example: "What terminal tools do AI CoE leaders recommend for remote work?"

02

Cosmo reads project data

Cosmo reads the project data it has received plus its normalized view of all contributions.

03

Groups relevant contributions

Contributions are grouped by category and tool, with attribution, rationale, and recency preserved.

04

Synthesizes a useful answer

The answer reflects who currently prefers what, why they prefer it, how recent the recommendation is, and where there is disagreement or divergence.

Why This Might Actually Work Better Than a Wiki

Contribution Happens Closer to Work

The contribution path starts where work already happens — not in a separate tool that requires a context switch.

Structure Added by the Agent

The agent adds structure, not the human by hand. This removes the formatting and categorization burden from contributors.

Hub Answers from Grouped Knowledge

The hub answers questions from grouped, normalized knowledge — not stale pages that nobody has updated in months.

No Wiki Gardeners Required

The system can improve without requiring everyone to become a wiki gardener. Governance is built into the federation model itself.

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.

When Not to Use This

Highly Structured Operational Data

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

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.

Zero-Trust Public Sharing

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

Instant Certainty

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

Shared expert knowledge usually fails because contribution is too disconnected from real work. A tool-agnostic, agent-mediated, federated pattern makes contribution easier, more natural, more structured, more likely to survive beyond the original conversation — and more governable because sharing follows explicit relationships.

5

Core Entry Types

tool-preference, model-preference, workflow-tip, config-note, recommendation-rationale

5

CoE Leaders

Each contributing through their own agent and environment

1

Query Surface

Cosmo — the single hub where users ask questions and get synthesized answers

Source Code

The full implementation of the Open Gateway Protocol (OGP) — the foundation for the federation pattern described in this framework — is available as open source.

Open Gateway Protocol (OGP)

OGP is the protocol that makes the federation pattern possible. It enables agents to contribute structured knowledge through federation without requiring a centralized tool or a shared schema enforced from the top down.

The repository includes the core protocol implementation, example project configurations, and the contribution and query patterns described in this framework.

What You'll Find

  • Core OGP protocol implementation
  • Federation graph configuration examples
  • Entry type definitions and metadata schemas
  • Normalization and query layer patterns
  • AI CoE Expert Network reference implementation

About the Author

Author

David Proctor

VP of AI at Trilogy

David Proctor writes about AI infrastructure, enterprise automation, and what actually works in production. His work focuses on the practical challenges of deploying AI at scale inside real organizations — not the hype, but the hard-won lessons from building systems that have to survive contact with reality.

AI Infrastructure

Building the systems that make AI reliable and governable inside enterprises.

Enterprise Automation

Designing automation that fits how organizations actually work, not how they wish they worked.

What Works in Production

Honest analysis of patterns, protocols, and frameworks that survive real-world deployment.