O Segundo Cérebro Que Fala Com Todos Os Seus Agentes

In partnership with

1,000+ Proven ChatGPT Prompts That Help You Work 10X Faster

ChatGPT is insanely powerful.

But most people waste 90% of its potential by using it like Google.

These 1,000+ proven ChatGPT prompts fix that and help you work 10X faster.

Sign up for Superhuman AI and get:

• 1,000+ ready-to-use prompts to solve problems in minutes instead of hours—tested & used by 1M+ professionals

• Superhuman AI newsletter (3 min daily) so you keep learning new AI tools & tutorials to stay ahead in your career—the prompts are just the beginning

Claim your free prompts

Acima temos o anunciante da News dessa semana  Se puder, clique no link do anunciante acima para deixar seu apoio (é grátis!) ❤️

Fala, pessoal! Tudo certo? Jonata, founder da Olympus aqui.

News diferente hoje.

Quero contar uma história pessoal. Não sobre um modelo novo, nem sobre a ferramenta da semana.

Sobre uma decisão tomei recentemente.

Eu migrei toda minha base de conhecimento do Notion para o Obsidian.

Pra quem me acompanha há um tempo, sabe que eu sempre fui fã do Notion.

A flexibilidade, os databases, as views, a UX polida. Eu era evangelista. Convenci clientes. Montei sistemas inteiros lá dentro.

Mas alguma coisa começou a incomodar.

Não foi um bug. Não foi o preço. Foi uma percepção que foi crescendo devagar, até ficar impossível de ignorar: meus dados estavam presos numa ilha.

Por mais que o Notion tenha sua IA e MCP para você conectar. Eles ainda controlam a porta de entrada. Formato e velocidade de acesso.

Sentia que toda essa mudança de formato de trabalho, para tornar todos workflows “agent-based” precisava de uma atualização na ferramenta de gestão de conhecimento.

Algo que desse liberdade, sem vendor-lockin, para experimentar com as ferramentas novas que saem a cada dia.

Olha o cenário hoje.

• Temos N modelos — GPT, Claude, Gemini, DeepSeek, Llama.

• N harnesses — Codex, Claude Code, Cursor, Windsurf, Cline.

• N orquestradores open source — Openclaw, Symphony, CrewAI, Agno.

Todo mundo buscando a melhor combinação.

A pergunta que domina os fóruns é "qual stack de IA usar?".

Mas a pergunta que me travou foi outra.

O que é compartilhado entre todos eles?

Skills. Identidades. Workflows. Definições de agentes. Recursos de referência. O contexto que torna qualquer IA útil de verdade — independente do modelo ou da ferramenta.

E aqui é onde os dados ficam desconfortáveis. Dois em cada três devs dizem que IA perde contexto crítico durante tarefas de código (Qodo, 2025). 66% citam "código quase certo, mas não exatamente" como frustração #1 (Stack Overflow, 2025).

O problema não é o modelo. É o contexto. E o meu contexto estava preso no Notion — numa plataforma proprietária, que controla o acesso ao conteúdo e com sistema de export de arquivos que não funciona para bases realmente grandes (meu último export do Notion que funcionou tinha 13gb)

Cada nova ferramenta que eu adotava era onboarding do zero. Cada agente que eu configurava começava sem memória.

Então eu migrei. Em ~24h. E quero compartilhar o que descobri.

1️⃣ Markdown Como Camada Agnóstica

A decisão de arquitetura mais estratégica que você toma hoje não é qual modelo usar.

É O QUE e COMO o conhecimento alimenta todos seus agentes.

Olha o que aconteceu no último ano. O ecossistema de IA fragmentou — e cada ferramenta inventou seu próprio arquivo de configuração. Cursor tem .rules. Claude Code tem CLAUDE.md. Codex tem AGENTS.md. Windsurf tem .rules. Cada plataforma quer que você escreva as instruções no formato dela.

Mas repara numa coisa.

Todas elas leem Markdown.

Não importa se é um arquivo chamado SKILL.md, AGENTS.md, SOUL.md ou qualquer outro nome criativo que a próxima ferramenta vai inventar.

Por baixo do capô, é tudo .md. Markdown é o menor denominador comum universal do ecossistema de IA.

