The Brain Was the Architecture: How a Metaphor Became My System Design

I named my memory system after the hippocampus. Then I named the orchestration runtime after the prefrontal cortex. By the time I caught myself calling the MQTT bridge "the thalamus" out loud, the metaphor had stopped being a cute label and started being the architecture. The brain wasn't decorating my system. It was designing it.

That's the part nobody tells you about naming. A metaphor isn't a coat of paint you apply after the structure is built. Pick the right one early and it does structural work — it tells you what belongs where, what each piece is allowed to touch, and where the seams should fall. Pick the wrong one and you spend a year fighting a name that keeps lying to you about what your system is.

Here's the map I ended up with, and why each pairing earned its place.

The Map

Hippocampus → Coquina. The hippocampus is where the brain consolidates experience into memory — it decides what's worth keeping and files it for retrieval. That is exactly Coquina's job. It's a self-healing memory platform for AI agents: every write passes through admission control that scores it on five signals before it's allowed in, so the system is choosy about what becomes a memory instead of hoarding everything. It auto-links what it keeps into a relationship graph — right now ~2,046 memories tied together by ~48,359 typed edges across 25 projects. Dual-path search, recency-ranked, sub-2ms. The biological hippocampus consolidates, links, and retrieves. So does Coquina. The name isn't analogy — it's a spec.

Prefrontal Cortex → Forge. The prefrontal cortex is the executive: it plans, sequences, holds goals, decides what runs next. Forge is my agent runtime — 32 autonomous workers and a 25-step overnight chain that runs at 5 AM doing security review, code review, auto-fix, research scouting, consolidation, benchmarks. It's the part that decides what happens and in what order. Calling it the prefrontal cortex told me, on day one, that Forge should never store long-term memory itself. Executive function doesn't hoard memories; it calls the hippocampus. So Forge calls Coquina. The metaphor drew the boundary before I did.

Thalamus → the MQTT bridge. In the brain, almost every sensory signal routes through the thalamus before it reaches the cortex. It's the gate — the relay that decides what gets passed up. My Thalamus is the MQTT bridge that takes IoT and Home Assistant signals from the physical world and routes them into Coquina. The name does a job here too: a thalamus relays, it doesn't think. So the bridge stays dumb on purpose. No business logic lives in it. The moment I'm tempted to make the gate clever, the name reminds me that's not its role.

Corpus Callosum → Nerve. The corpus callosum is the bundle of fibers connecting the two hemispheres so they stay in sync. Nerve is my MCP server registry and guardian — it watches the connections between tools and agents, detects drift, and auto-restores configs that get silently wiped. It is, almost literally, the connective tissue that keeps the halves of the system talking. A registry guarding the wiring between everything else is a corpus callosum. The name wrote the job description.

Visual Cortex → Frigate. The visual cortex turns raw retinal signal into recognized objects. Frigate is the vision layer. Same transformation, silicon edition: pixels in, recognized things out. The metaphor here is almost too on-the-nose to count, which is exactly why it's reliable — nobody on my system will ever wonder what Frigate is for.

Why a Good Metaphor Is a Design Tool, Not a Decoration

Three things happen when the metaphor is right, and all three are design work.

It makes a complex system legible. I can describe this entire stack to someone in thirty seconds because they already own the reference hardware. Everyone has a brain. When I say "the thalamus relays sensory input to the memory system, and the prefrontal cortex decides what runs," a person with zero infrastructure background nods, because they're not learning my system — they're mapping it onto one they've had since birth. Legibility is a design property. A system you can't explain is a system you can't hand off, can't hire for, can't onboard anyone into. The metaphor is the documentation that writes itself.

It guides what each part should and shouldn't do. This is the part that surprised me. A good metaphor isn't just descriptive — it's prescriptive. It comes with built-in rules about behavior, and those rules turn into architectural constraints for free. The thalamus doesn't reason, so my bridge doesn't either. The prefrontal cortex doesn't store memories, so my runtime delegates to the memory layer instead of growing its own. The corpus callosum connects but doesn't compute, so Nerve guards wiring and stays out of business logic. Every time I felt the pull to let one component creep into another's job, the metaphor was right there saying that's not your organ. I've watched plenty of systems rot because a component slowly absorbed responsibilities that didn't belong to it. A strong metaphor is a cheap, durable defense against exactly that drift.

It's an information-architecture decision in disguise. This is the one I want designers to sit with. When you name the parts of a system, you are deciding how people will think about it — which means you're deciding the mental model, the boundaries, the categories. That's information architecture. It's the same discipline as deciding what goes in a nav bar, how you group settings, what counts as a "project." Naming Coquina the hippocampus didn't just label a database; it asserted that memory is one coherent thing with one home, not a feature smeared across five services. The name made an architectural claim. Get to that claim through the metaphor, early, and the system organizes itself around a model that already makes sense to humans.

The Honest Tradeoff

Metaphors have a failure mode, and I'd be lying if I pretended mine doesn't. A metaphor that fits too well can stop you from doing the right thing when biology and engineering disagree. The brain has no clean analog for a Redis queue or a GPU coordinator or a self-healing daemon that restarts a worker in 60 seconds. When I hit those, I don't force a brain-region name onto them — forge-internal plumbing is allowed to just be plumbing. The metaphor is a tool, not a religion. The discipline is knowing when the map stops matching the territory and being willing to drop it at the boundary instead of contorting the system to keep the bit going.

That's the actual skill. Not "pick a clever theme." It's knowing how far a metaphor's load-bearing capacity extends, using it hard inside that range, and letting it go the instant it would cost you a good decision.

What This Says About Naming

After fifteen years designing product, I thought I understood that naming matters. Building this taught me it matters more than I credited — because in a system, a name isn't a label on a finished thing. It's a hypothesis about what that thing is, broadcast to every future decision about it. A weak name leaves the boundaries undefined and lets responsibilities bleed. A strong one — one that carries a model people already hold — does ongoing architectural work long after you've stopped thinking about it. The hippocampus has been telling me what Coquina is allowed to do for months. I just had to pick the right organ.

If you're building agent systems and want to talk architecture, naming, or how a designer's eye changes infrastructure decisions, I'm at reed@grainlabs.io.