Meta's AI second brain reaches 63,000 employees: the infrastructure did the heavy lifting

There is a wave of application rebuilding and replacement going on. At Eli5, we review articles about software modernization every week to find real value for CTOs, PMs, and POs who have to deal with the modernization of legacy software.
"The agent is only as useful as the systems it can reach." (Analytics at Meta)
Abstract. This week we reviewed a Medium post from Analytics at Meta describing how an internal experiment called the AI Second Brain grew from one data scientist's fix for scattered notes to 63,000 installs across Meta in roughly three months. The system gives an AI agent persistent, structured access to a person's projects, meeting notes, tasks, and internal tools, so every session starts with context instead of a cold explanation. It runs on Claude Code, a structured workspace on Google Drive, a set of connectors to internal systems, and reusable workflow instructions written in plain markdown. The post is honest about what made it possible and what they learned along the way. Our conversation kept landing on the part of the story that gets one paragraph in the article and deserves the headline: none of this works without infrastructure that most companies do not have.
Source. Analytics at Meta
Review and insights
A folder structure an agent can understand. The workspace is organized with PARA, a productivity method by Tiago Forte that was originally designed for human note-taking. PARA splits all personal information into four categories: projects for short-term active work, areas for long-term responsibilities, resources for reference material, and archives for everything that is no longer active but worth keeping.

It turns out this structure works just as well for an agent, because it communicates what is active, what matters right now, and where new information should be filed. Each session starts from a lean root context file, and the agent drills into specific project folders only when the conversation requires it. Meta calls this progressive disclosure. When Floris asked whether there is special logic behind that drilling, Kishan's answer was that there is nothing exotic built in. Modern reasoning models work this way by default: they start from the superficial knowledge in front of them and use their tools to retrieve more until they can act. The same shift explains why vector databases barely appear in this architecture. Retrieval augmented generation (RAG) still exists, but with today's context windows you can load the relevant knowledge for a project directly, and the elaborate retrieval machinery becomes optional. The approach also rhymes with the layered context model we introduced in an earlier review: structure the knowledge in tiers, and let the agent infer the rest.
The investment that mattered was made years ago. The article states it plainly: the investment that made the project possible was Meta's development of Model Context Protocol (MCP) servers and command line interfaces (CLIs) that give agents authenticated, scoped access to internal systems. Without that layer the agent can read local files and nothing else. With it, the agent pulls meeting transcripts, checks task status, reads discussion threads, and writes documents, all within the user's own permissions. Kishan called exposing data in a form an agent can work with the most difficult part of the entire exercise. No two companies are alike. Every organization has its own processes, its own systems, and its own way of working, and unless those are documented and reachable through an interface, the agent has nothing to stand on. Meta had a structural head start here. The company was built for the internet, so the modernization question that dominates most enterprise AI conversations never really existed for them. Floris raised the fair suspicion that this made the project easy, and Kishan pushed back: it was probably hard for Meta too, they simply had more capability, more tech-savvy people, and systems that were already in order. It also helps that this came out of Meta Analytics, a business unit with a clear objective and control over its own tooling and access. Doing this globally, across every business unit in every country, would be a different story.
Two quiet months, then one viral post. The adoption chart in the article is the most instructive image in it. The system launched in December and almost nothing happened for two months. Then a non-technical product manager published an internal post with a plain install guide and concrete examples of what the tool unlocked, and within days it spread across every function at Meta, executives included. Today it counts over 63,000 installs and roughly 10,000 daily active users, all without a top-down directive. Kishan's reading: you can build something that works and put it out there, and nobody will use it until somebody makes it accessible and shows what it can do. Between launch and the viral post, the tool itself barely changed. What changed was that someone lowered the entry cost and made the value visible. For anyone who has watched a mandated enterprise AI pilot limp along, the contrast stings. Grassroots adoption of this scale cannot be ordered into existence, and the moment the whole thing became undeniable was, fittingly, an incident: usage tripped API rate limits hard enough to slow Meta's broader AI development environments, forcing a tenfold capacity increase. Adoption you have to firefight is adoption you can trust.
Meta built this on someone else's model. The deployment runs on Claude Code with Anthropic's latest model. Llama, Meta's own model family, is nowhere in the article, and this apparently sailed through Meta's own publication process without anyone addressing it. We found that remarkable. This is a company that trains frontier models, reportedly records how its own employees work to feed those models, and around the same period was in the news because Google cut off its heavy internal Gemini usage. So why is the flagship internal productivity system built on a competitor's stack? The honest answer is that we do not know, and neither does anyone outside Meta. It could be raw model capability. It could be that Claude Code as a harness, the execution environment with its agentic loop, tool calling, and error recovery, is currently ahead of anything Meta has internally. The article itself notes that an agent is a model plus a harness, and that their architecture is harness-agnostic. Whatever the reason, a company with every incentive to use its own model chose otherwise, and that choice says more than any benchmark.
The bill behind the second brain. Those API rate limits point at something the article leaves out: cost. Ten thousand daily active users running agentic sessions is a significant line on any balance sheet, and the spend does not stop at the model provider. Every agent session also hammers the APIs of the systems it reaches into. If you hit rate limits at Claude, you are probably also hitting them at Google Drive and every other system the agent touches. Current subscription and API pricing is widely assumed to be subsidized, so organizations planning something similar should expect the unit economics to get worse before they get better. The practical mitigation is already visible in how these systems get built: let an expensive frontier model do the difficult thinking up front, then hand the scoped, repetitive work to cheaper models that cost a fraction per call. Running your own local models sounds attractive until you account for the hardware, the expertise, and the fact that frontier capabilities are unlikely to ever be open sourced, which leaves self-hosters permanently a step behind.
The link to software modernization
Read as a case study rather than a victory lap, the Meta post confirms the sequence we keep arriving at in this series. Before an agent can act as a second brain, the systems have to be in order, the data has to be exposed through interfaces an agent can call, and the processes have to be documented somewhere accessible. Meta could skip that phase because two decades of staying modern had already paid for it. For an average organization with legacy systems, undocumented business logic, and fragmented data, that groundwork is most of the project. Call it 80 percent. In our previous review we argued that the forward deployed engineers (FDEs) now being placed inside enterprises by the frontier labs will end up doing modernization work under an AI flag, because that is where the actual blocker sits. Meta's post is a preview of what that work buys you once it is done: an agent layer that a viral internal post can scale to 63,000 people in weeks, because everything underneath it was already reachable.
Concluding remarks
The Meta article is a well-written adoption story, and the numbers earn it. The transferable lesson sits in the first line of their own learnings section: infrastructure comes first. Everything else in the piece, the folder structure, the skills, the viral growth, rests on authenticated access to internal systems that took years to build. Organizations that want their own second brain should read this post backwards. Start with the access layer, the documentation, and the data plumbing, and accept that this is where the time and money will go. The agent on top is increasingly the simple part, and as Meta's own model choice quietly demonstrates, it is also the part you can swap.
Full video episode
The first step to start your modernization journey
Software modernization and architectural rebuilds lie at the heart of Eli5. We solve complexity to deliver direct business value by focusing on pragmatic, cloud-native transitions.
Before you decide whether to wrap your legacy system, buy a new SaaS product, or use AI to build custom tools, you need total visibility into your current tech landscape.
Would you like to book a free brainstorm to discuss your legacy stack? It is the essential first step to turning your technical debt into a scalable, modular future.





.webp)









.webp)
.webp)



















.webp)

.webp)





.webp)






%20(1).webp)







.webp)
.webp)


