Outline — One Brain, No Filtering

Speaker

Robert Overweg — Co-founder of Leapfrog A.I. Leapfrog A.I. helps fashion brands optimise their studio, e-comm, and content creation through AI, serving some of the world's biggest fashion brands. Robert has 13+ years of experience in technology, digital transformation, and bringing new technology to large enterprises like Heineken global. Prior to this he had a part-time art career, with exhibitions at Centre Pompidou and Seoul Media Biennial.

Abstract (as provided)

We're running an experiment: all leadership shares one brain. It contains research, client context, delivery dates, client preferences. Each person knows different pieces. We stopped keeping them separate. Now in production or decision-making moments, it all weaves together. A multiplayer brain.

Every client gets their own section in the vault: brand DNA, preferences, delivery dates, what their AD flagged last week. Our orchestrator has access to it all. The AI learns their brand, their preferences, not generic patterns.

We built it using OpenClaw and structured vaults. A knowledge management layer that agents read from and write to. A living system where research, decisions, and learnings flow in continuously.

I'll cover how we structured it, what flows in, what changed when we stopped relying on memory, and what it enabled.

Thesis (synthesis)

For a small team producing very high volumes of work, AI-native knowledge flow isn't optional — searching for files, chasing people for context, and losing learnings in chat windows is incompatible with the output rate. Leapfrog's answer is two structured vaults (personal research + per-client knowledge) orchestrated by OpenClaw, surfaced via Obsidian locally and Telegram on the go, fed by Granola-recorded meetings and a cron-driven research agent, with a strict "promote to vault" discipline so the team-wide brain only receives validated material. Keep this knowledge on your own stack, not in vendor chat windows.

Section TOC

Terminology glossary (Robert's own framing)

• One brain / multiplayer brain — leadership's shared knowledge state, woven together at decision-making and production moments rather than kept in separate heads.
• Vault — a structured GitHub repository of markdown files (Robert uses Obsidian locally on top of it). Leapfrog has at least two: a personal/research vault and a per-client vault.
• Promote to vault — Robert's discipline: research surfaced by the daily agent goes into a scratch space first; only after validation does he "promote stuff to the vault" so it reaches the wider team. "It needs to find some grounding in reality."
• Research agent — a cron job running on OpenClaw that tracks specific Hex accounts and keywords (e.g. "genetic engineering" or pipeline-related terms) and serves a daily morning digest.
• Chief-of-staff agent — an agent that surfaces the right questions at the right moment (e.g. prompting sales questions during a client call); aims to shave ~20% off busywork.
• OpenClaw ("oak claw" / "open cross" / "open gloss" in the speech-to-text) — the orchestrator Robert uses; chosen because it suited ~1500 large markdown files without extra infrastructure.
• GBrain — "that's from Gary Tan. Of Y Combinator" — an added layer Robert connected via a GPT factor that uses zero entropy for vector keywords / translation. Robert says he doesn't really need it yet at his current file count but expects it to matter at larger scale.
• Granola — meeting-transcription tool that "prioritize molds it around your notes"; connects via MCP/API.
• OB — open-source hardware/software recorder Robert has ordered; records conversations and sends them to his own servers, "no like subscription stuff which is really own the data".
• Memory search / vault context / direct file reads — the three retrieval modes OpenClaw uses in his setup, plus GBrain for large research.

Named frameworks / concepts

1. The two-vault split — personal research vault separated from client-knowledge vault, kept on different instances so they don't "leak over into each other".
2. Per-client vault section — "Every client gets their own section in the vault: brand DNA, preferences, delivery dates, what their AD flagged last week" (abstract). The orchestrator has access to all of it.
3. Promote-to-vault gating — research starts in a personal scratch area; only validated material is promoted; this protects the team-wide brain from unvalidated noise.
4. Record everything — meetings (Granola), ambient conversations (OB recorder), code base. "Everything that is not like digitized sort of doesn't exist and you're already a disadvantage if you don't do that."
5. AI-undermines-hierarchy (citing Jack Dorsey) — "the emergence of AI is generous and premise of hierarchy as a requirement for the first line" — if information can be modeled and distributed in real time, the org needs fewer coordination layers.
6. Start-small rollout — "start small. Let one person suffer through first don't roll this out to everyone."
7. Own-your-stack principle — "I would not want my knowledge to sit in just a lot or in other people. S chat windows I'd like to keep it as much as possible on like our own our own stack and our own service."

Open questions / not covered

• Permission models and data-segregation across multiple users for the client vault — "we still need to look into stuff like permissions and making sure all the data keeps being segregated like its own buckets".
• How the system would scale beyond ~1500 markdown files; whether GBrain or Neo4j becomes load-bearing.
• Specific evaluation criteria for what counts as "validated" before promoting to vault — Robert mentions the principle but doesn't formalise it.
• Concrete chief-of-staff agent implementation — Robert calls it planned/not-yet-built ("So we have developed this yet" — likely "we haven't developed this yet").
• Comparative evaluation of orchestrators — Robert explicitly says he didn't do "a very large industry wide scan".
• A worked example of the per-client vault schema (the abstract describes it; the talk doesn't walk through a literal file layout).
• Hermes as an alternative — considered but not adopted; no comparison data.
• Data-residency / compliance specifics for fashion-brand client data beyond "run it locally" and "align with what you're actually allowed to do with the data".