Um agente de IA empresarial não é um modelo de linguagem com um prompt longo. É um ciclo fechado: o modelo recebe um objetivo, escolhe uma ação, invoca uma ferramenta externa, lê o resultado e decide o passo seguinte — até o objetivo ser cumprido, até ficar bloqueado, ou até esgotar o orçamento de passos. Sob o capô existem apenas quatro componentes: modelo, ferramentas, memória e controlo. No inquérito da McKinsey de novembro de 2025 (1.993 inquiridos em cerca de 105 países), aproximadamente 62% das organizações estavam a fazer experiências com agentes, mas apenas cerca de 23% os tinham escalado, e a Gartner prevê que mais de 40% dos projetos de IA agêntica serão cancelados até ao final de 2027. Essa diferença quase nunca está no modelo.
O que realmente distingue um agente de um chatbot
A diferença não está na qualidade da resposta. Está em quem decide a ordem das operações. Num chatbot decide a pessoa: pergunta, recebe texto e decide o que fazer com ele. Na automação clássica decide o programador, à partida: o processo é escrito como um fluxograma e cada ramificação foi definida na fase de construção. Num agente, essa decisão passa para o tempo de execução — o modelo escolhe que ferramenta invocar, por que ordem e quando parar.
Esta é a única diferença que importa, e é também a origem de todos os riscos. A partir do momento em que a ordem das operações deixa de estar fixada à partida, não se consegue testar o sistema como se testa software comum, nem contar com que a execução bem-sucedida de ontem siga hoje o mesmo caminho.
| Propriedade | Chatbot | Automação clássica | Agente |
|---|---|---|---|
| Quem define a ordem das operações | O utilizador | O programador, na fase de construção | O modelo, em tempo de execução |
| Acesso a sistemas | Normalmente nenhum | Fixo e predefinido | Dinâmico, através de uma camada de ferramentas |
| Comportamento em caso de falha | Devolve uma resposta errada | Para e comunica um erro | Continua e agrava o erro |
| O que se testa antes do lançamento | Qualidade da formulação | Caminhos conhecidos | Distribuição dos resultados ao longo das execuções |
A linha essencial: uma automação que se avaria para. Um agente que se avaria continua a trabalhar. É por isso que o controlo é um componente do sistema e não algo que se acrescenta no fim.
O ciclo de execução: planear, agir, observar
Independentemente do fornecedor, da linguagem ou da framework, todos os agentes correm o mesmo ciclo. O modelo recebe o objetivo e o estado atual do mundo, produz uma decisão sobre o passo seguinte, emite uma chamada a uma ferramenta externa, recebe um resultado — e volta a executar-se com esse resultado como parte do seu contexto. O ciclo termina quando o modelo declara que terminou, quando uma ferramenta devolve um erro bloqueante, ou quando um mecanismo externo o interrompe.
A palavra importante aqui é observar. O agente não sabe nada sobre o mundo exceto o que as ferramentas lhe devolvem em texto. Se o CRM devolver um campo vazio, então, para o agente, o cliente não tem mesmo número de telefone. A qualidade da observação é por isso uma variável de engenharia de primeira ordem, e não um detalhe técnico.
| Fase do ciclo | O que acontece na prática | Modo de falha típico |
|---|---|---|
| Receção do objetivo | O objetivo torna-se contexto inicial, ao lado das instruções de sistema | Um objetivo vago que produz um caminho diferente em cada execução |
| Planeamento do passo | O modelo seleciona uma ferramenta e os seus argumentos | Ferramenta certa, argumento errado — a falha mais comum de todas |
| Execução | A camada de ferramentas corre a chamada contra o sistema real | Uma permissão demasiado ampla que autoriza uma ação destrutiva |
| Observação | O resultado regressa ao contexto | Um payload longo que empurra para fora informação crítica anterior |
| Decisão | Continuar ou parar | Um ciclo infinito que consome orçamento até ao teto |
Os quatro componentes de que qualquer agente é feito
Desmonte um agente e obtém quatro componentes. Três deles não são o modelo, e é aí que vive a maior parte do trabalho de engenharia e quase toda a falha.
| Componente | A sua função | O que se parte quando é fraco |
|---|---|---|
| Modelo | Produz a decisão sobre o passo seguinte | Formulação elegante com raciocínio defeituoso; atualizar o modelo não corrige os outros componentes |
| Ferramentas | A única interface do agente com a realidade | Uma descrição imprecisa da ferramenta leva a uso indevido mesmo com um modelo excelente |
| Memória e contexto | O que o agente sabe no momento da decisão | Informação crítica empurrada para fora, ou contexto poluído que arrasta o agente para o caminho errado |
| Controlo | Limites, permissões, orçamento de passos e pontos de aprovação | Nenhuma forma de travar um erro antes de tocar num cliente ou num sistema |
Nos projetos que vemos, a primeira reação quando algo não funciona é quase sempre trocar de modelo. Na maioria dos casos não é esse o problema. Descrições precisas das ferramentas, saída estruturada em vez de texto livre e uma condição de paragem clara melhoram a taxa de sucesso mais do que qualquer atualização de modelo.
A camada de ferramentas: o que o MCP mudou realmente
Até há pouco tempo, cada ligação entre um modelo e um sistema empresarial era escrita de raiz: uma integração à medida para cada combinação de modelo e sistema. O Model Context Protocol substituiu isso por uma camada uniforme — um servidor que declara ferramentas e um cliente que as invoca.
A revisão estável da especificação, datada de 28 de julho de 2026, é a maior revisão do protocolo desde o seu lançamento. As sessões ao nível do protocolo e o cabeçalho Mcp-Session-Id foram removidos do transporte Streamable HTTP; o handshake initialize foi eliminado; e as listas de ferramentas, recursos e prompts deixaram de variar por ligação, o que as torna cacheáveis. A par disso chegaram pedidos com múltiplas idas e voltas, encaminhamento baseado em cabeçalhos, uma framework formal de extensões e uma autorização reforçada. Um servidor que precisa de estado entre chamadas recebe-o agora através de um handle explícito emitido pelo servidor e passado como argumento normal de ferramenta.
Porque é que isto importa a quem não escreve código: um protocolo sem estado pode ser implementado atrás de um balanceador de carga padrão, escalado horizontalmente e monitorizado com ferramentas comuns. Por outras palavras, a camada de ferramentas deixou de ser um projeto de investigação e passou a ser infraestrutura que se orça, opera e audita. Se planeia correr essa camada na sua própria infraestrutura, o modelo de custos completo está no nosso guia para correr agentes no seu próprio hardware.
O contexto é um orçamento, não um armazém
O erro de conceção mais comum é tratar a janela de contexto como armazenamento. Não é. É um orçamento consumido a cada passo, e paga-se por ele de novo em cada chamada. Um agente que corre vinte passos paga vinte vezes o seu próprio histórico.
Daqui decorrem três decisões de conceção. Devolver das ferramentas saída estruturada e compacta em vez de documentos inteiros. Comprimir o histórico num resumo de estado ao fim de um número fixo de passos. Ir buscar o conhecimento empresarial em tempo de execução em vez de o pré-carregar. O lado financeiro dessas decisões está tratado no nosso guia para reduzir o custo de inferência.
Onde isto se parte na prática
Três causas explicam a maior parte das falhas que encontramos.
Erros que se acumulam. Num ciclo, um erro no passo três não fica no passo três. Entra no contexto e a partir daí alimenta todas as decisões seguintes. A falha visível aparece por isso longe do sítio onde foi criada, razão pela qual depurar um agente exige seguir uma execução inteira em vez de inspecionar uma única resposta.
Medição otimista. A métrica de sucesso habitual pergunta se o agente conseguiu uma vez em condições favoráveis. Em produção o que conta é a estabilidade: a mesma tarefa, cem execuções, quantas terminaram corretamente. A distância entre esses dois números é a distância entre uma demonstração impressionante e um sistema em que se pode confiar. Fechá-la é o tema do nosso guia de avaliação de agentes.
Agent washing. A Gartner estima que, entre os milhares de fornecedores que promovem capacidade agêntica, apenas cerca de 130 oferecem a coisa real; os restantes estão a rebatizar assistentes existentes, RPA e chatbots. A pergunta que filtra mais depressa numa reunião comercial: que ferramentas é que este agente consegue invocar, e quem decide quando as invoca.
A mesma nota da Gartner contém o outro lado da história: até 2028, cerca de 15% das decisões de trabalho do dia a dia serão tomadas de forma autónoma e 33% das aplicações de software empresarial incluirão capacidade agêntica, face a menos de 1% em 2024. A direção é clara; o que se parte é o calendário e as expectativas.
Uma checklist antes do seu primeiro agente
- Defina uma tarefa que termina. Uma tarefa com uma condição de conclusão inequívoca, e não uma área de responsabilidade em aberto.
- Conte as ferramentas. Se um primeiro agente tem mais de dez ferramentas, é provável que tenha mapeado um cargo em vez de uma tarefa.
- Escreva as descrições das ferramentas como contratos. O que entra, o que sai, o que acontece em caso de falha e quando é que a ferramenta não deve ser usada.
- Defina um orçamento de passos e um orçamento de tokens. Um teto rígido que trava o ciclo mesmo quando o modelo está convencido de que vai no caminho certo.
- Marque as ações irreversíveis. Enviar email, cobrar, apagar, atualizar um estado visível para o cliente — tudo isto precisa de um ponto de aprovação humana.
- Defina as permissões antes de escrever um prompt. É o modelo de permissões que limita os danos, não a redação das instruções. O tratamento completo está no nosso guia sobre as fronteiras do agente.
- Registe todas as execuções. Sem um registo completo de chamadas e resultados não há depuração nem melhoria.
Se preferir começar por uma avaliação estruturada de prontidão, comece pelas nossas áreas de especialização. Se já sabe o que quer pôr a correr, fale connosco sobre a fase de implementação.
Perguntas frequentes
Qual é a diferença entre um agente de IA e a automação comum?
Na automação, a ordem das operações é fixada à partida por um programador. Num agente, o modelo escolhe as suas ações em tempo de execução, com base no objetivo e no que observa. A automação testa-se por isso ao longo de caminhos conhecidos, enquanto um agente se testa pela distribuição dos resultados ao longo de execuções repetidas.
Preciso de um modelo especialmente forte para construir um agente?
Na maioria dos casos não. A taxa de sucesso é determinada mais pela qualidade das descrições das ferramentas, pela gestão do contexto e pelas condições de paragem do que pela escolha do modelo. Um modelo mais forte esconde problemas de conceção durante algum tempo, mas também torna mais caro cada passo do ciclo.
O que é o MCP e porque é que toda a gente fala dele?
O Model Context Protocol é um protocolo uniforme para ligar modelos a ferramentas e fontes de dados. A revisão estável de 28 de julho de 2026 tornou-o sem estado: acabaram as sessões ao nível do protocolo, as listas de ferramentas passaram a ser cacheáveis e a autorização foi reforçada. Na prática, isto permite implementar uma camada de ferramentas como infraestrutura normal em vez de como um projeto pontual.
Quanto tempo demora a pôr um primeiro agente em produção?
Uma tarefa única com três a cinco ferramentas e um ponto de aprovação humana chega normalmente a produção em quatro a oito semanas. A maior parte desse tempo não é gasta a construir o ciclo; é gasta na integração limpa com os sistemas, na conceção das permissões e na construção do conjunto de testes.
Qual é o sinal de que um agente não é a solução certa para uma tarefa?
Se conseguir escrever o processo como um fluxograma completo, sem decisões ambíguas, não precisa de um agente — a automação será mais barata, mais rápida e testável. Um agente compensa quando o espaço de possibilidades é demasiado largo para ser escrito à partida.