E não é só IA que reconhece isso. Markdown é a tecnologia #1 mais admirada entre devs por 3 anos seguidos no Stack Overflow Developer Survey — 84% de aprovação. Mais que Python. Mais que TypeScript. Mais que qualquer framework da moda.

A razão é simples: zero lock-in.

Se o Obsidian morrer amanhã, meus arquivos continuam funcionando. Se Claude Code for descontinuado, meus skills continuam legíveis.

Se eu migrar pro orquestrador da vez em 6 meses, meus dados migram comigo — porque são texto puro.

Agora compara com o Notion. Eu amava o Notion. De verdade. Provavelmente ainda vou usar ele como ferramenta de dashboard e gestão de equipe.

Mas agora o cerne de onde trabalho moveu para o Obsidian.

No meu setup novo, o vault inteiro vive no iCloud — sync automático entre todos os dispositivos — e versionamento git usando --separate-git-dir pra manter o histórico de versões fora do iCloud e evitar conflitos de sync.

Cada arquivo é um .md que eu posso abrir no VS Code, no Vim, no Obsidian, ou em qualquer editor de texto que ainda não foi inventado.

Seus dados deveriam sobreviver a qualquer combinação de modelo + IDE + orquestrador que você use hoje — e que vai mudar em 6 meses.

2️⃣ P.A.R.A. — Estrutura Que Qualquer Agente Entende

Ok, eu tenho meus arquivos em Markdown. Mas Markdown solto numa pasta é só bagunça com extensão .md.

Organização não é sobre onde guardar. É sobre criar uma estrutura tão previsível que qualquer IA — GPT, Claude, Gemini — consiga navegar sem ajuda.

Eu adotei o P.A.R.A. — framework criado por Tiago Forte, autor de Building a Second Brain, com 5.000+ alunos em 70+ países. A ideia é organizar por acionabilidade, não por tema:

• Projects — iniciativas ativas com prazo e objetivo claro

• Areas — responsabilidades contínuas sem deadline (saúde, finanças, carreira)

• Resources — material de referência que alimenta o resto

• Archive — o que encerrou, preservado mas fora do caminho

O insight que me pegou: uma boa taxonomia funciona como API.

Se a estrutura é clara, qualquer agente novo que você plugar já sabe onde encontrar o quê. Não precisa de tutorial, não precisa de prompt explicando "olha, as coisas ficam assim...". A hierarquia fala por si.

No meu setup, adicionei ao P.A.R.A. duas pastas extras: 5. Clippings/ pra captura de conteúdo externo (artigos, newsletters, repositórios, um "inbox" de tudo que capturo na internet) e 6. Dailies/ como diário operacional.

Cada pasta tem um index file que funciona como hub de navegação — pra mim e pro agente. Quando o Claude Code abre meu vault, ele não precisa varrer 200 arquivos. Ele lê o index e já sabe o que existe.

E tem um detalhe que conecta tudo: eu integrei o ciclo de vida do Shape Up dentro do P.A.R.A. Cada projeto passa por Framing → Shaping → Project → Archive. Framing define o problema. Shaping desenha a solução. Project executa. Archive preserva.

Na prática, o framing da minha migração para fora do Notion feito usando a skill /framing que eu tinha acabado de criar. Ou seja: o vault foi definido antes de existir.

A skill empacotou a metodologia, o P.A.R.A. deu a estrutura, e o resultado foi um projeto que já nasceu organizado — não só pra mim, mas pra qualquer agente que eu plugasse depois.

P.A.R.A. não é uma metodologia de organização. É uma API para o seu conhecimento — e APIs boas funcionam com qualquer cliente.

3️⃣ QMD — Busca Semântica Local, Sem Vendor Lock-in

Estrutura resolve onde as coisas ficam.

Mas com N ferramentas rodando ao mesmo tempo — Claude Code, Cursor, Codex, o que vier semana que vem — como você garante que todas tenham acesso ao contexto certo?

Grep encontra palavras. RAG na cloud manda seus dados pra terceiros. Busca semântica local te dá o melhor dos dois mundos.

