Conteúdo detalhado
🧑🍳 Skill = 1 verbo; agente = o chef
A diferença essencial: uma skill é um verbo — uma tarefa. Em algum momento, várias skills relacionadas merecem virar uma entidade própria, equipada com julgamento: o agente. Ele não é uma skill única; é um especialista que orquestra várias skills, na ordem certa, decidindo qual usar.
🌱 Novo aqui?
Um agente é um papel — pense num "funcionário" do seu OS, especialista num pedaço do domínio. Orquestrar quer dizer escolher e disparar skills na sequência certa, como um chef que decide qual ferramenta pegar e prova o prato antes de servir. A skill é a faca; o agente é quem decide cortar.
Como ler: a caixa grande (roxa) é o agente; as três menores (ciano) são skills — cada uma um verbo. O que o agente adiciona não é mais um verbo: é o julgamento de qual chamar, quando e com qual revisão.
Por que aprender
Porque confundir skill com agente é o erro que infla custo e fragilidade. Se a tarefa é um único verbo, ela é uma skill — criar um "agente" ali é exagero. O agente só se justifica quando há várias skills para coordenar com julgamento. Guardar essa fronteira evita o anti-padrão que abre a Trilha 1: pular para agentes cedo demais.
Conceitos-chave
🚪 O portão de revisão antes de algo sair
O que torna um agente confiável não é só o que ele faz — é o portão de revisão (review gate) antes de qualquer coisa sair para o mundo. Todo agente que produz algo que vai para fora (um e-mail, um relatório, um lançamento) passa por um ponto de checagem: você, ou outro agente, confere antes do envio.
Como ler: o rascunho do agente não sai direto. Ele passa pela revisão (o losango roxo). "Sim" segue para o mundo; "não" (vermelho) volta ao agente para refazer. Esse laço é o que evita que bobagem chegue ao cliente.
💡 Quem revisa
O revisor pode ser você (humano no loop, dando o OK final) ou outro agente — o revisor cético do tópico 6. Em domínios sérios (dinheiro, jurídico), o portão é obrigatório; é ele que sustenta a confiança no agente.
Por que aprender
Porque um agente sem portão é um risco solto. Com o review gate, você ganha autonomia sem perder controle: o agente trabalha, mas nada irreversível acontece sem passar pela checagem. É o equivalente, na camada de agentes, ao hack read-only da camada de ferramentas — segurança por desenho.
Conceitos-chave
🔼 Promova só uma rotina que você já faz à mão
O critério de quando criar um agente é direto: só promova a agente uma rotina que você já executa à mão hoje, com skills que já existem para ele orquestrar. É o mesmo "comece manual" da camada de skills, um nível acima — agente não é onde você começa, é onde você chega.
✓ Pronto para virar agente
- ✓Você já faz essa rotina à mão, repetidamente.
- ✓Já existem skills para o agente orquestrar.
- ✓Há um portão de revisão claro antes do envio.
✗ Agente-teatro
- ✗Agente para algo que você nunca fez à mão.
- ✗Nenhuma skill embaixo — só promessa.
- ✗Parece poderoso, mas não entrega nada confiável.
⚠️ O erro nº1 do curso, de novo
A maioria das pessoas começa pela camada de agentes — a última que deveriam tocar. Um agente é um "funcionário" que só faz sentido contratar depois que você tem contexto, skills e regras construídos. Sem essa base, o agente não tem em que se apoiar.
Por que aprender
Porque é o freio contra o entusiasmo. Agentes são a parte "legal" e por isso a tentação de começar por eles é enorme. Promover só rotinas reais, com skills prontas embaixo, garante que cada agente seja um trabalhador de verdade — não um enfeite que impressiona e falha.
Conceitos-chave
🔀 Agente vs workflow vs sub-agentes descartáveis
Nem todo trabalho merece um "funcionário" permanente. Antes de criar um agente, pergunte: você precisa mesmo de um agente, ou só de um processo que roda de vez em quando? Uma auditoria pontual de centenas de arquivos talvez seja um workflow dinâmico, não um agente fixo. E quando precisa de mais força bruta, você sobe sub-agentes descartáveis.
Um papel permanente que você "emprega". Faz sentido para rotinas recorrentes com julgamento — ex.: o agente de resposta.
Um processo pontual, montado para uma tarefa específica — ex.: auditar 100s de arquivos uma vez. Não precisa de "funcionário".
Quando você precisa de muito mais firepower, sobe vários agentes throwaway para a carga e depois os descarta.
🔎 A escala da escolha
Pense em escala: tarefa única e grande → workflow. Rotina recorrente com julgamento → agente fixo. Pico de carga que exige paralelismo → sub-agentes descartáveis. Escolher a forma certa evita criar um "funcionário" permanente para um trabalho que acontece uma vez.
Por que aprender
Porque "agente" não é a única — nem sempre a melhor — resposta. Tratar tudo como agente fixo enche o OS de papéis que raramente rodam. Distinguir agente, workflow e sub-agentes te faz aplicar a forma certa para cada carga, economizando contexto e manutenção.
Conceitos-chave
🗂️ Exemplos: agente de resposta e de deep research
No Freedom OS, os agentes nasceram de rotinas que o autor já fazia à mão. Eles mostram a camada viva: cada agente é um "funcionário" com um trabalho claro, e novos vão surgindo conforme o OS amadurece.
Por que aprender — como os agentes apareceram
Agente de resposta
Tem acesso ao Gmail (via CLI). Quando o autor manda "varra meu e-mail", ele olha as mensagens das agências, junta os 10 documentos certos e rascunha as respostas — o autor só confere e envia (review gate).
Agente de deep research
Monitora constantemente mudanças nas leis de passaporte e residência. Quando um país muda a legislação (ex.: a nova lei tributária da Turquia), ele sinaliza que vale revisitar aquela cidadania.
Um OS vivo
Cada parte é muito intencional, com review gates. Os agentes não nasceram de uma vez: foram empregados um a um, conforme as rotinas se firmavam.
💡 O fio condutor
Repare: o agente de resposta usa uma CLI (Gmail) e várias skills (buscar documento, rascunhar). Ele só foi possível porque as camadas de baixo — contexto, skills, ferramentas — já existiam. É a Trilha 3 inteira convergindo num agente.
Por que aprender
Porque exemplos reais tiram o agente do abstrato. Eles mostram que um agente é um trabalhador com um recorte claro — não uma "IA mágica" — e que ele se apoia nas skills e ferramentas que você já construiu. É o seu modelo para desenhar o primeiro agente do seu OS.
Conceitos-chave
🛡️ Review gates: o revisor cético
O portão do tópico 2 ganha um nome quando o revisor é outro agente: o revisor cético (advogado do diabo). É um agente desenhado para "te xingar antes do contador" — ou do cliente: ele confere o trabalho com olhar adversarial antes de qualquer coisa sair.
✓ Com revisor cético
- ✓Você é "roasted" pelo seu OS antes do erro vazar.
- ✓Menos idas e vindas com o contador/cliente.
- ✓O agente busca a fonte do problema antes de você.
✗ Sem gate adversarial
- ✗O erro só aparece quando o contador reclama.
- ✗Retrabalho e desgaste com quem recebe.
- ✗O agente "vendedor de si mesmo" não se questiona.
🔎 Caso real
No Tax OS, antes de enviar um ledger ao contador, um revisor cético checa se há algo estranho. Em consultoria, o revisor pode assumir a voz do cliente — um agente nomeado com o contato, primado por todas as reuniões sintetizadas — e às vezes você quer vários revisores adversariais, não um.
Por que aprender
Porque o revisor cético é o que transforma autonomia em confiança. Ele baixa a chance de erro chegar a quem importa, reduz interações chatas (que matam o que você ama fazer) e te deixa delegar de verdade. É o review gate na sua forma mais poderosa.
Conceitos-chave
🧠 Modelos mais espertos → menos instrução, talvez nenhum agente
Um ponto que muda a forma como você cuida da camada: agentes mudam com o tempo. Conforme os modelos ficam mais espertos, o mesmo agente precisa de menos instrução para o mesmo resultado — ou pode deixar de ser necessário, porque o Claude Code ou o Codex já faz aquilo nativamente.
💡 Revisite, não acumule
Pergunte de tempos em tempos: "este agente ainda precisa de toda essa instrução? Ele ainda precisa existir, ou o modelo já resolve sozinho?". Tratar agentes como permanentes para sempre é o caminho do inchaço; revisitá-los mantém o OS enxuto.
🔎 O que decai por domínio
Lembre da Trilha 1: cada camada apodrece num ritmo. Agentes mudam porque os modelos evoluem; identidade tende a ser mais estática; contexto pode precisar de atualização mensal. Saber o que decai (e quando) é parte de manter o OS vivo.
Por que aprender
Porque te protege do acúmulo. Se você nunca revisita agentes, fica com uma frota de "funcionários" que talvez o modelo novo já dispense. Auditar periodicamente — menos instrução? ainda necessário? — é o que mantém a camada de agentes proporcional ao que você realmente precisa.
Conceitos-chave
📄 Copy-run: o esqueleto de um AGENT.md
Hora de esboçar o seu primeiro agente. Um agente vive num arquivo AGENT.md (na pasta agents/ do OS) com partes claras: o papel, as skills que orquestra, a ordem, o review gate e os limites. Copie o esqueleto abaixo e preencha para uma rotina que você já faz à mão.
Copie e preencha — agents/<nome>/AGENT.md
Objetivo: esboçar um agente que orquestra skills que você já tem, com um portão de revisão antes de qualquer envio.
Crie o arquivo e troque o que está entre < >:
--- name: <nome-do-agente> role: <o funcionário que ele é, ex.: "agente de resposta de e-mail"> --- ## Quando empregar <a rotina que eu JÁ faço à mão hoje e quero delegar> ## Skills que orquestra (já existem) - /<skill-1> — <o que faz> - /<skill-2> — <o que faz> ## Ordem de operação 1. <primeiro passo> 2. <segundo passo> 3. produzir um RASCUNHO (nunca enviar direto). ## Review gate (obrigatório) - nada sai sem revisão: <eu confiro / um revisor cético confere>; - se reprovar, voltar ao passo <N> e refazer. ## Limites (never) - <ex.: nunca enviar e-mail sem meu OK>; - <ex.: só LER do CRM, nunca escrever>. ## Done-check - <como sei que o agente fez um bom trabalho>.
Como verificar: leia o arquivo e confirme as cinco partes — papel, skills, ordem, review gate e limites. Se faltar o review gate ou se alguma "skill" não existir de verdade na sua pasta skills/, o agente ainda não está pronto: volte e construa a base antes.
💡 Dica
O bloco "produzir um RASCUNHO (nunca enviar direto)" + o review gate são o coração da segurança. Sem eles, você tem um agente que age sem freio. Comece sempre com o portão ligado e só relaxe quando confiar — nunca o contrário.
Por que aprender
Porque fecha a Trilha 3 com um artefato seu. Ao preencher este esqueleto, você junta as três camadas de ação — skills (3.1), ferramentas (3.2) e agentes (3.3) — num único papel com julgamento e revisão. Daqui você segue para a Trilha 4, onde o /os-coach constrói tudo isso com você, camada por camada.
Conceitos-chave
✅ Resumo do módulo
Próxima trilha:
Trilha 4 — Passo a passo: construa o seu OS com o /os-coach 🛠️