Agentes de IA: como estruturar uma arquitetura para produção

Ao definir a arquitetura dos seus agentes de IA, comece com um único agente capaz de investigar um caso, propor uma ação e aguardar aprovação. Contrate o modelo e a infraestrutura padrão; desenvolva as regras de negócio, os limites de permissão e os mecanismos que comprovam a conclusão correta do trabalho.

Um agente de suporte se torna útil quando consegue relacionar a mensagem do cliente à conta, à política e à ação certas. Para ser confiável, porém, ele depende de uma aplicação que consiga explicar o que foi acessado, impedir alterações não autorizadas e se recuperar de falhas nas ferramentas.

Pense no sistema como uma rede de transporte. O modelo escolhe o trajeto, as ferramentas levam aos destinos, a memória preserva o histórico da viagem e a orquestração coordena o movimento. As proteções e as etapas de aprovação controlam o acesso; a avaliação e os logs mostram se os passageiros chegaram ao lugar certo.

As descrições dos componentes abaixo foram conferidas com a documentação da Anthropic, da OpenAI e do Google Cloud e com a especificação do Model Context Protocol em 25 de outubro de 2026. O fluxo de suporte é um exemplo de projeto, não o relato de um sistema em operação em um cliente.

Arquitetura de agentes de IA: o que cabe à aplicação

A arquitetura define o que o modelo pode decidir e o que a aplicação precisa garantir. Essa divisão importa mais do que o nome do framework.

O conceito de LLM ampliado da Anthropic, um modelo de linguagem conectado à recuperação de informações, a ferramentas e à memória, é um bom ponto de partida. A orientação da empresa distingue um workflow cujo caminho está definido em código de um agente que escolhe dinamicamente suas próximas ações. A recomendação é acrescentar complexidade apenas quando a tarefa exigir. Orientações da Anthropic sobre agentes

Na triagem de suporte, o modelo pode decidir entre consultar um guia de solução de problemas e verificar um pedido. Ainda assim, cabe ao código da aplicação determinar quais registros de cliente ele pode ler, se o reembolso proposto é permitido e o que acontece se a execução parar no meio.

Mantenha previsível o que já é previsível. Autenticar uma conta, conferir um direito de acesso e registrar uma ação concluída não exigem improvisação de um agente. Deixe para o modelo a parte incerta: entender a mensagem, selecionar as evidências relevantes e propor um próximo passo útil.

Diagrama da arquitetura: camadas e conexões

Um agente precisa de um ciclo controlado, com estado persistente e verificações ao redor. As camadas abaixo representam responsabilidades; cada uma delas não exige necessariamente um serviço ou uma assinatura à parte.

Leia as conexões como um ciclo: a aplicação reúne o contexto, o modelo solicita uma ação, o ambiente de execução verifica e executa essa ação, e o resultado passa a compor o contexto da próxima decisão. O guia sobre o ciclo dos agentes detalha esse processo e suas condições de parada.

Modelo: entender o caso e propor a próxima ação

O OpenAI Agents SDK, biblioteca da OpenAI para criar workflows de agentes, reúne modelo, instruções e ferramentas em um Agent; o modelo interpreta o chamado e propõe o próximo passo. Neste projeto, ele recebe um problema de acesso à conta e solicita o registro do direito de acesso correspondente antes de redigir a resposta. Escolha o modelo avaliando casos representativos de suporte: um texto bem escrito não comprova a escolha correta da ferramenta nem a autorização para agir. Definições de agentes da OpenAI

Ferramentas e MCP: acessar os sistemas do negócio

O Model Context Protocol (MCP), uma interface padronizada entre aplicações de IA e recursos externos, define ferramentas nomeadas com um inputSchema, descoberta por tools/list e invocação por tools/call. A consulta de conta pode ser disponibilizada via MCP ou por uma função comum que chama uma API do negócio. Em ambos os casos, o serviço responsável precisa validar os argumentos e restringir o acesso à conta correta. O MCP padroniza a conexão; o guia sobre MCP explica o protocolo e seus limites de confiança. Especificação de ferramentas do MCP

