According to a June 2026 forecast by the German Economic Institute, an average of roughly 1.3 million baby boomers in Germany will reach retirement age each year through 2036. Only about 800,000 younger people will reach working age behind them.

That is a cohort gap of roughly half a million potential workers a year. By 2036, the institute expects it to add up to 4.3 million.

These are demographic cohorts, not a prediction that exactly 500,000 jobs will suddenly be vacant each January. Reaching retirement age is not the same as leaving work, and reaching working age is not the same as entering employment. Immigration, longer careers and higher labour-force participation can all reduce the gap.

But the direction is clear. A large and experienced generation is moving towards retirement. The generation behind it is smaller.

Germany's Federal Statistical Office describes the scale from another angle. By 2040, around 13.3 million people who were economically active in 2025 will have passed the statutory retirement age of 67. That is equivalent to 30% of the 2025 labour force. The younger cohorts are not large enough to replace them numerically.

The 30% figure does not mean that every younger employee will literally have to work 30% more. It is a warning about the scale of the productivity challenge. If companies want to maintain or grow their output with fewer people, the people who remain need more leverage. Telling the next generation to simply work a third harder is not a strategy.

And headcount is only the visible problem.

Companies bleed experience faster than they can replace it. Most mature companies are banks. Not in the money sense. They are banks of accumulated judgement.

Over decades, they collect knowledge about customers, products, machines, suppliers, software, regulations and thousands of decisions that made sense at a particular moment. Their org charts have grown layer by layer. Their product lines contain exceptions nobody fully understands anymore. Their technology stacks hold sediment from four generations of architects.

An acquisition adds another system. A regulation creates another process. A customer promise becomes a permanent exception. A temporary workaround survives long enough to become infrastructure.

From the outside, this often looks like unnecessary complexity. Sometimes it is. But complexity can also contain memory. Before removing it, somebody needs to know why it exists.

Many of the people who know why things are the way they are are among those approaching retirement.

When an experienced employee retires, the company does not only lose a pair of hands. It can lose the history behind a customer commitment, the workaround for a temperamental system, the warning signs that appear before a machine fails, the reason a process has an apparently pointless extra step and the context behind an architectural decision nobody wants to revisit.

Documentation may explain what a system does. Experienced employees know why it works that way. They know which exceptions matter, where the documentation is wrong, what failed during the last attempted change and who needs to be in the room before somebody tries again.

That is implicit knowledge. The workarounds. The reasons behind decisions. The who-to-ask. The it-depends.

Traditionally, companies transferred this knowledge through proximity. A younger colleague sat next to an experienced one. People learned through projects, reviews, informal conversations and years of repeated exposure.

That model becomes fragile when many experienced people leave in a short period and fewer people arrive behind them. There is less time for shadowing, fewer opportunities to ask and more work waiting for the people who remain. Nobody mentors at that pace. The classic handover, two weeks of shadowing and a farewell cake, transfers almost nothing.

The additional capacity has to come from leverage: less time searching, fewer repeated questions, faster onboarding, fewer handover losses and more reuse of work the company has already done.

We need to preserve the experience the company has already paid to acquire. But where do we put it? And how do we make it useful to the next person at the exact moment they need it?

The default answer arrives once a quarter, when someone proposes the same fix: let's put all our knowledge in one place. New wiki. New platform. Big migration.

Everyone nods. Six months later the wiki is a graveyard and the answers live where they always lived. In chat threads, in code, in tickets, in someone's head. And soon: in retirement.

Simply storing more documents does not solve the problem. An archive can hold information without helping anyone recall it. The goal is not storage. The goal is usable organizational memory.

What a company brain is

A company brain is a living, permission-aware system that collects what an organization already knows and makes it answerable.

It watches the places where knowledge gets created: Slack threads, wikis, code repositories, tickets, documents and internal databases. It turns that fragmented material into one queryable memory. You ask a question in plain language. It finds the evidence and returns an answer with sources. Humans use it. Automations and agents can use it too.

It is not simply a new wiki. It is also not a chatbot trained on every company document. The source material can stay where people already create it. The brain's job is to keep track of that material, retrieve the right evidence and show where the answer came from.

A knowledge base stores information. A company brain helps the company recall it.

The idea is old. Knowledge management has promised some version of this for decades. What changed is that language models can finally work with the mess companies actually produce instead of demanding perfect documentation that people were never going to write.

Cerebras is not a case study about Germany's demographic transition. Its immediate pressure was rapid growth rather than retirement. But the two situations share an underlying knowledge challenge: knowledge exists somewhere, and the person or agent who needs it cannot find it.

