Anatomia de um agente

Um agente empresarial não é “uma IA com acesso a ferramentas”. É uma função computacional desenhada com missão, contexto, memória, autoridade, métricas, escalamento e responsabilidade operacional.

A palavra agente tornou-se uma das mais utilizadas no vocabulário tecnológico recente.
Tudo parece poder ser chamado de agente.
Um chatbot.
Um script.
Uma automação.
Um modelo com ferramentas.
Um fluxo de trabalho.
Um assistente.
Um sistema que executa ações.
O problema é que, se a palavra descreve tudo, deixa de ajudar a desenhar alguma coisa.
Para uma empresa, precisamos de uma definição operacional.
Não interessa apenas saber se determinada solução é tecnicamente “agentic”.
Interessa saber se ela está suficientemente bem especificada para ocupar uma função dentro da operação.
É essa a diferença entre uma demonstração e uma capacidade empresarial.

---

1. A definição operacional

Neste livro, chamaremos agente empresarial a um sistema que:

1. recebe ou deteta uma missão;
2. obtém contexto relevante;
3. interpreta o estado atual;
4. escolhe entre ações permitidas;
5. utiliza ferramentas;
6. executa;
7. observa resultado;
8. regista aquilo que fez;
9. escala quando necessário;
10. opera dentro de limites definidos.
    Esta definição não exige autonomia total.
    Um agente pode pedir aprovação.
    Pode apenas recomendar.
    Pode operar num ambiente restrito.
    O que o distingue de uma simples resposta é a existência de um ciclo operacional.

---

2. O ciclo do agente

Este ciclo parece simples.
Mas cada bloco contém decisões de arquitetura.

---

---

3. Missão

O primeiro componente é a missão.
Sem missão, o agente é apenas capacidade disponível.
Uma boa missão deve responder:

• que resultado procura;
• para quem;
• em que contexto;
• dentro de que horizonte;
• sujeito a que limites.
  Exemplo fraco:

“Faz follow-up comercial.”

Exemplo melhor:

“Garantir que todos os leads qualificados com proposta enviada recebem acompanhamento adequado dentro de 48 horas, de acordo com a política comercial, registando interações e escalando negociações sensíveis.”

A segunda versão é mais longa.
Mas é operacional.

---

4. Missão não é KPI

É fácil confundir.
Missão:

garantir acompanhamento adequado.

KPI:

percentagem de propostas com follow-up até 48 horas.

O KPI mede.
Não define completamente comportamento.
Se transformarmos métrica em missão, podemos criar distorção.
Um agente obcecado apenas em atingir “100% follow-up” pode enviar mensagens inadequadas.
Missão precisa de incorporar qualidade e contexto.

---

5. Trigger

Todo agente precisa saber quando começar.
O trigger pode ser:

Temporal

Todos os dias às 08:00.

Evento

Nova proposta enviada.
Novo lead.
Pagamento falhou.
Stock abaixo de limite.

Pedido humano

“Analisa esta conta.”

Pedido de outro agente

Coordenador solicita pesquisa.

Estado

Cliente está há cinco dias sem resposta.
Triggers mal definidos criam ruído.
Um agente que acorda demasiado pode desperdiçar recursos.
Um agente que acorda tarde pode perder oportunidade.

---

6. Contexto

Antes de agir, o agente precisa saber o que está a acontecer.
Contexto pode incluir:

• cliente;
• produto;
• histórico;
• política;
• preço;
• stock;
• contrato;
• etapa do processo;
• ações anteriores;
• exceções;
• identidade de quem pediu.
  O problema não é “dar todo o contexto”.
  É dar o contexto certo.
  Demasiada informação também degrada decisão.

---

7. Contexto mínimo suficiente

Podemos utilizar um princípio:

o agente deve receber o mínimo contexto suficiente para executar com qualidade e segurança.

Isto melhora:

• custo;
• velocidade;
• privacidade;
• segurança;
• foco.
  Se um agente de marketing não precisa de informação financeira sensível, não deve recebê-la.
  Se um agente de stock não precisa de dados pessoais de clientes, não deve vê-los.
  Arquitetura agentic também é arquitetura de informação.

---

8. Conhecimento

Contexto descreve o caso atual.
Conhecimento descreve aquilo que o agente precisa saber de forma mais estável.
Pode incluir:

• políticas;
• manuais;
• catálogo;
• contratos modelo;
• FAQ;
• SOPs;
• documentação técnica;
• regras fiscais internas;
• brand guidelines;
• legislação relevante quando aplicável.
  Conhecimento não deve ser tratado como um grande depósito indiferenciado.
  Precisa de:
• fonte;
• versão;
• validade;
• prioridade.

---

9. Fonte de verdade

Toda operação precisa de definir fontes oficiais.
Preço vem de onde?
Stock vem de onde?
Política vem de onde?
Contrato válido é qual?
Horário é qual?
Quando duas fontes entram em conflito, qual vence?
Sem essa definição, o agente pode escolher informação errada com enorme confiança.
Um sistema inteligente não elimina a necessidade de master data.
Torna-a mais importante.

---

10. Memória

A palavra memória também é utilizada de forma vaga.
Podemos separar quatro tipos.

Memória de trabalho

Informação necessária para a execução atual.

Memória episódica

Histórico de interações ou eventos específicos.

Memória semântica

Conhecimento relativamente estável: políticas, conceitos, catálogo.

Memória operacional

Estado de processos: o que já foi feito, o que falta, quem aprovou, que exceção ocorreu.
Estas memórias podem viver em sistemas diferentes.
O agente não precisa guardar tudo internamente.
Precisa saber recuperar.

---

---

11. Ferramentas

Ferramentas transformam inteligência em capacidade.
Exemplos:

• CRM;
• ERP;
• email;
• WhatsApp;
• calendário;
• base de dados;
• browser;
• e-commerce;
• sistema financeiro;
• BI;
• documentos;
• APIs;
• execução de código.
  Cada ferramenta representa poder.
  Consultar é uma coisa.
  Alterar é outra.
  Enviar é outra.
  Transferir dinheiro é outra.
  Por isso, acesso a ferramentas precisa de estar ligado a permissões.

---

12. Princípio do menor privilégio

O agente deve possuir apenas o acesso necessário para cumprir a missão.
Se precisa ler, não precisa editar.
Se precisa preparar, talvez não precise executar.
Se precisa executar até R$ 500, não precisa acesso ilimitado.
Este princípio reduz risco.
E permite aumentar autonomia de forma segura.

---

13. Permissões

Permissão pode ser definida por:

• tipo de ação;
• valor;
• horário;
• cliente;
• produto;
• território;
• sistema;
• nível de risco;
• origem do pedido.
  Exemplo:

pode conceder crédito promocional até R$ 50 em clientes elegíveis, uma vez por pedido, sem aprovação.

Isto é muito mais preciso do que:

“pode resolver reclamações.”

---

14. Política de decisão

Quando existem várias ações permitidas, o agente precisa de critérios.
Exemplo:
Se lead é enterprise e valor potencial > R$ 100 mil:

• não enviar proposta automática;
• preparar briefing;
• atribuir vendedor sénior;
• agendar contacto.
  Se lead é padrão:
• seguir fluxo normal.
  A política de decisão traduz estratégia em comportamento.

---

15. Planeamento

Alguns agentes precisam executar um passo.
Outros precisam decompor um objetivo em sequência.
Exemplo:
Objetivo:

preparar entrada comercial no Chile.

Subtarefas:

• dimensionar procura;
• analisar concorrência;
• adaptar oferta;
• estimar logística;
• estimar margem;
• verificar pagamentos;
• preparar conteúdo;
• identificar riscos.
  A capacidade de decompor trabalho é útil.
  Mas aumenta risco de erro acumulado.
  Quanto maior o plano, maior necessidade de checkpoints.

---

16. Outputs

Um agente pode produzir diferentes tipos de saída.

Informação

Resumo.
Análise.
Relatório.

Recomendação

Opções.
Prioridade.
Plano.

Ação

Enviar.
Atualizar.
Criar.
Agendar.

Decisão limitada

Escolher dentro de política.

Escalamento

Solicitar intervenção humana.
A arquitetura deve declarar quais outputs são permitidos.

---

17. Escalamento

Escalar não é falhar.
É uma capacidade.
Um agente maduro sabe quando parar.
Critérios de escalamento podem incluir:

• confiança baixa;
• informação contraditória;
• valor acima de limite;
• risco elevado;
• reclamação sensível;
• política inexistente;
• ação irreversível;
• anomalia;
• pedido explícito do cliente;
• incidente de segurança.
  O objetivo é evitar dois extremos:
  agente que escala tudo;
  agente que nunca escala.

---

18. Escalamento precisa de contexto

Um agente que apenas diz:

“preciso de ajuda”

transfere trabalho.
Um bom escalamento entrega:

• problema;
• contexto;
• ações já executadas;
• opções;
• risco;
• recomendação;
• decisão necessária.
  Isto reduz custo de intervenção humana.

---

PRINCÍPIO

O melhor agente não é o que nunca pede ajuda. É o que pede ajuda no momento certo e entrega a decisão preparada.

