O mapa não é a arquitetura: autonomia, autoridade e o que os frameworks de IA agêntica não mostram

É um material bem feito, e o rodapé traz a frase mais importante do desenho: comece baixo na pilha e só adicione uma camada quando o problema justificar. Concordo integralmente. O problema é que o próprio diagrama contradiz essa frase em vários pontos, e quem usa esse tipo de mapa como checklist de arquitetura acaba construindo exatamente o sistema que a frase tenta evitar.

Neste artigo faço uma leitura crítica desse modelo mental e proponho outro, construído em torno de uma pergunta que o mapa não faz: quanto da decisão estou delegando ao modelo, e quanto da autoridade continua com o sistema?

O risco dos mapas que viram lista de compras

Infográficos de arquitetura têm uma função legítima: dar vocabulário comum para times que estão começando. O risco aparece quando o mapa deixa de ser vocabulário e vira requisito. Já vi mais de uma vez um time olhar para um diagrama como esse e concluir que precisa de RAG, MCP, sub-agentes, memória de longo prazo e reflexão, porque tudo isso está desenhado ali, lado a lado, com o mesmo peso visual.

Um mapa não diz o que é obrigatório, o que é opcional e o que é caro. Não diz o que falha primeiro. E não diz onde termina aquilo que o modelo propõe e começa aquilo que o sistema garante. Essa ausência é o que transforma um bom material didático em fonte de overengineering.

Três erros conceituais no modelo em camadas

1. A contenção está invertida

No diagrama, AI é o círculo menor, no centro, e Agentic Systems é o círculo externo, que envolve todos os outros. Visualmente, isso comunica que sistemas agênticos contêm a inteligência artificial.

Na taxonomia clássica a relação é a oposta. IA é o superconjunto, Machine Learning é subconjunto de IA, Deep Learning é subconjunto de Machine Learning. O autor quis representar uma pilha de construção e desenhou uma relação de contenção. Para quem está começando, parece detalhe. Para quem vai tomar decisão de arquitetura, é o primeiro sinal de que o desenho foi otimizado para estética, não para precisão.

2. A pilha é uma narrativa da era LLM, não uma taxonomia

A sequência de seis camadas sugere que cada degrau é pré-requisito do seguinte. Isso não se sustenta. IA generativa existe antes dos foundation models: GANs e VAEs geravam imagens anos antes dos grandes modelos pré-treinados. E agentes existem sem IA generativa: planejadores clássicos e agentes de aprendizado por reforço tomam decisões orientadas a objetivo sem gerar uma linha de texto.

O efeito colateral dessa narrativa é posicionar o agente como topo evolutivo, o lugar onde todo sistema deveria chegar. Na prática, boa parte dos problemas de negócio que resolvo com IA termina antes desse ponto, e termina melhor.

3. As categorias misturam dimensões diferentes

O último ponto merece atenção. Tool calling é a capacidade do modelo de emitir uma chamada estruturada para uma função. MCP é um protocolo para expor ferramentas e contexto a um cliente. Na arquitetura que uso, a interface MCP faz parte da fronteira de confiança: é onde as capabilities são expostas ao modelo. Mas o protocolo sozinho não é essa fronteira. Autenticação, autorização, escopo de credenciais, isolamento de tenant, sandboxing e auditoria continuam sendo responsabilidade do sistema. Um servidor MCP mal configurado é superfície de ataque, não controle. Quando o mapa trata tool calling e MCP como sinônimos, esconde justamente essa decisão.

Autonomia não é capacidade

Antes de propor uma alternativa, preciso nomear a confusão de fundo que o diagrama carrega, e que aparece em muitas discussões sobre agentes: tratar capacidade e autonomia como a mesma coisa.

Capacidade é o que o sistema consegue fazer: entender linguagem natural, recuperar conhecimento privado, chamar uma API, ler uma tela. Autonomia é quem decide o que acontece em seguida. Um sistema pode ter LLM, RAG e dezenas de ferramentas e não ser agêntico, se todas as transições entre etapas estiverem codificadas. Ter tools não torna um sistema agêntico.

O termo agêntico ainda é usado com definições diferentes, que ora enfatizam comportamento orientado a objetivo, ora planejamento, ora execução iterativa com feedback do ambiente. Não pretendo resolver essa discussão. Para fins arquiteturais, uso uma definição operacional: considero agêntico o sistema em que parte da política de transição entre estados é delegada ao modelo.

Essa distinção é mais precisa do que dizer que "no agente, o modelo controla o fluxo". Mesmo em sistemas agênticos maduros, o modelo não controla o sistema. Ele seleciona ações dentro de um envelope de execução definido pelo runtime. A formulação que uso é esta: no workflow, a política de transição entre estados está codificada explicitamente; em um sistema agêntico, parte dessa política é delegada ao modelo.

Essa mudança altera a natureza do problema de engenharia. O runtime continua determinístico, mas parte da política que escolhe a próxima transição passa a ser probabilística. As consequências são concretas: o espaço de estados cresce, a cardinalidade de caminhos pode ficar aberta, o custo por execução vira variável, reproduzir um comportamento fica mais difícil e passo a precisar de orçamentos de execução, tracing semântico e políticas explícitas de autorização.