Cerebras's engineers published a detailed write-up of the internal system they built to solve this. It is one of the most instructive descriptions of organizational memory I have read in a long time.

"Company brain" is my framing. Cerebras calls the system Cerebras Knowledge and describes it as an internal knowledge base.

Who Cerebras is

Cerebras is an AI infrastructure company founded in 2015. It is best known for building wafer-scale processors. Cerebras describes its third-generation Wafer-Scale Engine as the world's largest AI processor.

Where conventional chipmakers cut a silicon wafer into many individual processors, Cerebras turns almost the entire wafer into one enormous processor. Its third-generation Wafer-Scale Engine contains four trillion transistors and 900,000 AI-optimized cores. It is roughly the size of a dinner plate.

The company is also known for extremely fast AI inference. In January 2026, OpenAI announced a partnership to add 750 megawatts of Cerebras's low-latency compute to its platform. In March, AWS and Cerebras announced plans to combine AWS Trainium and Cerebras systems in a disaggregated inference service through Amazon Bedrock.

This is not a company short on brilliant engineers.

Its teams span chip design, hardware, data-center operations, model training, inference and cloud infrastructure. And still its communication channels filled with the same questions every growing company eventually drowns in: Where can I find this? Who is the expert on that? What does this mean?

Hundreds of new employees join Cerebras every year. Each new person has to learn an organization that stretches from silicon physics to cloud software. Much of what they need has already been discussed, decided or solved. The problem is finding it.

So Cerebras built Cerebras Knowledge.

Three months after launch, the system was receiving more than 15,000 questions a day. Cerebras described it as one of its most widely adopted internal tools. It was used not only by people, but by automations and AI agents as well.

The number is impressive. The more useful lesson is how Cerebras built the memory underneath it.

The founding decision: do not fight behavior

Most knowledge projects begin with a migration. Cerebras began with the opposite question: how can we collect company knowledge while requiring as little behavior change as possible?

Information gets produced wherever producing it is convenient. Suggested edits live in documents. Engineering debates live in Slack. Code references live in GitHub. Status and ownership live in Jira. Specialist teams have internal databases built for their own work.

Those tools are good at their jobs. Discussing a pull request in Google Docs would be misery. Forcing every useful conversation into a central wiki would create friction, and much of the knowledge would never make the journey.

So Cerebras did not try to replace the tools. It extracted data directly from them.

This is the first important design choice. The company brain is not another destination employees have to remember to update. It is a shared access layer over the places where work already happens.

The architecture is deliberately boring

At a high level, the system has three jobs.

It collects and stores internal data. It answers queries over that data. And it enforces authentication and authorization, with auditing and analytics around how the system is used.

That third job is the one many internal AI pilots forget until legal or security remembers it for them. A company brain is useful only if people and agents see what they are allowed to see, and if the company can understand how the system is being used.

At the core sits a single Postgres table. Every source, from Slack threads and wikis to code repositories, chip netlists and custom databases, lands as the same basic kind of row: a normalized document or summary, an embedding, metadata, source information and timestamps.

The architecture uses pgvector with 3,072-dimensional embeddings and an HNSW index. But the more important choice is the common interface. One connector per source. One shared row shape. Anything that reaches the table becomes queryable through the same retrieval layer.

Each source defines what its data is, how the system should connect to it and how often it should be fetched.

No exotic vector database. No knowledge-graph moonshot before the first useful answer. Postgres with pgvector.

The boringness is a feature.

Because the interface is simple, teams can onboard their own data. A team opens a pull request containing a small Python module that reads from its internal system, emits rows in the shared format and defines a matching data-source entry. Once the data fits the common schema, the rest of the stack works unchanged.

The central team does not need to understand every specialist database. Teams bring their own knowledge into the shared brain without moving that knowledge into Slack or a document platform first.

Slack was the most important source. It held some of Cerebras's freshest engineering knowledge. It was also a swamp.

A one-word acknowledgment and a detailed kernel explanation are both messages. Message lengths vary wildly. Short, low-value replies can outrank longer technical answers in naive vector search. And the meaning of one message may depend entirely on the surrounding thread.

Cerebras initially tried simple embeddings over raw Slack text. They were not enough.

Full-text search catches the exact tokens embeddings blur together: pasted error strings, configuration flags, host names and identifiers. When an engineer pastes a literal error, an exact lexical match is usually the evidence that matters.