---

19. KPIs

KPIs precisam medir resultado, não apenas atividade.
Agente de atendimento:
fraco:

• número de mensagens.
  melhor:
• tempo de resposta;
• resolução;
• escalamento correto;
• satisfação;
• taxa de retrabalho.
  Agente comercial:
  fraco:
• número de follow-ups.
  melhor:
• cobertura do pipeline;
• tempo de follow-up;
• conversão;
• qualidade de oportunidade;
• opt-outs.
  Métrica errada produz comportamento errado.

---

20. Observabilidade

Se um agente age, precisamos saber:

• o que recebeu;
• o que consultou;
• que decisão tomou;
• que ferramenta utilizou;
• o que alterou;
• quando;
• por quê;
• qual resultado;
• se alguém interveio.
  Isto é observabilidade.
  Sem observabilidade, autonomia torna-se confiança cega.

---

21. Logs não são observabilidade

Guardar tudo não basta.
Milhares de linhas de log podem tornar-se inúteis.
Precisamos transformar execução em informação de gestão.
Exemplo:
Hoje

• 842 casos processados;
• 791 concluídos automaticamente;
• 38 escalados;
• 13 falharam;
• 4 ações revertidas;
• custo médio por caso: R$ X;
• impacto estimado: Y.
  Isto permite gerir capacidade.

---

22. Segurança

Um agente com ferramentas pode ser alvo de:

• credenciais comprometidas;
• instruções maliciosas;
• dados manipulados;
• acesso excessivo;
• prompt injection;
• exfiltração;
• uso indevido de ferramentas.
  Segurança precisa existir no desenho.
  Não depois.
  Princípios:
• autenticação;
• autorização;
• segregação;
• validação;
• least privilege;
• logs;
• rate limits;
• isolamento;
• revisão.

---

23. Identidade do agente

Uma organização deve saber quem está a agir.
Cada agente deveria possuir identidade operacional própria.
Isso facilita:

• permissões;
• auditoria;
• revogação;
• atribuição de ações;
• análise de comportamento.
  Não utilizar uma única conta “admin” para todos os agentes.
  Isso destrói rastreabilidade.

---

24. Human override

Sistemas precisam de mecanismo de interrupção.
Pode ser:

• pausar;
• revogar credencial;
• bloquear ferramenta;
• mudar limite;
• cancelar fluxo de trabalho;
• assumir caso.
  Uma empresa madura precisa saber como parar aquilo que automatizou.

---

25. Custo

Agentes têm custo operacional.
Não apenas subscrição.
Podem existir custos de:

• modelo;
• API;
• armazenamento;
• ferramentas;
• monitorização;
• manutenção;
• revisão;
• erro.
  Um agente deve possuir uma unidade económica compreensível.
  Custo por caso.
  Custo por lead.
  Custo por documento.
  Custo por ticket.
  Custo por decisão.

---

26. Agent Unit Economics

Podemos criar uma pequena equação gerencial.
Custo do agente por unidade

compute + ferramentas + infraestrutura + supervisão + custo de erro
Comparar com:
valor por unidade

tempo libertado + custo evitado + receita incremental + risco reduzido
Não é contabilidade perfeita.
É disciplina de decisão.

---

27. O Agent Charter

O Agent Charter será um artefacto central da metodologia AtlasHub.

---

---

28. Exemplo — AI Sales Follow-up Agent

Missão

Garantir que propostas qualificadas recebem acompanhamento em até 48 horas.

Trigger

Proposta enviada + 36 horas sem resposta.

Contexto

Cliente, proposta, histórico, vendedor, valor, etapa.

Conhecimento

Política comercial, tom de voz, condições.

Ferramentas

CRM, email, WhatsApp autorizado, calendário.

Permissões

Enviar mensagens aprovadas; atualizar CRM; sugerir reunião.

Não pode

Alterar preço; conceder desconto; prometer exceção contratual.

KPIs

Cobertura, resposta, reunião, conversão, opt-out, erro.

Escalamento

Cliente reclama; valor > limite; negociação sensível; dúvida de política.

responsável

Diretor Comercial.
Isto já se aproxima de uma verdadeira especificação funcional.

---

29. Teste

Nenhum agente deveria ir diretamente de ideia para produção.
Um ciclo mínimo:

Shadow mode

O agente observa casos reais e sugere ação.
Mas não executa.
Comparamos com humanos.
Isto é extremamente útil para calibrar.

---

30. Testes adversos

Não testar apenas o caso normal.
Testar:

