🆔 Identidade × prompt
Um prompt é uma instrução temporária: "analise este contrato", "refatora essa função", "gere o relatório mensal". Quando termina, vai embora. Identidade é diferente: é o que o agente é em todas as sessões, em todos os prompts, independentemente do que você pede. É o substrato que persiste quando o contexto da conversa se apaga.
🔄 A diferença fundamental
- Prompt: instrução única, volátil, muda a cada sessão, sem persistência garantida.
- Identidade: contrato persistente, versionado em git, define quem o agente é e o que nunca muda.
- Na prática: prompt diz "o que fazer agora". Identidade diz "quem você é sempre".
A analogia do passwd
No Unix, o arquivo /etc/passwd define quem os usuários são — nome, home, shell — independentemente do que eles digitam. O CLAUDE.md é o passwd da era agêntica: define a identidade do agente antes de qualquer interação. Você pode dar mil prompts diferentes; a identidade persiste em todos eles.
📛 Nome, função e SLA
A "carteira de identidade" de um agente vai além do nome. Ela define função, jurisdição e SLA — os três pilares que transformam um LLM genérico em um colaborador com papel definido. Um agente sem essa carteira é como um funcionário sem contrato: você não sabe o que ele faz, não sabe onde ele opera, e não tem como cobrar performance.
Exemplos de identity cards
- CFO Bot (Marco): "Analiso dados financeiros do e-commerce. Acesso somente /finance/. Respondo em até 2 min. Não tomo decisões de pagamento sem aprovação."
- Legal Researcher (Sally): "Pesquiso jurisprudência e legislação. Acesso /cases/cliente-ativo/ e bases legais. Respondo em até 5 min. Não ofereço conselho jurídico — análise apenas."
- Clinical Assistant (Dra. Sana): "Apoio diagnóstico diferencial. Acesso somente /data/clinical/paciente-ativo/. Nunca externalizo dados. Sempre recomendo confirmação médica."
💡 Por que SLA importa
SLA não é só expectativa de tempo — é um contrato de qualidade. Define quando o agente deve escalar para humano (complexidade acima do SLA), o que é aceitável como resposta (análise vs decisão) e como medir performance (tempo médio, % escaladas).
🔑 Identidade vs autenticação
Na segurança de sistemas, confundir identidade com autenticação é uma fonte clássica de vulnerabilidades. Identidade é "quem o agente é" — definido pelo CLAUDE.md, estável, persistente. Autenticação é "como ele prova que é quem diz ser" — tokens, API keys, certificados. E autorização é "o que ele pode fazer" — permissões, jurisdição. Os três são distintos e precisam ser gerenciados separadamente.
Os três pilares — identity × authn × authz
- Identity (quem sou): CLAUDE.md, nome, função, jurisdição. Definido por configuração, não por credencial.
- Authentication (como provo): API keys, OAuth tokens, certificados. Secrets em vault, nunca em CLAUDE.md.
- Authorization (o que posso): settings.json, permissões de filesystem, allowlist/denylist.
⚠️ Vulnerabilidade clássica
Colocar tokens de autenticação no CLAUDE.md para "facilitar". O CLAUDE.md vai para o git. O git vai para o repositório. O repositório pode ser público. Resultado: credenciais vazadas, sistema comprometido. Identity e authentication vivem em lugares diferentes por boas razões.
📇 Agent Cards (A2A)
O protocolo A2A (Agent-to-Agent) do Google introduziu o conceito de Agent Cards — um formato padronizado para agentes anunciarem suas capacidades, autenticação disponível e endpoints de comunicação. É o equivalente de um cartão de visita em JSON: quando um agente encontra outro, apresenta seu card e ambos sabem imediatamente como se comunicar.
O que um Agent Card contém
- •name + description: quem é o agente, o que faz em linguagem natural.
- •capabilities: lista de skills e tasks que o agente pode executar.
- •authentication: métodos suportados (OAuth, API key, mTLS).
- •endpoints: onde enviar tasks, como receber callbacks.
- •constraints: o que o agente não faz (scoped de jurisdição).
Adoção em 2026
A2A com Agent Cards é o protocolo de descoberta de agentes mais adotado em 2026 — 150+ parceiros, 22k+ stars no GitHub. Quem constrói Agent Cards hoje participa do ecossistema de descoberta automática: seu agente pode ser encontrado e contratado por outros agentes sem configuração manual.
🔄 Identidade vive no controle de versão
CLAUDE.md e AGENTS.md precisam estar em git — isso não é sugestão, é obrigação. Identidade não pode mudar sem rastro. Se alguém modifica as regras inegociáveis de um agente sem passar por PR review, você não sabe quando aconteceu, quem fez, ou por quê. Em produção, isso é inaceitável. Em setores regulados, é violação de controle.
Workflow git-backed para identidade
- 1. Mudança proposta: cria branch feature/claude-md-update com o diff.
- 2. PR review: pelo menos um revisor analisa a mudança de regras.
- 3. Discussão: motivo documentado no PR description.
- 4. Merge: aprovado, merge em main, entra em vigor na próxima sessão.
- 5. Rastreabilidade: git blame mostra quem mudou cada linha, quando, por quê.
💡 Rollback de identidade
Com CLAUDE.md em git, reverter para uma versão anterior de identidade é um git revert. Se uma mudança de regras causou comportamentos inesperados, você restaura o estado anterior em segundos — com registro completo de que o rollback aconteceu e por quê.
🎓 Quando criar nova identidade
Criar um novo agente — uma nova identidade — tem custo operacional real: manter o CLAUDE.md, as permissões, os logs, o SLA, o treinamento de quem usa. Não crie agentes por modismo. Crie quando há carga real e função genuinamente distinta que justifique o overhead. O princípio YAGNI (You Ain't Gonna Need It) se aplica aqui com toda a força.
✓ Criar novo agente quando...
- ✓Função é distinta e especializada
- ✓Volume justifica dedicação integral
- ✓Jurisdição e dados diferentes
- ✓Isolamento de risco necessário
- ✓SLA diferente dos outros agentes
✗ Não criar agente quando...
- ✗Tarefa é pontual ou sazonal
- ✗Um skill resolve sem overhead
- ✗Função se sobrepõe a agente existente
- ✗Só para parecer "mais avançado"
- ✗Sem dono humano definido
Consolidação vs proliferação
Marco começou com 8 agentes. Após 3 meses, consolidou para 4 — dois eram redundantes, dois outros raramente usados. Resultado: menos overhead de manutenção, mais foco, melhor qualidade. Menos agentes bem definidos superam muitos agentes vagos. Periodicamente, questione: "este agente ainda justifica sua existência?"
📋 Resumo do Módulo e da Trilha
Próxima Trilha:
Trilha 3 — Camada de Conhecimento: Silver Platters, MCP, memória e como o agente sabe o que sabe.