What Meta Found When It Sent Agents Into Its Own Codebase

Somewhere inside one of Meta's large-scale data pipelines, two configuration modes use different field names for the same operation. Swap them and the code compiles fine. The output is just wrong.

Nobody wrote that down. An engineer learned it once, probably the hard way, and told the next person who needed to know. This spring, when Meta sent AI agents into that pipeline, the agents didn't know. So they explored, tried things, guessed. They produced code that looked correct and wasn't. The pipeline spans four repositories, three programming languages, and over 4,100 files. Only 5% had structured documentation. The other 95% was held together by knowledge that lived in people's heads: which enum values are labeled "deprecated" but must never be deleted because serialization depends on them, which intermediate fields get silently renamed between stages, which six subsystems need touching in a specific order to onboard a single new data field.

The agents were capable enough. What they needed had simply never existed in a form anything could read.

To surface it, the team built a swarm of 50+ specialized agents that systematically read every file and produced 59 concise context documents encoding tribal knowledge. Explorer agents mapped repository structure. Module analysts interrogated each file against standardized questions. Critic agents ran independent review passes. The output was small: all 59 files together consume less than 0.1% of a modern model's context window. But in preliminary tests, agents with access to those files needed roughly 40% fewer tool calls per task. A sliver of institutional memory was the difference between blind exploration and directed work.

The same bottleneck appears across two other Meta engineering posts from April, at different layers of the stack. In the Capacity Efficiency platform, agents couldn't find or fix performance regressions until the team encoded senior engineers' reasoning patterns into composable "skills": when to check GraphQL endpoints for latency regressions, when to look for schema changes if the affected function handles serialization. In KernelEvolve, agents couldn't optimize hardware kernels until chip-specific architecture manuals and optimization patterns were injected into a retrieval-augmented knowledge base. When a new chip arrives, the expensive part is curating hardware documents into a form the agent can read. Three projects, three layers, one prerequisite: the expertise had to be excavated and made machine-readable before agents could do expert-level work.

Sit with the failure mode here, because it's quiet. An agent that crashes is easy to diagnose. An agent that produces code which compiles, passes casual review, and is subtly wrong generates no error, no incident report, no organizational signal that anything went sideways. The system is optimized to produce plausible output. That's the feature. And it's what makes undocumented knowledge specifically dangerous. A model that said "I don't know" would be safe. A model that confidently applies the wrong field name produces output that looks like success until something downstream breaks, weeks later, attributed to something else entirely.

Meta had the engineering resources to build a 50-agent swarm to excavate its own institutional knowledge, and what it found was that 95% of what held a critical pipeline together had never been written down. Most organizations deploying agents against complex operational systems haven't done this excavation. Many don't know it's needed, because the failure that results from skipping it doesn't announce itself. The gap turned out to be knowledge nobody had thought to formalize, because until now nobody besides a person ever needed it. Meta can solve that at scale. Most organizations are still at the stage where they don't know the problem exists.