Memória: preservar o contexto certo

O Agent Development Kit (ADK), framework do Google para criar agentes, usa Session e state para informações de uma interação e oferece memória entre sessões por meio de componentes como o Memory Bank. No suporte, mantenha o caso atual e a aprovação pendente no armazenamento da aplicação, consulte os dados atuais da conta na fonte e retenha preferências do cliente somente quando isso fizer sentido. São funções distintas; o guia sobre memória de agentes explica contexto, armazenamento de sessão e memória de maior duração. Orientações de arquitetura do Google Cloud

Orquestração: controlar o andamento, as pausas e a recuperação

O guia da OpenAI para criar agentes descreve o Agents SDK como responsável pelo ciclo de ferramentas, pelas transferências entre agentes e pelas proteções. Ele fornece à aplicação um mecanismo para executar o trabalho conduzido pelo modelo. Ao redor desse mecanismo, persista o estado do chamado — em investigação, aguardando revisão, em execução ou concluído — para que o processo possa recuperar o caso após reiniciar. O guia de orquestração explica como as execuções de agentes se encaixam em um processo de negócio mais longo. Guia de agentes da OpenAI

Proteções e aprovação humana: controlar as consequências

O OpenAI Agents SDK separa as proteções automáticas, ou guardrails, das interrupções para aprovação, que pausam uma chamada de ferramenta e retornam um estado que permite retomar a execução. No agente de suporte, valide automaticamente o acesso à conta e os argumentos propostos. Depois, exija que uma pessoa autorizada aprove qualquer alteração sensível antes da execução. Faça cumprir essas regras junto à ferramenta que realiza a ação; o guia sobre guardrails aprofunda essas verificações. Guardrails e revisão humana na OpenAI

Avaliação e observabilidade: entender o que aconteceu e se funcionou

O rastreamento do OpenAI Agents SDK registra chamadas ao modelo, chamadas de ferramentas, transferências entre agentes e atividades dos guardrails. Já a orientação sobre avaliação de rastros de execução explica como pontuar o comportamento do workflow com critérios explícitos. A observabilidade mostra como o chamado de suporte se desenrolou; a avaliação verifica se o agente selecionou a conta correta, seguiu a política e produziu uma resposta sustentada pelas evidências. Defina o que coletar e por quanto tempo reter esses dados antes de comparar ferramentas de observabilidade para LLMs. Rastreamento no SDK, avaliação de agentes

A arquitetura de referência do Google Cloud reúne ADK, Cloud Run, acesso ao modelo, conexões MCP, Model Armor e observabilidade em uma implantação concreta. O exemplo documentado deixa explicitamente de fora do diagrama a memória e o armazenamento de sessão. Por isso, a persistência do estado do caso continua sendo uma decisão de projeto, não algo que se deva presumir incluído. Arquitetura de referência

Da chegada do chamado à resposta com a solução

Dê ao agente um caso bem delimitado, cuja conclusão possa ser verificada. Neste exemplo, um cliente diz que pagou pelo acesso, mas ainda não consegue usar o serviço. O agente pode investigar e preparar uma correção, enquanto um líder de suporte aprova as alterações na conta e a resposta ao cliente durante a fase inicial de implantação.

Os nomes de ferramentas abaixo descrevem funções da aplicação que você implementaria, não uma integração de suporte pronta de algum fornecedor.

1. 1

   Receber e identificar o caso

   O webhook do chamado, um evento enviado pelo sistema de suporte, cria ou retoma um caso usando o identificador externo do chamado. Autentique o cliente pelo fluxo de conta existente; um endereço de e-mail digitado na mensagem não deve servir para conceder acesso a uma conta. Salve a mensagem recebida como conteúdo não confiável fornecido pelo cliente.

2. 2

   Buscar evidências com ferramentas de escopo restrito

   Dê ao agente recursos como get_account_entitlement e search_support_policy. No código da aplicação, vincule o acesso à conta à identidade autenticada e retorne o registro relevante e a referência da política. O modelo pode escolher quais evidências solicitar sem receber acesso irrestrito ao banco de dados.

