Conteúdo detalhado
🧱 As 6 camadas — visão geral
Todo AIOS, por mais diferente que seja o domínio, é montado a partir das mesmas 6 camadas. Pensar em camadas é o que tira o OS do "balde de prompts soltos" e o transforma num sistema com partes nomeadas — cada uma com um papel claro, que você constrói e audita separadamente.
🌱 Novo aqui?
Uma camada é só um tipo de coisa que entra no seu OS — um agrupamento. O "gráfico de pizza" é a metáfora do autor: imagine a soma de tudo que compõe um OS como uma pizza inteira, e cada camada como uma fatia. A sacada do módulo é que as fatias têm tamanhos diferentes e mudam conforme o domínio. Cada termo aqui (Identidade, Substrato, Regras…) é definido em detalhe no Módulo 1.3 (o glossário) — aqui você só pega o mapa.
Como ler: as 6 fatias somam 100%, mas nenhuma é igual à outra. Neste exemplo (um OS tributário), o Contexto domina porque o domínio vive de leis e documentos. Em outro domínio, a maior fatia seria outra. As fatias verdes são a fundação; as azuis, a ação — você vê essa divisão no Tópico 5.
As 6 fatias, em uma frase cada
Por que aprender
Porque é o esqueleto do curso inteiro. As Trilhas 2 e 3 são, literalmente, uma camada por módulo; a Trilha 4 te faz construí-las em ordem. Se você sai daqui com o mapa das 6 camadas na cabeça, todo o resto vira "preencher as fatias".
Conceitos-chave
🍕 Por que a pizza NÃO é dividida igual
A frase exata do autor é direta: "o gráfico de pizza não está dividido uniformemente". As 6 camadas existem em todo OS, mas o peso de cada uma depende do domínio. Tratar todas com o mesmo esforço é o jeito mais rápido de gastar tempo no lugar errado.
✗ Pizza igual (o erro)
- ✗Dar a mesma atenção às 6 camadas, "pra ser completo".
- ✗Copiar a distribuição de um OS pronto para outro domínio.
- ✗Polir agentes enquanto o contexto, que é o gargalo, está vazio.
✓ Pizza sob medida (o caminho)
- ✓Perguntar: qual camada importa mais aqui?
- ✓Investir o esforço na fatia que carrega o domínio.
- ✓Deixar fatias pequenas pequenas — e tudo bem.
💡 As duas perguntas que guiam a fatia
Antes de construir qualquer OS, faça as duas perguntas-fio do curso: "qual camada importa mais aqui?" e "o que vai apodrecer mais rápido?". A primeira diz onde investir; a segunda, o que vai exigir manutenção. Juntas, elas desenham a sua pizza melhor que qualquer template.
Por que aprender
Porque protege seu tempo. A diferença entre um OS que "ficou bom no fim de semana" e um que travou está quase sempre em ter investido na fatia certa. Aceitar que a pizza é desigual é o que te deixa priorizar com critério em vez de tentar fazer tudo por igual.
Conceitos-chave
🪜 A ordem que funciona
As fatias podem ter qualquer tamanho, mas a ordem de construção é quase sempre a mesma: você ergue a fundação antes de pendurar a capacidade. Em uma linha: Identidade → Substrato & Contexto → Regras & Ganchos → Habilidades → Ferramentas → Agentes. Não é por acaso que as Trilhas 2 e 3 deste curso seguem exatamente essa sequência.
A sequência, passo a passo
Identidade
Defina quem o OS é antes de tudo. Sem alma, as camadas seguintes não têm a quem servir.
Substrato & Contexto
Organize e destile o conhecimento do domínio. É o que faz o OS ser especialista, e não genérico.
Regras & Ganchos
Ponha as cercas: o que sempre fazer, o que nunca fazer, e onde travar de forma determinística.
Habilidades
Capture os verbos que você mais repete. Agora há base sólida para empacotar processos.
Ferramentas & Conexões
Decida os fios pra fora — skill, CLI, MCP ou API — só quando uma skill precisa tocar o mundo.
Agentes
Por último: papéis com julgamento que orquestram as skills. Só fazem sentido quando há skills para orquestrar.
💡 A regra de ouro da ordem
Bastidores primeiro, capacidade depois. Você não dá braços (agentes) a alguém que ainda não sabe quem é (identidade) nem o que sabe (contexto). A ordem existe para impedir que você construa o telhado antes das paredes.
Por que aprender
Porque a ordem evita retrabalho. Quem começa pelo fim (agentes) acaba refazendo tudo quando percebe que faltava a base. Seguir a sequência te dá um OS utilizável em cada parada — e cada camada se apoia na anterior.
Conceitos-chave
⚠️ O erro nº 1: pular pra Agentes cedo demais
O autor é categórico: agentes são a última camada, não a primeira — e "a maioria das pessoas pula para agentes cedo demais". Agente é a parte brilhante e empolgante, então é natural querer começar por ela. Mas um agente sem fundação é um trabalhador esperto a quem ninguém explicou o trabalho.
🌱 Novo aqui?
Um agente é um "papel com julgamento": em vez de fazer um passo fixo, ele decide quais habilidades (verbos prontos) usar e em que ordem, normalmente com um ponto de revisão antes de algo sair. Por isso ele depende das camadas de baixo: sem skills para orquestrar, sem regras para respeitar e sem contexto para consultar, o agente não tem com o que trabalhar. O glossário (Módulo 1.3) define agente com mais calma.
✗ O atalho que dá errado
- ✗Criar um "agente que faz tudo" antes de ter qualquer skill.
- ✗Esperar julgamento de um OS que não tem contexto do domínio.
- ✗Dar autonomia sem regras — o agente erra rápido e em escala.
✓ O caminho que sustenta
- ✓Primeiro identidade, contexto e regras — a base estável.
- ✓Depois 1 ou 2 skills reais, das tarefas que você mais repete.
- ✓Só então um agente, para orquestrar o que já existe e funciona.
⚠️ O sintoma típico
"Montei um agente incrível e ele dá respostas genéricas / faz besteira." Quase sempre o problema não está no agente — está nas fatias de baixo que ficaram vazias. A correção não é mexer no agente: é voltar e preencher contexto e regras.
Por que aprender
Porque esse é, segundo o autor, o erro mais comum de todos. Saber dele de antemão te poupa de construir o brinquedo brilhante primeiro e ter que desmontar tudo depois. Você ganha paciência para fazer a parte "chata" que faz a parte legal funcionar.
Conceitos-chave
🏗️ Camadas estáticas vs dinâmicas
As 6 camadas se separam em dois grupos. As três primeiras são a fundação (estática) — o "back of house", os bastidores que mudam devagar. As três últimas são a ação (dinâmica) — os braços que executam. É exatamente por isso que este curso tem uma Trilha 2 (base) e uma Trilha 3 (capacidade).
Como ler: a coluna verde (fundação) é o que você constrói primeiro e mexe pouco; a coluna azul (ação) é o que executa e evolui sempre. A seta lembra a regra: a base sustenta a ação — sem a esquerda sólida, a direita não funciona.
Por que aprender
Porque essa divisão organiza sua cabeça e o curso. Quando você sabe que está mexendo na fundação (algo que muda devagar) ou na ação (algo que evolui sempre), você calibra quanto esforço e quanta manutenção cada parte merece.
Conceitos-chave
🧭 Como a distribuição muda por domínio
A melhor prova de que a pizza é desigual é ver domínios reais lado a lado. Cada um tem uma fatia que pesa mais — e isso muda totalmente onde você investe o esforço. Esta é uma prévia da Trilha 5, onde cada domínio vira um módulo completo.
| Domínio | Fatia que domina | Por quê |
|---|---|---|
| Tax OS 🧾 | Contexto (~34%) | Vive de leis, auditorias e compêndios — muito material para destilar. |
| Sales OS 📈 | Ferramentas + Skills | ~30% contexto, mas o peso vai pra scrapers, enriquecimento e qualificação. |
| Content OS 🎬 | Equilibrado | Fábrica de títulos, briefs e repurpose — fatias mais parelhas. |
| Consulting OS 💼 | Regras & Ganchos | Voz do cliente e portões de revisão exigem controle de qualidade pesado. |
| Freedom OS 🗽 | Modelos locais | Dados sensíveis (certidões, passaportes) não vão pra nuvem. |
💡 O padrão por trás dos números
Não decore as porcentagens — elas são exemplos. O que importa é o padrão: domínios cheios de conhecimento pesam em Contexto; domínios de prospecção pesam em Ferramentas; domínios sob risco pesam em Regras. Achar a fatia dominante do seu domínio é o trabalho.
Por que aprender
Porque te dá repertório. Ao ver cinco formas diferentes da mesma pizza, você passa a reconhecer a sua própria distribuição mais rápido — e entra na Trilha 5 já sabendo onde cada domínio costuma concentrar peso.
Conceitos-chave
🔀 "Order of operations": por onde começar
A ordem do Tópico 3 (Identidade primeiro) é o padrão, não uma lei rígida. Na prática, às vezes você precisa organizar o contexto antes de escrever a identidade — porque só depois de ver o material do domínio você consegue dizer com clareza quem o OS é. Isto é "order of operations": a sequência sensata, com exceções conscientes.
🌱 Novo aqui?
"Order of operations" é uma expressão emprestada da matemática (a ordem em que você resolve uma conta). Aqui significa a ordem em que faz sentido construir as camadas. O ponto é: existe uma ordem padrão boa, mas o seu domínio pode pedir um pequeno ajuste — e tudo bem, desde que seja uma escolha pensada, não bagunça.
✓ Identidade primeiro quando…
- ✓Você já conhece bem o domínio e o público.
- ✓O OS é mais sobre tom e regras do que sobre dados.
- ✓Você consegue descrever a alma sem consultar arquivos.
↔ Contexto primeiro quando…
- •Há um "caminhão de lixo em chamas" de arquivos pra organizar.
- •A identidade só fica clara depois de ver o material.
- •O domínio é denso em conhecimento (ex.: tributário, jurídico).
💡 Como o curso resolve isso pra você
Na Trilha 4, a skill /os-coach decide a "order of operations" no seu lugar: ela faz 2-3 perguntas e escolhe se começa pela identidade ou pelo contexto. Você não precisa acertar a ordem de cabeça — só precisa saber que ela existe e por que às vezes muda.
Por que aprender
Porque remove a rigidez. Quem trata a ordem como lei trava quando o domínio não encaixa. Entender que é "padrão com exceções conscientes" te deixa adaptar sem culpa — exatamente o espírito de "arte mais que ciência" do Módulo 1.1.
Conceitos-chave
✅ Resumo do módulo
Próximo módulo:
1.3 — Glossário essencial: cada termo definido com frase + analogia 📖