Raciocínio não é autoridade

A segunda distinção que falta no mapa é entre liberdade de raciocínio e autoridade operacional. Um modelo pode ter alta liberdade para interpretar, planejar e propor, sem possuir autoridade para executar.

O modelo pode concluir que precisa consultar o processo X. Quem decide se aquele usuário pode consultar o processo X é o sistema. O modelo propõe a próxima ação. O sistema continua decidindo se ela tem permissão para ser executada.

Isso define o que chamo de fronteira de decisão. O modelo pode participar da decisão: interpretar, classificar, gerar, propor, selecionar a próxima ação candidata. Mas as invariantes do sistema permanecem fora dele:

• controle de acesso e isolamento de tenant;
• limites financeiros e regras de compliance;
• invariantes de schema e de domínio;
• commit de transações e efeitos colaterais irreversíveis.

LLMs podem participar da decisão, mas invariantes precisam permanecer fora do modelo. Essa é a leitura correta da separação entre camada determinística e camada probabilística. Não é uma questão de onde existe IA. É uma questão de quem detém a autoridade final.

As camadas que o mapa não desenha

Com essas duas distinções em mãos, fica claro o que o diagrama deixa de fora.

Dados. Não existe camada de ingestão, qualidade, lineage ou governança do índice vetorial. RAG aparece como padrão de aplicação, como se recuperação fosse problema de prompt. A qualidade de um RAG começa muito antes de o modelo receber o contexto: ingestão, segmentação, metadados, controle de acesso, recuperação, reranking e atualização do índice fazem parte do problema.

Envelope de execução. O mapa não trata custo nem limites como dimensão arquitetural. Em vez de pensar em teto de iterações, timeout e orçamento de tokens como mecanismos soltos, trato todos como um único envelope: orçamento de tokens, de tempo, de chamadas de ferramenta, de iterações e monetário. A pergunta de engenharia deixa de ser se o agente terminou e passa a ser se ele terminou dentro do envelope operacional esperado. Um agente sem limites explícitos de iteração, tempo e consumo transforma uma falha de decisão em uma falha operacional potencialmente não limitada.

Observabilidade semântica. "Observability & tracing" aparece no mapa, mas em sistemas probabilísticos trace não pode registrar apenas chamadas e latência. Precisa preservar o contexto recuperado, a versão do prompt e do modelo, cada tool call com argumentos e resultado, a decisão de política aplicada, o fallback acionado, o custo e o resultado da avaliação. Sem isso, consigo ver que o sistema errou, mas não por quê.

Avaliação como arquitetura. "Evaluation & monitoring" aparece como controle de produção, como se fosse QA posterior. Em IA, eval é parte do sistema de engenharia. Nenhum aumento de autonomia deveria entrar em produção porque parece melhor em demo. O nível seguinte precisa superar o anterior em um conjunto de avaliações representativo do workload real.

Reversibilidade. Nenhum bloco trata a capacidade de voltar atrás. Se introduzo um agente e a qualidade cai, preciso conseguir voltar para o workflow, desligar uma ferramenta específica, trocar o modelo, operar em modo degradado e reexecutar uma execução a partir do trace. Arquitetura que não pode ser revertida não é decisão, é aposta.

Uma heurística de escalada arquitetural

No lugar da pilha, uso uma heurística de escalada. Faço questão de deixar explícito o que ela é e o que não é: esses níveis não formam uma taxonomia nem uma relação de contenção. Cada nível representa a introdução de uma nova fonte relevante de complexidade operacional. O ponto não é chegar ao topo. É parar no nível mais baixo que resolve o problema com a confiabilidade exigida.

Para não repetir o erro que critiquei no diagrama, separo duas dimensões que costumam ser misturadas.

A primeira é capacidade: o que o sistema consegue fazer em cada etapa. Vai de lógica determinística, passa por chamada de LLM com saída estruturada e chega a grounding (RAG) e uso de ferramentas.

A segunda é orquestração: quem decide a próxima transição. Vai de chamada única, passa por workflow com grafo fixo, chega a agente e, por fim, a multiagente.

As duas se combinam livremente. Um workflow sem nenhum LLM é legítimo. Um agente pode não usar RAG. Um sistema multiagente pode conter workflows determinísticos. A escalada que realmente exige justificativa é a de orquestração, porque é ela que delega decisão ao modelo.

flowchart LR
    subgraph C["Capacidade: o que cada etapa consegue fazer"]
        direction TB
        C0["Lógica determinística"] --> C1["LLM com saída estruturada"]
        C1 --> C2["Grounding e ferramentas"]
    end
    subgraph O["Orquestração: quem decide a próxima transição"]
        direction TB
        O0["Chamada única"] -->|"tarefa tem várias etapas<br/>com caminhos conhecidos"| O1["Workflow com grafo fixo"]
        O1 -->|"não é viável codificar<br/>a política de transição"| O2["Agente"]
        O2 -->|"responsabilidades com contexto, políticas<br/>ou fronteiras de confiança distintas"| O3["Multiagente"]
    end
    C -. "combinam livremente" .- O

