Build Your Company's Shared Intelligence Layer

Every capable person in your company has quietly become a one-person team. With Claude Code and a few agents, a single operator now runs the research, the outreach, and the follow-up that once took several people, working from a private setup of their own prompts and context. That leverage is real, but it belongs to the individual who built it, so the day they leave it walks out the door and the company is no smarter than before.

What we recommend building instead is a shared intelligence layer your organization can reach, the context layer a company actually runs on, with the work left exactly where it already happens. In our experience it rests on two graphs that work together. A knowledge graph captures how the company operates, following the principles Cerebras laid out for their own, and an entity graph, the revenue layer we built with Nous, resolves every customer into a single sourced record. Together they form the foundation everything else stands on, while your agents, skills, and playbooks run as the execution layer above them, and the guide that follows builds both one layer at a time.

Layer 1: Inputs and access

Before any data moves, two questions decide the shape of everything that follows, and the first is access. We settle who in the company can see what while the layer is still small and easy to govern, because a shared layer without a permission model is a standing leak. From the start we map each role to the scope it should read, so a rep sees their own accounts, a manager sees the team, and RevOps sees the whole book.

The second question is what actually goes into the layer, and we frame it around what the company needs to know about a customer and which existing tool already holds each piece of that. You write those facts down together with their source, and that short document becomes the specification everything after it is built against. In practice we recommend starting narrow, with the two or three sources that carry the most decision-shaping context, usually meetings, email, and the outbound tool, then adding the rest once the layer is already earning its keep.

Layer 2: The internal knowledge base

The first graph is the knowledge graph, and it captures how your company actually operates, from the way it is organized to the reasoning behind the decisions it has made and where everything lives. We treat it as the institutional memory of the business, the understanding a senior employee carries in their head, made queryable so an agent can draw on it too.

What it answers

Most of this knowledge is never written down anywhere an agent can reach. It lives in your internal Slack, in the meetings your team runs, in the documents half the company has never opened, and in the memory of the people who have been there longest, so a new hire spends their first months absorbing it by asking around. An agent that begins with none of it stalls the moment a question depends on something only your company knows.

In our experience these are the questions a team reaches for every day without one place to look for them, questions like who owns this, why did we decide that, where does this live, and who is the expert on it. Once those answers sit somewhere your people and your agents can query, onboarding accelerates, settled decisions stop getting relitigated, and every agent you build inherits context that a senior employee spent a year earning.

The sources it pulls from

The sources are the systems that already hold this knowledge, among them your internal Slack channels, team meeting notes, documentation and wikis, the codebase, and the tickets and incidents where hard-won lessons live. The work is to collect from each of them into one queryable store while everyone keeps working exactly as they do today. The clearest public account of building this half is Cerebras writing about their own internal knowledge base, which now answers more than fifteen thousand questions a day across the company, and the mechanics we describe below follow what they published in How we built our knowledge base.

Retrieving the right passage

A knowledge graph is reached through retrieval, where the unit you retrieve is a single passage of text. The entire challenge sits in that retrieval, because the answer already exists in some thread or document and the system has to surface the right one at the exact moment an agent asks. Everything therefore depends on how the text is prepared going in and how it is ranked coming back out.

We learned early that embedding raw text directly performs badly, because messages vary enormously in signal and a throwaway line carries the same weight as a detailed technical explanation, while short messages routinely outrank longer and more useful ones in cosine similarity. So we distill each source before storing it, having a model read the thread and rewrite it into a normalized document, the one-line question someone would actually search, a short summary, the resolution, and the systems it touched. That normalized document is what gets embedded, and its metadata, the author, timestamp, channel, and thread, is stored alongside the vector.

From there we retrieve with several methods at once, because in our experience no single scorer can be trusted on its own and each one covers a weakness the others share.

• Full-text search catches the exact tokens an embedding blurs together, an error string, a flag name, a host name. When someone pastes a literal error, the exact lexical match is the strongest evidence there is, and semantic similarity should defer to it.

• Embedding search catches paraphrase. "Restore hangs after manifest load" and "checkpoint stalls on the NFS mount" may never share a word, and the vector is what connects the question to an answer written in a different vocabulary.

