📋 Critérios para criar um agente
Agente não é sinônimo de IA. Um agente é uma entidade autônoma com identidade, ferramentas, contexto e SLA. Criar um agente sem necessidade real é criar complexidade que você vai manter para sempre. O critério de criação é rigoroso.
✅ Os 4 critérios obrigatórios
- 1. Carga real e recorrente
A tarefa acontece regularmente (diário, semanal, a cada evento). Não é one-off. Se é pontual, use skill ou prompt direto. - 2. Função distinta e não coberta
Nenhum agente existente cobre essa função. Criar um agente que duplica o que outro já faz é desperdício. - 3. Complexidade que supera skill
A tarefa requer decisão, memória ou contexto que não cabe numa skill. Skills são stateless; agentes têm estado. - 4. SLA definível e mensurável
Você consegue dizer: "esse agente entrega X em Y segundos com Z% de precisão". Sem SLA, não há como saber se funciona.
💡 A pergunta certa
Antes de criar um agente, pergunte: "Eu precisaria contratar uma pessoa para fazer isso full-time?" Se sim, pode virar agente. Se não — se seria trabalho de meio período ou eventual — fica como skill ou prompt.
🚫 Sinais de NÃO criar agente
Tão importante quanto saber quando criar é saber quando não criar. Os anti-padrões de criação de agente são comuns e custosos — cada agente desnecessário é manutenção, custo e complexidade que nunca some.
Sinais de alerta (NÃO criar)
- ✗"Pra eu ter IA nisso também"
- ✗Tarefa acontece menos de 1x/semana
- ✗Outro agente já cobre 80% do caso
- ✗Não consegue descrever o output em 1 frase
- ✗Uma skill resolve sem estado
- ✗Ninguém vai usar os outputs
Alternativas antes do agente
- →Skill no Claude Code (stateless, simples)
- →Prompt template reutilizável
- →Hook que roda script existente
- →Workflow n8n sem LLM
- →Extensão de agente existente
- →Silver Platter que outro agente lê
🪜 Skill → agente: o caminho de promoção
O caminho correto não é "criar agente desde o início". É começar como skill, promover quando justificado. A maioria das necessidades começa como skill simples. Só vira agente quando a skill cresce em complexidade e a necessidade de estado fica óbvia.
O caminho de promoção
- Nível 1Prompt direto — você faz manualmente, sem automação.
- Nível 2Skill — automatiza o prompt em um slash command reutilizável.
- Nível 3Skill com contexto — skill lê Silver Platters para ter contexto sem custo extra.
- Nível 4Agente — quando a skill virou família de skills + decisão entre elas + estado persistente.
Marco: do prompt ao CFO Bot
Marco começou pedindo análise financeira manualmente (Nível 1). Criou skill /analise-financeira (Nível 2). Adicionou leitura de Silver Platters do /finance (Nível 3). Quando a análise precisou comparar com semanas anteriores e lembrar de alertas, promoveu para CFO Bot com estado (Nível 4). Cada promoção foi justificada por necessidade real.
📐 O custo real de um agente
Agentes não são gratuitos. O custo não é só tokens — é custo de manutenção, custo de debugging, custo de coordenação. Antes de criar, calcule o custo total de propriedade (TCO) do agente ao longo do tempo.
Componentes do custo de um agente
- Custo de tokens — cada execução consome tokens. Volume × frequência × custo por token.
- Custo de manutenção — AGENTS.md precisa de atualização quando o negócio muda. Estimativa: 2h/mês por agente.
- Custo de debugging — quando falha, alguém precisa investigar. Mais agentes = mais pontos de falha.
- Custo de coordenação — o CoS precisa conhecer e gerenciar cada agente adicionado.
- Custo de drift — agente desatualizado gera outputs errados silenciosamente.
⚠️ Sana e o jardim de agentes
Sana criou 12 agentes em 2 meses, animada com as possibilidades. Seis meses depois: 7 não rodavam mais por AGENTS.md desatualizado, 3 se sobrepunham, 2 funcionavam bem. Custo: 15h/semana de manutenção. Aprendizado caro: agente que não tem dono ativo vira dívida técnica.
🗂️ Inventário e governança de agentes
Uma operação saudável tem um inventário vivo de seus agentes. Quais existem, qual função, quem é o dono, quando foi atualizado pela última vez, qual o custo mensal estimado. Sem esse inventário, você não sabe o que tem.
Template de inventário de agentes
# Inventário de Agentes — [Nome da Operação]
Última atualização: 2026-05-15
| Agente | Função | Dono | Freq. | Custo/mês | Última rev. |
|-------------|-----------------|--------|---------|-----------|-------------|
| cfo-bot | Análise KPI fin. | Marco | diária | $12 | 2026-05-01 |
| cmo-bot | Voz do cliente | Sally | semanal | $8 | 2026-04-20 |
| ops-bot | Monitor SLAs | Marco | diária | $6 | 2026-05-10 |
| researcher | Pesquisa ad-hoc | Sana | on-demand | $var | 2026-05-12 |
## Regras de governança
- Revisão mensal de todos os agentes
- Agente sem dono ativo = candidato a deprecação
- Novo agente exige aprovação + critérios documentados🏁 Hire-when-needed: o princípio final
O princípio que resume tudo nesta trilha: hire-when-needed. Agentes são como funcionários — você não contrata dez antes de ter dez tarefas distintas e recorrentes para dez pessoas. Contrata um de cada vez, quando a necessidade é real e contínua.
O checklist final antes de criar
- □Tentei resolver com skill primeiro e não foi suficiente?
- □A tarefa ocorre regularmente (≥1x/semana)?
- □Nenhum agente existente cobre essa função?
- □Consigo definir o SLA em uma frase?
- □Há um dono identificado que vai manter?
- □O custo mensal estimado é justificado pelo valor?
💡 A conclusão da Trilha 4
Você chegou ao fim da Camada de Trabalhadores. Sabe por que multi-agent supera single-agent (90,2%), como estruturar o chief-of-staff, como definir especialistas, como usar A2A e cross-framework, e — mais importante — quando NÃO criar agente. Esse último ponto é o que separa o arquiteto do acumulador de complexidade.
📋 Resumo do Módulo
Próxima Trilha:
T5 — Automação: hooks, schedules, observabilidade e o trabalho invisível que mantém tudo rodando