OS de Agentes — Do Ponto A ao Ponto B

OS de Agentes é um sistema operacional baseado em agentes de IA que automatiza e controla operações de uma empresa. No PD Framework, os squads correspondem às áreas — Comercial, Marketing, CS, Dev, Infra, Financeiro, Produto — cada um com CLAUDE.md próprio, memória (STATE.md), skills específicas e workers determinísticos rodando em cron.

A diferença para automação isolada, chatbot ou RPA é a integração. Um chatbot responde perguntas. Uma automação executa uma tarefa. Um RPA replica cliques. Um OS de Agentes tem contexto compartilhado, memória entre sessões, agentes especializados que se coordenam e um orquestrador central (no PD Framework, o Stamper — persona baseada em "Doug Stamper" de House of Cards, Chief of Staff implacável).

O que faz o sistema funcionar não é o modelo — é a arquitetura. O mesmo Claude Code opera diferente quando está dentro de um OS bem construído versus quando é usado como chat solto. A previsibilidade, a memória e a divisão de trabalho vêm do OS, não do modelo por baixo.

Harness agnóstico é uma arquitetura onde o mesmo OS roda em qualquer runtime — Claude Code, Codex, OpenCode, Hermes, futuros harnesses que ainda não existem — sem dependência de plataforma. Felipe demonstra ao vivo o PD Framework operando em Claude Code e em OpenCode a partir da mesma fonte de estado.

As três primitivas que viabilizam agnosticismo: Markdown como contexto (CLAUDE.md, STATE.md, foundation docs), scripts Python no core (hooks, workers, motor de skills), skills como diretório (SKILL.md com steps declarativos). Nenhuma dependência de API proprietária, nenhum código em linguagem específica do harness.

Por trás disso vive um contrato de runtime com capacidades explícitas — abrir sessão, escrever memória, proteger main, fechar sessão, executar skill, chamar subagente. Cada harness implementa o contrato do seu jeito. O framework não sabe quem está executando. Felipe: "Você não precisa de 3 frameworks diferentes. Precisa de 1 contrato que qualquer runtime implementa."

Conceito cunhado pelo fundador da OpenRouter e explorado por Felipe na aula: modelos diferentes foram treinados com dados diferentes, arquiteturas diferentes, objetivos diferentes — logo, têm personalidades e forças distintas. Tratar todos como intercambiáveis é o erro estratégico mais caro do mercado atual.

Exemplos práticos que Felipe usa: Grok é o melhor para copywriting (treinado com dados do Twitter, tom coloquial nativo). GLM 5.2 é excelente para classificar bugs em P1/P2/P3 (rigor lógico chinês). Qwen entra no debate de code review (perspectiva ortogonal ao GLM). GPT-o1 (Sol) é o mais cuidadoso para tarefas que exigem precisão. Claude Fable 5 fez arquitetura complexa antes de ser banido para não-EUA.

A implicação prática é multi-model como padrão. Usar Claude Code para orquestrar, GLM para classificar código, Qwen para debater review, Grok para copy, Gemini para imagem — cada tarefa com o modelo certo. Quem padroniza em um só modelo por conveniência paga mais caro e recebe resultado pior. Quem monta o time de IAs certo tem vantagem competitiva estrutural.

A Cascata Linear é a sequência canônica que Felipe defende como obrigatória antes de qualquer código ser escrito. Cada etapa produz um artefato que serve de contrato para a próxima — nenhum agente executa sem o artefato anterior estar validado.

Briefing captura contexto do negócio: quem, o quê, por quê, quando, quanto. PRD (Product Requirements Document) descreve o produto: features, jornadas, critérios de sucesso — o que será construído, sem detalhe técnico. RFC (Request for Comments) especifica a implementação: contratos, dados, integrações, restrições — como será construído. Epics quebram o RFC em blocos de trabalho grandes. Stories quebram os Epics em unidades executáveis por sessão.

Cada etapa reduz alucinação porque estreita o espaço de decisão do agente. Sem cascata, você pede feature genérica, o agente inventa detalhes, você descobre no final que ele decidiu por você. Com cascata, o agente executa contra o contrato: qualquer desvio vira falha explícita. Felipe: "PRD é a feijoada. RFC é como cozinhar o feijão."

Gate de Babysit é o padrão que Felipe usa para revisar código gerado por agente antes do merge. Em vez de humano revisar linha a linha (não escala) ou aceitar cegamente (bugs em produção), o código passa por um consenso multi-modelo: GLM 5.2 classifica bugs em P1/P2/P3, Qwen roda em paralelo, o consenso decide.

P1 é bloqueante — bug lógico, vulnerabilidade, quebra de contrato. P2 é sério — regressão silenciosa, edge case não tratado. P3 é estilo — nome ruim, comentário faltando. O merge só acontece com P1 zerado e P2 crítico corrigido. Não zerou, o agente refatora e o gate roda de novo — até 3 iterações, depois escala para humano.

A vantagem sobre code review humano puro: consistência (o gate não cansa), velocidade (roda em minutos), custo (chamada de API vs hora de sênior), auditoria (todo achado fica versionado). A vantagem sobre confiar cegamente na IA: você tem uma segunda e terceira opinião de arquiteturas diferentes antes de subir código em produção.

