Femke Plantinga published a breakdown this week of nine real "company brain" builds, GBrain, mem0, Letta, Zep/Graphiti, Sylph, a DIY Claude Code and git setup, Pletor, Gorgias Cortex, and Slite Agent, and found they all reduce to the same four jobs: getting signals, remembering, dreaming and pruning, speaking and searching. We read it, then opened our own admin dashboard to check something we had never framed this way before: we have been running one of these for over a year, and nobody here had called it a company brain.
Where the framework comes from
Plantinga's research looked at Gorgias Cortex specifically, an in-house system holding 12,000 markdown nodes, alongside work touching 149 teams more broadly, and landed on the same four-part shape across every implementation she examined, regardless of whether it was a personal tool, an agent-memory library, or a full in-house build. One line from her comment section is worth repeating exactly: successful implementations put "a named human on the other end of the staleness signal," and stale knowledge becomes, in her framing, "a system reliability problem, not just a search problem."
What we actually run
Thirteen agents, registered in one file (`lib/agent-store.ts` if you want to check the receipts yourself, this is not a marketing number). One orchestrator fires every morning at 06:00 UTC and fans out to six of them in sequence: SEO monitoring, job-signal scanning, tender monitoring, competitor monitoring, content intelligence, and social drafts. Every run logs to Redis, status, tokens, and cost included, so we can see exactly what ran and what it cost without guessing.
Three of the four, verified
Getting signals is the six-agent pipeline above, real, running daily, not hypothetical. Speaking and searching is the admin dashboard plus a HubSpot sync that fires automatically once a lead scores above a threshold, so a qualified signal reaches the CRM without anyone copying and pasting it there. Remembering is the part that turned out to be more interesting than we expected going in.
Agent output that matters does not go live untouched. It lands in a Notion database with one property, Status: Needs Review, and a human has to mark it reviewed before it counts as fact rather than a draft. That is, functionally, exactly the "named human on the other end of the staleness signal" Plantinga's commenters described. We did not build it to match a framework. We built it because letting an agent's output stand unchecked felt obviously wrong, over a year before that sentence existed anywhere we'd read it.
The one we do not have
Dreaming and pruning: nothing. A year of Redis logs just accumulates. Nothing decays, nothing gets re-summarised, nothing gets deleted. The Notion review queue keeps the trusted layer clean because a human curates it manually, but the operational history underneath it only ever grows. That is the same gap Plantinga's research found in most of the nine builds she looked at, and it is worth naming in public rather than leaving out of a piece like this one, because a system that only remembers and never forgets is not actually finished, it is just young.
This is the same architecture question we now get asked directly: a client wants AI workflow automation, and the real design decision underneath that request is never "which model," it is where the human review gate sits, and what happens to everything the system logs after the gate has done its job. We happened to answer that question by instinct, over a year before anyone gave the answer a name.