Você construiu seu segundo cérebro de IA. E agora? (Veja como fazê-lo evoluir)

Ver no idioma original →

Autoria: Cole Medin · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: You Built Your AI Second Brain. Now What? (Here’s How to Evolve It) · Canal: Cole Medin · 16:01 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, RAG, busca e recuperação de informação

Resumo

Cole Medin explica como evoluir um segundo cérebro pessoal de IA para um cérebro de equipe, sem substituir os agentes pessoais de cada integrante. A proposta central é manter uma base de conhecimento compartilhada em um banco de dados centralizado, com documentos padronizados e controle de acesso aplicado no próprio banco. Um MCP server conecta os agentes pessoais à base, enquanto a busca combina palavras-chave e pesquisa semântica, com citações das fontes. O exemplo usa Oracle AI database, mas as estratégias apresentadas podem ser aplicadas com outras ferramentas.

Pontos-chave

• A evolução para um cérebro de equipe não exige descartar o segundo cérebro pessoal; os agentes individuais podem continuar com suas próprias personalidades e memórias.
• A base de conhecimento da equipe deve ficar centralizada, em vez de depender de cópias locais de um vault do Obsidian ou de um repo.
• Padronizar as fontes em uma tabela de documentos simplifica a consulta, mesmo quando as informações vêm de Slack, GitHub ou documentação.
• Os conectores devem buscar dados nas fontes e convertê-los para o formato comum de documento.
• Um MCP server permite que os agentes pessoais consultem a base compartilhada e oferece funções como identificar o usuário, pesquisar e buscar documentos.
• As fontes devem receber rótulos de domínio durante a ingestão, para que o sistema saiba quais grupos podem acessar cada documento.
• A autorização deve ser aplicada no banco de dados, usando identidade, tokens e segurança em nível de linha; não se deve depender do agente pessoal para impor as permissões.
• Uma função de identificação de especialistas pode ajudar a encontrar quem conhece determinado assunto, mesmo quando o usuário não tem acesso direto aos documentos relacionados.
• Para recuperar informações em escala, a busca por palavras-chave deve ser combinada com a busca semântica, que cobre lacunas de significado e vocabulário.
• Citações de fontes permitem verificar se as respostas do agente vêm de conversas, repos ou documentação da equipe.

Capítulos

Início	Capítulo	Resumo
00:00	Do segundo cérebro pessoal ao cérebro de equipe	O autor apresenta os ganhos do sistema pessoal e os desafios de ampliar seu uso para colaboradores, incluindo escala, armazenamento, recuperação e permissões.
03:05	Arquitetura: agentes pessoais e conhecimento centralizado	A proposta mantém os agentes pessoais e centraliza o conhecimento em um banco de dados, organizado em um formato comum de documentos e acessado por um MCP server.
07:12	Permissões e segurança no banco de dados	Documentos recebem rótulos durante a ingestão, enquanto tokens e grupos determinam os acessos aplicados em nível de linha no banco.
10:46	Conexão pelo MCP e demonstração de acesso	O autor mostra como conectar um agente pessoal e como as respostas mudam conforme as permissões do usuário, além de apresentar uma busca por especialistas.
12:52	Busca híbrida e citações das fontes	Para recuperar informações em grande escala, o autor combina busca por palavras-chave e semântica e destaca a importância de citar as fontes.
15:29	Resumo das estratégias e próximos passos	O autor recomenda usar as ideias como modelo para criar um cérebro de equipe e encerra convidando o público a acompanhar futuros vídeos.

Citações

Na última vez que medi, ele me economizava cerca de 20 horas por semana. — 00:31

O cérebro de equipe é, na verdade, mais a base de conhecimento que acessamos. — 03:05

A barreira de acesso precisa ficar no banco de dados. — 10:16

A melhor estratégia que encontrei é combinar busca por palavras-chave e busca semântica. — 13:24

Conceitos e entidades

• AI second brain (conceito): Sistema pessoal de IA que organiza conhecimento e ajuda o usuário em diferentes tarefas do negócio.
• team brain (conceito): Base de conhecimento compartilhada por uma equipe, com acesso controlado para diferentes pessoas e grupos.
• MCP server (ferramenta): Ponto de conexão que permite aos agentes pessoais consultar a base de conhecimento da equipe e aplicar as permissões de acesso.
• Oracle AI Database (ferramenta): Banco de dados usado na demonstração para armazenar documentos, aplicar permissões e oferecer recursos de busca.
• LangChain (ferramenta): Framework cuja integração com Oracle AI database é usada no exemplo para embeddings e recuperação de informações.
• Obsidian (ferramenta): Aplicativo associado a vaults de Markdown, considerado insuficiente pelo autor como armazenamento central para uma equipe.
• Claude Code (ferramenta): CLI que o autor usa para interagir com seu segundo cérebro e consultar a base de conhecimento por meio do MCP.
• Codex (ferramenta): CLI que o autor também usa para interagir com seu segundo cérebro.
• Cole Medin (pessoa): Criador do vídeo que apresenta sua abordagem para evoluir um segundo cérebro pessoal para uma base de conhecimento de equipe.

