Agentes de IA: o que são, como funcionam e como criar um
Agentes de IA vão além do chatbot: recebem objetivos, escolhem ferramentas, mantêm estado e executam etapas. Entenda a arquitetura, os riscos e como criar um agente útil.
Um chatbot responde.
Um agente age.
Essa é a diferença mais simples — e também a mais perigosa de simplificar demais.
Quando você conversa com um modelo de linguagem e pergunta “qual é a previsão do tempo?”, ele pode responder usando conhecimento ou uma busca. Quando você diz “reagende minha reunião, avise as pessoas e atualize o documento do projeto”, a tarefa exige outra arquitetura: interpretar um objetivo, decidir etapas, acessar ferramentas, observar resultados, corrigir o plano e executar ações em sistemas reais.
É aí que entramos no terreno dos agentes de IA.
Nos últimos anos, o termo virou rótulo para quase tudo: chatbot com function calling, automação com LLM, workflow no n8n, assistente de programação, sistema multiagente e até scripts que apenas chamam uma API.
Isso cria confusão.
Por isso, antes de pensar em frameworks, MCP, memória ou squads de agentes, vale construir uma definição operacional.
Um agente de IA é um sistema no qual um modelo recebe um objetivo, interpreta o estado atual, escolhe entre ações disponíveis, usa ferramentas e repete esse ciclo até produzir um resultado ou chegar a um limite definido.
O ponto importante não é “usar IA”.
É delegar parte da decisão sobre o próximo passo ao modelo.
Essa mudança parece pequena. Na prática, transforma a IA de componente de geração em componente de operação.
Chatbot, workflow e agente não são a mesma coisa
Comecemos separando três arquiteturas.
Chatbot
O fluxo costuma ser:
usuário
↓
mensagem
↓
modelo
↓
resposta
O modelo pode ter contexto, memória e busca, mas a principal saída continua sendo uma resposta.
Workflow com IA
Agora existe um caminho definido pelo software:
formulário
↓
classificar texto com IA
↓
consultar banco
↓
gerar resumo
↓
enviar e-mail
A IA participa do processo, mas o código já decidiu a sequência.
Anthropic usa uma distinção útil: workflows seguem caminhos predefinidos; agents deixam o modelo dirigir dinamicamente parte do processo e do uso de ferramentas.
Agente
O fluxo muda:
objetivo
↓
modelo observa o contexto
↓
escolhe uma ação
↓
usa uma ferramenta
↓
recebe o resultado
↓
decide o próximo passo
↓
...
↓
resultado
A diferença está no loop.
O software define regras, ferramentas, limites e ambiente.
O modelo decide, dentro desses limites, o que fazer a seguir.
Um agente não é apenas um LLM com um nome
A forma mais útil de pensar em agentes é como um sistema formado por camadas.
Uma arquitetura mínima costuma ter:
objetivo
↓
instruções
↓
modelo
↓
orquestração / estado
↓
tools
↓
sistemas externos
↓
observação
↺
Cada camada resolve um problema diferente.
1. O modelo
O modelo é o mecanismo de interpretação e decisão.
Ele recebe:
- a solicitação;
- instruções;
- contexto disponível;
- descrição das ferramentas;
- resultados anteriores;
- eventualmente memória ou conhecimento recuperado.
Então decide se precisa:
- responder;
- pedir mais informação;
- chamar uma ferramenta;
- delegar;
- executar outra etapa;
- encerrar.
Um modelo melhor pode aumentar a qualidade das decisões.
Mas isso não transforma automaticamente um sistema ruim em agente confiável.
Já escrevi sobre esse ponto em O modelo não é o produto: em aplicações reais, arquitetura, contexto, ferramentas, validação, custo e controle importam tanto quanto o modelo.
2. As instruções
Um agente precisa saber qual trabalho executa.
Não basta:
“Você é um agente útil.”
Uma especificação melhor contém:
- objetivo;
- fronteiras;
- critérios de sucesso;
- decisões permitidas;
- decisões proibidas;
- quando pedir ajuda;
- formato esperado;
- regras de segurança.
Por exemplo:
Objetivo:
qualificar leads recebidos pelo formulário.
Pode:
- consultar CRM;
- consultar histórico de contato;
- sugerir prioridade;
- criar tarefa para vendedor.
Não pode:
- enviar proposta;
- alterar preço;
- excluir registros;
- prometer prazo ao cliente.
Escalar para humano quando:
- valor estimado > R$ 50 mil;
- dados estiverem inconsistentes;
- cliente solicitar condição fora da política.
Isso é muito mais próximo de um contrato operacional.
3. As tools
Tools são as capacidades do agente.
Sem tools, o modelo pode pensar e gerar texto.
Com tools, ele pode interagir com o mundo.
Exemplos:
- buscar dados;
- consultar banco;
- criar ticket;
- enviar mensagem;
- executar SQL;
- chamar API;
- manipular arquivo;
- rodar testes;
- abrir pull request;
- controlar navegador;
- disparar workflow.
OpenAI descreve agentes como unidades que combinam modelo, instruções e capacidades como tools, MCP, guardrails e handoffs. Google também coloca tools como uma das peças centrais: são elas que transformam raciocínio em ação.
Mas uma ferramenta mal desenhada aumenta o risco.
Compare:
execute_sql(query)
com:
buscar_cliente_por_email(email)
criar_tarefa_comercial(cliente_id, descricao)
registrar_nota(cliente_id, nota)
A primeira entrega poder enorme e pouco contexto.
As outras expõem operações mais estreitas, compreensíveis e auditáveis.
Anthropic resume isso de forma prática: agentes são tão bons quanto as ferramentas disponíveis.
4. O estado e a memória
Um agente que executa tarefas em múltiplas etapas precisa lembrar onde está.
Imagine:
- buscar pedido;
- verificar política;
- consultar pagamento;
- decidir se pode reembolsar;
- executar ação;
- registrar evidência.
Se o sistema perde o estado entre as etapas, o agente não sabe o que já verificou.
Por isso precisamos distinguir algumas coisas.
Contexto de trabalho
Informação necessária para esta execução.
Estado
O que já aconteceu no processo.
Memória persistente
Informações que devem continuar disponíveis depois desta execução.
Conhecimento externo
Documentos, banco, RAG, APIs ou outras fontes consultadas quando necessário.
Misturar tudo numa enorme janela de contexto é possível em demos.
Em produção, normalmente precisamos decidir explicitamente o que guardar, por quanto tempo e para quê.
5. A orquestração
A orquestração controla o loop.
Em pseudocódigo:
estado = iniciar(objetivo)
enquanto estado.nao_finalizado:
decisao = modelo.decidir(
objetivo,
instrucoes,
estado,
ferramentas
)
se decisao.tipo == "tool":
resultado = executar_com_controle(decisao.tool)
estado.registrar(resultado)
se decisao.tipo == "perguntar":
pausar_e_pedir_entrada()
se decisao.tipo == "finalizar":
validar_saida()
encerrar()
Na prática entram mais componentes:
- timeouts;
- retry;
- limites de passos;
- validação de argumentos;
- autenticação;
- autorização;
- tracing;
- aprovações;
- tratamento de falhas.
É aqui que um “prompt esperto” vira engenharia de software.
Como um agente trabalha na prática
Imagine um agente de suporte para pedidos.
O usuário escreve:
“Meu pedido não chegou. Quero saber o que aconteceu.”
O agente pode executar algo como:
Etapa 1 — identificar o cliente
Tool:
buscar_cliente(email)
Etapa 2 — localizar o pedido
Tool:
listar_pedidos(cliente_id)
Etapa 3 — consultar logística
Tool:
consultar_rastreamento(pedido_id)
Resultado:
status: retido na transportadora
motivo: endereço incompleto
Etapa 4 — decidir
As regras dizem:
- endereço incompleto pode ser corrigido;
- reenvio exige confirmação do cliente;
- reembolso acima de determinado valor precisa de aprovação humana.
Etapa 5 — agir
O agente pergunta:
“O endereço cadastrado termina em 125. Deseja corrigir antes de solicitar o reenvio?”
Perceba a diferença.
O agente não apenas respondeu uma pergunta.
Ele:
- observou;
- consultou ferramentas;
- aplicou regras;
- escolheu o próximo passo;
- pausou para obter autorização.
Isso é agentic.
Autonomia não é binária
Um erro comum é pensar:
manual ←──────────────→ autônomo
como se existissem apenas dois estados.
Na prática, podemos desenhar níveis.
Nível 1 — recomendação
O agente analisa e sugere.
Humano executa.
Nível 2 — preparação
O agente cria rascunho, proposta, query ou mudança.
Humano aprova.
Nível 3 — execução limitada
O agente pode executar ações de baixo risco.
Ações sensíveis exigem aprovação.
Nível 4 — execução ampla
O agente possui maior autonomia dentro de políticas e limites.
Essa escala é útil porque mais autonomia não significa automaticamente melhor sistema.
Para muitos casos, o nível 2 ou 3 entrega boa parte do ganho com muito menos risco.
Quando usar agente — e quando não usar
Agentes são interessantes quando:
- a sequência exata de passos varia;
- o sistema precisa interpretar situações novas;
- existem várias tools possíveis;
- o agente precisa buscar informação antes de decidir;
- a tarefa envolve exceções;
- um workflow fixo seria grande e frágil;
- há valor suficiente para justificar custo e complexidade.
Mas se o processo for:
se pagamento aprovado:
enviar nota
senão:
avisar financeiro
você provavelmente não precisa de um agente.
Código tradicional é:
- mais barato;
- mais previsível;
- mais fácil de testar;
- mais fácil de auditar.
Anthropic recomenda explicitamente começar pela solução mais simples e aumentar a complexidade apenas quando o problema justificar.
Esse conselho é importante.
“Agentificar” tudo é tão ruim quanto tentar resolver tudo com microsserviços.
Como criar seu primeiro agente
Vamos transformar a arquitetura em um processo prático.
Passo 1 — escolha uma tarefa estreita
Evite começar com:
“agente que administra minha empresa.”
Prefira:
“agente que recebe tickets novos, consulta documentação e prepara uma resposta para revisão humana.”
A tarefa precisa ter:
- entrada clara;
- objetivo claro;
- ferramentas definidas;
- saída verificável.
Passo 2 — escreva o contrato
Defina:
entrada
objetivo
tools
limites
critérios de sucesso
condições de parada
condições de escalonamento
Se você não consegue escrever isso, ainda não entende suficientemente o processo para automatizá-lo com segurança.
Passo 3 — exponha poucas ferramentas
Comece pequeno.
Por exemplo:
buscar_documentacao(query)
buscar_ticket(id)
salvar_rascunho(ticket_id, texto)
Não exponha acesso administrativo inteiro “porque pode ser útil depois”.
Cada tool aumenta:
- superfície de decisão;
- superfície de erro;
- superfície de segurança.
Passo 4 — crie validação
Se o agente produz saída estruturada, valide.
Se chama ferramenta, valide argumentos.
Se modifica dado crítico, valide estado anterior.
Se existe política, transforme parte dela em código determinístico.
Um bom padrão é:
modelo decide
↓
código valida
↓
ação acontece
e não:
modelo decide
↓
ação acontece diretamente
Passo 5 — limite o loop
Todo agente precisa de condições de parada.
Por exemplo:
- máximo de 8 passos;
- timeout de 90 segundos;
- máximo de 3 falhas de tool;
- orçamento de custo;
- necessidade de aprovação em determinadas ações.
Sem limites, um erro de raciocínio pode virar:
- loop;
- custo;
- spam;
- alterações repetidas.
Passo 6 — registre tudo o que importa
Você precisa conseguir responder:
- qual instrução estava ativa?
- qual modelo foi usado?
- quais tools estavam disponíveis?
- qual tool foi chamada?
- com quais argumentos?
- qual resultado voltou?
- por que a execução parou?
- quem aprovou uma ação sensível?
Isso é observabilidade de agentes.
O artigo Agentes em produção: migração, permissões e segurança aprofunda exatamente essa camada.
Passo 7 — crie avaliações
“Funcionou comigo” não é benchmark.
Monte casos.
caso 1: pedido normal
caso 2: dado ausente
caso 3: política ambígua
caso 4: ferramenta falha
caso 5: usuário pede ação proibida
caso 6: informação conflitante
Depois meça:
- taxa de conclusão;
- decisão correta;
- uso correto de tools;
- número de passos;
- custo;
- necessidade de intervenção;
- erros críticos.
Agentes são sistemas probabilísticos operando sobre software determinístico.
Avaliação é a ponte entre os dois.
Passo 8 — aumente autonomia devagar
Primeiro:
agente prepara.
Depois:
agente executa ações reversíveis.
Só então considere:
agente executa ações de impacto maior.
Autonomia deveria ser conquistada por evidência.
Não presumida pela qualidade de uma demo.
E onde entra o MCP?
MCP — Model Context Protocol — é uma forma padronizada de conectar sistemas de IA a ferramentas, recursos e fontes externas.
Em vez de cada aplicação inventar uma integração exclusiva, um servidor MCP pode expor capacidades para clientes compatíveis.
Mas MCP não “transforma algo em agente”.
Ele resolve outra camada:
agente
↓
como acessar ferramentas/contexto?
↓
MCP pode ser uma das respostas
Um agente também pode usar:
- function calling;
- SDKs;
- REST APIs;
- CLI;
- banco;
- browser;
- integrações nativas.
MCP será um dos próximos conteúdos deste cluster porque vale ser entendido separadamente.
Um agente precisa de memória?
Não necessariamente.
Essa é outra confusão comum.
Um agente simples pode concluir uma tarefa em uma única execução usando apenas o estado daquela sessão.
Memória persistente faz sentido quando existe valor em lembrar algo depois.
Exemplos:
- preferência do usuário;
- histórico operacional;
- decisão anterior;
- contexto de projeto;
- conhecimento aprendido.
Mas guardar tudo também cria problemas:
- privacidade;
- dados obsoletos;
- contexto irrelevante;
- custo;
- conflito de informação.
A pergunta não é:
“Como coloco memória no agente?”
É:
“Qual informação futura realmente melhora a próxima decisão?”
Multiagente é melhor que um agente?
Também não.
Você pode criar:
agente gerente
├── agente pesquisa
├── agente código
├── agente teste
└── agente revisão
Isso pode ser útil quando existem especializações e fronteiras claras.
Mas também adiciona:
- coordenação;
- mais chamadas;
- mais custo;
- mais latência;
- mais estados;
- mais pontos de falha.
Um único agente com boas tools pode ser melhor que cinco agentes conversando entre si.
Arquitetura multiagente deve resolver um problema.
Não servir como decoração técnica.
O principal risco muda quando a IA pode agir
Quando um modelo apenas gera texto, uma alucinação pode virar uma resposta errada.
Quando um agente possui tools, a mesma classe de erro pode virar:
- registro alterado;
- arquivo apagado;
- código publicado;
- mensagem enviada;
- pagamento iniciado;
- permissão concedida.
Por isso, segurança de agentes precisa combinar segurança tradicional com controles específicos.
NIST publicou em 2026 uma análise sobre segurança de agentes e encontrou amplo consenso de que eles introduzem ameaças novas e exigem adaptação das práticas de cybersecurity.
Alguns controles básicos:
Menor privilégio
Dê apenas as permissões necessárias.
Tools estreitas
Prefira ações específicas a interfaces administrativas genéricas.
Aprovação humana
Ações irreversíveis ou de alto impacto devem poder pausar.
Isolamento
Execução de código e arquivos precisa de sandbox quando aplicável.
Validação determinística
Nunca delegue ao modelo aquilo que pode ser garantido de forma barata por código.
Auditoria
Ação importante precisa deixar rastro.
O perigo da prompt injection
Imagine um agente que:
- lê páginas da web;
- acessa seu e-mail;
- possui tool para enviar mensagens.
Uma página externa pode conter instruções maliciosas tentando convencer o modelo a usar suas tools de forma indevida.
O agente precisa distinguir:
instrução confiável do sistema
≠
conteúdo externo não confiável
Esse problema não é resolvido por “um prompt melhor”.
Ele exige arquitetura:
- separar dados de instruções;
- restringir tools;
- limitar credenciais;
- validar destino;
- exigir aprovação quando necessário.
Agentes não eliminam engenharia de software
Eles aumentam a importância dela.
Um bom agente precisa de:
- contratos;
- APIs;
- autenticação;
- autorização;
- estado;
- filas;
- logs;
- testes;
- observabilidade;
- rollback;
- tratamento de erro.
A diferença é que agora existe uma camada probabilística escolhendo algumas transições.
Isso faz com que disciplina de engenharia seja ainda mais valiosa.
Como saber se seu agente é bom
Eu usaria uma pergunta simples:
ele produz resultados válidos de forma repetível, com custo e risco aceitáveis?
Não:
“ele parece inteligente?”
Um agente impressionante numa conversa pode ser péssimo operacionalmente.
Meça:
resultado válido
───────────────
custo + tempo + risco
No artigo Quando um agente de IA fica realmente mais barato que um funcionário?, eu aprofundo essa unidade econômica: o que importa não é token barato, mas custo por resultado aceito.
Um exemplo de arquitetura segura
Imagine um agente comercial.
Em vez de:
agente
↓
acesso total ao CRM
↓
faz qualquer alteração
podemos criar:
┌→ buscar_cliente
│
objetivo → agente ──┼→ listar_oportunidades
│
├→ criar_rascunho_followup
│
└→ solicitar_aprovacao
↓
humano
↓
enviar_followup
A IA continua tomando decisões úteis.
Mas a arquitetura limita o blast radius.
Esse é o tipo de sistema que me interessa muito mais do que “agente 100% autônomo” usado como slogan.
O melhor primeiro agente é pequeno
Se você quiser experimentar hoje, escolha algo que:
- você já sabe fazer manualmente;
- acontece com frequência;
- possui critérios claros;
- usa poucas ferramentas;
- tem erro reversível;
- consegue ser avaliado.
Algumas ideias:
Desenvolvimento
Agente que recebe issue, investiga arquivos e prepara patch para revisão.
Conteúdo
Agente que pesquisa fontes, cria outline e marca afirmações que precisam de conferência.
Suporte
Agente que consulta base de conhecimento e prepara resposta.
Vendas
Agente que pesquisa lead e gera briefing para uma conversa.
Operação
Agente que analisa logs e sugere diagnóstico sem executar mudanças automaticamente.
Começar pequeno não reduz ambição.
Aumenta a chance de aprender o que realmente precisa ser automatizado.
O que muda daqui para frente
Agentes de IA estão deslocando a interface com software.
Antes, nós mesmos navegávamos por telas e APIs.
Agora, cada vez mais podemos expressar um objetivo e deixar um sistema decidir parte dos passos intermediários.
Isso é poderoso.
E cria uma nova responsabilidade.
Quanto maior a capacidade de ação, mais importantes ficam:
- limites;
- observabilidade;
- avaliação;
- identidade;
- autorização;
- supervisão;
- engenharia.
O futuro interessante dos agentes não é um mundo em que ninguém controla nada.
É um mundo em que software consegue fazer mais trabalho sob contratos claros e verificáveis.
Essa diferença separa automação útil de autonomia irresponsável.
Um checklist para seu primeiro agente
Antes de colocar qualquer agente em produção, responda:
- Qual é o objetivo exato?
- Como sei que ele concluiu corretamente?
- Quais tools ele realmente precisa?
- Que ações são reversíveis?
- O que exige aprovação?
- Qual o limite de passos?
- Qual o limite de custo?
- O que fica registrado?
- Como testo casos ruins?
- O que acontece quando uma tool falha?
- Como revogo acesso?
- Como paro a execução?
Se essas respostas não existem, ainda não existe um agente pronto para produção.
Existe uma demo.
Próximo nível
Se você já entendeu a arquitetura — modelo, instruções, tools, estado, avaliação e controle — o próximo passo é construir sistemas reais e medir o que acontece quando eles saem da demo.
No AIStack, eu aprofundo justamente essa transição: sistemas com IA, agentes, tools, RAG, custo, avaliação e segurança como engenharia, não como coleção de prompts.
Nos próximos conteúdos deste cluster, vamos separar componentes que merecem ser entendidos individualmente — especialmente MCP, diferença entre agentes e chatbots, uso de agentes no n8n e comparação entre arquiteturas agentic.
Uma resposta