• dado em falta;
• dado contraditório;
• pedido fora de escopo;
• cliente hostil;
• ferramenta indisponível;
• política ambígua;
• conteúdo malicioso;
• tentativa de obter informação restrita;
• sequência longa;
• falha parcial.
  A robustez aparece nas exceções.

---

31. Versionamento

Agentes mudam.
Prompts.
Políticas.
Modelos.
Ferramentas.
Conhecimento.
Cada mudança pode alterar comportamento.
Por isso, produção deveria possuir versionamento.
Que versão executou esta ação?
Que política estava ativa?
Que modelo?
Que ferramentas?
Isto é essencial para investigar erro.

---

32. Ciclo de vida

Um agente possui ciclo de vida.

Descoberta

Problema identificado.

Design

Agent Charter.

Construção

Configuração e integrações.

Validação

Testes.

Piloto

Escopo restrito.

Produção

Operação real.

Monitorização

KPIs, qualidade, custo.

Melhoria

Ajustes.

Retirada

Desativar quando deixa de criar valor.
Nem todo agente deve viver para sempre.

---

33. Agent debt

Tal como software cria dívida técnica, organizações podem criar agent debt.
Agentes antigos.
Prompts duplicados.
Políticas desatualizadas.
Integrações frágeis.
responsáveis que já saíram.
Permissões excessivas.
Ninguém sabe quem mantém.
Quanto mais agentes, maior necessidade de inventário e governação.

---

34. O Agent Registry

Uma Empresa Aumentada madura deveria manter um registo.
Para cada agente:

• nome;
• responsável;
• missão;
• estado;
• versão;
• sistemas;
• permissões;
• risco;
• KPIs;
• custo;
• última revisão.
  Isto transforma agentes em ativos geríveis.

---

---

35. Autonomia como propriedade configurável

Um agente não é “autónomo” ou “não autónomo”.
Podemos configurar autonomia em várias dimensões:

• decidir;
• executar;
• comunicar externamente;
• movimentar valor;
• criar objeto;
• alterar dado;
• delegar;
• requisitar outro agente.
  Isso permite desenho fino.

---

36. Agent Risk Tier

Podemos classificar agentes.

Tier 1 — Assistivo

Sem ações externas.

Tier 2 — Operacional de baixo risco

Ações reversíveis.

Tier 3 — Operacional com impacto

Ações externas ou financeiras limitadas.

Tier 4 — Crítico

Decisões de alto impacto, dados sensíveis, financeiro, saúde, jurídico ou segurança.
Quanto maior o tier:
mais teste;
mais supervisão;
mais logs;
mais restrição.

---

37. O agente é uma função, não um personagem

Esta frase merece destaque.

Um agente empresarial deve ser desenhado como função operacional, não como personagem de ficção.

Pode ter nome.
Pode ter interface.
Pode ter voz.
Mas o desenho começa em:
responsabilidade;
dados;
ferramentas;
limites;
resultado.

---

38. O que acontece quando temos muitos agentes?

Até aqui falámos como se existisse um agente isolado.
Mas uma empresa pode ter dezenas.
Depois centenas.
Vendas.
Marketing.
Compras.
Financeiro.
Atendimento.
Operações.
E agentes dentro de cada função.
Surge então um problema semelhante ao das organizações humanas.
Coordenação.
Quem distribui trabalho?
Quem evita duplicação?
Quem resolve conflito?
Quem cria prioridade?
Quem recebe exceção?
Isso leva ao próximo capítulo.
Antes de agentes coordenarem agentes, precisamos visualizar a organização inteira.
Precisamos atualizar o organograma.

---

A EQUAÇÃO

Um agente só merece existir se alterar uma variável.

RECEITA ↑

Aumenta capacidade comercial ou experiência?

CUSTOS ↓

Reduz trabalho ou erro?

VELOCIDADE ↑

Diminui latência?

CONTROLO ↑

Aumenta consistência e observabilidade?
Se não conseguimos medir nenhuma melhoria, o Agent Charter pode estar tecnicamente perfeito e economicamente inútil.

---

39. Fecho

A empresa não precisa de “mais agentes”.
Precisa de agentes bem desenhados.
O salto entre chatbot e agente não está apenas em ferramentas.
Está na disciplina operacional em redor da inteligência.
Missão.
Contexto.
Memória.
Ferramentas.
Permissões.
Política.
Métricas.
Escalamento.
Observabilidade.
responsável.
É quando estes elementos aparecem que deixamos de falar de uma experiência interessante.
E começamos a falar de uma função empresarial.
No próximo capítulo, essas funções deixam de existir isoladas.
Passam a ocupar lugar dentro da arquitetura da empresa.

O organograma vai mudar.