Skill é um prompt estruturado, encapsulado num arquivo Markdown, invocável com `/nome`. Não é mágica, não é framework proprietário, não é produto que precisa ser comprado. É texto. Felipe tem 275 skills no seu OS — todas escritas por ele a partir do trabalho real, versionadas no Git, iteradas ao longo do tempo.

A armadilha comercial da vez é vender pacote de skills como se fosse produto. Felipe é direto na aula: comprar pacote de skills é a nova versão de comprar pacote de curso — monetiza quem não sabe o que está comprando. A próxima onda será vender acesso a MCP com o mesmo argumento. A lógica é sempre a mesma: promessa de atalho para quem não quer entender.

Antídoto: crie suas skills a partir do trabalho real. Toda vez que você repetir uma sequência de passos, transforme em skill. Toda vez que uma decisão for repetível, encapsule. Suas skills serão melhores que qualquer pacote comprado porque refletem sua operação, sua linguagem, seu contexto. E ficam sob seu controle — sem lock-in de fornecedor.

Memória é o que separa agente de chatbot. Sem memória, cada sessão começa do zero — o agente esquece o que decidiu ontem, repete perguntas, ignora convenções. Com memória bem estruturada, o agente lembra decisões, respeita padrões e evolui junto com o negócio.

No PD Framework a memória vive em duas camadas versionadas em Git. STATE.md por squad no formato bracketed L1/L2/L3 (agora, em progresso, decisões/backlog). Memory files Markdown com frontmatter por tópico (user, feedback, project, reference). Tudo comita em Git — múltiplas máquinas, múltiplos agentes, todos leem a mesma verdade.

A escolha por Git como storage é deliberada. GitHub como fonte central. Histórico, blame, diff, branches — o toolset já resolveu problema de sincronização e versionamento há 20 anos. Adicionar SQLite ou banco proprietário como camada de memória é reinventar o problema. Felipe: "GitHub é a memória compartilhada entre todas as máquinas do OS."

Regra dura de Felipe: agente de IA com tool use NUNCA roda direto na VPS de produção. A infraestrutura do PD Framework tem cinco máquinas coordenadas — notebook do Felipe, notebook do Luiz (quando ativo), VPS Dev, VPS Master (produção, workers determinísticos), CAIXA1 (VPS Local Windows). A VPS Master fica isolada: só scripts determinísticos, sem agente com tool use.

A razão é dura: alucinação pode deletar container, remover arquivo crítico, executar destrutivo silencioso. O risco é real e já aconteceu em outros ambientes — Felipe cita casos públicos. Um erro do agente com acesso amplo a produção custa horas de recuperação e pode custar o negócio.

O padrão de mitigação: agente roda no notebook ou na VPS Dev, escreve código, gera artefatos. Deploy em produção passa por PR, review humano e worker determinístico que aplica a mudança. Operações destrutivas exigem confirmação textual explícita. Credenciais nunca em arquivo commitado — sempre via 1Password Service Account. Backup automatizado em disco separado da produção. Segurança não é feature — é postura arquitetural.

Felipe defende que o sistema operacional já existe na cabeça de todo empreendedor. O que falta é externalizar. O primeiro passo concreto não é escolher ferramenta, não é decidir modelo, não é assinar plataforma. É listar tudo que você faz no dia a dia, dividir em passos e transformar em arquivos ".md".

Uma sessão típica de bootstrap: abre um documento em branco, escreve as áreas do negócio (uma linha por área), sob cada área escreve os processos recorrentes (contato inicial, follow-up, envio de proposta, cobrança, onboarding, publicação de conteúdo). Cada processo vira um arquivo Markdown descrevendo os passos. Esse é o seu OS embrionário — ainda sem nenhum agente.

Só depois de ter o OS em Markdown você escolhe harness (Claude Code, OpenCode) e decide qual processo virar skill primeiro. Ferramenta é a última decisão, não a primeira. Felipe: "Frustração com IA quase sempre vem de pular entre ferramentas sem objetivo definido. Comece com objetivo, escreva o processo, depois escolha a ferramenta que executa."

A pergunta que fecha a aula não é técnica — é comercial. Felipe é direto: se a IA não está retornando pelo menos 10x o valor investido, o problema não é técnico. É que você está criando e não vendendo. A maior parte dos "empreendedores de IA" gasta meses construindo, adiando venda, esperando o produto ficar perfeito.

Segundo insight: o cliente define o público, não o fundador. O Cadencia foi reposicionado de PMEs para agências e freelancers de marketing porque Felipe foi vender e descobriu quem realmente comprava. Nenhum plano de negócio escrito antes teria acertado o público real — só o mercado responde essa pergunta.

Terceiro insight, com fricção intencional: "A melhor forma de conhecer seu público é vendendo. Plano de negócio é papo de pessoa preguiçosa com medo de botar a cara a tapa." A frase gera reação, mas o ponto é sério — o custo de escrever plano perfeito antes de vender uma unidade é infinitamente maior do que aprender com as primeiras 10 vendas reais.