3. 3

   Preparar uma proposta fundamentada

   O modelo compara o relato do cliente com o registro da conta e a política aplicável. Se as evidências justificarem uma correção no direito de acesso, ele prepara a alteração e a resposta propostas. Se faltarem evidências ou houver contradições, pede esclarecimentos ou encaminha o caso. Guarde as referências das evidências com a proposta para que o revisor possa conferir sua fundamentação.

4. 4

   Pausar antes da ação de negócio

   Valide a operação proposta de acordo com a política e salve a ação pendente e o estado da aprovação. Mostre ao líder de suporte a conta afetada, a alteração exata proposta, as evidências que a sustentam e a resposta ao cliente. Uma rejeição mantém a gravação bloqueada e devolve o caso para revisão ou tratamento manual.

5. 5

   Executar e conferir o resultado

   Após a aprovação, verifique novamente se a conta e a proposta ainda correspondem ao que foi revisado. Só então chame a ferramenta de correção. Use uma chave de idempotência, identificador que impede a aplicação repetida da mesma operação em uma nova tentativa, quando o serviço responsável oferecer esse recurso. Confirme o direito de acesso resultante antes de enviar uma resposta dizendo que o acesso foi restabelecido; registre o resultado do envio antes de marcar o caso como concluído.

6. 6

   Transformar o resultado em evidência para avaliação

   Vincule o resultado da execução, a resposta aprovada e o estado final do caso ao rastro de execução. Encaminhe resultados incertos a uma pessoa, em vez de interpretar o esgotamento do tempo de espera como sucesso ou falha. Quando a revisão encontrar um erro, preserve no conjunto de avaliação um exemplo com os dados sensíveis devidamente ocultados.

A falha crucial é uma gravação de resultado ambíguo: o serviço de contas pode ter aplicado a alteração mesmo que sua aplicação não tenha recebido a resposta. Confira o estado no sistema de origem antes de tentar novamente. Um registro da conversa que diz “vou restabelecer o acesso” comprova a intenção, não que o acesso foi alterado.

Quando vale adotar um sistema multiagente?

Mantenha um único agente enquanto a tarefa estiver sob uma política coerente, um conjunto de ferramentas e um responsável. Acrescente um especialista quando ele resolver um problema concreto de separação de responsabilidades. Depois, teste se a melhoria se sustenta diante da coordenação adicional.

A OpenAI distingue handoffs, em que um especialista assume a conversa, de agentes como ferramentas, em que o agente principal chama um especialista, mas continua responsável pela resposta. A orientação é separar quando houver diferenças relevantes nas instruções, nas capacidades ou nas políticas. Orquestração e handoffs

No caso de suporte, buscar um artigo de ajuda e redigir uma resposta não justificam automaticamente agentes separados. Uma contestação de cobrança pode justificar: ela pode exigir outra política, ferramentas financeiras restritas e outro revisor. Você pode chamar esse especialista para uma análise delimitada, mantendo o agente de suporte como responsável pelo caso, ou transferir explicitamente a responsabilidade quando o fluxo de cobrança precisar assumir o atendimento.

Diagrama de sistemas multiagentes: divida pelas responsabilidades

Uma política diferente é um bom motivo para considerar a separação, mas não uma exigência universal. Tarefas independentes de coleta de evidências também podem justificar agentes trabalhando em paralelo, desde que o responsável final consiga resolver conflitos entre os resultados e o benefício observado compense o trabalho adicional dos modelos.

Antes de acrescentar um especialista, registre a falha que ele deve corrigir: escolha da ferramenta errada, instruções conflitantes, excesso de contexto ou falta de conhecimento especializado. Compare o projeto proposto nos mesmos casos, incluindo situações de falha. Mantenha-o apenas se a melhoria justificar o aumento de latência, consumo e trabalho de depuração e revisão. Esse é um critério de decisão, não uma promessa de ganho de desempenho.

