Your Moat Isn't the Model. It's the 40 Pages Nobody Bothered to Write Down.
Meta's second brain agent points at the real defensible layer in AI products, and it isn't a fine-tuned model trained on your proprietary data
Last year I did fractional CTO work for an immigration-AI company. The founder came in convinced the hard part was model selection. Which one is best at legal reasoning, should we fine-tune, do we need our own?
The hard part turned out to be a series of conversations with one attorney.
She had been doing this for two decades. She could look at a case file and tell you in ninety seconds whether the petition was going to have a problem, and why, and what evidence would fix it. None of that was written down anywhere. It lived in her head, and it leaked out one client at a time. The product was not "AI reads immigration documents." Every competitor could do that. The product was her judgment, made repeatable.
Meta published something this week that describes the same shape from the other end of the scale. They built what they call an organizational second brain, an agent that captures expert knowledge inside the company and makes it usable by everyone else. The interesting part is not that it exists. The interesting part is the architecture they chose.
They kept the knowledge separate from the reasoning. The expert knowledge lives in a structured, auditable layer you can inspect and edit. The model sits next to it and does the thinking. When an expert corrects the system, the correction updates the knowledge layer. Nobody retrains anything.
That is a deliberate choice, and it is the opposite of what most founders I talk to believe they are supposed to be doing.
The assumption I keep having to unwind
The story goes like this. We have proprietary data. We hire an ML engineer. They train a model on our data. The trained model is our moat, because nobody else has our data.
Almost every part of that is wrong for a company under twenty people.
Your proprietary data is usually not training data. It is a few hundred case files, a CRM export, some Slack history, and a folder of PDFs. Fine-tuning wants volume and consistency, and what you have is small and messy. Even when it works, you get a model that is slightly better at imitating your outputs and no better at explaining itself. You cannot look inside it and ask why it said what it said. You cannot let your domain expert go in and fix one specific wrong belief on a Tuesday afternoon.
And the moment a materially better base model ships, which is roughly every quarter now, your fine-tune is a sunk cost sitting on top of yesterday's foundation.
Meanwhile the actual thing your expert knows is sitting in their head, undocumented, and nobody has scheduled the interviews.
Tribal knowledge is a business risk, not a culture quirk
I scaled one engineering org from 4 to 31 people. The bottleneck was never hiring, and it was rarely tooling. It was that the four original engineers knew everything and had written down none of it. Why the payment retry logic has that weird backoff. Which service you must never restart during a live event. What the finance team actually means when they say "reconciled."
Every new hire cost us a senior engineer's month, because onboarding was an oral tradition. We eventually got religious about writing decisions down, and velocity moved more from that than from any framework choice we made.
Same lesson, different decade: undocumented expertise does not scale, and it walks out the door when the person does.
What is new is that written-down judgment is now executable. Five years ago a well-structured internal wiki was a nice-to-have that humans occasionally read. Today that same document, structured properly, is the thing a model reads before it answers a customer. The rules you write become product behavior.
When I built FlipSmrt on my own, the code was not the interesting part. The domain rules were the product. What makes a deal good, which signals matter, what disqualifies a property immediately. Getting those right was slow, human work. The software around them was comparatively easy.
What this means for who you hire this quarter
If your edge is domain expertise, your first AI hire is probably not an ML engineer. It is someone who can sit with your expert, ask uncomfortable questions for two weeks, and turn the answers into structured text a model can consume.
That work looks like this. You take the twenty decisions your expert makes most often. For each one, you get them to explain the actual criteria, not the sanitized version they would say on a webinar. You write down the edge cases, the exceptions, the "well, unless" clauses. You write down what a good output looks like and what disqualifies a bad one. You put it in files, in version control, so every change has an author and a date and a reason.
Then you point a good off-the-shelf model at it and see how far you get. In my experience it is much further than founders expect, and the gaps it reveals are almost always gaps in the written knowledge, not gaps in the model.
Then you build the loop Meta built. When the expert says "this answer is wrong," that correction goes back into the knowledge layer as a new rule or a sharpened one. No retraining. No ML pipeline. Your expert improves the product directly, in a form you can audit and a regulator or an enterprise buyer can read.
Two people can do this. One who understands the domain, one who can structure it. There is no ML hire in that sentence.
The part that survives the next model release
Here is why I think this is the right bet rather than just the cheap one.
Everything else you build this year is depreciating. The model you picked will be superseded. Your prompting tricks will stop being clever when the next generation stops needing them. Your orchestration code will be replaced by whatever the frameworks absorb next.
The forty pages that encode how your best attorney, underwriter, ops lead or clinician actually thinks do not depreciate. They get better every time someone corrects them. They transfer to the next model in an afternoon, because they were never entangled with it in the first place.
That is the asset. It is unglamorous, it does not demo well, and it is the reason one company in your category will be defensible in three years and the other four will not.
If you are sitting on real domain expertise and being told you need an ML team to use it, I would push back hard. Book thirty minutes and I will tell you what I would actually do first. It usually starts with a recorder and your best person's calendar.