Meta's AI Second Brain Runs on a Knowledge Supply Chain

Meta's engineering team has published a rare thing: a component-level engineering writeup of an internal agent it calls an organizational second brain, built to answer compliance questions the way its own domain experts would. Most coverage will talk about the agent. The more useful read treats the document as a build spec, and the spec is blunt once you squint at it. An AI second brain succeeds or fails on its knowledge supply chain, the pipeline by which expert knowledge gets elicited, validated, owned, and retired. Retrieval, the layer vendors market hardest, is the part you can assemble from off-the-shelf components in an afternoon.

The disclosure describes a compliance-domain agent with a structured knowledge base of 200-plus files, a reasoning layer of composable procedures, evaluation gates, and a self-improvement loop that turns expert corrections into regression-tested edits. Strip out the ML vocabulary and what remains is a knowledge-operations playbook: who extracts knowledge from which experts, who checks it before it ships, who owns each entry, and who kills entries when reality moves. This piece reconstructs how Meta built its organizational second brain from the disclosure itself, separates what was said from what I am inferring, catalogs the ways these systems die, and ends with a keep-adapt-drop transfer test plus a build order sized to a small team's expert-time budget.

What Meta's AI Second Brain Writeup Actually Describes

The writeup is unusually concrete for a large-lab disclosure, so it rewards reconstruction at the component level. Everything below is disclosed unless marked as inference. (This is not Meta's first public discussion of its internal AI agent lineage; a recorded Metamate talk covers earlier engineering context on the company's internal assistants.)

Meta reports that after three development sprints spanning six weeks, domain experts rated outputs useful almost all the time, individual assessments dropped from days to minutes, and improvement cycles produced zero regressions. These are self-reported figures without external audit, so treat them as directional. The structural claims are the durable part: files in version control, human-reviewed diffs, and a regression suite that grows with every fix.

Two disclosed choices deserve more attention than they get. First, experts remain the source of truth. The agent surfaces its reasoning at checkpoints for confirmation, escalates genuine ambiguity instead of guessing, and every correction becomes input to the improvement loop. Knowledge enters through a loop with named humans in it, which is what converts an ML project into a knowledge-operations project. Second, the wiki-versus-RAG split is decided by information density and usage frequency. High-density, frequently consulted knowledge gets curated into files; sparse, situational material stays behind retrieval. Both are supply decisions dressed up as architecture.

The Knowledge Supply Chain, Stage by Stage

Read through a supply-chain lens, the writeup maps cleanly onto four stages. Each has a decision Meta made visibly, and a cost that hits smaller teams harder.

Elicitation, the stage that eats expert time

Meta extracts knowledge two ways: an offline process that reasons over source documents and distills them into structured files, and an online loop that mines expert corrections from conversation traces. The motivating pain is familiar. Experts were spending more hours answering routine, recurring questions than doing the ambiguous judgment work where they are actually scarce.

Elicitation is typically the most expensive stage, because the binding constraint on expert knowledge capture is expert time. The naive move, asking experts to write down what they know, usually fails, since the most valuable part of expertise is tacit and invisible to the expert themselves. Human-factors researchers built applied cognitive task analysis for exactly this problem: structured probes over real past cases, not requests for general wisdom. Knowledge elicitation for AI agents is the same discipline with a new consumer. And whatever else you do, schedule the supply, because agents that passively wait for voluntary contributions starve.

Validation, the stage that protects trust

Every knowledge edit at Meta passes two gates: targeted replay, where the agent reruns the original scenario and a blind judge scores the output without knowing what changed, and regression testing across domain benchmarks. A separate adversarial agent reviews proposed diffs in a fresh context so it cannot inherit the proposing agents' blind spots, and a deterministic linter fails structural problems outright. The output is a pull request; the writeup estimates about 30 seconds of expert attention per diff.

That last number is the design. Internal tools get roughly one chance with their users. A single confident, wrong answer on a question the expert would have nailed does more damage than a month of mediocre-but-hedged answers, because it teaches the team the agent cannot be trusted where it counts. Validation gates and honest uncertainty handling are load-bearing requirements, not polish.

Ownership, the stage that decides who can change what

Every file in Meta's system declares its dependencies and consumers, glossaries are maintained as single sources of truth, and changes land as reviewed pull requests. That gives every piece of knowledge an address a name can attach to. The implied rule: every entry in an AI knowledge base needs an answerable owner, assigned per entry, not per team. An entry without a named owner is a stale entry on a timer. When two entries conflict, ownership decides who arbitrates. When a position turns out wrong, ownership is what gives someone the standing to fix it fast.

Retirement, the stage Meta says least about

This is the thinnest part of the disclosure, and honest reconstruction should say so. Meta describes version control, diffs, and reversibility, which make retirement mechanically possible, but discloses little about scheduled re-verification, expiry, or archiving positions that no longer hold. The inference is that at Meta's staffing level, active expert reviewers and the improvement loop catch drift as it happens. Smaller teams get no ambient expert attention, so retirement needs explicit mechanics: a last_verified date on every file, a re-review interval proportional to how fast the domain moves, and an orphan queue that fires the moment an owner leaves or changes role.

Why the Retrieval Stack Is the Easy Part