Embedding search catches paraphrase. The person asking about a restore hanging after a manifest loads may be looking for an answer written by somebody who described a checkpoint stalling on an NFS mount. The vocabulary is different. The underlying problem is the same.

Inverse document frequency gives more weight to rare, meaningful terms and less to polite filler. A short message containing an obscure configuration flag may be valuable. A short message saying "sounds good, thanks" is probably not, even if it sits close to the question in embedding space.

Age decay encodes something most knowledge systems refuse to admit: answers expire. Two threads may answer the same question, but the older one may describe infrastructure that no longer exists. When relevance is otherwise equal, newer wins.

Each technique produces its own ranked view of the same corpus. None is trusted on its own. The system fuses them later.

How Slack enters the brain

Slack ingestion runs in real time. Cerebras installed a bot in Socket Mode, so Slack pushes every message event over a persistent WebSocket instead of forcing the system to poll the Web API and burn through rate limits.

When an event arrives, the system acknowledges it immediately, deduplicates it using the stable event ID and passes it to an ingest consumer.

That consumer does not store a new reply as an isolated fragment. It identifies the thread, fetches the parent and every reply again, and writes the full conversation back as one record. A new reply therefore refreshes the entire thread, including its participants and last-activity timestamp.

Every Slack channel included in the system is treated as its own data source. That lets teams tune freshness channel by channel. A busy incident channel can be refreshed more aggressively than a quiet one.

The raw conversation remains available for exact search. As soon as it lands, a Postgres GIN full-text index makes it keyword-searchable.

This distinction matters because Cerebras does not embed the raw transcript directly.

Distill before you embed

A complete Slack thread is still not good memory. It contains greetings, false starts, tangents, incomplete ideas and context that only makes sense to people who were present.

Before creating a semantic embedding, Cerebras uses a language model to distill the full thread into a structured artifact.

The artifact contains a one-line question an engineer might actually search for, a short summary, the resolution, and the systems and code references mentioned in the discussion.

That normalized document is what gets embedded and written to the shared table. The raw transcript remains available for exact full-text retrieval, but the semantic search operates over a cleaner representation of what the conversation meant.

Cerebras says retrieval accuracy increased significantly after it stopped embedding raw transcripts and adopted the normalized format. It does not publish a percentage, but the direction of the result is clear.

Raw data and useful memory are not the same thing.

Bursting: rescuing what summaries lose

Distillation introduced another problem. A thread-level summary can flatten a long discussion and omit one technically important tangent.

Cerebras solved this with what it calls bursting.

A burst is a run of consecutive messages from the same author. The system prepends the thread topic for context and embeds useful bursts separately. That makes a technical detail findable even when its vocabulary never appears in the overall thread summary.

Not every burst deserves a place in the database. Cerebras scores each one using a weighted combination of signals. Those signals include whether it contains a relatively rare token with an inverse-document-frequency score of at least 4.0, whether its combined length reaches 200 characters, and whether colleagues reacted to its messages.

Only bursts that clear the threshold are embedded and stored beside the thread-level record.

Emoji reactions as a curation signal. The social layer does the librarian's job.

The result is memory at two levels. The normalized thread preserves the overall question and resolution. The burst preserves a specific insight that might otherwise disappear.

Slack needed distillation because conversation is messy. Code presented the opposite problem: it was structured, but enormous.

Why Cerebras indexed code too

The team initially questioned whether semantic code search was necessary. With command-line coding agents becoming increasingly common, it was tempting to believe that "grep is all you need."

But exact search works best when you already know the symbol, filename or vocabulary you need. Semantic retrieval can find relevant code when the person asking knows the problem but not the implementation.

Some Cerebras repositories exceed 40 GB. Keeping code embeddings current without rebuilding the entire index became the main challenge.

After several experiments, the team chose CocoIndex, an open-source framework for maintaining code embeddings.

Instead of cutting a file into arbitrary windows every N tokens, CocoIndex uses language-specific regular-expression boundaries ordered from coarse to fine. It tries higher-level structures such as classes first. If a chunk remains too large, it falls back to methods and then smaller blocks.

One file can therefore produce several embeddings at different levels of specificity: a file-level record, a class-level record and a function-level record.

CocoIndex stores its synchronization metadata in Postgres alongside the embeddings. When a commit changes a section of code, it re-embeds and re-exports only the affected chunks rather than recomputing the entire repository.

Repository onboarding eventually became self-service. Teams submit configuration files with allowlists and denylists down to the file-path level.

The pattern is consistent across the whole system: centralize the interface, not ownership of every source.