• Rarity and recency break the ties. A short message built around a rare token earns its rank, "sounds good, thanks" sits close to everything and means little, and when two threads answer the same question the newer one wins, because the older one may describe infrastructure that no longer exists.

We fuse those ranked views with reciprocal rank fusion, so a passage several retrievers agree on outranks one that only a single retriever favored, then a small reranker model scores the survivors and keeps the strongest few. The winning context goes into the prompt alongside the question, which is the entire point of the exercise, because a model can only answer from what sits in front of it and a missing passage becomes an invented one. This is why we treat the knowledge graph as a retrieval-engineering problem, where how you chunk, distill, and enrich the text decides whether the right passage ever surfaces.

Layer 3: The revenue layer

The second graph is the entity graph, the revenue layer, and its nodes are resolved people and companies. The question an agent asks here is who a customer is and what is true about them right now, which places identity at the center of everything the layer does. In our experience this is exactly where most systems break, because the same buyer appears as a reply in Gmail, a row in HubSpot, a message from an unfamiliar LinkedIn handle, and a name in a call transcript, and to an agent that looks like four different people.

Retrieval on its own makes this harder, because a RAG system pointed at your stack will return text mentioning "S. Chen", "Sarah", "@sarah", and schen@acme.com while treating them as strangers, since nothing in the raw data ever connected them into one person. This is the work the revenue layer does first, resolving those fragments into one record so that every fact an agent reads is already attached to the right customer, and every score and next step is computed on a whole person rather than a fragment.

What it has to hold

The first source we recommend every team integrate is meeting notes together with the surrounding calendar, because they hold the richest record of what a customer actually said and almost nobody captures them into anything an agent can read. Starting here gives the layer its most valuable context on the first day, before a single other tool is connected.

LinkedIn belongs in the layer as well when your team is active there, alongside your LinkedIn outbound if you run it through a tool like HeyReach, since both the conversations and the connections are genuine context. We see teams underweight this source, and yet it often carries the first signal that an account is worth pursuing at all.

The inbox is the source most teams overlook, and in our experience overlooking it is expensive. A call goes well, everyone nods, and an hour later the buyer emails a security objection they never raised on the call, so when the meeting notes and the inbox live apart an agent reads the deal as healthy while the real blocker sits in a different tool entirely. The activity has to live in one place, or every decision gets made on half the story.

What it unlocks

Once the activity lives together, this layer is what makes everything else possible. An account that used to take half an hour to research can be assembled in seconds, and outbound closes its own loop by tying the message that worked to the customer situation that made it work. Beyond any single account, the entire pipeline becomes readable at once, surfacing the pains and objections that recur and the plays that are landing across every deal rather than one rep's memory at a time.

The embedding pipeline

This is where raw activity becomes the entity graph, and it is the part we built with Nous. The substrate holds strictly to one principle, storing every fact as an observation that carries its source and date, and computing the current belief about a customer from all the observations it has seen. Because nothing is ever overwritten, the entire belief layer can be rebuilt from the raw record at any time, and the pipeline that produces it runs in four steps.

Ingest

Every event from every connected source is written as an append-only observation, on whatever cadence that particular source needs. A database trigger rejects deletes and edits, which keeps the evidence trail immutable and means nothing depends on a person remembering to export anything.

Resolve

Every observation lands on an already-resolved entity before it is stored. The resolver leads with stable identifiers like an email or a LinkedIn URL, and it falls back to a name only when a second signal corroborates it, so a shared first name never links two records by itself. Because fusing two real people is the expensive mistake, the resolver would rather leave a clean duplicate for a reversible merge to fix later than risk a wrong link, and we document the full waterfall and its guards in the open at identity resolution.

Claims

A resolved record still holds hours of transcript and long email threads, so this step extracts the durable facts from that activity. Each fact carries the observations it came from, a confidence, and a freshness that decays over time, which lets an agent read "security objection, July 3, from the follow-up email" in place of a wall of transcript. Two kinds of fact live here, the structured claims such as title and deal stage and the extracted intel drawn from a customer's own words, and each is tagged with a controlled category so it rolls up into patterns across every account, as we describe in claims.

Embed and serve

