Most AI adoption in marketing plateaus because every workflow starts from zero. The fix is infrastructure: a semantic knowledge base that holds voice samples, client conversations, decisions, and patterns, queryable by any AI through MCP.
This blueprint covers the architecture (Supabase + pgvector + a custom MCP server), the six-table schema we actually use, the management layer that keeps team data clean, and the failure modes that kill most AI adoption programmes before they compound.
What is an Open Brain, and why does a marketing team need one?
An Open Brain is a persistent, semantically-searchable knowledge base wired into every AI tool the team uses, so context never resets between workflows. It's the infrastructure layer that makes AI output compound rather than plateau at month two of adoption.
Origin and frame
The Open Brain is a concept Nate Jones published on 3 March 2026: a personal database you own, connected to any AI through MCP, so your context stops resetting every time you open a new chat or switch tools. His thesis is the one worth leading with. Memory is the actual bottleneck in most people's AI usage, not prompting. Every new chat starts from zero. Every tool switch wipes context. The compounding advantage goes to whoever builds the portable, agent-readable memory layer first.
Our version is the agency-scale implementation of that pattern. Built for a three-person team supporting three retained clients, not for one person's personal context. Six purpose-built tables instead of a generic thoughts store. Typed fields (severity, client, knowledge type, recruitment) because agency work has structure that a single-user notebook doesn't need. A full management layer (v3) for update, soft-delete, and audit, because stored data across a team needs hygiene.
The underlying mechanics are the same as Nate's. Postgres plus pgvector, MCP server, semantic search. The shape of the problem is different.
The problem we're solving.
Two versions of the same problem, stacked on top of each other.
Nate's name. Every conversation starts from zero.
You open Claude and spend four minutes catching it up on your role, your project, your constraints. You open ChatGPT for a second opinion and do it again. You open Cursor and do it again. None of those tools share context with any of the others.
You're burning your best thinking on context transfer instead of the work. Platform memory features (Claude memory, ChatGPT memory) help inside a single app and make the problem worse across apps, because they create silos that don't talk.
The agency version on top of that.
A commercial decision made in February needs to be retrieved in April. Technical findings from an audit need to be visible when a related content brief is written. Role history and communication preferences should live with the client record, not in one person's head.
The agency has a compound memory problem: per-team-member context silos, plus cross-team knowledge fragmentation, plus the long tail of 17-year client history that nobody can hold in working memory.
Dead Notion pages and broken Slack-search are symptoms. The root cause is that none of the tools we were using were built to be queried by AI. They were built for human browsing. The Open Brain inverts that: it's built agent-first, with the human interface (Claude conversations, future dashboards) layered on top.
The five-layer stack.
How a capture works end-to-end. Claude receives a capture instruction, the MCP server generates an embedding for the content via OpenRouter, the row is inserted into the relevant Postgres table with its embedding stored alongside structured fields, and an audit entry is written to change_log.
How a search works. Claude sends a natural-language query, the MCP server generates a query embedding, Postgres uses pgvector's cosine similarity to rank rows, and the top matches are returned with entity IDs so Claude can reference them for updates or deletes.
Self-hosted. No vendor lock-in, no per-request pricing, no external memory service holding client data.
The two-door principle.
From Nate's OpenBrain 2 piece: every extension should be a surface both the agent and the human can see and act on. Agent-readable and agent-writable, human-readable and human-writable. Both sides operate on the same data, each one does what it's best at.
The gap matters less for internal work than it will for content: once we're publishing regularly from Open Brain material, Katie and Jon will want to see state at a glance rather than query it conversationally each time.
The six tables.
Each table is purpose-built for a specific kind of knowledge, with typed fields rather than generic memory slots. Nate's OB2 argues for domain-specific extensions on top of a generic thoughts store. We went further and made the whole thing domain-structured from the ground up, because agency work is predictable enough in shape that structured tables pay for themselves immediately.
The 19 tools.
Fourteen original tools, plus five management tools added in v3 (March 2026). Every MCP client, Claude, Cursor, anything authorised against the server, sees the same 19.
- capture_thought
- capture_client_knowledge
- capture_technical_finding
- capture_contact
- capture_meeting_notes
- capture_playbook
- search_thoughts
- search_client_knowledge
- search_technical_findings
- search_contacts
- search_meeting_notes
- search_playbooks
Each runs over the pgvector cosine index on the matching table's embedding column.
- table_stats
- list_entries
- delete_entry
- update_entry
- restore_entry
All queries return entity IDs. All queries exclude soft-deleted rows. Every delete, update, and restore is logged to change_log, full table with before and after snapshots.
Four principles that govern how we use it.
The four principles below come from Nate's Open Brain 2. They have all held well to agency work.
The agent brings time.
Memory doesn't decay. A decision made on a PEI call in February 2025 is as accessible as one made yesterday. Anywhere the value comes from connecting events across months or years, long-running client work, recurring technical issues, slow-moving strategic shifts, that's the Open Brain's territory.
The agent sees across categories.
The human isn't in any single silo. It's in the connections between tables that no human would cross-reference manually. A contact's communication style meeting a client's active workstream meeting a technical finding raised six months ago. Claude pulls those together in one retrieval.
The most valuable answers are to questions you don't ask.
A database waits for queries. An agent notices things proactively. Our twice-daily scan ("Coventr, with Open Brain integration") surfaces what's worth attention across Gmail, Slack, Calendar, Drive, and Zoom. Captures go into Open Brain. The agent raises what needs raising. The human isn't the retriever.
Agent surfaces, human decides, agent executes.
The agent holds memory and pattern recognition. The human holds judgement. The agent never publishes client content without sign-off, it never emails a contact on our behalf without review. The division is clean and it's what makes the system trustworthy. Blur the line and people stop using it.
Capture conventions.
The Open Brain is only useful if the current state of the work actually lives in it. Four conventions keep it current. All four live as process_playbooks entries that Claude reads whenever it's capturing.
At the end of every substantive work session, Claude proactively runs a sweep. Decisions, findings, contacts, meeting outcomes, observations get categorised by table, proposed as captures grouped with draft titles, and fired once approved. Triggered when the work feels complete, not waiting for it.
During conversations, Claude flags significant items for capture in real-time: scope changes, strategic shifts, new technical findings, meeting outcomes, new contacts, process decisions. Typically phrased as "that's a client decision, want me to capture it?"
Entries can be refined later. Lost context cannot be recovered. The cost of capturing something trivial is negligible. The cost of losing something important is real.
Don't combine multiple decisions into one client_knowledge entry. Don't combine multiple findings into one technical_finding. The embedding needs to represent one thing for semantic search to work cleanly.
Version history.
Baseline.
Six tables, 14 tools. Capture and search only. No soft-delete, no audit log, no way to update or remove an entry once captured.
Full management layer.
Five new management tools: table_stats, list_entries, update_entry, delete_entry, restore_entry. The upgrade moved Open Brain from append-only memory to a full knowledge management system. Entries could be corrected, retired, or restored without being lost.
See Section 12.
Active, in flight. Five enhancements currently queued, detailed in the Roadmap section that follows.
Stats and usage as of late March 2026.
Current release, in production since 22 March 2026
6 capture · 6 search · 5 cross-table management · 2 bookkeeping
Purpose-built for agency work. No generic key-value store.
Captured across meeting notes, client knowledge, contacts, findings, thoughts, and playbooks.
Quarterly public refresh cycle, with monthly stats checks behind it.
Retained-client contexts are partitioned and indexed separately.
Audit methodology / public aggregate only · private client splits omitted · monthly stats check
Open Brain as content pipeline.
The piece Nate's personal-productivity frame doesn't cover and the one that makes the Open Brain strategically interesting for an agency.
The knowledge base being built is the source of truth for operations. It's also the richest source of content we have.
- + Technical findings, "common crawl issues" blog series, technical SEO explainers, auditing methodology pieces, anonymised cross-client pattern reports.
- + Client knowledge, anonymised case study material, sector commentary, strategy-in-practice write-ups, decision archaeology.
- + Process playbooks, methodology content for the website, how-we-work pages, service explainers.
- + Meeting notes, LinkedIn threads, progress summaries, narrative case studies.
Every meeting, every audit, every strategic decision generates potential content as a by-product. Nothing needs to be "written for content". It's already written, already captured, already structured. The task becomes curation and publishing, not creation. The Open Brain inverts operational capture into a content pipeline.
This is the frame our 2026 strategic content playbook is built around: Katie and Jon draft against retrieved evidence instead of blank docs. Robin reviews what's already in use thinking re-surfaced rather than whatever's changed in four publications a month (one pulse, two blogs, one nurture sequence) produced without hiring. Put all of that playbook specifies the scheduled rhythms (Monday opportunities digest, monthly cross-client pattern report, weekly performance review, daily momentum check, quarterly refresh audit) that move the content pipeline from potential to operational.
Roadmap, v4 priorities.
Five enhancements, in current priority order. The top two are in-flight. The rest are queued.
- 01
Confidence and outcome-encoding layer.
In-flightEvery entry and scan output will carry a class flag of {FACT / INFERENCE / OPEN QUESTION} before it is used downstream. A confidence metadata field is planned for client_knowledge, technical_findings, and the thoughts tables, paired with outcome encoding so findings move from static records into actionable loops.
- 02
Scheduled maintenance (planned, Jon).
A scheduled maintenance pass will de-duplicate entries, consolidate repetitive items, and flag content drift caused by working files outside the knowledge base. It is planned as a guarded routine, not an unsupervised cleanup job. Once the maintenance loop is live, the same scheduling pattern can support the content-pipeline routines from the strategic playbook.
- 03
Graph-relationships layer.
Add a relationships table or integrate a Supabase graph extension to map entity connections. Person to organisation, contact to workstream, finding to decision. This enables multi-hop traversal queries, such as which stakeholder owns a workstream and which findings are tied to it, without manual joins. Highest strategic value. Most complex to implement.
- 04
Memory versioning.
Add version and previous_version_id columns so entries track how they evolve. Currently update_entry timestamps an edit but no version chain. Useful for client knowledge that shifts: retainer scope changes, strategy pivots, evolving decisions. Light lift, meaningful for reconstructing the history of any given decision.
- 05
Entry TTL and automated fact extraction.
Paired evolutions: they share a design logic. Optional expiry dates would let time-sensitive entries auto-flag as stale when the constraint ends. And, at some point, a post-conversation sweep could propose captures automatically rather than relying only on the end-of-session sweep. Both reduce the cost of keeping the brain current.
Want this wired into your stack?
Book a call and we'll walk through your current setup, what it would take to stand up an Open Brain against it, and what the first 90 days would look like.