Tradução completa (pt-BR)

00:00 Passei este ano inteiro construindo meu segundo cérebro pessoal de IA e ensinando você a fazer o mesmo. Tenho muito conteúdo no meu canal explicando como construir esse sistema, em que você tem um agent que cria uma base de conhecimento ao longo do tempo com tudo o que ajuda você no seu negócio. Agora, essa visualização em grafo não é exatamente prática. É só uma boa visualização para dar uma ideia de quanto uso isso todos os dias. Cheguei ao ponto em que uso meu segundo cérebro para me ajudar a operar em todas as áreas do negócio em que queria usá-lo. Não me entenda mal. Meu segundo cérebro está longe de ser perfeito; é impressionante quanto tempo ele

00:31 me economiza toda semana. Da última vez que medi, ele me economizou cerca de 20 horas por semana, e isso foi há alguns meses. Então, gosto muito do estado em que meu segundo cérebro está agora. Mas a próxima pergunta que me faço é: como transformar o segundo cérebro em um cérebro de equipe? Porque quero que o ganho de produtividade que tenho se estenda a todas as pessoas com quem colaboro. Essa é a grande questão para mim, e também tenho recebido essa pergunta de muitas outras pessoas. É o próximo passo natural para o seu segundo cérebro de IA. Talvez você não perceba

01:02 isso quando pensa no assunto pela primeira vez, mas há muita coisa envolvida na criação de um cérebro de equipe. Por isso, quis fazer este vídeo para mostrar como estou fazendo essa evolução e quais são minhas estratégias, pelo menos em alto nível. Porque, quer dizer, a primeira coisa em que precisamos pensar aqui é a escala. Quando você tem muitos colaboradores, as informações vêm de muitos lugares diferentes. Então, como colocamos todas essas informações no nosso cérebro e como as armazenamos? Além disso, um vault do Obsidian com Markdown não vai mais dar conta, como dá quando é só para você. Também precisamos pensar em como

01:33 ampliar as estratégias de recuperação para que sejam precisas em escala, como lidar com a citação das fontes e, outra coisa importante que espero que seja óbvia para você, como cuidar da segurança e das permissões. É muito improvável que todas as pessoas da sua equipe tenham acesso total a todas as informações do cérebro de equipe. Precisamos de algum tipo de separação, em que rotulamos os dados na ingestão, dependendo da fonte, e depois configuramos chaves de acesso para garantir que, no banco de dados, apenas certas pessoas possam visualizar determinados

02:03 documentos. Então, neste vídeo, quero mostrar em alto nível como estou fazendo tudo isso. Para tudo o que demonstro neste vídeo, tenho um exemplo funcional que vou deixar no link da descrição. Você pode até dar isso ao seu coding agent para ajudar a incorporar essas ideias à medida que evolui seu sistema pessoal e o transforma em algo para toda a equipe. E posso dizer: vale a pena investir nisso, independentemente do tamanho da sua equipe, de algumas pessoas até uma empresa de grande porte. Na verdade, fiz uma parceria com a Oracle. Neste exemplo, estou usando o Oracle AI database só para mostrar como é

02:35 possível escalar para o nível de uma empresa de grande porte. Eles nos oferecem tudo de que precisamos para ajudar com a ingestão a partir das nossas fontes, nossas estratégias de recuperação e as permissões por função. Mas, no geral, o que abordo neste vídeo é bem amplo. Vai se aplicar independentemente das ferramentas que você usa. Só vou mostrar algumas recomendações na minha demonstração. E, com isso, vamos começar pela decisão de arquitetura mais importante. Talvez você pense que, ao criar um cérebro de equipe, vai substituir completamente seu sistema pessoal, mas não é

03:05 o caso. Espero que isso seja uma boa notícia, porque significa que tudo o que você construiu até agora não será descartado. Na verdade, será a camada com a qual você continuará interagindo. O cérebro de equipe é, na prática, apenas a base de conhecimento que acessamos. E pensei bastante nisso por um tempo, porque há dois caminhos possíveis. Você pode manter o agent no nível pessoal e distribuir apenas a base de conhecimento. Ou pode fazer com que até o próprio agent seja um único cérebro ao qual todos acessam pela própria interface. E há muitos

03:35 motivos para eu ter decidido fazer essa separação. Você pode pensar nisso como distribuir a política e o conhecimento, mas ainda manter o agent pessoal, com a personalidade e a parte do sistema de memória de cada indivíduo. Isso também oferece a melhor escalabilidade, porque nos dá agents distribuídos e nos permite continuar personalizando nosso sistema pessoal, o que é importante para mim. Provavelmente também é para você. Ao construir seu próprio segundo cérebro de IA, tenho certeza de que percebeu que ele é bem diferente do de todo mundo. Então, quero que você consiga

