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.
Framework
AI CoE
Knowledge 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.

Built on OGP (Open Gateway Protocol), the idea is not "replace everyone's systems with one master system." It is a low-friction capture and query path for expertise that would otherwise stay trapped in chats, local notes, and people's heads.
  • 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.

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