Once the knowledge became queryable, the problem changed. Collection was no longer the bottleneck. Recall was.

Answering is a pipeline, not a lookup

When a user asks Cerebras Knowledge a question, the system does not send it to one giant vector index and hope for the best.

A lightweight planning model first decides which sources and tools are likely to matter. It sees the user's active project plus a compact catalog of what Cerebras has indexed, which sources belong to each project and what each source is good at answering.

The planner has six main tools available.

subsystem_index retrieves per-file LLM summaries. search runs the unified indexed pipeline across Slack, wikis, code and other sources. search_slack performs direct Slack retrieval. search_code runs ripgrep over source repositories. recent_prs finds recent pull requests related to the question. who_knows identifies people with demonstrated expertise on a topic.

The tools selected by the planner fan out in parallel and return evidence in a common format. Then comes fusion.

Different retrievers produce scores that cannot be compared directly. A vector similarity score is not the same thing as a full-text score or a recency signal. Cerebras combines the ranked result lists using reciprocal rank fusion.

For each list where a document appears, it contributes weight / (60 + rank) to that document's total. The default weight is 1.0 and the smoothing constant is 60.

The arithmetic matters less than the principle: consensus beats one lucky first place. A document that ranks well across several different retrievers can outrank a document that appears first in only one.

Duplicate chunks are merged back to their original source. The system caps how many results one file can contribute so no single file can dominate the candidate set. That produces a diverse top twenty.

A small reranker then scores those twenty candidates from zero to ten against the original question and keeps the best ten.

Finally, the system restores context that chunking may have removed. If a winning result is one section of a wiki page, Cerebras also retrieves the two neighboring sections. Headings, prerequisites and caveats travel with the matched paragraph.

Only after retrieval, fusion, deduplication, reranking and context expansion does the end-to-end web pipeline ask a final model to synthesize the answer with citations.

One brain, two interfaces

Cerebras exposes the same memory in two different ways.

The web interface hides the entire pipeline behind one interaction: ask a question and receive a sourced answer. Planning, parallel retrieval, evidence normalization and final synthesis all happen underneath.

Through MCP, Cerebras exposes the retrieval building blocks directly rather than hiding everything behind one magical "answer this question" endpoint.

Most MCP tools run one retrieval primitive, apply lightweight scoring and return structured raw evidence rows. Claude Code or another MCP-compatible agent decides which tools to call, in what order, and how to turn the evidence into an answer or a code change.

The tools are deliberately small, fast and as free of their own LLM orchestration as possible. The client is the orchestrator.

That decision turned the knowledge base into infrastructure. The same memory layer can serve employees, internal applications, automations and agents. It is not tied to one chat interface, and MCP-compatible agents can use the same retrieval layer.

But even excellent retrieval becomes noisy when the search scope is wrong.

Scope is part of intelligence

As the corpus grew, "search everything everywhere" stopped being useful.

Compiler engineers do not want infrastructure runbooks filling their results. Data-center teams do not need every compiler discussion. The most semantically similar passage in the whole company is not necessarily the right answer for this person and this task.

Cerebras introduced projects as the primary search scope. A project is a named bundle of relevant Slack channels, code repositories, internal databases and document spaces.

The same source can belong to several projects without being duplicated. A central repository or shared incident channel might be relevant to both the compiler and platform teams.

During onboarding, users select or create a default project, such as Compiler, ML Training Infrastructure or Data Center Operations. That choice is stored on the user profile and scopes future questions automatically.

A new employee gets relevant answers on day one, before learning which channels, repositories and document spaces matter.

The architecture explains how Cerebras built the system. Its design choices explain why it worked.

What I take from this

I no longer believe in the single source of truth

The single source of truth is dead, and I am not convinced it was ever alive.

Most failed knowledge initiatives I have seen made the same mistake: they asked people to change where they write things down. Cerebras designed for minimal behavior change instead. It met information where it was already being created.

Adoption was not only a rollout program. It was a property of the architecture. If employees can keep working normally and receive better answers, the knowledge system does not need to win a daily argument about where they should document something.

The intelligence is not where most of the complexity lives

Language models matter in Cerebras Knowledge. They distill threads, create per-file summaries, help plan searches and synthesize final answers. A separate small reranker model scores the retrieved evidence.

But read the architecture closely and most of the system is plumbing: connectors, schemas, event deduplication, synchronization state, chunk boundaries, exact indexes, vector indexes, rate limits, permissions, auditing, project scope and source metadata.