Para cada passo na dimensão de orquestração, faço três perguntas: o que justifica subir, o que passa a custar e o que passa a falhar.

A mudança de natureza está entre workflow e agente. Até o workflow, a política de transição é código. A partir do agente, parte dela é delegada. É o passo que mais exige evidência, e é por isso que ele só deveria acontecer quando o problema tem, de fato, incerteza sobre o caminho. Autonomia precisa ser proporcional à incerteza que realmente existe no problema.

Caso real: onde o Kazo.ai parou de escalar

O Kazo.ai é uma plataforma de IA jurídica para escritórios de advocacia brasileiros. O MVP tem como peça central um assistente de WhatsApp que atende clientes do escritório.

Olhando para o mapa, seria natural desenhar esse assistente como um agente autônomo com memória, ferramentas, reflexão e sub-agentes por área do direito. Foi exatamente o que decidi não fazer no MVP.

O assistente precisa decidir entre três caminhos: responder diretamente, consultar um dado ou escalar para um humano. Esses caminhos são conhecidos, e a política de transição entre eles cabe inteira em código. Não há incerteza sobre o caminho, só sobre a intenção da mensagem. Na dimensão de orquestração, isso é um workflow, não um agente. A decisão foi usar o LangGraph como orquestrador único, com um grafo fixo em que o modelo classifica a intenção e opera dentro de cada nó, mas a política de transição entre nós é código.

Na dimensão de capacidade, cada nó usa o mínimo necessário, e a fronteira de autoridade fica visível em cada um:

• A classificação da mensagem é uma chamada de LLM com saída estruturada validada por schema. Se a saída não passa na validação, o fluxo cai para escalonamento humano, nunca para um palpite.
• A consulta de dados do caso é lógica determinística. Quem busca o dado é o sistema, com permissão verificada na camada de negócio. O modelo recebe apenas o resultado para redigir a resposta. Ele não tem autoridade para pedir dados de outro cliente porque essa capability simplesmente não é exposta a ele.
• A resposta sobre documentos do escritório usa grounding, com filtro de tenant aplicado na consulta ao índice, antes de qualquer contexto chegar ao modelo.
• O escalonamento para humano não é capacidade do agente. É uma regra do grafo, acionada por intenção, falha de validação ou baixa confiança.

Frameworks multiagente e agentes especializados por área do direito ficaram deliberadamente para a fase de módulos especializados. Quando existirem responsabilidades com contexto, ferramentas, políticas ou fronteiras de confiança suficientemente distintas, e quando uma avaliação sobre conversas reais mostrar ganho sobre o workflow, a escalada começa a se justificar.

O resultado dessa escolha é um sistema em que o caminho de cada conversa pode ser reconstruído a partir do trace, o custo por atendimento é previsível, a reversão para uma versão anterior do grafo é trivial e o pior erro possível do modelo é uma resposta mal redigida, não uma ação sem autorização.

Checklist: o próximo nível paga a conta?

Antes de escalar a orquestração, respondo a estas perguntas. Se alguma resposta for fraca, fico onde estou.

1. Consigo descrever, com exemplos reais, o problema que o nível atual não resolve?
2. É viável antecipar e codificar a política de transição da tarefa? Se for, por que delegá-la ao modelo?
3. Quais invariantes do sistema estão em jogo, e todas continuam fora do modelo no novo nível?
4. Toda ação com efeito colateral é idempotente, autorizada pelo sistema e auditável?
5. O envelope de execução está definido: tokens, tempo, chamadas de ferramenta, iterações e custo?
6. O trace preserva contexto, versões, tool calls e decisões de política, e não só latência?
7. Tenho um conjunto de avaliação representativo do workload real mostrando que o novo nível é melhor, e não apenas mais sofisticado?
8. Consigo reverter para o nível anterior, desligar uma ferramenta ou operar em modo degradado sem redesenhar a arquitetura?
9. Quem é o dono desse comportamento quando ele falhar às três da manhã?

Conclusão

O infográfico da GenAI.works é um bom mapa de vocabulário e traz uma frase final que todo time deveria colar na parede. Mas mapa não é arquitetura. Ele inverte a relação entre as camadas, apresenta uma narrativa como taxonomia, mistura capacidade com protocolo e deixa de fora as dimensões que decidem se um sistema sobrevive em produção.

O modelo mental que proponho no lugar dele se apoia em cinco ideias. Autonomia não é capacidade: ter LLM, RAG ou ferramentas não torna um sistema agêntico. Agência é delegação da política de transição: a mudança essencial está em quem escolhe o próximo passo. Raciocínio não é autoridade: o modelo pode propor a próxima ação sem possuir autoridade para executá-la. Decisões probabilísticas precisam de envelopes determinísticos: políticas, permissões, orçamentos e invariantes ficam fora do modelo. E complexidade precisa ser conquistada com evidência: cada aumento de autonomia paga seu custo em avaliações reais, não em demos.

A arquitetura correta não é a que maximiza autonomia. É a que delega ao modelo exatamente a quantidade de decisão que o problema exige, enquanto mantém invariantes, autoridade e efeitos colaterais sob controle do sistema.