04:06 manter isso. Mas ainda precisamos centralizar tudo na base de conhecimento para que possamos gerenciar as permissões, certo? Não podemos simplesmente despejar todas as fontes, como conversas do Slack, repos do GitHub e documentação, em algum repo do GitHub que todo mundo clona localmente. Também não podemos mais deixar um vault do Obsidian ao lado de cada cérebro, como fazemos com o nosso sistema pessoal. Precisamos de um banco de dados central, e é para isso que estou usando a Oracle: armazenar tudo e manter uma única fonte de verdade para nossas estratégias de recuperação e nossas permissões. E

04:37 então cada cérebro individual vai acessar essa única tabela por meio de um servidor MCP. Daqui a pouco também vou mostrar como isso funciona. Como prometi, vou manter a explicação em alto nível, mas, enquanto passamos pelas diferentes estratégias, quero mostrar um pouco de como meu sistema funcional opera e como estou usando o Oracle AI database. O principal é que tenho uma única tabela chamada documents. Mantenha a simplicidade. Não há motivo para ter um monte de tabelas diferentes para todas as minhas fontes. Independentemente de onde as informações vêm, em toda a minha

05:07 empresa, estou reduzindo tudo a este esquema. Uma conversa do Slack, um repo do GitHub, documentação ou qualquer outra coisa: tudo entra neste formato, no qual extraio o título, o texto, a URL e o autor. Você pode ver algumas das colunas aqui, que também dão uma ideia de como podemos gerenciar as permissões e descobrir, sabe, quem é o especialista nesse assunto na empresa. Configurei muita coisa aqui, mas o importante é que existe um padrão para manter as consultas simples. Queremos uma interface bem básica para que nossos agents pessoais se conectem ao banco de dados. Então, agora, passando rapidamente à implementação,

05:39 tudo o que entra na base de conhecimento vem neste formato único de documento. O esquema que você está vendo aqui corresponde diretamente ao que temos no Oracle AI database. Cada um dos meus conectores, como o conector do Slack, por exemplo, tem como única responsabilidade buscar as informações da conversa do Slack ou de qualquer outra fonte e, em seguida, adaptá-las ao formato do documento, certo? Ou seja, descobrir como buscar o autor, os domínios, os metadados e a fonte de uma conversa do Slack e colocar tudo neste formato, para que possamos inserir

06:09 na base de conhecimento. Assim, temos um único ponto de entrada para que nossos segundos cérebros individuais de IA façam consultas. E vamos fazer isso por meio de um servidor MCP bem simples. Mesmo sendo simples, o servidor MCP é muito importante, porque é o ponto de conexão entre nossos segundos cérebros e a base de conhecimento de toda a empresa. É só mais uma ferramenta que você adiciona ao seu segundo cérebro de IA. Na verdade, não precisa mudar nada na sua arquitetura. Temos uma ferramenta para identificar quem somos, só para confirmar nossa identidade, e outra para pesquisar nos documentos aos quais temos acesso, a mesma

06:41 com código, porque funciona de um jeito um pouco diferente; e depois outro para buscar um documento inteiro, partindo do princípio de que temos acesso a ele com base nas nossas permissões e no domínio desse documento. E há mais uma função com que tenho experimentado recentemente: uma função de “quem sabe”. Isso é legal porque, se associarmos um autor a cada registro na base de conhecimento, também podemos identificar quem é a pessoa na empresa a quem devemos recorrer caso tenhamos uma pergunta de acompanhamento. Então, espero que sua cabeça já esteja a mil, pensando em todas as maneiras úteis de criar funcionalidades neste

07:12 MCP. Certo, você viu o banco de dados e como organizamos as coisas no servidor MCP. Agora vamos entrar mais a fundo no pipeline e falar sobre como isso funciona e por que precisamos disso. É claro que a grande lacuna é que, se não tivermos permissões, uma consulta pelo servidor MCP simplesmente vai retornar todos os registros, e definitivamente não queremos isso. Mas o primeiro passo, antes mesmo de configurarmos as permissões no servidor MCP, é rotular os itens durante a ingestão. Então, quando adicionamos fontes àquela tabela única de documentos, precisamos saber que isto veio do Slack de operações ou que aquilo veio do espaço da wiki de marketing, para sabermos quem deve ter acesso a cada item. E não preciso entrar em detalhes técnicos. É bem simples. Quando configuramos nossas fontes inicialmente, vamos apenas criar esse mapeamento: esta fonte específica vai ter este rótulo. Então, aplicamos esse rótulo a cada registro, toda vez que adicionamos o novo documento à base de conhecimento, como vemos aqui. Por exemplo, isto veio do Slack de marketing, então vai ter o domínio de marketing ou o domínio de operações. E esta coluna aqui é como

