Agentic OS em Claude Code: a construção de três camadas
A maioria das pessoas usa Claude Code como uma máquina caça-níqueis.
Abra o terminal. Digite um prompt. Puxe a alavanca. Às vezes você obtém um refatorador funcional. Às vezes você recebe uma parede de advertências. Às vezes você recebe metade do que pediu e uma explicação educada de por que a outra metade “não é aconselhável neste momento”. Então você rola novamente o prompt. Puxe novamente. Talvez ajuste uma palavra. Puxe novamente.
Fiz isso durante os primeiros oito meses em que usei o Claude Code. Eu disse a mim mesmo que era uma engenharia rápida. Não foi. Foi um jogo.
O que finalmente quebrou o ciclo foi uma metodologia que aprendi em um resumo de vídeo sobre a construção de um “sistema operacional agente” em cima do Claude Code, e então moldada contra minha própria realidade confusa de administrar quatro marcas e enviar cerca de 250 postagens longas através do sistema este ano. A metodologia tem três camadas: arquitetura, memória e observabilidade. Palavras chatas. Recompensa enorme.
Este post é a versão dessa metodologia que eu realmente uso, escrita em campo, com as primitivas Claude Code específicas que estou executando e as coisas que tentei que não sobreviveram ao contato com o trabalho real. Se você está no estágio das máquinas caça-níqueis e começa a suspeitar que existe uma maneira melhor, você está certo. Aqui está.
O problema das máquinas caça-níqueis tem um custo
Antes que a metodologia faça sentido, a dor deve ser específica. Então deixe-me ser específico.
Um fluxo de trabalho de caça-níqueis parece produtivo. Você está no terminal. As coisas estão acontecendo. O código está sendo gerado. Mas o trabalho por trás do trabalho – a parte em que você reexplica a voz da sua marca pela décima primeira vez, cola a mesma estrutura de pastas em uma nova sessão, depura uma saída que muda porque você esqueceu de mencionar a restrição que era óbvia para você, mas invisível para o modelo – essa parte é invisível até que você a meça.
Medi o meu em março. Ao longo de uma semana de sessões Claude Code, gastei cerca de 35% dos meus tokens de prompt no contexto que já havia fornecido ao modelo em uma sessão anterior. Não o trabalho em si. A configuração para o trabalho. Regras da marca que escrevi em três lugares. Caminhos de pasta que mostrei na terça e mostrei novamente na sexta. Restrições de voz enterradas em um CLAUDE.md em algum lugar que nunca me preocupei em apontar.
Pior: a variação. Peça ao Claude Code para escrever uma postagem no mejba.me na segunda-feira e você obterá um formato. Pergunte da mesma forma na sexta-feira e você receberá algo que parece ter sido escrito por uma pessoa próxima, mas desconhecida. Esse não é o modelo se comportando mal. Sou eu executando um prompt não estruturado em um mecanismo sem estado e ficando surpreso ao ver que a saída não é estável.
A metodologia do sistema operacional agentic corrige ambos os problemas, interrompendo o jogo e iniciando a arquitetura. Três camadas, em ordem de impacto: organizar o que você faz (arquitetura), lembrar o que você fez (memória), ver o que está acontecendo (observabilidade).
Mesmo se você adotar apenas a primeira camada, obterá a maior parte do valor. Quero ser honesto sobre isso desde o início, porque a tentação quando você lê sobre um sistema de três camadas é tentar construir todas as três em um sábado. Não. Construa a camada um. Viva nele. Em seguida, adicione o próximo.
Vamos entrar no assunto.
Camada Um: Arquitetura — De Prompts Aleatórios a um Organograma Real
A primeira camada é aquela que quebrou o hábito das máquinas caça-níqueis para mim. É também aquele que quase pulei porque parece menos técnico.
A ideia é simples. Pare de pensar em Claude Code como um local onde você digita prompts. Comece a pensar nela como uma organização com departamentos, descrições de cargos e procedimentos operacionais padrão. Concretamente, isso significa organizar seu trabalho em quatro conceitos aninhados:
- Domínios — as amplas áreas em que você realmente atua (criação de conteúdo, pesquisa, produtividade, comunidade, segurança)
- Tarefas — o trabalho recorrente que cada domínio produz (uma postagem no blog, uma verificação do concorrente, uma revisão de código, uma auditoria de marca)
- Habilidades — instruções codificadas e repetíveis sobre como executar bem uma tarefa específica
- Automações — habilidades que são executadas com um gatilho em vez de esperar que você as invoque
Isto não é abstrato. Em Claude Code, cada um desses conceitos é mapeado em um primitivo real. As habilidades vivem como arquivos SKILL.md com frontmatter YAML. Os subagentes vivem como arquivos markdown em .claude/agents/. Os comandos de barra residem como arquivos em .claude/commands/. As automações são habilidades agrupadas em um gancho (SessionStart, PostToolUse) ou em um gatilho agendado por meio do SDK do agente Claude. A plataforma já está moldada para isso. Você só precisa usar a forma.
Qual é a aparência real de um domínio na minha configuração
Eu administro quatro marcas – mejba.me, ramlit.com, colorpark.io, xcybersecurity.io – além de um domínio interno de “operações” para tudo que cruza marcas. Portanto, tenho cinco domínios. Cada domínio tem entre três e sete tarefas que realizo de forma recorrente, e cada tarefa tem no máximo uma habilidade associada.
Aqui está a estrutura truncada no disco:
~/projects/agentic-os/
├── CLAUDE.md # root config (more on this below)
├── .claude/
│ ├── settings.json # permissions + hooks
│ ├── agents/ # subagents (one per role)
│ │ ├── aria.md # content engineer
│ │ ├── auditor.md # SEO + voice auditor
│ │ └── researcher.md # WebSearch + summary specialist
│ ├── commands/ # slash commands
│ │ ├── morning-scan.md
│ │ ├── post-from-video.md
│ │ └── brand-audit.md
│ └── skills/ # repeatable instructions
│ ├── write-blog-post/SKILL.md
│ ├── extract-video-summary/SKILL.md
│ └── seo-pass/SKILL.md
└── vault/ # memory layer (Obsidian)
├── raw/
├── wiki/
└── output/
Essa é toda a arquitetura em uma árvore. Nenhuma ferramenta inteligente. Nenhuma plataforma proprietária. Apenas pastas que o Claude Code já entende nativamente.
O que torna este organograma e não apenas uma pasta são as relações entre as peças. O subagente aria.md lê a habilidade write-blog-post. O comando de barra morning-scan chama o subagente researcher, que lê a habilidade extract-video-summary. Cada peça faz uma coisa. Nenhum deles se duplica. Quando quero alterar a forma como as postagens do mejba.me são escritas, edito um arquivo - o write-blog-post/SKILL.md - e cada invocação em cada domínio herda a alteração.
Essa é a superpotência chata. Uma fonte de verdade para cada capacidade.
Uma habilidade real, não de brinquedo
Deixe-me mostrar como realmente é uma habilidade. Aqui está uma versão simplificada daquela que uso para extrair resumos estruturados de transcrições de vídeo antes de se tornarem postagens de blog:
---
name: extract-video-summary
description: Extract a structured summary from a video transcript or YouTube URL. Use when the user provides a video, transcript, or asks to "summarize this video" before writing a post.
---
You are extracting a structured summary that another agent will use as
source material for a blog post. The output must be:
1. **TLDR** — three sentences. The single most important takeaway.
2. **Key claims** — bullet list. One claim per bullet. No editorializing.
3. **Specific examples** — bullet list. Names, numbers, dates, tools.
4. **Quotes worth pulling** — direct quotes that would land in a blog.
5. **What the video gets wrong or oversimplifies** — be honest.
Rules:
- Do not soften claims. If the speaker said it, write it as they said it.
- If a claim is unverified, mark it `[unverified]` and move on.
- Save the result to `vault/raw/video-summaries/[slug].md` using
the video title as the slug.
É isso. Quarenta linhas depois de contar a formatação. Carregado em Claude Code por meio da ferramenta Skill, ele transforma um prompt não confiável "resuma isso para mim" em um processo determinístico. Sempre a mesma forma. Sempre o mesmo local de arquivo. Os mesmos agentes downstream podem lê-lo sem verificar qual formato apareceu hoje.
O principal de uma boa habilidade é o que ela remove, não o que acrescenta. Uma habilidade pega uma pergunta confusa e remove a variação. Se você estiver escrevendo uma habilidade longa e inteligente, provavelmente ainda não decidiu qual é realmente a tarefa.
Automações: habilidades com gatilho
Uma automação é uma habilidade que funciona sem você. No Claude Code, a maneira mais barata de conectar um é por meio de um gancho no settings.json. Um gancho SessionStart é acionado quando uma sessão Claude Code é iniciada. Um gancho PostToolUse é acionado após a conclusão de uma ferramenta. Ambos são configurados em settings.json e estão documentados na referência oficial de ganchos Claude Code.
Aqui está a varredura de tendências matinais que executo. Ele é conectado como um comando de barra (/morning-scan) que eu aciono manualmente na maioria dos dias, mas nos dias em que quero automatizá-lo, o mesmo comando é executado a partir de um cron job que apenas desembolsa para claude -p "/morning-scan":
---
name: morning-scan
description: Aggregate AI news, competitor moves, and trending topics into a single daily brief. Save to vault/raw/scans/YYYY-MM-DD.md.
---
# Morning Scan
Run this every weekday morning before I open the terminal.
1. Use WebSearch to pull the top 5 stories from each of:
- Anthropic, OpenAI, Google AI launches in the last 24h
- HackerNews top 10 (filter to AI/dev/agent topics)
- r/ClaudeAI top posts of the day
2. For each story, write a 2-sentence summary. No fluff.
3. Flag anything that affects my multi-brand workflow:
- Claude Code changelog → tag #claude-code-update
- New AI tool launches → tag #stack-candidate
- Security/CVE news → tag #xcyber-relevant
4. Save the brief to vault/raw/scans/YYYY-MM-DD.md.
5. If anything in the brief is post-worthy for mejba.me, add a
line at the top: `POST CANDIDATE: [topic]`.
A habilidade é o quê. O cron job é o trigger. Juntos eles são uma automação.
Para a versão mais limpa, você usaria o SDK do agente Claude para agendar a execução programaticamente e postar o resultado em um canal do Slack ou em seu próprio painel. Eu construí essa versão eventualmente. A versão slash-command-plus-cron me rendeu 80% do valor em 30 minutos.
Quando a automação se torna uma armadilha
Seção honesta. Automatizei demais por dois meses no início de 2026. Construí quatorze automações nas quatro marcas. Ganchos disparando em cada Edit, varreduras agendadas a cada duas horas, um gancho que confirma automaticamente qualquer arquivo tocado pelo Claude Code. Ficou lindo em um quadro branco. Foi um desastre na prática.
Três coisas quebraram. Primeiro, os ganchos lutaram entre si. Um formatador PostToolUse continuou reformatando os arquivos no meio da edição e colocando-os em cascata na próxima chamada de ferramenta. Em segundo lugar, o custo disparou – cada varredura agendada era uma sessão Claude completa sem limite, e a conta em março foi quase o dobro da de fevereiro. Terceiro, o barulho. Quatorze automações significavam quatorze notificações do Slack por dia, a maioria das quais eu silenciei, o que anulou todo o objetivo.
Reduzi para quatro automações. Varredura matinal. Limpeza do cofre no final do dia. Auditoria semanal de voz da marca. Revisão mensal da pilha. Todo o resto se tornou um comando de barra que executo quando realmente quero. A lição: a automação é para coisas que você executaria de qualquer maneira, não para coisas que você gostaria que alguém executasse.
Se você está começando do zero, desenvolva uma habilidade, um comando de barra e zero automações. Use-os por uma semana. Adicione a próxima coisa somente quando sentir a ausência.
Abordei a filosofia mais ampla de design de habilidades em o mergulho profundo nas habilidades Claude Code que as empresas pagam em 2026 e os padrões táticos para manter as habilidades baratas em o posto de economia de tokens de habilidades do homem das cavernas - ambos valem a pena ler antes de começar a codificar o seu próprio.
Essa é a camada um. Domínios, tarefas, habilidades, automações. Se você parar de ler aqui e apenas construir isso, já estará à frente de 95% dos usuários do Claude Code. As próximas duas camadas o compõem.
Camada dois: memória - o cofre Obsidian e o CLAUDE.md que o executa
A camada um organiza o que você faz. A camada dois fornece ao Claude Code um lugar para lembrar o que fez.
Quero ter cuidado aqui, porque “memória” é o conceito com maior engenharia no ecossistema de agentes no momento. A cada duas semanas, outra startup envia uma “camada de memória para Claude” que é, após inspeção, um banco de dados vetorial com um orçamento de marketing. Para 90% dos fluxos de trabalho pessoais e de equipes pequenas, você não precisa disso. Você precisa de uma pasta de arquivos markdown e um arquivo de configuração que informe ao Claude Code o que há nele.
O padrão que finalmente funcionou para mim é a abordagem Karpathy LLM Wiki – Andrej Karpathy postou sua versão em 3 de abril de 2026, e passei um fim de semana reconstruindo a minha para combiná-la. A forma consiste em três pastas dentro de um cofre Obsidian: raw/, wiki/, output/. Cada pasta tem um trabalho claro. O LLM é o bibliotecário e o autor. Não há banco de dados vetorial, nem incorporações, nem estratégia de agrupamento.
Eu escrevi sobre essa abordagem em detalhes na postagem Karpathy Obsidian RAG - essa postagem é um mergulho profundo em por que ela funciona. Esta seção é sobre como ele se encaixa no sistema operacional agente como camada de memória.
As três pastas e para que serve cada uma
O cofre é extremamente simples:
vault/
├── raw/ # ingestion, no organization required
│ ├── video-summaries/
│ ├── scans/ # morning-scan output lands here
│ ├── transcripts/
│ ├── research-clippings/ # Obsidian Web Clipper drops here
│ └── inbox/ # everything else, sorted later
│
├── wiki/ # codified knowledge, LLM-maintained
│ ├── index.md # master index, LLM-written
│ ├── claude-code/
│ │ ├── index.md
│ │ ├── skills.md
│ │ ├── hooks.md
│ │ └── agents.md
│ ├── brands/
│ │ ├── mejba-me-voice.md
│ │ ├── ramlit-positioning.md
│ │ └── colorpark-design-rules.md
│ └── ops/
│ ├── seo-rules.md
│ └── publishing-checklist.md
│
└── output/ # final deliverables
├── posts/
├── briefs/
└── decks/
raw/ é o depósito de lixo. Qualquer coisa que eu queira que Claude Code eventualmente saiba sobre os terrenos aqui, não está classificado. Transcrições de vídeo. Recortes da Web (um clique por meio do Obsidian Web Clipper). Daily scan results. Notas de voz aleatórias que eu dito enquanto caminho. O atrito de ingestão é intencionalmente próximo de zero, porque no segundo em que tenho que pensar sobre onde arquivar algo, paro de arquivar as coisas.
wiki/ é onde o LLM ganha seu sustento. Em uma programação recorrente (ou sob demanda por meio de um comando de barra), Claude Code lê raw/, identifica novo material que não foi integrado e atualiza o wiki. Escreve artigos em estilo enciclopédico. Mantém o mestre index.md. Ele faz links cruzados de conceitos relacionados usando [[wiki-style links]] que Obsidian renderiza nativamente. O wiki é o entendimento compilado do LLM de tudo no cofre, escrito em um formato que a próxima sessão possa ler com eficiência.
output/ é a linha de chegada. As postagens finais do blog vão aqui. Os resumos do cliente vão aqui. Os decks para os próximos workshops estão aqui. Qualquer coisa que tenha sido entregue. A razão pela qual isso obtém sua própria pasta é para que Claude Code possa responder rapidamente "o que eu enviei?" sem rastrear o resto do cofre.
Essa é toda a camada de memória. Três pastas. Remarcação. Livre. Portátil.
O CLAUDE.md no nível do cofre que o une
O único arquivo que torna esta camada funcional é o CLAUDE.md na raiz do vault. É a configuração que informa ao Claude Code o que há nas pastas e como tratá-las. Sem ele, Claude terá que adivinhar todas as sessões. Com ele, você reduz seus tokens de configuração de contexto em algo em torno de 70%.
Aqui está a minha estrutura real, levemente redigida:
# CLAUDE.md — Configuração do cofre Agentic OS
## Objetivo
Este cofre é a camada de memória persistente para o sistema operacional agente. É
mantido em conjunto por mim e Claude Code. O cofre tem três níveis superiores
pastas, cada uma com uma função específica.
## Funções de pasta
### cru/
Material de origem não processado. Trate isso como apenas ingestão.
- NÃO modifique arquivos em raw/ exceto para adicionar novos.
- NÃO use raw/ como fonte primária ao responder perguntas —
sempre verifique wiki/ primeiro e depois volte para raw/ se o wiki
tem uma lacuna.
- Novo material do Obsidian Web Clipper, resumos de vídeo e
a automação da varredura matinal chega aqui.
###wiki/
Conhecimento codificado, mantido por Claude Code. Trate isso como o
fonte primária de verdade para tudo o que foi processado.
- Sempre comece aqui ao responder uma pergunta.
- Sempre atualize wiki/index.md ao criar um novo artigo wiki.
- Use [[links estilo wiki]] para fazer referências cruzadas de conceitos relacionados.
- Se você encontrar uma lacuna na wiki ao responder uma pergunta, observe
na parte inferior do index.md relevante como um TODO.
### saída/
Entregas finais. Trate isso como leitura principalmente.
- Escreva aqui apenas quando solicitado explicitamente a produzir um produto final.
- Ao produzir uma nova postagem, verifique output/posts/ para ter certeza
a bala ainda não foi tomada.
## Regras de fluxo de trabalho
1. Quando eu pedir uma postagem no blog, leia a seção relevante da wiki
primeiro, depois bruto/ para qualquer material novo desde que o wiki foi
atualizado pela última vez e, em seguida, grave o rascunho em output/posts/[slug].md.
2. Quando adiciono novo material ao raw/, não o processe automaticamente.
Espere que eu execute /update-wiki.
3. As regras de voz da marca estão em wiki/brands/. Sempre carregue o
relevante antes de escrever na voz dessa marca.
4. As regras de SEO estão em wiki/ops/seo-rules.md. Aplique em todas as postagens.
## Marcas ativas
- mejba.me (pessoal, em primeira pessoa, apaixonado)
- ramlit.com (corporativo, terceira pessoa, focado em resultados)
- colorpark.io (design, opinativo, visual)
- xcybersecurity.io (segurança, oficial, urgente)
Esse arquivo tem talvez 60 linhas. Faz mais pela consistência dos meus resultados do que qualquer habilidade que escrevi. A razão é simples: elimina suposições. Claude Code não precisa descobrir onde as coisas estão, para que serve cada pasta ou como lidar com solicitações ambíguas. As regras estão no arquivo, o arquivo é carregado a cada sessão e cada subagente herda o contexto.
Se você for escrever um arquivo de configuração para toda a configuração, escreva este.
O que tentei primeiro e abandonei
Dois experimentos de memória que não sobreviveram ao contato com o trabalho real.
Primeiro: tentei armazenar memória em um banco de dados vetorial Supabase com um servidor MCP personalizado. Supabase como armazenamento de vetores, embeddings OpenAI, recuperação semântica sobre minhas anotações. Funcionou. Também foi extremamente projetado para o que eu realmente precisava, que era "lembre-se do que decidimos na terça-feira passada". A qualidade da recuperação era ativamente pior do que apenas deixar Claude Code ler a marcação diretamente, porque os pedaços seriam cortados no meio da frase e as pontuações de similaridade apareceriam quase duplicadas em vez da nota mais útil. Depois de dois fins de semana de ajustes, apaguei tudo.
Segundo: tentei fazer com que o Claude Code processasse automaticamente cada novo arquivo bruto no momento em que ele fosse adicionado - um gancho PostToolUse que acionaria uma atualização do wiki em cada gravação no raw/. O custo foi brutal. Cada vez que eu recortava um artigo longo, gerava uma sessão que lia o artigo, decidia onde ele se encaixava no wiki, às vezes escrevia um novo artigo, às vezes atualizava um existente. Algumas dessas sessões tiveram mais de 30.000 tokens. Fazer isso dezenas de vezes por dia queimava créditos sem entregar valor proporcional, porque a maioria dos recortes não precisa de processamento no mesmo dia em que são salvos.
A correção foi o comando /update-wiki explícito no CLAUDE.md acima. Faço uma vez por semana, aos domingos. Ele agrupa toda a matéria-prima não processada em uma sessão, e a relação custo por insight cai algo como 10x.
A lição: as camadas de memória falham tanto no excesso de arquitetura (bancos de dados vetoriais) quanto no excesso de ansiedade (processamento automático de cada entrada). A estrutura de pastas Karpathy mais um CLAUDE.md claro mais um comando de atualização manual é o meio enfadonho que realmente funciona.
Essa é a camada dois. Três pastas, um arquivo de configuração, um hábito semanal. Agora o sistema tem continuidade.
Camada Três: Observabilidade — Um painel que expõe o sistema operacional aos humanos
A camada um organiza o que você faz. A camada dois lembra o que você fez. A camada três é a parte que importa quando você deixa de ser o único usuário.
Serei honesto: construí a camada três por último e por muito tempo achei que não precisava dela. Eu era o único operador. Eu morava no terminal. O terminal estava bem. Então tentei entregar a automação da verificação matinal a uma colega de equipe para poder sair de férias por uma semana, e todo o sistema caiu não porque a tecnologia falhou, mas porque ela teve que aprender três comandos CLI, uma estrutura de cofre e a diferença entre um comando de barra e um subagente antes que ela pudesse executar um trabalho.
O terminal é um fosso. Para mim é uma característica. Para todos os outros, é uma parede.
Um painel é a terceira camada de um sistema operacional de agente porque é a camada que permite ao sistema atender pessoas que não desejam digitar claude -p "..." para ganhar a vida. Isso inclui colegas de equipe não técnicos, clientes, futuro você em uma manhã de domingo, quando digitar parece um trabalho, e qualquer pessoa que queira ver o que o sistema está fazendo sem usar arquivos de log.
O que o painel realmente faz
Ainda não existe um único painel oficial do Claude Code. Em maio de 2026, a Anthropic envia a pilha de monitoramento Claude Code via OpenTelemetry — oito métricas incluindo contagem de sessões, uso de token, custo estimado e tempo ativo — e um ecossistema saudável de camadas de observabilidade construídas pela comunidade (o projeto claude-code-otel é o que eu mais usei). O que ninguém envia imediatamente é a superfície de controle — a parte que expõe suas habilidades e automações como botões.
Então você mesmo constrói essa parte. A forma que funcionou melhor para mim é um pequeno aplicativo Next.js - talvez 600 linhas no total - que faz quatro coisas:
- Expõe cada habilidade e automação como um botão clicável. Clique em "Verificação matinal" e o painel será enviado para
claude -p "/morning-scan"(ou acessará o SDK do agente Claude programaticamente). A saída é transmitida de volta para o UI. 2. Monitora o uso. Quando foi a última execução de cada habilidade? Quanto tempo demorou? Quantos tokens custou? Quais automações foram acionadas dentro do cronograma e quais falharam silenciosamente? 3. Apresenta alterações recentes no vault. O que foi adicionado aoraw/nas últimas 24h? O que a última alteração/update-wikiemwiki/? O que foi publicado nooutput/posts/esta semana? 4. Vincula cada saída de volta ao Obsidian. Cada resultado que o painel mostra tem um link "Exibir código-fonte" que abre o arquivo de marcação relevante em Obsidian.
Rastreabilidade total – cada reclamação que o sistema apresenta aponta para o arquivo de onde veio a reclamação.
Esse último é o mais importante. Sem ele, o painel se torna outra caixa mágica onde o AI faz as coisas e você confia nele. Com ele, cada saída pode ser auditada com um clique. Você vê o resultado, clica na fonte e lê o markdown que o agente leu. Nenhuma alucinação pode esconder-se.
O que o painel NÃO precisa fazer
Quero sinalizar isso porque queimei um mês nisso. O painel não precisa ser:
- Uma ferramenta completa de gerenciamento de projetos. Não é Linear. Não é um substituto para o seu rastreador de tarefas. É uma superfície de controle para o seu sistema operacional agente, ponto final.
- Uma plataforma analítica. O rastreamento de gastos com tokens é útil. Um armazém analítico personalizado não é.
- Um SaaS multilocatário. Se você criar um, gastará três meses em autenticação e nenhum mês em melhorias reais no fluxo de trabalho.
- Uma ferramenta de colaboração multiusuário em tempo real. Você é o operador. O painel é para você e talvez para um ou dois colaboradores de confiança.
O painel que criei é um aplicativo Next.js de página única com uma rota, sem autenticação (é apenas localhost) e uma instância do Postgres para logs de uso. Tempo total de construção: cerca de 14 horas, distribuídas em dois finais de semana. Ele faz as quatro coisas acima. Nada mais.
As métricas que realmente importam
Das oito métricas que Claude Code exporta nativamente, quatro aparecem na tela inicial do meu painel:
- Tokens gastos por habilidade, por semana. Esta é a métrica que detecta automações desonestas. Na semana em que o gancho automático do wiki foi acionado, esse gráfico aumentou 3x e pude ver exatamente qual habilidade era responsável.
- Contagem de execuções por automação. Quais automações realmente são executadas e quais eu silenciosamente parei de usar. Se uma automação semanal não for acionada em três semanas, ela estará morta e eu a excluirei.
- Vault delta. Quantos arquivos foram alterados em
raw/,wiki/,output/esta semana. Esta é a coisa mais próxima de "o sistema está realmente funcionando" que encontrei. - Data e hora da última execução por habilidade. Quando foi a última vez que invoquei isso? Habilidades que não executo há 60 dias são arquivadas. O sistema deveria ser um organismo vivo, não um museu.
As outras quatro métricas (contagem de PR, linhas de código, decisões de edição de código, tempo ativo) são úteis para equipes de engenharia, mas menos úteis para uma operação de conteúdo. Sua milhagem irá variar dependendo de quais são seus domínios.
O que eu construiria se começasse hoje
Se eu estivesse reconstruindo o painel do zero em maio de 2026, começaria com uma das pilhas de observabilidade Claude Code de código aberto - claude-code-otel de Cole Murray mais Grafana é uma base sólida - e aparafusaria a superfície de controle em cima dela. A parte da observabilidade é resolvida pelo trabalho comunitário. A superfície de controle é a parte que você mesmo deve escrever, porque é específica para suas habilidades e automações.
Não tente construir tudo na primeira semana. O painel deve ser o que você procura quando a execução do sistema operacional no terminal deixa de parecer rápida. Se você ainda está satisfeito com o terminal, ainda não precisa dele.
Essa é a camada três. Uma superfície de controle que expõe o sistema operacional aos humanos, com rastreabilidade até o cofre. Construa por último, construa pequeno, construa para um usuário.
Quando toda essa estrutura realmente compensa
Tenho escrito como se todos devessem construir todas as três camadas. Eles não deveriam. O sistema operacional agentico compensa em situações específicas e é um exagero em outras. Avaliação honesta:
Construa todas as três camadas se você:
- Executar mais de uma marca ou um grande projeto (a estrutura se compõe em cada um)
- Entregar o trabalho a colegas de equipe, clientes ou prestadores de serviços que não moram em um terminal
- Produzir resultados recorrentes dentro de um cronograma (postagens em blogs, resumos, auditorias, varreduras)
- Já se pegou explicando novamente a mesma coisa para Claude Code mais de três vezes
Crie apenas a camada um se você:
- É um operador solo com um projeto principal
- Use principalmente Claude Code para tarefas de codificação únicas
- Você está no primeiro mês usando Claude Code seriamente (dê um tempo antes de adicionar arquitetura)
Pule tudo se você:
- Use Claude Code ocasionalmente para projetos pessoais sem resultados recorrentes
- Ainda estão descobrindo quais são seus domínios e tarefas
- Quer aprender a plataforma primeiro – superestruturar antes de entender os primitivos é a segunda maneira mais rápida de desistir da plataforma
A razão pela qual o sistema operacional compensa especificamente para mim é que administro quatro marcas e envio cerca de 250 postagens longas por ano. Sem a estrutura, a variação me mata. Com a estrutura, cada marca tem voz estável, cada postagem parte do mesmo andaime e o tempo por postagem cai de “uma tarde inteira” para “noventa minutos incluindo pesquisa”. Essa é a matemática que faz com que a sobrecarga arquitetônica valha a pena.
Se sua matemática for diferente, a resposta será diferente. Quero ter certeza de que não estou vendendo algo que ninguém precisa.
O que eu pularia no primeiro dia
Sempre me perguntam "por onde começo?" e continuo dando a mesma resposta, então deixe-me deixar isso explícito. Se você leu esta postagem e decidiu construir um sistema operacional agente, eis o que fazer esta semana:
Primeiro dia, apenas esta semana. Escolha um domínio. Apenas um. O que você faz com mais frequência em Claude Code agora. Para mim, isso foi criação de conteúdo. Para você, pode ser revisão de código, pesquisa ou trabalho de design. Escolha um.
Dentro desse domínio, identifique três tarefas. As três coisas que você realmente faz de forma recorrente dentro desse domínio. Não são tarefas teóricas. Coisas que você fez pelo menos quatro vezes no último mês.
Escreva uma habilidade por tarefa. Use o formato acima. Quarenta linhas no máximo. O objetivo é eliminar a variação, não ser inteligente. Salve-os em .claude/skills/.
Escreva um único CLAUDE.md. Um parágrafo por tarefa explicando o que você deseja e onde o resultado deve ir. Não é um livro. Uma página.
Pare aí.
Não construa o cofre ainda. Não crie o painel ainda. Não crie automações. Use a arquitetura por duas semanas. Preste atenção onde ele quebra e onde canta. Ajuste as habilidades com base no que você aprendeu com o uso real.
Depois de duas semanas, se a arquitetura persistir, você começará a sentir ausência de memória. É quando você constrói o cofre. Depois de mais duas semanas, se estiver trabalhando com outra pessoa, você começará a sentir a ausência do painel. É quando você constrói o painel.
O interesse composto dessa abordagem é que cada camada resolve um problema que você já sentiu. Você não está construindo infraestrutura especulativa. Você está fechando lacunas que pode nomear.
O que isso muda na maneira como você usa Claude Code
A mudança mais profunda que o sistema operacional agente produz não é tática. É psicológico.
Antes de eu ter essa estrutura, cada sessão do Claude Code parecia poder seguir qualquer direção. Eu abriria o terminal com uma intenção vaga, digitaria algo e deixaria o modelo fazer o que quisesse. A variação parecia criatividade. Não foi. Foi aleatoriedade com boas relações públicas.
Depois da estrutura, cada sessão tem um formato. Eu abro o Claude Code sabendo qual habilidade será executada, qual subagente irá lidar com ela, em qual pasta a saída irá parar e qual agente downstream irá buscá-la em seguida. A sessão parece menos uma solicitação e mais uma expedição. Não estou mais colaborando com uma máquina caça-níqueis. Estou executando um organograma.
Essa mudança, mais do que qualquer ferramenta ou truque individual, foi o que fez o Claude Code passar de “ferramenta interessante” a “sistema operacional” para mim. A metodologia foi o que me levou até lá. As três camadas são o que o mantém no lugar.
Se você está no estágio das máquinas caça-níqueis agora, aqui está a única coisa que quero que você tire deste post: a saída não é um prompt melhor. É uma arquitetura melhor. Escolha um domínio esta semana. Escreva três habilidades. Escreva um CLAUDE.md. Pare de puxar a alavanca e comece a executar a operação.
Estarei no terminal, mas não vou mais jogar.
Perguntas frequentes
O que é um sistema operacional agente em Claude Code?
Um sistema operacional agentic é uma estrutura estruturada que transforma Claude Code de prompt ad-hoc em um sistema em camadas com três camadas - arquitetura (domínios, tarefas, habilidades, automações), memória (um cofre Obsidian com pastas brutas, wiki e de saída, além de um nível de cofre CLAUDE.md) e observabilidade (um painel que expõe habilidades e automações como botões clicáveis com métricas de uso). Ele usa primitivos nativos do Claude Code, como habilidades, subagentes, ganchos e comandos de barra, em vez de ferramentas personalizadas. Para obter o passo a passo completo da implementação, consulte o detalhamento das três camadas acima.
Preciso de um cofre Obsidian para usar o Claude Code de maneira eficaz?
Não — Obsidian é uma boa opção para a camada de memória, não um requisito. A camada do vault é apenas uma pasta de arquivos markdown com um CLAUDE.md no nível do vault informando ao Claude Code para que serve cada pasta. Você pode implementar a mesma estrutura em qualquer pasta simples; Obsidian adiciona visualização gratuita e amigável, links no estilo wiki e o Web Clipper para ingestão.
Qual a diferença entre uma habilidade Claude Code e um comando de barra?
Uma habilidade é um arquivo SKILL.md com frontmatter YAML que descreve uma tarefa repetível e é carregado automaticamente quando relevante. Um comando de barra é um arquivo markdown em .claude/commands/ que você invoca explicitamente com /command-name. Habilidades são sobre capacidade; comandos de barra são sobre invocação. A maioria dos sistemas bem construídos possui habilidades que são acionadas por comandos de barra.
O que é uma automação Claude Code e como posso construir uma?
Uma automação é uma habilidade executada em um gatilho em vez de esperar que você a invoque. A maneira mais barata de conectar um é por meio de um gancho em .claude/settings.json - um gancho SessionStart ou PostToolUse que dispara o comando de barra relevante. Para automações agendadas, um cron job enviado para claude -p "/your-command" funciona bem. O SDK do agente Claude fornece uma versão programática quando você supera isso.
Quanto custa executar um sistema operacional agente em Claude Code?
A camada um (arquitetura) não custa nada a mais — você está pagando pelo Claude Code de qualquer maneira. A camada dois (cofre) é gratuita se você usar Obsidian. A camada três (painel) é apenas o seu custo de hospedagem – normalmente abaixo de US$ 10/month para uma configuração de operadora única. O custo variável vem das automações: uma automação mal ajustada pode duplicar seu gasto com tokens, e é por isso que limito as automações a quatro e reviso as métricas de token por habilidade semanalmente.
Posso entregar um sistema operacional agente para um colega de equipe não técnico?
É exatamente para isso que a camada três (o painel) foi criada. O terminal é um fosso para os operadores técnicos e um muro para todos os demais. Um painel que expõe habilidades e automações como botões, com saída transmitida para o UI e links de origem de volta para o Obsidian, permite que um colega de equipe não técnico execute o sistema sem nunca tocar no CLI. Sem o painel, a transferência é dolorosa.
Vamos trabalhar juntos
Procurando construir sistemas AI, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.
- Fiverr (compilações e integrações personalizadas): fiverr.com/s/EgxYmWD
- Portfólio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e marca): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