Eu uso o QMD — uma ferramenta que combina três camadas de busca: BM25 (keyword clássico, tipo grep esperto), embeddings vetoriais (entende significado, não só palavras) e LLM reranking (reordena resultados por relevância real).

Tudo rodando local via Metal/Apple Silicon. Sem API externa. Sem mandar dados pra cloud. Os modelos ocupam ~2.2GB no M4 Max e rodam 100% na máquina.

O vault é indexado em três coleções separadas: vault (todas as notas P.A.R.A), skills (definições de skills) e agents (definições de agentes) - ambos vivem como recursos dentro do vault mas foram indexados como coleções de primeira classe para facilitar o acesso..

Isso permite buscas escopadas — pergunto sobre skills e não recebo ruído de daily notes.

Na prática: eu pergunto "o que eu sei sobre integração Toggl?" e recebo o contexto relevante — o framing do projeto, os recursos de referência, as notas do daily — sem grepping manual, sem abrir 15 arquivos, independente de qual ferramenta esteja usando naquele momento.

Isso resolve o problema da fragmentação na raiz. Não é cada ferramenta com seu pedaço de contexto. É uma camada unificada de busca semântica que serve qualquer cliente. O motor pode trocar — o IDE pode mudar, o modelo pode atualizar — mas a memória permanece intacta, local, e acessível.

A busca semântica local é a cola que conecta o seu vault a qualquer IA que você queira usar. O motor pode trocar — a memória permanece.

4️⃣ Skills e Agents — O Catálogo Portátil

Vamos analisar o problema da fragmentação.

Você cria um workflow no Cursor. Funciona bem. Aí muda pro Claude Code. O workflow fica pra trás. Faz um agente customizado. Funciona. Aí quer testar no Codex CLI. Começa do zero. Cada ferramenta cria um silo. Cada silo prende o seu conhecimento operacional.

O ativo mais valioso da era multi-modelo não é o prompt perfeito. É o catálogo de skills que funciona em qualquer plataforma.

A solução que eu encontrei foi tratar skills e agents como o que eles realmente são: Markdown com frontmatter + system prompt. Formato portável por design. Sem dependência de runtime, sem SDK proprietário, sem lock-in.

No meu vault hoje tenho uma série de skills ativas. Alguns exemplos:

• /framing — 111 linhas que transformam ideias vagas em problem statements usando metodologia Shape Up. Quando alguém chega com "a gente precisava de um feature que..." eu rodo o framing e saio com problema, outcomes, appetite e "not doing" — tudo delimitado antes de qualquer solução.

• /shaping — 178 linhas com uma subpasta references/ contendo breadboarding.md (223 linhas). É o Shape Up completo empacotado: solution design, breadboarding, fat marker sketches, slicing.

• /sync-toggl-notion — 109 linhas que sincronizam time logs entre Notion e Toggl automaticamente. Workflow operacional puro.

A mágica está na estratégia de distribuição. Cada skill mora no vault como source of truth (3. Resources/skills/{skill-name}/SKILL.md) e um symlink conecta ao sistema (~/.claude/skills → vault). Um arquivo. Uma localização canônica. Disponibilidade global em qualquer projeto. Se eu edito a skill no vault, ela atualiza em todo lugar.

Se eu mudo de ferramenta amanhã, o catálogo permanece — porque são arquivos Markdown numa pasta. Já tenho um projeto de migração pro Codex CLI onde as skills portam quase direto. A portabilidade não é teoria. É teste real.

Skills não são prompts presos a uma ferramenta. São conhecimento operacional empacotado como Markdown — e Markdown é portátil por definição.

5️⃣ O Onboarding Document — Contrato Com Qualquer Agente

Hoje cada IDE de IA tem seu arquivo de configuração. .cursorrules. CLAUDE.md. codex.md. .windsurfrules. O nome muda, o formato é o mesmo: Markdown.

O padrão que vejo na maioria dos times? Duplicar conteúdo manualmente entre esses arquivos. Copiar, colar, adaptar. Resultado previsível: drift, inconsistência, contexto desatualizado. Três ferramentas, três versões diferentes da verdade.

Se você não escreve instruções pro seu agente, cada ferramenta nova é onboarding do zero — vezes N ferramentas.