If you skim the architecture, you might credit the win to clever retrieval. The writeup argues the opposite by example. Routing indexes map input characteristics to the relevant positions and procedures, so core retrieval is deterministic and auditable rather than similarity-scored, with semantic or lexical search as a fallback for sparse material. The hard-won token reduction came from restructuring knowledge into staged recipes, a supply-side fix, not a search-side one.

Embeddings, vector search, hybrid retrieval, and rerankers are commodity components that a competent team assembles from open-source or vendor parts in days. Meanwhile the survey literature keeps cataloguing the same enterprise RAG limitations, with stale or mis-scoped knowledge high on every list; better search does not rescue wrong content. Why enterprise RAG fails on stale knowledge is a supply-chain question wearing a retrieval costume.

Put the two best-documented deployments side by side and the convergence stops being a coincidence. Morgan Stanley's OpenAI case study describes an assistant for wealth managers built on a curated library of roughly 100,000 documents, sustained over years by a real content operation. Meta's agent runs on 200-plus distilled files kept current by an automated validation pipeline, built in six weeks. The scales could hardly differ more, yet both winners spent their effort on the same stages: elicitation, validation, and ownership, the supply chain walked through above. Neither won on search. Morgan Stanley's durable advantage was institutional knowledge AI can actually trust, produced by curation and review; Meta's was a supply process that compounds with every expert correction. The writeup itself gestures at the convergence, citing file-based agent knowledge approaches in the wider industry.

Vendor second brain products mostly sell the opposite bet. AI knowledge management marketing leads with storage, search, and a chat surface, all fine things to buy, as long as you budget for what they do not solve. Elicitation, validation, ownership, and retirement arrive as the buyer's problem, and that is the part where these projects actually die.

How Organizational Memory Agents Fail

None of these failure modes is new, which is the point. Organizations have been bad at institutional memory since long before LLMs, and the research trail is long.

Starved supply. The lessons-learned literature documents decades of the same pattern: organizations capture lessons and then fail to reuse them, because capture is a system while reuse is a behavior. The why lessons learned fail research line covers this in detail. The AI version is sharper, because an agent that waits for voluntary contributions gets silence, then gets blamed for being empty.

Staleness. Any team that has trusted a stale runbook has run the documentation rot experiment personally; unowned text decays, and enterprise RAG inherits the failure wholesale when it indexes content nobody maintains.

Ownership vacuum, then attrition. Single-owner entries die twice, once when the owner burns out and once when they leave. A workforce knowledge loss survey flags institutional knowledge loss as a top concern while large cohorts retire or shift roles, and organizational memory research has long documented how quickly organizations forget what individuals knew.

Trust decay. After a few confident wrong answers, users stop asking and start routing around the tool, and the system enters decline with no telemetry to show for it.

The Transfer Test for Smaller Teams

Can small teams build an organizational second brain? The process transfers. The staffing does not. The writeup's acknowledgements list around sixteen named contributors for a single domain; even read generously, that list implies a multi-engineer team plus dedicated expert time. That is the part you cannot copy, and pretending otherwise is how internal tool budgets get burned.

A scoped example for a roughly 40-person company: the eight-person platform team owns one domain, incident severity classification and release go-no-go calls. Scope is 20 to 30 position files, built on about two hours per week of one senior expert for a quarter, roughly 24 expert hours in total, plus a fifth of one engineer. That budget does not buy Meta's system. It buys the supply chain in miniature: structured interviews, reviewed entries, named owners, dated files, and a small eval set, which is the part that decides whether the thing lives.

A Build Order That Fits a Small Team's Budget

1. Measure the domain for two weeks before writing anything. Log every recurring question that reaches your experts. Meta's disclosed fit criteria are tribal knowledge living in heads, consistency across assessments mattering, and volume exceeding expert capacity. If the same questions arrive weekly, the domain qualifies.
2. Run structured elicitation, not open requests. Forty-five to sixty minute interviews with task-analysis style probes over real past cases. Expert knowledge capture without burning expert time means interviews with a script, not a wiki page begging for volunteers.
3. Write files with supply metadata from day one. Each entry records the position, its boundary conditions, routing cues, a named owner, and last_verified. Markdown in git is enough.
4. Gate every entry behind a second reader. Author plus one reviewer before anything ships, and experts review diffs rather than drafts, which keeps review in the 30-second range Meta reports.
5. Ship dumb retrieval first. Rules, keywords, and filenames route queries; add embeddings only when file count makes lookup genuinely painful. Retrieval polish is cheap to add later and easy to overbuild now.
6. Set the retirement policy before launch. Re-review interval matched to domain velocity, an orphan queue on owner departure, and a documented one-edit way to invalidate an entry.
7. Grow an eval set from every correction. Thirty to fifty golden questions, rerun on each edit. This is the seed of Meta's regression suite at one-hundredth the scale.

The honest verdict closes the loop this piece opened with. A pattern like this pays off when recurrent expert-bound questions, consistency risk, and volume all point the same way, because then expert hours compound instead of evaporating. If you cannot fund the expert hours, or the knowledge is already written down and stable, a good wiki plus a capable copilot is the truthful answer; a starved agent would be worse than nothing because it spends trust you will need later. The retrieval stack you can buy. The supply chain you have to operate, and that is the whole decision.