The resolved, sourced claims are written into our database, which is Supabase, and indexed for retrieval. An agent reads them back through a structured assembly, where a single call gathers the account for the task at hand, the ranked claims, the timeline, and the ICP fit with its reasoning. Embeddings remain in the system as an optional pre-filter while the graph itself carries the load, and we mention this deliberately, because we built the document-memory version first and removed it once the resolved claim graph proved to serve agents better.

Keeping the graph current

Webhooks push new activity through the same four steps as it arrives, so the layer keeps itself current without anyone tending it. In our experience much of the real work is catching the failures that happen quietly, the connectors that drift, the tokens that expire, and the syncs that fail without raising an error. Access is scoped per workspace and enforced at the row, so each person and their agents read only the accounts they are entitled to, a decision made once here and inherited everywhere after.

Layer 4: MCP

With the data in place, the next question we address is how your agents act on it inside the tools you already run, and MCP is the bridge that lets them. It allows an agent to operate a tool directly, with no dashboard and no copy-paste in between, so once an agent has retrieved what it needs and decided what to do, MCP carries that decision into the tools where the work already lives. The shared layer supplies the context, and MCP supplies the reach.

The last mile

We rely on MCP for the last mile, the action step where the work actually lands. An agent that has read the full picture of an account can draft the follow-up, load the campaign, and write the outcome back without a person shuttling data between tabs, because each tool exposes a small set of actions through its MCP and the agent calls them the way it would call any other function.

The tools we connect

• HeyReach, to run LinkedIn outbound.

• Instantly, to send and manage email campaigns.

• Gmail, to draft and send from the inbox.

• Your CRM, to write the record back once the work is done.

Not every tool exposes an MCP yet, and where one is missing we bridge the gap with a lightweight automation until it ships. The principle holds either way, since the agent decides from the shared layer and acts through the tool it is given.

Layer 5: Skills

An agent with context and reach still needs to know how your team does the work, and that is the job skills do. A skill is a repeatable instruction, a single play written down once, that tells an agent exactly how to run a specific job on top of the layer and run it the same way every time.

This is what turns a capable agent into a reliable one, because without skills every run is improvised and two people asking for the same account brief get two different answers. With a skill in place, the brief is assembled from the same sources in the same shape whether a rep runs it, a manager runs it, or a scheduled job runs it at six in the morning, so your best operator's judgment is written down once and everyone on the team inherits it.

A few of the skills we run ourselves:

• meeting-brief: pulls everything the layer knows about a person before a call and writes the prep.

• signal-scan: reads an account for buying signals and records them onto the record.

• content-scan: reads a prospect's recent posts for the themes that map to your offer.

• email-writer: drafts the outbound from the account's real, resolved context.

• market-brief: reads what the market is saying and turns it into your content angles.

• campaign-audit: reads your outbound performance and says what to change.

Each skill is a single file, written once and run indefinitely, and every agent on the team executes it the same way.

Layer 6: How your team actually uses it

At this point you have the full system, the inputs, the two graphs, the pipeline, the reach, and the plays, and the last question is how the people in your company actually reach it. The answer is through agents, since the interface is an agent that reads the layer and acts on it, and we see three ways to give a team that access depending on how technical they are.

The first is an internal tool of your own, where you wire the knowledge graph and the revenue layer into a simple application over an MCP server with something like Lovable. Anyone in the company can then ask a question and act on the answer without touching the machinery underneath.

The second is Slack, where most teams already spend their day. A Slack agent lets a rep put a question to the layer and get an answer back without ever leaving the tool that is already open in front of them.

The third is the terminal, which we reserve for the technical operators, where the entire system runs headless from Claude Code and can be scripted into any workflow they already run.

Final thoughts

A shared intelligence layer is a decision more than a purchase, the decision to stop letting your company's understanding live in individual heads and private setups. Set the inputs and the access deliberately, build the knowledge graph and the entity graph as the distinct systems they are, run every activity through a real pipeline that resolves and grounds it, give your agents genuine reach and repeatable plays, and meet your team in the tools they already use. Do all of that, and the leverage that used to walk out the door finally stays with the company.

Read more

• How we built our knowledge base, Cerebras on building the internal knowledge base half, the deep dive for the knowledge graph.

• Identity resolution, how the entity graph resolves one record per person and company, the substrate and the full waterfall.

• Claims, the controlled claim taxonomy and the extraction pipeline behind the revenue layer.