07:42 vamos aplicar as permissões em nível de linha no banco de dados Oracle AI para filtrar o que cada pessoa pode acessar. E, claro, se você tem espaços em que vários grupos colaboram, como operações e marketing, pode aplicar vários rótulos a um único documento para ampliar o acesso. E é só isso. Temos apenas essa coluna para os domínios. Essa é uma parte do controle de permissões. A outra parte é criar a chave e fazer com que o servidor MCP a use, para que o banco de dados possa identificar quem está tentando

08:12 acessar e, em seguida, filtrar os registros com base nisso. Então, aqui no meu banco de dados Oracle AI, tenho uma tabela de tokens MCP. É muito simples. Você configura isso com antecedência, certo? Alguém como um administrador da organização vai criar esses tokens e depois atribuí-los a pessoas específicas da empresa. Então, você entrega esse token à pessoa, e ela o configura com o MCP. Vou mostrar como isso funciona daqui a pouco. E esse token passa a ser nossa chave de entrada para a base de conhecimento. Também vou mostrar que tenho aqui uma tabela de principais. É assim que

08:42 mapeamos o token para aquilo a que a pessoa tem acesso. Então, principais: vou executar esta consulta. Aqui, podemos ver que, para cada usuário, temos um mapeamento dos grupos a que ele tem acesso. Jeff só pode acessar as partes da base de conhecimento do domínio de operações. Julia pode acessar marketing e operações. E, obviamente, na maioria das vezes, você vai ter a liderança, que precisa poder acessar tudo. Então, há uma tag especial que as permissões reconhecem aqui, segundo a qual a liderança tem acesso a todo o conhecimento que temos na tabela de documentos. Depois que configuramos

09:13 a chave, quando fazemos uma consulta com o servidor MCP e uma dessas chaves para autenticação, o controle passa a ser aplicado no banco de dados. Então, fazemos uma pergunta, como “Qual é o nosso limite máximo de desconto?”. Vou mostrar uma demonstração ao vivo disso daqui a pouco. O banco de dados fica responsável por resolver a identidade usando a chave, descobrir a quais domínios temos acesso e, então, aplicar isso em nível de linha. Ou seja, temos segurança em nível de linha integrada ao banco de dados Oracle AI. O ponto mais importante a lembrar, não importa como você construa esse sistema, é que o controle de acesso precisa ficar no banco de dados. Você não pode

09:44 deixar esse segundo cérebro, a parte pessoal do sistema, responsável pela segurança de forma alguma, porque aí vai ser fácil demais para a pessoa contornar isso, por exemplo, com algum tipo de injeção de prompt no próprio agent ou simplesmente alterando a implementação do próprio agent. Precisamos que o acesso seja determinado pelo sistema que está sendo executado remotamente. Então, para esta demonstração, estou inserindo os usuários, os acessos deles e os tokens MCP. Em geral, você ou algum administrador da empresa vai criar esses tokens inicialmente e depois distribuí-los a todas as pessoas.

10:16 Depois, elas só precisam de uma configuração MCP bem simples. É só isso que é necessário para conectar o segundo cérebro à base de conhecimento por meio de um MCP remoto. No momento, estou executando isso localmente para a demonstração, mas normalmente seria um endereço remoto; depois, você configura a autorização com o token que recebeu. É isso que determina todos os acessos. É muito simples conectar seu segundo cérebro a essa base de conhecimento. Essa é a beleza de como configuramos tudo aqui. Então, não importa como você usa seu segundo cérebro atualmente: não precisa mudar nada. Estamos apenas adicionando o MCP como uma ferramenta a mais.

10:46 Normalmente, uso meu segundo cérebro no CLI do Codex ou do Claude Code. Aqui, faço uma pergunta simples: “Qual é o limite máximo de desconto para empresas?”. Com base na pergunta, meu segundo cérebro entende que precisamos consultar a base de conhecimento da equipe. Então, ele vai usar o MCP da base da equipe e executar essa consulta. E, se eu digitar /mcp, você verá as cinco ferramentas que mostrei rapidamente no código antes. Ele identifica a ferramenta, chama-a, executa a consulta e, então, recebemos a resposta: os representantes de vendas podem oferecer até 20% de desconto sobre o preço de tabela em um contrato anual. E, especificamente, Jeff, que é o usuário com quem estou usando o MCP, tem acesso a essa informação na base de conhecimento. Ou melhor, na verdade, executei essa demonstração específica como Sam. Porque, se eu fizer essa pergunta como Jeff, você verá que a base de conhecimento não contém informações sobre o limite máximo de desconto para empresas.

11:19 Então, a informação fica completamente invisível, como deveria, porque não temos acesso a ela. Mas, se eu fizer a mesma pergunta como Sam, é aí que recebemos a informação de que o desconto pode chegar a 20% sobre o preço de tabela, como vimos na sessão do Claude Code do meu segundo cérebro. Então, a informação fica completamente invisível, ou