Chamar os agentes de “pesquisador”, “crítico” e “gestor” não garante julgamentos independentes. Se todos partirem das mesmas evidências equivocadas, a concordância entre eles pode apenas repetir o erro. Para uma classificação mais ampla, consulte o mapa dos tipos de agentes de IA.

O que contratar e o que manter sob sua responsabilidade

Contrate os componentes substituíveis e assuma a responsabilidade pelas regras do negócio. Para o primeiro agente em produção, o melhor motivo para desenvolver um componente por conta própria é seu workflow exigir um comportamento que a opção disponível não consegue oferecer ou disponibilizar para integração.

Para fundadores: contrate um produto gerenciado de agentes se ele atender ao seu fluxo real de trabalho, às exigências de aprovação e à exportação de evidências. Desenvolva a solução com componentes padrão quando as políticas específicas de cada conta ou o comportamento das integrações forem seu diferencial. Uma demonstração convincente não basta se você não consegue recuperar um caso pausado ou inspecionar uma ação que falhou.

Para CTOs e desenvolvedores: mantenha as ferramentas de negócio com escopo restrito e passíveis de teste independentemente do modelo. Um ambiente de execução gerenciado pode hospedar a aplicação; ele não consegue inferir a diferença entre um cliente pedindo reembolso e um funcionário autorizado a concedê-lo. Defina essa distinção no serviço que realiza a operação.

Para líderes de operações: assumam a fila de exceções e a definição do que significa resolver um caso. Especifiquem quem recebe um caso não resolvido, quais evidências essa pessoa recebe e quando o chamado pode ser encerrado. Uma fila de aprovações sem ninguém para atendê-la é um workflow inacabado.

A execução de código é opcional para esse agente de suporte. Se uma tarefa futura precisar executar código gerado, trate o isolamento como uma decisão à parte e consulte o guia de sandboxes de código para agentes. Não introduza um shell de uso geral só para consultar uma conta.

Onde entra a aprovação humana e o que registrar desde o início

Posicione a aprovação imediatamente antes da ação que exige autoridade delegada. Revisar o texto do agente depois que uma alteração na conta já aconteceu não impede essa alteração.

O mecanismo de aprovação da OpenAI retorna uma execução pausada e um estado que permite retomá-la; a aplicação resolve a decisão pendente e dá continuidade ao processo. A mesma documentação alerta que as verificações de entrada e saída no nível do agente não envolvem cada chamada intermediária de ferramenta. Por isso, o ponto em que a ação é executada precisa de validação própria. Ciclo de aprovação e limites do workflow

Na implantação ilustrativa, o revisor vê a alteração exata na conta e a resposta juntas. Se a ação, o destinatário ou as evidências mudarem depois da revisão, exija uma nova decisão. Registre quem aprovou o quê, qual política se aplicava e se a execução correspondeu à aprovação.

Use a lista abaixo como ponto de partida para definir o que os logs devem registrar. Um trace conecta os eventos de um caso; um span registra uma operação individual dentro dele.

• Identidade do caso: identificador do caso, identificador do trace, evento de origem e referência da conta autenticada. Use referências em vez de duplicar os dados do cliente por toda parte.
• Configuração: identificador do modelo retornado pelo fornecedor, versão das instruções, versão do esquema das ferramentas e versão da política. Esses dados explicam qual comportamento estava em vigor.
• Evidências: identificadores dos documentos recuperados, revisões relevantes e escopo de acesso. Registre o que fundamentou a decisão sem copiar indiscriminadamente registros privados.
• Ações: nome da ferramenta, argumentos com dados sensíveis ocultados, registros de data e hora, duração, estado do resultado e identificador de nova tentativa ou de idempotência. Preserve informação suficiente para distinguir uma ação proposta de uma ação concluída.
• Decisões: resultados das validações, motivo do encaminhamento, estado da aprovação, referência do revisor e proposta aprovada.
• Resultado e consumo: estado final do chamado, efeitos confirmados das ações, resultado da entrega, consumo informado pelo fornecedor e rótulos de avaliação. Acompanhe correções feitas por clientes ou casos reabertos quando o sistema de suporte disponibilizar esses dados.

