Parts one and two of this series unpacked Meta’s organizational second brain: expert knowledge as structured files, reasoning as recipes, and a self-improvement loop that compiles corrections into permanent, tested fixes. The obvious objection: that’s Meta — they have research engineers to spare. Fair. So this post is the version I actually build for mid-market companies: the same four layers, scaled from 200+ files and multi-agent compilers down to a repo of markdown files, one disciplined admin, an eval set, and a monthly hour. The pattern survives the shrinking. Here’s the kit.

What I’ll Cover in This Blog

✔️ The scenario: a benefits firm whose expertise lives in two retiring heads
✔️ The starter kit: knowledge files with frontmatter, in a plain git repo
✔️ Light recipes: three checklists, not an orchestration engine
✔️ The manual flywheel: a correction log, an eval set, and a monthly hour
✔️ Where it plugs into your AI stack — and your Salesforce org

Now, let’s dive in! 🔥

The Scenario

Solari Benefits Group (anonymized composite) is a 120-person employee-benefits firm running on Salesforce. Their gold is interpretive: how to read a carrier’s eligibility rules, when a plan amendment triggers a compliance filing, which exceptions a specific carrier will actually grant. Almost none of it is written down. It lives with two senior consultants — one of whom retires next year.

They wanted an AI assistant for the service team. The first prototype pointed a model at their document drive and produced exactly what part one predicts: fluent summaries of what the documents say, with no idea what Solari does. The fix wasn’t a better model or better chunking. It was building the firm a second brain — small, honest, and maintained.

The Starter Kit: Knowledge Files in a Repo

Meta’s version has 200+ files and a strict taxonomy. Solari’s version launched with 31 markdown files in a git repository, following the same four types, because the types are what matter, not the count:

🔹 Position files (19). One page each: “How we handle mid-year dependent eligibility changes” — the firm’s stance, its boundaries, the exceptions, and which carrier rules override it. Each written by interviewing the senior consultants for an hour and distilling, exactly the interview discipline from the Current State Assessment.

🔹 One vocabulary file. The firm’s terms, each defined once. Half the “AI errors” in the prototype turned out to be the humans using three names for the same plan type.

🔹 One routing index. A table mapping question types to position files. Deterministic: “COBRA questions → positions 7, 12, 14.” No embedding roulette for the rules that matter.

🔹 Gateway rules (one file). The questions the assistant must not answer — legal advice, carrier disputes, anything touching protected health detail — and where to send them instead. The same detect-your-limits discipline as an exception path.

Every file carries simple YAML frontmatter: applies_to, depends_on, owner, last_reviewed. That’s the dependency graph and the freshness system in four lines — and because it’s a git repo, every change is a reviewable diff. Files, not fine-tunes, works at every budget.

Light Recipes: Checklists, Not Orchestration

Meta’s recipes compose into pipelines with a routing recipe on top. Solari needed exactly three, each a one-page checklist the assistant follows:

1️⃣ Answer an eligibility question: check the gateway rules → consult routing → load the named positions → answer with the position cited → if no position covers it, say so and escalate.
2️⃣ Review a plan change: list what changed → check each against the compliance positions → produce a flag list with citations → human signs off (an approval gate, because filings are consequential).
3️⃣ Draft a client explanation: load the vocabulary file → draft in firm terms → attach the underlying position for the consultant to verify.

The rule carried over intact from part one: recipes name positions; they never contain them. When a carrier changes a rule, Solari edits one position file and every recipe that references it is current. That’s the entire maintenance model — and the reason the assistant’s answers stay consistent across all three workflows.

Where does the live data come from? The same split as always: the knowledge repo is the stable canon riding in the assistant’s cached context (cache the stable, retrieve the volatile — 31 files ≈ 45K tokens, comfortably cacheable), while client, plan, and case records are retrieved from Salesforce per query, with sharing rules enforcing who sees what. Positions tell it how to think; the CRM tells it what’s true about this client today.

The Manual Flywheel: A Monthly Hour

Here’s the honest scaling-down of part two’s compiler. No multi-agent diagnosis, no adversarial reviewer agents — but the same loop, run by humans on a calendar:

🔹 Capture: every time a consultant corrects the assistant, the correction goes in corrections.md with one crucial extra: which positions the assistant had loaded. Thirty seconds, in the moment.

🔹 Diagnose (monthly, 20 minutes): run each correction through Meta’s attribution test, which works at any scale: could the assistant have answered correctly from the files it had? Yes → fix a recipe/checklist. No → write or amend a position. Consultants disagree → that’s not an edit, that’s an agenda item for the partners.

🔹 Compile and validate (20 minutes): make the minimal file edit, then rerun the eval set — the 30 scored questions — before the change merges. A failing question blocks the merge. Git review is the adversarial reviewer at this scale: the other senior consultant reads the diff cold.

🔹 Enrich (5 minutes): the corrected scenario and its approved answer join the eval set. Month over month, the suite grows and the same mistake becomes structurally impossible to reintroduce silently.

The Four-Week Rollout

How this actually gets built, with one admin, two experts’ interview hours, and a decision-maker:

🔹 Week 1 — Interview and distill. Pick ONE domain (Solari chose eligibility). Interview the experts; draft the first 15–20 position files and the vocabulary file. If data readiness is the blocker, run the 30-Day Data Foundation Sprint first — a second brain on top of rotten CRM data answers beautifully about policy and wrongly about customers.

🔹 Week 2 — Routing, gateways, eval set. Build the routing table, write the must-not-answer rules, and collect 30 real questions with expert-approved answers. The eval set before the assistant — always.

🔹 Week 3 — Wire the assistant. Knowledge pack in the cached prefix; Salesforce records retrieved per query behind sharing rules; the three recipe checklists as its operating procedure. Score it against the eval set until the experts sign off.

🔹 Week 4 — Launch the loop, not just the tool. Train the team, install the corrections log, put the monthly hour in the calendar with a named owner. The adoption-watch discipline applies unchanged: the loop is what you’re launching; the assistant is just its interface.

Solari’s result after one quarter, for honest scale: the assistant answers the routine eligibility questions with citations, the senior consultants field escalations instead of repetition — and 54 position files now exist where zero were written down a year before the retirement that motivated all of it. The second brain is also a succession plan. That’s the part no benchmark measures.

Conclusion

✔️ The pattern survives the shrinking: four file types, light recipes, an eval set, a correction loop — Meta’s architecture at 31 files instead of 200+.
✔️ Files, not fine-tunes, at every budget — a git repo of markdown with four frontmatter lines is a governable knowledge system.
✔️ Recipes stay fact-free — checklists that cite positions, so one edit updates every workflow.
✔️ The flywheel can be manual: capture with context, attribute monthly, validate against the eval set, enrich it forever. One hour a month.
✔️ Plug it into the stack you have: knowledge pack cached, Salesforce records retrieved behind sharing rules.
✔️ It’s a succession plan wearing an AI project’s clothes — the knowledge outlives the retirement.

Start with one domain, two experts, and thirty-one files. The compounding takes care of the rest.

Connect with me on LinkedIn →

Which expert’s retirement would hurt your company most? Tell me their domain — four weeks is enough to start writing it down.

How many of your company’s most important rules exist only in someone’s head? Tell me on LinkedIn.

About the Author — Abubakar Asif