11:49 você pode ter algum tipo de sistema que saiba que o documento existe, mas diga que não pode visualizá-lo. Se quiser que Jeff saiba, por exemplo: “Certo, eu teria que perguntar ao Sam.” Você pode configurar isso de algumas maneiras diferentes, mas seria fácil ajustar se necessário. Por padrão, se não houver correspondência, não há acesso. E aí você sabe que precisa perguntar a outra pessoa. Você pode ter uma parte separada do sistema, como configurei, em que temos os documentos, sim, mas também um lugar separado que identifica quem é especialista em certos assuntos. Então, posso simplesmente perguntar ao MCP: “Quem sabe sobre o escalonador automático do cluster em lote?”. Jeff é quem sabe, e Elena aparece como uma voz secundária na conversa do Slack.

12:20 Então, ele buscou a fundo o contexto. Se eu não fosse Jeff, mas Brian perguntando sobre operações, saberia que deveria procurar Jeff. Legal. O servidor MCP é a estrela do show porque é o que torna essa conexão muito fácil, cuidando de todas as permissões. Mas a outra coisa muito importante que precisamos discutir é a estratégia de recuperação. Também quero mostrar como faço isso com o banco de dados Oracle AI e o LangChain. Porque o seguinte: não estamos mais trabalhando com um banco de dados pessoal de arquivos Markdown. Temos uma tabela dedicada. E talvez estejamos consumindo

12:52 voz secundária na conversa do Slack. Então, ele investigou a fundo o contexto ali. E, se eu não fosse Jeff, se fosse Brian perguntando sobre assuntos de operações, eu saberia que deveria procurá-lo. Legal. Então, o servidor MCP é a estrela do show, porque é ele que torna a conexão super fácil aqui, cuidando de todas as permissões. Mas a outra coisa muito importante de que precisamos falar é a estratégia de recuperação. E quero mostrar como estou fazendo isso também com o banco de dados Oracle AI e o LangChain. Porque é o seguinte: não estamos mais trabalhando com um banco de dados pessoal de arquivos markdown. Temos uma tabela dedicada. Estamos potencialmente consumindo

13:24 milhares, milhões de registros de threads do Slack, repos e coisas assim, porque estamos evoluindo para algo que envolve mais do que apenas uma pessoa. Não podemos mais simplesmente fazer uma wiki de LLM no estilo Karpathy, com apenas busca por palavras-chave. A melhor estratégia que encontrei é combinar busca por palavras-chave e busca semântica. E elas meio que compensam as falhas uma da outra, certo? Por exemplo, a busca por palavras-chave consegue encontrar termos muito específicos, IDs e coisas assim. Já a busca semântica consegue encontrar significados e conceitos relacionados que não têm necessariamente as mesmas

13:55 palavras-chave. Então, usar as duas juntas em uma única busca e ponderar os diferentes resultados que aparecem é o ideal. E isso é muito importante porque, mesmo com o controle de permissões, ainda pode haver milhares de registros com que precisamos lidar. Digamos que temos 40.000 no nosso banco de dados, menos o que o banco de dados não vai nos mostrar; então talvez esse número caia para 10.000. Bem, ainda queremos apenas alguns documentos ou trechos para fornecer ao agent, que ele possa processar e usar para nos dar a resposta final. Então, é definitivamente importante ter uma estratégia de busca poderosa para eliminar toda a informação irrelevante

14:26 e nos dar apenas o que precisamos. E, claro, também citar as fontes, para podermos voltar à fonte em uma thread do Slack, na documentação ou onde quer que seja, a fim de verificar as informações. Para ter certeza de que o agent não está inventando coisas. Isso realmente veio de algo da empresa. Implementar essas estratégias de busca com o Oracle AI database é muito simples, porque ele tem integração com LangChain, então podemos usar facilmente o pacote LangChain Oracle DB para criar nossos embeddings. E temos o recuperador, que nos permite fazer busca por palavras-chave e busca semântica. E o Oracle AI database oferece suporte a

14:58 tudo isso pronto para uso. Por exemplo, uma busca por palavras-chave realmente poderosa em todos os nossos dados. Eles têm modelos de embedding que podemos usar diretamente no banco de dados. Já está tudo pronto para criarmos exatamente o que precisamos para o cérebro da equipe. Com a integração com LangChain e o que o Oracle AI database oferece pronto para uso, não precisamos trazer nada de fora. Modelos de embedding, bibliotecas, nada. Temos o necessário para gerar embeddings dos nossos documentos e das consultas dos usuários, e recuperar informações com busca vetorial e busca por palavras-chave. Há também uma documentação muito boa sobre essa integração, diretamente na documentação do LangChain. Se você quiser