Organizations spend enormous energy debating which model to pick. Models will keep changing. The durable system is the layer that knows what information exists, how fresh it is, who may see it and how to retrieve it reliably.

The model is not irrelevant. But the plumbing is the moat.

Knowledge rots, and honest systems admit it

Most wikis treat knowledge as if it only accumulates. A page is written, and unless somebody remembers to update it, the system quietly assumes it remains true.

Cerebras makes age a ranking signal. That is a small technical choice with a large philosophical implication: company knowledge expires.

Freshness should not be an afterthought. It is part of relevance.

Distill before you embed

Distillation improved semantic recall; raw indexing preserved exact evidence. Cerebras did not choose between the two representations. It kept both.

Many retrieval projects dump raw documents into a vector store and wonder why the results are mediocre. The unglamorous extraction step is often the difference between a demo and a tool. But the deeper lesson is not simply to summarize before embedding. It is to preserve different representations for different kinds of recall.

Who knows this should be a first-class question

One of Cerebras's retrieval tools does not return a document. It returns people with demonstrated expertise.

That matters more than it first appears. A large share of waiting time in knowledge work is spent finding the person who can unblock a decision. A system that answers "who knows this?" directly attacks waiting time at its source.

Sometimes the right answer is not a paragraph. It is the right conversation with the right person.

Agents are users too

A knowledge base that only supports a human chat interface is useful. A knowledge base that exposes stable retrieval tools to agents becomes infrastructure.

An agent that can search the company's actual code, decisions, terminology and experts does not have to interrupt a human for every piece of context. It can make better edits and produce more specific work with company-specific context.

If companies want AI to increase productivity rather than generate generic output, this memory layer is the groundwork.

The building blocks are accessible. The implementation is not trivial.

The published architecture is built from familiar components rather than one proprietary model. Postgres, pgvector, an open-source code indexer, Slack APIs and MCP are all accessible building blocks.

But turning those parts into a secure, reliable company system still requires disciplined engineering. Permissions must be correct. Connectors must stay current. Ranking must be evaluated. Sources need owners. Auditing and operational maintenance do not disappear because the architecture looks boring.

The encouraging lesson is not that every company can copy Cerebras over a weekend. It is that the path is understandable. You do not need to begin with a perfect ontology or a giant migration. You can begin by indexing the mess you already have, one useful source at a time.

This is bigger than search

Germany's demographic transition creates a labour problem. It also creates a memory problem.

A company brain cannot replace the people who are retiring. It cannot reproduce judgement earned across thirty years of work. And it should not become an excuse to stop investing in mentoring, apprenticeships and human handovers.

What it can do is make more of that experience reusable. It can preserve the earlier answer, connect it to its source, use age as a ranking signal so newer evidence can win when relevance is otherwise comparable, and make that evidence available to the next employee or agent without forcing them to rediscover it from scratch.

That is the leverage a smaller generation will need: not simply working harder, but starting each task with more of the company's accumulated knowledge already in the room.

Your company has already answered most of the questions it asks itself.

The only open question is how many more times you will pay people to rediscover the answers.

Because the people who found them first are already packing up.

Sources:

Institut der deutschen Wirtschaft, "Babyboomer in Rente: Bis 2036 fehlen 4,3 Millionen Arbeitskräfte," June 15, 2026: https://www.iwkoeln.de/presse/pressemitteilungen/babyboomer-in-rente-bis-2036-fehlen-43-millionen-arbeitskraefte.html

Statistisches Bundesamt, "13,3 Millionen Erwerbspersonen erreichen in den nächsten 15 Jahren das gesetzliche Rentenalter," June 23, 2026: https://www.destatis.de/DE/Presse/Pressemitteilungen/2026/06/PD26_N039_13.html

Cerebras, Isaac Tai, Daniel Kim and Mike Gao, "How We Built Our Knowledge Base," July 15, 2026: https://www.cerebras.ai/blog/how-we-built-our-knowledge-base

Cerebras company overview: https://www.cerebras.ai/company

Cerebras, "Cerebras Announces Third-Generation Wafer Scale Engine": https://www.cerebras.ai/press-release/cerebras-announces-third-generation-wafer-scale-engine

OpenAI, "OpenAI partners with Cerebras," January 14, 2026: https://openai.com/index/cerebras-partnership/

Cerebras, "AWS and Cerebras Collaboration Aims to Set a New Standard for AI Inference Speed and Performance in the Cloud," March 13, 2026: https://www.cerebras.ai/press-release/awscollaboration

‍