Agentes de IA exigem mais que bons modelos. Exigem engenharia de autoridade.

Vejo que estamos atribuindo ao modelo capacidades que, na prática, pertencem à arquitetura inteira do agente. Essa distinção se torna particularmente importante quando sistemas de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → deixam de apenas responder e passam a consultar dados, utilizar ferramentas e executar ações.

Para entender essa arquitetura, precisamos separar modelo, workflow, agente, harness, ferramentas e ambiente de execução. Essas fronteiras não são universalmente padronizadas e variam entre implementações, mas a separação conceitual ajuda a entender onde estão capacidade, execução e controle.

O modelo interpreta o contexto disponível e produz inferências. Pode gerar texto, classificar informações, propor próximos passos e selecionar ou solicitar ferramentas. Isoladamente, isso não o transforma necessariamente em um agente.

A diferença entre workflow e agente está principalmente em onde fica a lógica que determina os próximos passos. Em um workflow, o caminho é predominantemente definido pelo software. Pode haver condições, desvios e decisões baseadas nas respostas de um LLM, mas a estrutura geral foi estabelecida pelos desenvolvedores.

Em sistemas mais agênticos, parte dessa escolha é delegada ao modelo. A partir do estado disponível, ele pode selecionar ferramentas, interpretar resultados e determinar próximos passos dentro dos limites definidos pelo sistema.

Não são categorias excludentes. Um workflow pode incorporar agentes e um agente pode operar dentro de processos maiores, com etapas determinísticas e limites predefinidos. Na prática, muitas arquiteturas empresariais serão híbridas.

O harness é uma forma útil de descrever o software ao redor do modelo que o conecta aos demais componentes. Pode organizar contexto, estado, memória quando necessária, ferramentas e ciclos de execução. Também pode implementar ou acionar políticas, verificações, observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → e controles. Mas não existe uma definição universal que determine que todas essas funções pertençam necessariamente ao harness.

Imagine pedir a um agente que analise um contrato, identifique riscos e compare suas cláusulas com políticas internas. O modelo pode solicitar o contrato. O sistema encaminha a solicitação à ferramenta apropriada, dentro das permissões existentes. O documento retorna como contexto. O modelo pode então solicitar outra fonte, comparar informações e propor o próximo passo.

Forma-se um ciclo de inferência, proposta de ação, execução, observação e nova inferência. É aqui que aparece uma distinção fundamental. Saber fazer, poder fazer e estar autorizado a fazer são coisas diferentes.

O modelo pode produzir uma solicitação para apagar um registro. Uma ferramenta pode ser tecnicamente capaz de executá-la. Isso não significa que a operação deva ser permitida.

A autorização precisa depender da identidade utilizada, de quem delegou aquela autoridade, das permissões concedidas, do recurso envolvido, do contexto da operação e das políticas aplicáveis.

Isso introduz uma questão frequentemente negligenciada em arquiteturas agênticas. Em nome de quem o agente está agindo?

Agentes que executam ações precisam de identidades e credenciais administráveis, permissões mínimas e, em determinados processos, segregação de funções. A capacidade técnica de executar uma operação não deve definir a autoridade para executá-la.

Existe também o ambiente de execução, ou runtime, no qual o software opera. É nele, juntamente com outras camadas de infraestrutura e controle, que se materializam muitas fronteiras concretas de acesso a sistemas, redes e recursos.

Quando agentes executam ações reais, problemas clássicos da engenharia reaparecem. Imagine que uma ferramenta processe um reembolso, mas a conexão caia antes de confirmar o resultado. Se o sistema simplesmente repetir a operação, poderá realizar dois reembolsos.

A arquitetura precisa saber verificar o estado anterior, tratar falhas e repetições, estabelecer limites de tempo, recuperar operações e, quando possível, compensar ou reverter ações. Agentes não eliminaram os problemas clássicos dos sistemas distribuídos. Acrescentaram componentes probabilísticos a eles.

A segurança também muda de dimensão. Um contrato, e-mail, página ou documento recuperado pode conter instruções maliciosas destinadas a influenciar o modelo. Conteúdo externo deve ser tratado como dado potencialmente não confiável, não como fonte automática de autoridade.

Informação não é instrução. E instrução não é autorização. Por isso, dizer ao modelo o que ele não deve fazer não equivale a impedir tecnicamente que determinada ação seja executada.

Controles críticos precisam existir também nas fronteiras de execução, por meio de identidade, permissões, validações determinísticas, isolamento, limites operacionais, aprovações e mecanismos de interrupção proporcionais ao risco.

Há ainda outro componente essencial. Observabilidade. Quando um agente age, precisamos conseguir reconstruir o que aconteceu. Qual objetivo recebeu, qual contexto relevante utilizou, quais ferramentas chamou, quais ações solicitou, sob qual identidade operou, quais políticas foram aplicadas, quais aprovações ocorreram e qual foi o resultado. Sem isso, investigar erros e atribuir responsabilidades se torna muito mais difícil.

Também não basta avaliar o sistema uma única vez. Mudanças no modelo, prompts, ferramentas, dados, políticas ou integrações podem alterar seu comportamento. Agentes empresariais precisam de avaliações antes da implantação, monitoramento em produção e critérios claros para ampliar, reduzir ou retirar autonomia. Isso explica por que melhorar o modelo não significa automaticamente melhorar o agente.

Um sistema empresarial depende também de dados confiáveis, integrações, identidade, estado, observabilidade, tratamento de falhas, políticas e controles. Mesmo trocar apenas o modelo exige reavaliar o comportamento do conjunto, especialmente seleção e uso de ferramentas. Um modelo excelente não compensa, por si só, uma arquitetura deficiente.

A distinção final pode ser resumida assim. O modelo fornece capacidade de inferência. O agente é o sistema configurado para executar tarefas orientadas a objetivos utilizando essa capacidade. O harness coordena parte da interação entre modelo e demais componentes. As ferramentas oferecem capacidades de consulta ou ação. O runtime fornece o ambiente no qual o software executa.

A autoridade precisa ser definida e aplicada por mecanismos externos à simples intenção expressa no prompt. Quando o sistema apenas responde, grande parte da avaliação está na qualidade da resposta. Quando começa a agir, surge outra disciplina. Precisamos determinar quem pode fazer o quê, em nome de quem, sobre quais recursos, em quais circunstâncias e dentro de quais limites.

Quanto maior a autonomia operacional concedida, maior deve ser a capacidade de observar, limitar, interromper e auditar suas ações. O desafio, portanto, não é apenas construir agentes mais capazes. É desenvolver uma verdadeira engenharia de autoridade para permitir que sistemas com componentes probabilísticos atuem no mundo real sem transformar capacidade técnica em autoridade irrestrita.