15:29 incorporar isso ao seu próprio projeto, forneça a documentação ao seu agent. Você pode até começar de graça com o Oracle AI database para experimentar essas ideias e executar minha demonstração completa e funcional também. Mas, no geral, espero que você tenha aproveitado bastante essas estratégias de alto nível. Não importa como você construa um cérebro para a equipe, é isso que você deve buscar ao evoluir suas estratégias de busca, implementar o controle de permissões e fazer a conexão super simples com o servidor MCP. Use isso como modelo para começar a criar o cérebro da sua própria equipe. E, se você gostou deste vídeo e está esperando por mais conteúdo sobre segundos cérebros de IA e programação agentic, eu

16:01 ficaria muito grato se você curtisse o vídeo e se inscrevesse no canal. E, com isso, nos vemos no próximo vídeo.

Transcrição original

[00:00] I’ve spent this entire year building my personal AI second brain and teaching you how to do the same. I have so much content on my channel covering how to build this system where you have an agent that builds a knowledge base over time with everything that is helping you with in your business. Now, this graph view isn’t actually practical. It’s just a good visualization to give you a glimpse into how much I’m using this every single day. I’ve gotten it to the point now where I’m using my second brain to help me operate in every part of the business I wanted to. Now, don’t get me wrong. My second brain is far from perfect, crazy how much time it

[00:31] saves me every single week. Now, the last time I actually measured it, it saved me about 20 hours per week, and that was a few months ago. And so, I really love the state that my second brain is in right now. But, the next question that I have is how do I take the second brain and turn it into a team brain? Cuz I want the productivity boost for me to extend to everyone I’m collaborating with. It’s the big question for me, and I’m getting this question from a lot of others as well. It’s the next natural step for your AI second brain. Now, you might not realize

[01:02] this thinking about it initially, but there is so much that has to go into creating a team brain. And so, that’s why I wanted to make this video to show you how I’m making this evolution and what my strategies are, at least at a high level. Because, I mean, even the first thing we have to think about here is scale. You have information coming from so many different places when you have a lot of collaborators. So, how do we get all that information into our brain, and how do we store it? Because also, an Obsidian vault with Markdown is not going to cut it anymore like it is for just you. And so, also thinking how

[01:33] do we expand the retrieval strategies to make it accurate at scale, how do we handle source citation, and then another big thing that is hopefully obvious to you is that we need to handle security and permissioning. It is very unlikely that your team brain is going to have everybody with full access to all information. You need some kind of separation where we’re going to label things at ingestion depending on the source, and then setting up keys for access so we can enforce in the database only certain people can view certain

[02:03] documents. And so at a high level in this video, I want to show you how I’m doing all of this. And for everything that I demonstrate in this video, I have a working example here that I’ll link to in the description. You can even give this to your coding agent to help you incorporate these ideas as you evolve your personal system to something that is team-wide. And let me tell you, this is worth investing in no matter how big your team is. A couple of people all the way to an enterprise level. And I actually partnered up with Oracle. I’m using the Oracle AI database in this example just to show you how this is

[02:35] possible to scale to an enterprise level. They give us everything we need to help us with our ingestion from our sources, our retrieval strategies, and the role level permissioning. But as a whole, what I’m covering in this video is very high-level. It’s going to apply no matter the tools that you use. I just have some recommendations that I’m showing in my demo here. And so with that, let’s get into the most important architecture decision first. You might think that in building a team brain, you’re going to entirely replace your personal system, but that isn’t actually

[03:05] the case. And I hope that’s good news for you because it means that everything you built up until this point is not going to be scrapped. In fact, it’s going to be the layer that you continue to interact with. The team brain is really more just the knowledge base that we access. And I actually wrestled with this for a while because there are two paths you can go here. Either you maintain the agent at the personal level and it’s just the knowledge base that you distribute. Or you can make it so that even the agent itself is just a single brain that everyone accesses from their own interface. And there are many

[03:35] reasons why I’ve decided to have this separation here. You can think about it like we distribute the policy and the knowledge, but we still maintain the personal agent with the personality and the part of the memory system for that individual. This also scales the best because it gives us distributed agents and it allows us to continue to customize our personal system, which that’s important to me. It probably is to you as well. As you built your own AI second brain, I’m sure you realize that it’s quite a bit different from everyone else’s. So I want you to be able to

[04:06] maintain that. But we still need everything centralized for the knowledge base so that we can manage the permissions, right? We can’t just dump all the sources like Slack conversations, GitHub repos, documentation into some GitHub repo that everyone clones locally. We can’t have some Obsidian vault just sitting next to each brain like we do for our personal system anymore. We need a central database, which is what I’m using Oracle for, to store everything and have the single source of truth for our retrieval strategies and our permissioning. And

[04:37] then each individual brain is going to access this single table through an MCP server. I’ll show you what that looks like in a little bit as well. Now, as promised, I’ll stay high-level, but as we’re going through the different strategies here, I do want to give you glimpses into how my working system functions and how I’m using the Oracle AI database here. So the main thing is I have a single table called documents. Keep it simple, stupid. There is no reason to have a ton of different tables for all of my sources. No matter where the information is coming from across my