A minha abordagem foi criar UM documento canônico com a verdade completa. Meu CLAUDE.md tem 236 linhas. Não é um prompt. É um contrato operacional. Ele define 6 princípios que o agente aplica automaticamente:

1. CLI first — Usa o Obsidian CLI, não manipulação direta de filesystem

2. Always explicit — Passa vault e path em todo comando, nunca depende de contexto implícito

3. Preserve links — Checa backlinks antes de mover ou renomear qualquer arquivo

4. Keep indexes current — Toda nota nova ganha entrada no index correspondente

5. Incremental edits — Usa append/prepend ao invés de reescrever arquivos inteiros

6. Audit before reorganizing — Roda unresolved, backlinks, orphans antes de mudanças estruturais

O agente que lê esse documento não é genérico. Ele já sabe a estrutura do vault, as convenções de nomenclatura, os workflows comuns.

Ele sabe onde cada coisa está e como operar. Quanto tempo você gasta re-explicando as mesmas convenções pro seu assistente de IA? Cada sessão. Cada conversa nova. Cada "não, não é assim que a gente faz aqui."

Com o onboarding document, esse custo cai pra zero. O agente lê o contrato no início da sessão e opera dentro das regras. Sem surpresas.

E o ponto que fecha tudo: eu fiz essa migração inteira — Notion pra Obsidian, P.A.R.A., skills, QMD, onboarding document completo — em ~24 horas. Quatro commits no git contam a história. A migração não precisa ser um projeto de 3 meses. Se a estrutura é clara e o formato é portável, é um fim de semana focado.

O melhor investimento que você faz em IA não é no modelo. É no onboarding document que você escreve uma vez e que serve pra todas as ferramentas.

🔮 O Shift

A maioria das pessoas está otimizando pra ferramenta.

"Qual o melhor IDE de IA?" "Qual modelo é mais rápido?" "Cursor ou Claude Code?"

Essa pergunta vai ficar obsoleta a cada 3 meses. E você sabe disso — porque já trocou de resposta pelo menos duas vezes no último ano.

O shift é mudar o investimento de tempo: em vez de dominar uma ferramenta específica, construa a camada de conhecimento que todas elas consomem.

O ecossistema de IA está fragmentando em velocidade absurda. Novos modelos a cada semana. Novos IDEs a cada mês. Novos orquestradores a cada trimestre. A única constante nessa equação é o seu conhecimento — como ele está organizado, como ele é acessado, e se ele sobrevive à próxima migração.

Markdown é o contrato universal. Git é o histórico. A busca semântica local é a ponte. O catálogo de skills é o portfólio operacional. E o onboarding document é a interface entre você e qualquer IA que aparecer amanhã.

A pergunta que importa não é qual modelo você usa. É: se o modelo mudar amanhã — e vai mudar — o que sobrevive?

"O segundo cérebro mais poderoso não é o que usa o melhor modelo. É o que funciona com qualquer modelo."

DICA: Quer construir algo assim também? Cole esse prompt para seu agente e peça pra ele te instruir no passo a passo de configuração. Se tiver alguma dúvida, é só responder esse e-mail.

📚 Conteúdos Recomendados

📖 Livro: Building a Second Brain — Tiago Forte. O livro que originou P.A.R.A. e a filosofia de "segundo cérebro". Leitura fundamental pra quem quer organizar conhecimento de verdade.

📄 Docs: Model Context Protocol (MCP) — Anthropic. O protocolo aberto que conecta LLMs a ferramentas externas. Anúncio oficial (Nov 2024).

🔧 Tool: Obsidian — 1.5M+ usuários ativos, 2.000+ plugins, zero VC funding. Comece pelo vault local + daily notes.

📰 Artigo: The Plain Text Project — Por que plain text sobrevive a tudo. Recurso educativo sob Creative Commons.

📊 Report: State of AI Code Quality 2025 — Qodo. 609 devs, dados concretos sobre frustração com contexto e qualidade de IA.

🎧 Podcast: Coding Agents in Obsidian — Tool Use AI Conversations (Nov 2025). Claude Code + Obsidian, second brain com IA. Direto no tema dessa edição.

Forte abraço,

Jonata