Esse é um esquema recomendado para a aplicação, não uma promessa de que um SDK coleta todos os campos automaticamente. Restrinja o acesso, defina a retenção e oculte segredos antes da exportação. Não exija o registro do raciocínio interno oculto do modelo: entradas, saídas, ações e evidências observáveis precisam sustentar a trilha de auditoria.

Os limites que importam e as promessas exageradas

O limite mais importante é a autoridade que você delega. Defina tetos explícitos para a duração da execução, a atividade das ferramentas e o uso de recursos, além de um caminho claro de encaminhamento. Escolha os valores com base na sua carga de trabalho e nos requisitos do serviço, em vez de copiar um limite arbitrário de uma demonstração.

Memória não é fonte da verdade. Se uma conversa salva diz que o cliente tem acesso, mas o sistema de contas diz o contrário, investigue a divergência nos registros oficiais atuais. Acumular mais texto na memória não corrige evidências desatualizadas.

MCP não concede permissão. A especificação de ferramentas continua exigindo controles de acesso e validação de entradas. Um conector que disponibiliza uma operação ampla precisa da mesma revisão das autorizações de negócio que uma API própria. Requisitos de segurança do MCP

Uma execução concluída não significa um caso bem resolvido. Avalie se a conta correta foi alterada, se a política foi seguida e se a resposta corresponde ao resultado. A orientação da OpenAI sobre avaliação vai da inspeção de rastros de execução ao uso de conjuntos de dados em avaliações repetíveis, para que as mudanças possam ser julgadas com critérios consistentes. Avaliação de workflows de agentes

Vários agentes não dispensam um responsável. Alguém precisa responder pela resposta final, pelas evidências compartilhadas e pelas exceções não resolvidas. Um especialista é útil porque tem uma responsabilidade diferente, não porque deixa o diagrama da arquitetura mais sofisticado.

Dúvidas sobre arquitetura de agentes

O que é arquitetura de agentes de IA?

A arquitetura de agentes de IA organiza decisões do modelo, ferramentas, memória, orquestração, controles e avaliação para que uma aplicação possa realizar uma tarefa. No contexto de negócios, ela também define quem pode autorizar ações e como verificar a conclusão do trabalho.

O que é um agente de IA?

Um agente de IA usa um modelo para selecionar ações em direção a um objetivo, observa os resultados e decide como continuar. Sua autonomia útil é delimitada pelas ferramentas, pelas permissões e pelas regras de parada fornecidas pela aplicação.

Quais são os tipos de arquitetura de agentes?

Uma distinção prática separa workflows predefinidos, um único agente que escolhe entre ferramentas e especialistas que colaboram entre si. A escolha depende de quanto a tarefa é previsível e de haver responsabilidades distintas que precisem de ferramentas, políticas ou responsáveis próprios. São padrões de implementação, não uma classificação universal.

Para começar na segunda-feira: desenhe o caso antes de escolher a stack

Comece agora se você tem uma fila de suporte com casos recorrentes, acesso aos registros de origem e uma pessoa responsável pelas exceções. Escolha um caso representativo e marque o evento de entrada, as leituras permitidas, as gravações propostas, o ponto de aprovação e as evidências necessárias para o encerramento. Rode o fluxo inicial em modo de rascunho e revisão. Depois, use as falhas observadas para decidir quais permissões podem ser ampliadas com responsabilidade.

Adie a execução autônoma se ainda não estiverem resolvidas a identidade da conta, a responsabilidade pela política ou a comprovação da conclusão. Enquanto resolve essas dependências, você pode melhorar a recuperação de informações e a qualidade dos rascunhos. Se o workflow já segue regras determinísticas confiáveis e não precisa do julgamento de um modelo, mantenha essa automação.

A primeira entrega deve ser um caso que você consiga explicar da entrada ao resultado, incluindo o que acontece quando a aprovação é negada ou o resultado de uma ferramenta é desconhecido.

Para receber guias práticos sobre como desenvolver e operar sistemas de IA, assine a newsletter.