[05:07] business for the company, I’m boiling it down into this schema. So a Slack thread, GitHub repo, documentation, whatever, it comes into this format where I extract the title, text, URL, author. You can see some of the columns here, which will also give you an idea how we can do our permissioning and figuring out, you know, like who’s the expert on this thing in the company. There’s a lot that I have set up here, but the important thing is it’s a standard to keep the querying simple. We want a very basic interface from our personal agents to connect into our database. So now getting into the implementation very quickly here,

[05:39] everything that comes into the knowledge base comes in under this single format of a document. And so the schema that you’re looking at here maps directly to what we have in the Oracle AI database. And so now each of my connectors, like the Slack connector for example, its sole responsibility is to fetch the information from the Slack thread or whatever, and then mold it into the format that fits the document, right? So figuring out like here’s how we fetch the author, the domains, the metadata, the source from a Slack thread, get it into this format now where we can put it

[06:09] in the knowledge base, and now we have a single entry point for our individual AI second brains to query. And we’re just going to be doing that through a pretty simple MCP server. And the MCP server, even though it’s simple, is very important because it is the connection point between our second brains and the company-wide knowledge base. And so it’s just another tool that you give to your AI second brain. You don’t really have to change anything in your actual architecture. So we have a tool to identify who we are, just to confirm our identity, one to search over the documents that we have access to, same

[06:41] with code cuz it works a little bit differently, and then one to fetch an entire document again, assuming we have access to it based on our permissions and the domain for that document. And then another one that I’ve been experimenting with recently is a who knows function. This is cool cuz if we attach an author to individual records in the knowledge base, we can also identify like if we have a follow-up question, who’s the person in the company that we go to. So yeah, I hope that your your gears are turning your brain right now. All the useful ways that you can build functionality into

[07:12] this MCP. Okay, so you’ve seen the database, you’ve seen how we organize things in the MCP server. Now let’s get more into the pipeline and talk about how this works and why we need this in the first place. So obviously the big gap being if we don’t have any permissioning, then a query through the MCP server is just going to return all records, and we definitely don’t want that. But the first step, even before we can set up the permissions in the MCP server, is we need to label things at ingestion. So when we’re bringing sources into that single documents table, we need to know that like this

[07:42] came from the ops slack or this came from the marketing wiki space, so we know who should have access to it in the first place. And I don’t have to get technical here at all. It’s pretty simple. When we set up our sources initially, we’re just going to create that mapping like this specific source is going to have this label. So, we just apply that to every single record every single time we’re entering that new document into the knowledge base like we’re looking at right here. Like this came from the marketing slack, so it’s going to have the marketing domain or it’s going to have the ops domain. And this right here, this column is how

[08:12] we’re going to apply the row level permissions in the Oracle AI database to filter out what certain people can access. And of course, if you have spaces where multiple groups are collaborating like ops and marketing, of course you can apply multiple labels to a single document, so you can expand who can access it. And that’s really it. We just have that column for the domains. That is one side of the permissioning. The next side is we have to create the key and have the MCP server use that so the database can identify who is trying

[08:42] to access and then filter records based on that. So, within my Oracle AI database here, I have an MCP tokens table. Super simple. You set this up ahead of time, right? Like some kind of administrator in the organization is going to create these tokens and then assign them to specific people in the company. And so then you give that token to the individual, they set that up with the MCP. I’ll show you what that looks like in a bit. And now that is our ticket into the knowledge base. And so with that, I’ll also show you I have a principal table here. And so this is how

[09:13] we map the token to what they have access to based on it. So, principals, let me run this query. So, right here we can see that like for each user, we have a mapping to the groups they have access to. Like Jeff can only access the parts of the knowledge base for the ops domain. Julia can access marketing and ops. And then obviously most of the time you’re going to have leadership where you’d want them to to able to access everything. So, a special tag that the permissions will recognize here where leadership has access to all knowledge that we have in the documents table. So, once we have

[09:44] the key set up, then when we make a query with the MCP server and one of those keys for our authentication, now we’re going to enforce in the database. So, we ask our question like what’s our discount ceiling? And I’ll show a live demo of this in a second. Then, the database is responsible for resolving the identity using the key to figure out the domains we have access to and then applying that at a row level. So, it’s a row level security we have built into the Oracle AI database. The most important takeaway here, no matter how you build this system, is you need the gate to sit in the database. You cannot

[10:16] have this second brain, the personal part of the system, responsible for the security in any way cuz then it’s going to be way too easy for the individual to get around it with, you know, sort of like prompt injection to their own agent or just changing their own agent’s implementation. We need to have the access be determined by the system that is running remotely. So, for the sake of our demo here, I am seeding the users and their access and MCP tokens. Generally, yourself or some kind of admin in the company is going to get these tokens created initially and then distribute them to all the individuals.

