---
title: "Implicit Knowledge Is Invisible to AI Agents"
description: "Implicit knowledge — the reasoning, planning and structure your documents only imply — is unreadable to AI agents. What a frontier lab does about it, and what you should copy."
author: "MDflow"
date: 2026-09-17
reading_time: "17 min"
canonical_url: https://mdflow.cz/blog/implicit-knowledge-ai-agents
md_url: https://mdflow.cz/blog/implicit-knowledge-ai-agents.md
---

# Implicit Knowledge Is Invisible to AI Agents

*Published September 17, 2026 · 17 min read*


There is a reason your AI agent keeps making decisions your team settled eighteen months ago. It is not that the agent is careless, and it is usually not that it failed to retrieve the right document. It is that the document it retrieved records *what* was decided and says nothing about *why* — and the why was the whole point.

That gap has a name, and the people training frontier models hit it long before you did. At AI Engineer in July 2026, Marah Abdin and Robert McHardy of [poolside](https://poolside.ai) gave a talk called *The Messy Reality of Scale: Synthetic Data and Pre-Training*, walking through what broke as they scaled their Laguna coding models. The most transferable idea in it has nothing to do with GPUs. It is that organic human text is a bad teacher — not because it is wrong, but because the most valuable thing in it is never actually written down.

> **TL;DR** — **Implicit knowledge** is everything a document means but never states: the rationale, the ordering, the relationships, the constraint that ruled out the obvious option. Human readers reconstruct it; models cannot, because they only see the tokens. Frontier labs now spend a meaningful share of their pre-training budget rewriting organic documents specifically to surface implicit reasoning and structure — about 13% of poolside's Laguna XS.2 mix was synthetic data built for exactly that. The same fix works one level up: if you want an agent to use your knowledge, the shape of your documents is not cosmetic, it is the interface. [MDflow](https://mdflow.cz) stores that shape as plain markdown with folder-level descriptions an agent reads directly.

## What is implicit knowledge?

**Implicit knowledge is the part of a document that a reader supplies rather than reads.** A runbook says "restart the worker pool, then flush the cache" and never says that the order matters because a flush during startup corrupts the warm set. An architecture note lists three services and assumes you know the fourth was removed last quarter. A style guide forbids a pattern without recording the incident that caused the ban.

None of this is missing information in the human sense. It is *compressed* information: the author left it out because any colleague would fill it in. That compression is exactly what a model cannot decompress. It sees tokens. If the causal link between two sentences was never a sentence, there is nothing there to weigh.

Abdin framed the pre-training version of this plainly. Organic data, she said, has a lot in it that is implicitly hidden — things that could teach the model but are not presented in anything like the optimal way. Synthetic data, at poolside, is not a way to replace organic data and is not really about inventing new facts. It is a way to *extract those features and project them onto new planes*: to expose implicit rationale, implicit planning and implicit structure that were already latent in the source.

poolside's own write-up of the Laguna models uses almost the same words for its heavier pipelines: **feature extraction and recomposition, surfacing implicit reasoning, structure, and relationships.** That is not a euphemism for generating fake data. It is a rewriting operation, and the original document is the seed.

## What this actually costs a frontier lab

It is worth being concrete about the scale, because it tells you how seriously the problem is taken.

| | Laguna XS.2 | Laguna M.1 | Laguna S 2.1 |
|---|---|---|---|
| Total parameters | 33.4B | 225.8B | 118B |
| Active per token | 3B | 23.4B | 8B |
| Training tokens | 30T | 30T | 30T |

In Laguna XS.2, synthetic data was **about 13% of the final training mix across all pre-training stages**, drawn from a synthetic corpus of roughly 4.4 trillion tokens and up — which, in the talk, was described as having since grown past six trillion and still growing. Thirteen percent of a thirty-trillion-token budget is not a garnish. It is a deliberate decision that a meaningful fraction of what the model learns from should be organic knowledge *re-presented*, not organic knowledge as found.

The structure of those pipelines is worth stealing wholesale. Abdin described every synthetic data pipeline as the same six components: seeds, primary inputs, metadata, secondary inputs, a generator function, and supplementary functions such as filters and validators. Pipelines then spread along one axis of complexity. At the cheap end are seed-heavy pipelines that reshape content across formats — question and answer, structured lists, dialogue — using small models, where quality is dominated almost entirely by the seed. At the expensive end are orchestrated, multi-agent pipelines reserved for material worth the spend.

The distinction matters for you because **most documentation work sits at the cheap end, where the seed dominates the outcome.** If the source document is thin, no amount of clever reformatting rescues it. If the source is dense but badly shaped, reformatting is nearly free value.

## The quality trap: why a perfectly curated knowledge base fails

Here is the counter-intuitive part, and it is the single most useful thing in the talk for anyone maintaining a knowledge base.

poolside started, reasonably, by optimising hard for **quality over quantity** — a small, excellent corpus. Then they scaled the models, which meant scaling the training budget, and the strategy broke. With a limited pool of high-quality data and a bigger budget, the model saw the same documents too many times. Repetition drove early saturation: the loss stopped improving not because the model had learned everything, but because it had exhausted what those particular tokens could teach.

The fix had two halves. Rephrasing replaced repeated tokens with genuinely different presentations of the same material, which is where that ablation showed a consistent gap between the repeated-seed run and the rephrased run. And web curation was rebuilt **for recall rather than precision** — keeping mid- and lower-quality buckets alongside the top tier, which produced roughly **twice as many unique tokens while maintaining performance**.

The knowledge-base equivalent is a mistake almost every team makes on purpose. You prune to a single canonical document per topic. You delete the older design note because a newer one supersedes it. You merge four overlapping runbooks into one authoritative one. Every step feels like hygiene, and each one removes a different *angle* on the same idea. What you end up with is a small pile of perfect documents that say each thing exactly once — which is precisely the corpus shape that saturated poolside's models.

Diversity of presentation is not clutter. It is signal. A decision that exists as a narrative memo, a comparison table and a rejected-alternatives list is more learnable than the same decision stated once, beautifully.

## Four shapes for making implicit knowledge explicit

The talk grouped pipelines into four shapes. All four transfer directly to documentation, and none require an ML team.

1. **Rephrasing.** Re-present the same content in a different format. A decision record becomes a comparison table; a procedure becomes a numbered list with preconditions; a policy becomes question and answer. A different shape forces different things onto the surface — a table has no room for an unstated assumption in a column.

2. **Multi-stage decomposition.** Build long documents in stages instead of one pass. Abdin's example was generating a novel: you get a far better result by first generating the setting, the characters, the plot and the twists, and only then writing chapters, than by writing chapter after chapter directly. The governing rule is blunt — *if the task is too hard for your model, the model falls on its face, loses correctness and loses diversity; so break the task down and make it simpler.* That rule does not stop applying when the writer is human.

3. **Cross-domain porting.** Move content from one mode to another. poolside converted math problems into code. Your version: turn a written policy into a lint rule, a runbook into a script, an API guideline into a failing test. Porting is a brutally effective implicitness detector, because the target format will not accept a step you never specified.

4. **Multi-turn iteration.** Instead of one linear pass, iterate: two agents in conversation, or a judge and an evolver going back and forth for some number of rounds. In documentation terms, one pass drafts and another interrogates — *what does this assume the reader already knows?* — and the answers become text.

A fifth move is implied by all four and easy to miss: **write the output down as a document.** The most common way teams do this work today is by explaining context to a chat assistant, getting a good answer, and closing the tab. The explanation was the valuable artefact. It evaporated.

## Don't trust the pipeline: the verification half

McHardy's half of the talk was about training infrastructure, and it lands on a principle worth importing: *we don't trust anything.*

poolside runs multiple replicas of the same model during distributed training. The weights across replicas should be identical — that is an invariant you can actually check, so they hash the weights periodically and compare. If the hashes diverge, something has gone seriously wrong and the run is killed.

That check earned its keep. Two runs with identical configuration, data and code produced visibly different loss curves and wildly different gradient norms; the only difference was that one had a **broken GPU** in the pool causing silent data corruption. Separately, around 50,000 steps into a Laguna M.1 run, the loss simply flattened — activations before the unembedding had grown large enough that the tensor-parallel accumulation, running in BF16 by default, no longer had the numerical precision to be accurate. Moving that one accumulation to FP32 and resuming from the checkpoint brought convergence back and started the gradient norm trending down again.

The third failure is the instructive one. A race condition in open-source FP8 GEMM kernels produced illegal memory accesses and NaNs — but it also produced an **unobservable** effect: roughly **0.5% of the gradient silently replaced with random values**. And McHardy named the blind spot honestly. In a real training run there is no redundancy where the same weights meet the same data, so you can never hash-check whether forward and backward behaved identically across replicas. The invariant that catches broken hardware cannot catch that bug.

Translate the principle rather than the mechanism. In a knowledge base, corruption does not look like a crash. It looks like a paragraph. A stale figure, a reversed condition, an agent-written summary that quietly dropped a caveat — all of them render perfectly and read plausibly, and none of them raise an exception. The only defences that work are the ones that make change *visible*: an actor on every write, a diff, a way back, and the discipline of not trusting a document merely because it exists.

## Which applications benefit most

1. **Engineering knowledge bases and runbooks**, where the omitted *why* is the difference between a fix and an outage.
2. **AI coding agents** working against internal conventions — the constraints that are obvious to the team are the ones never written down.
3. **Support and customer-facing assistants**, where the same answer needs to exist as a policy, a script and an FAQ, and the FAQ form is the one that actually retrieves.
4. **Compliance and regulated documentation**, where the reasoning behind a control is the auditable artefact, not the control itself.
5. **Onboarding material**, which is implicit knowledge extraction aimed at humans and works identically for agents.
6. **Research and analysis teams**, where the rejected alternatives carry more information than the conclusion.
7. **Anyone building agent evals**, since a task specification with unstated assumptions produces a benchmark that measures guessing.

## How MDflow fits

To be precise about the boundary: **MDflow does not run synthetic data pipelines**, does not fine-tune anything, and has no opinion about your training mix. What it does is hold the written half of an agent's context in a form where structure survives — which is the part this entire problem turns on.

### What already lines up today

**Structure that reaches the agent intact.** Documents are plain markdown, not rows in a proprietary schema. Headings, tables, numbered lists and frontmatter arrive at the model exactly as written, over [MCP](/docs/mcp), the [HTTP API](/docs/api) or the raw `.md` twin — [this post has one](https://mdflow.cz/blog/implicit-knowledge-ai-agents.md). When the whole point of a rewrite is to put implied structure on the surface, storing it somewhere that flattens structure defeats the exercise.

**Relationships stated as text, not inferred.** Every folder carries a description saying what its documents are *for*, and [`mdflow_get_context`](/docs/mcp) ranks those descriptions above folder names and titles — [retrieval without a vector database](/blog/folder-descriptions-agent-context). A folder described as *"current API contracts — supersedes anything in /archive"* converts an implicit relationship into an explicit one the agent reads. That is the cheapest possible version of the same move poolside makes with expensive pipelines.

**Room for many angles on one idea.** Collections group documents across folders, so the memo, the table and the rejected-alternatives note can all exist and all be reachable, without one having to win and the rest being deleted. The saturation lesson argues directly for keeping variants rather than merging them into a single canonical file.

**Agents that write back.** An agent connected over MCP or with a [Personal Access Token](/docs/api) can create and update documents, which is what makes the "write the explanation down" step actually happen instead of staying in a chat log. Writes that arrive over the API or MCP are attributed as `automated · <token name>`.

**Change you can see.** Version history records every change with an actor and a line-by-line diff. Against silent corruption that renders as a plausible paragraph, the attribution and the diff are the whole defence.

**One copy, many surfaces.** The same markdown is readable from Claude and the ChatGPT app over [remote MCP with OAuth](/docs/mcp), from Cursor, Codex and Claude Code, from [VS Code](/docs/vscode), from [n8n](/docs/n8n), and via the [web clipper](/clipper) on the way in. No second copy means no drift between the document a human reviews and the one the agent obeys. Passage-anchored comments let a reviewer flag *that* sentence — the one that assumes too much — without opening a pull request. Client-side [encryption](/blog/client-side-encryption-for-online-notes) covers documents that should never be readable by anything but you.

### Where we are headed

Direction rather than a dated commitment: richer typed frontmatter, so a document can carry status, owner and freshness as signals an agent weighs before trusting it; explicit relationships between documents, so *supersedes* and *derived from* are fields rather than sentences a reader has to notice; and tighter review round-trips for agent-proposed edits before they land.

## The bottom line

The most valuable thing in your documentation is the part nobody wrote down, and that is precisely the part an agent cannot see. Frontier labs treat this as a first-class engineering problem and spend real budget on it — roughly 13% of a thirty-trillion-token pre-training mix, aimed squarely at surfacing implicit reasoning, structure and relationships that organic text only implies. They also learned that a small, perfectly curated corpus saturates, and that the pipeline producing your data can corrupt it silently while every dashboard stays green.

You do not need their infrastructure to use their conclusions. Rewrite your important documents into a second shape. Stop deleting the variant that said it differently. Port a rule into a test and find out what you never specified. Write the explanation down instead of leaving it in a chat window. And keep an actor and a diff on every change, because a bad document does not throw an error.

[Start free](/login) · [Connect an AI agent](/docs/mcp) · [Read the API docs](/docs/api)

## Frequently asked questions

### What is implicit knowledge, and why can't AI agents use it?

Implicit knowledge is everything a document means but never states — the reasoning behind a decision, the order steps must happen in, the relationship between two sections, the constraint that made an option unavailable. A human reader reconstructs it from experience and from context the document assumes you already have. A model cannot, because it only ever sees the tokens on the page. If the rationale for a choice was never written down, the agent has no way to weigh it; it will either ignore the constraint or invent a plausible one. This is the same problem frontier labs hit with organic web text, and they solve it by rewriting documents so the implied structure is stated on the surface.

### How much of a frontier model's pre-training data is synthetic?

More than most people assume, and it is not a replacement for organic data. In poolside's Laguna XS.2, synthetic data made up about 13 percent of the final training mix across all pre-training stages, drawn from a corpus of roughly 4.4 trillion or more synthetic tokens built for the Laguna series. The stated purpose is not to manufacture new facts. It is to take organic documents and re-present them so that the reasoning, structure and relationships they only imply become explicit text a model can actually learn from.

### Is a small, highly curated knowledge base better for an AI agent?

Not past a point, and the failure is counter-intuitive. poolside started by optimising hard for quality over quantity and found that at scale the model saw the same high-quality documents too many times and saturated early — repetition reduces the effective value of each token. Rebuilding web curation for recall rather than precision, by keeping mid- and lower-quality buckets alongside the top tier, yielded roughly twice as many unique tokens with no loss in performance. The equivalent mistake in a knowledge base is pruning it down to a handful of perfect canonical documents and losing every variant that showed the same idea from a different angle.

### What is the practical way to make implicit knowledge explicit in my documentation?

Four moves, all borrowed from synthetic data pipelines. Reformat the same content into a second shape — a decision as a table, a procedure as a numbered list, a policy as question and answer — because a different shape exposes different relationships. Decompose anything long into stages rather than writing it in one pass, since a task too hard for the writer produces text that loses both correctness and diversity. Port across domains, turning a written rule into a code snippet or a test. And iterate in turns, with one pass proposing and another critiquing. Then write the output down as a document rather than leaving it in a chat log.

### How does MDflow help an agent read implicit knowledge?

By making the structure part of the storage rather than something an agent has to infer. Every folder carries a description saying what its documents are for, and the `mdflow_get_context` MCP tool ranks those descriptions above folder names and titles, so the relationship between a document and its purpose is text the agent reads rather than a guess. Documents are plain markdown with frontmatter, served identically over MCP, an HTTP API and a raw `.md` twin, so headings, tables and lists survive to the agent instead of being flattened into an opaque embedding. And version history records every change with an actor and a diff, which makes a silent bad edit visible instead of plausible.

## Further reading

- [The Messy Reality of Scale: Synthetic Data and Pre-Training](https://www.youtube.com/watch?v=KhYifX22yhE) — Marah Abdin and Robert McHardy, poolside, AI Engineer (July 2026). The talk this post is built on.
- [Laguna XS.2 and M.1: A Deeper Dive](https://poolside.ai/blog/laguna-a-deeper-dive) — poolside's write-up of the data mix, AutoMixer, and the synthetic pipelines.
- [Laguna M.1/XS.2 Technical Report](https://arxiv.org/abs/2605.27605) — the full technical report, with the Model Factory methodology.
- [BeyondWeb: Lessons from Scaling Synthetic Data for Trillion-scale Pretraining](https://arxiv.org/abs/2508.10975) — the rephrasing-for-pre-training work referenced in the talk.
- [Introducing Laguna S 2.1](https://poolside.ai/blog/introducing-laguna-s-2-1) — the 118B open-weight model whose training run the second half of the talk previews.
- [Folder descriptions as agent context](/blog/folder-descriptions-agent-context) — retrieval that reads a sentence instead of an index.
- [Context engineering for AI agents](/blog/context-engineering-for-ai-agents) — the wider discipline this sits inside.
- [MDflow MCP documentation](/docs/mcp) · [HTTP API](/docs/api) · [FAQ](/faq)