[10:46] And so, then they just have to have very simple MCP configuration. This is all it is to attach their second brain to the knowledge base through a remote MCP. So, I have this running locally for the demo right now, but usually this would be a remote address and then you set the authorization to the token that you were given. This determines all the access. It is so simple to get your second brain connected into this knowledge base. That’s the beauty of how we’ve set things up here. So, no matter how you use your second brain right now, it doesn’t have to change. We’re just attaching the MCP as an additional tool.

[11:19] So, typically I use my second brain within either the Codex or Claude Code CLI. And so, here I just ask a simple question. What is our enterprise discount ceiling? And based on the question, my second brain knows that this is something that we need to access the team knowledge base for. So, it’s going to use the team brain MCP. It’s going to run that query. And if [snorts] I do a {slash} MCP, you’ll see the five tools that I showed in the code very briefly earlier. So, it identifies the tool, it calls it, it runs the query, and then we get our answer. Reps can offer up to 20% off the list on an

[11:49] annual contract. And specifically, Jeff, who I’m using the MCP as, he has access that information in the knowledge base. Or sorry, I actually ran that specific demo as Sam. Because you can see if I ask that question with Jeff, it says the knowledge base doesn’t cover anything around the enterprise discount ceiling. So, the information is completely invisible as it should be cuz we can’t access it. But if I ask the same question as Sam, this is where we get that up to 20% off list price like we saw within my second brain Claude code session. So, completely invisible or you

[12:20] could have some kind of system where like it knows the document’s there, but it says it can’t view them. If you want Jeff to know like, “Okay, I would have to go ask Sam.” So, couple different ways you can set it up, but it’d be easy to tweak this if you need. So, by default, no match means no access. And that’s when you know you have to ask someone else about it. So, you can have a separate part of the system like I set up where we have the documents, yes, but we also have a separate place where we identify who is the expert on certain things. So, I can literally just ask the MCP like, “Who knows about the batch cluster auto scaler?” And Jeff is the one who knows this with Elena as the

[12:52] secondary voice in the Slack thread. So, it dug deep into the context there. And so, if I wasn’t Jeff, if I was Brian asking about ops stuff, then I would know to go and ask him. Cool. So, the MCP server is the star of the show because it’s what makes the connection super easy here, handling all the permissions. But the other really important thing we have to talk about is the retrieval strategy. And I want to show you how I’m doing this with the Oracle AI database and LangChain as well. Cuz here’s the thing. We’re not operating in a personal database of markdown anymore. We have a dedicated table. We’re potentially consuming

[13:24] thousands, millions of records from Slack threads and repos and things like that because we’re evolving to more than just one person. We can’t just do a Karpathy LLM wiki with just keyword search anymore. The best strategy that I found is to combine keyword search and semantic search together. And they kind of cover each other’s flaws, right? Like keyword search is able to find very specific wording or IDs, things like that. Then semantic search is able to find meanings, concepts that are related that don’t actually have the same

[13:55] keywords. And so, both together in a single search and waiting the different results that come back, this is what’s optimal. And this is really important because even with the permissioning, there’s still going to be thousands of records potentially we have to deal with. Like let’s say we have 40,000 in our database minus what the database won’t show us, so maybe that brings it down to 10,000. Well, we still only want a couple of documents or snippets that we give into the agent to deal with and give us the final answer. So, it’s definitely important to have a powerful search strategy to cut out all the fluff

[14:26] and give us just what we need. And of course, citing sources as well, so we’re able to even go back to the source in a Slack thread or documentation or whatever to verify things. To just know that the agent isn’t making things up. This really came from something in the company. Now, implementing these search strategies with the Oracle AI database is so straightforward because they have an integration with LangChain so that we can very easily use the LangChain Oracle DB package to create our embeddings. And we have the retriever, so we’re able to do the keyword search and the semantic search. And Oracle AI database supports

[14:58] all this out of the box. Like really powerful keyword search across our data. They have embedding models that we can use directly within the database. Everything is out of the box for us to build exactly what we need for the team brain. So, with the LangChain integration and what Oracle AI database gives us out of the box, we don’t have to bring in anything external. Embedding models, libraries, and nothing. We have what it takes to embed our documents and user queries, retrieve things with vector search and with keyword search. There’s also really good documentation for this integration directly in the LangChain docs. If you want to

[15:29] incorporate this for yourself, give the documentation over to your agent. You can even get started for free with the Oracle AI database to experiment with these ideas, run my full working demo as well. But overall, I hope that you just got a lot out of the high-level strategies here. No matter how you build a team brain, this is what you should be shooting for for evolving your search strategies, building in permissioning, the super simple connection with the MCP server. Use this as a template to get started with your own team brain. And so, if you appreciated this video, you’re looking forward to more things on AI second brains and agentic coding, I

[16:01] would really appreciate a like and a subscribe. And with that, I will see you in the next video.