O que é um agente de IA?

Um agente de IA é um sistema guiado por LLM que persegue um objetivo em loop: raciocina, chama uma tool, observa o resultado e repete. Uma chamada simples de LLM responde e para; um agente envolve essa chamada num loop de controle com tools (funções que ele pode invocar), memória (estado entre os passos) e autonomia suficiente para escolher a própria sequência de ações. A virada de chave para quem desenvolve backend é o fato mais simples e menos dito sobre agentes: as “tools” de um agente são os seus endpoints de backend — quando um agente “usa uma tool”, ele está chamando uma API que você escreveu, o que faz do seu backend, e não do prompt, o lugar onde a segurança realmente mora.

Principais pontos

Como funciona o loop de raciocínio de um agente de IA (ReAct)

OBJETIVO: "Reembolse meu último pedido e me envie a confirmação"

  ┌────────────────────────────────────────────────┐
  │ 1 REASON   modelo: "qual é o último pedido?"     │
  │ 2 ACT      chama tool: find_orders(user, last=1) │
  │ 3 OBSERVE  resultado: pedido #1187, $42, entregue│
  │ 4 REASON   "elegível — reembolsar"               │
  │ 5 ACT      chama tool: refund_order(1187)        │◄─ cada ACT atinge
  │ 6 OBSERVE  resultado: reembolsado                │   o SEU backend
  │ 7 REASON   "agora enviar o e-mail"               │
  │ 8 ACT      chama tool: send_email(...)           │
  │ 9 REASON   "pronto" → resposta final             │
  └────────────────────────────────────────────────┘

O modelo nunca executa uma tool. Ele SOLICITA uma (nome + argumentos);
seu código a executa e devolve o resultado para o próximo passo de raciocínio.

As tools desse loop, no backend — com escopo, com permissões, rodando como o usuário:

// JavaScript — Cloud Code (cloud/main.js)
// An agent's "tool" is a backend function — scoped, permissioned, auditable
Parse.Cloud.define('refundOrder', async (req) => {
  // Runs under the CALLING USER's session — ACLs gate everything.
  // A hijacked agent can't exceed what this user may already do.
  const order = await new Parse.Query('Order').get(req.params.orderId);
  // beforeSave/ACL checks apply: not your order → this throws, agent or not
  if (order.get('amount') > 100) throw 'Refunds over $100 need human approval';
  order.set('status', 'refunded');
  await order.save();
  return { refunded: order.id }; // the tool result the model reasons over next
});
// The backend, not the prompt, is the security boundary.

// Flutter / Dart — Back4app Flutter SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
final result = await ParseCloudFunction('runAgent')
    .execute(parameters: {'goal': 'Refund my last order and email me'});
print(result.result);
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

// iOS / Swift — Back4app Swift SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
let result: [String: Any] = try await Cloud.run(
    name: "runAgent",
    parameters: ["goal": "Refund my last order and email me"])
print(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

// Android / Kotlin — Back4app Android SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
val params = mapOf("goal" to "Refund my last order and email me")
val result = ParseCloud.callFunction<Map<String, Any>>("runAgent", params)
println(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

Os quatro componentes centrais de um agente de IA

A decomposição canônica é modelo + planejamento + memória + uso de tools, mas a versão operacional é mais simples: um modelo raciocina, tools agem (e elas são funções do backend), a memória guarda o estado — curto prazo na janela de contexto, longo prazo num banco de dados ou vector store — e o loop de orquestração amarra tudo, baseado no padrão ReAct de intercalar raciocínio e ação.

Agente vs. chatbot vs. chamada de LLM vs. workflow

A distinção que mais importa, e que quase nenhum glossário traça: um workflow é orquestração por caminhos de código predefinidos; um agente deixa o modelo dirigir o próprio caminho. A orientação da Anthropic é direta sobre a consequência — a maioria das tarefas que parecem precisar de um agente é mais bem servida por um workflow determinístico, e você só adiciona agência quando o caminho genuinamente não pode ser roteirizado.

Confiabilidade: os erros se compõem para baixo

A seção honesta que as páginas de vendor evitam. Agentes são impressionantes por passo e frágeis por cadeia, porque o sucesso se multiplica: se cada passo tem probabilidade de sucesso p, uma tarefa de n passos tem sucesso de aproximadamente pⁿ.

sucesso por passo   10 passos   20 passos
      95%             ~60%        ~36%
      90%             ~35%        ~12%
      85%             ~20%         ~4%

Uma demo que acerta um passo impressionante não é um sistema que acerta vinte.
No mundo real, o sucesso de agentes multi-passo entre sistemas fica muitas vezes em 20–40%.

Essa matemática dita o manual de produção: mantenha as cadeias curtas, verifique os resultados entre os passos em vez de confiar neles, coloque ações irreversíveis (enviar, apagar, cobrar, publicar) atrás de aprovação humana e limite o loop com tetos de passos e de custo, para que um agente confuso falhe barato em vez de caro. Confiabilidade não é uma propriedade do modelo que você espera melhorar; é uma arquitetura que você impõe.

A superfície de segurança

Um agente que pode agir pode ser enganado para agir, o que faz dele uma superfície de ataque genuinamente nova. Prompt injection transforma instruções na entrada do modelo em ações reais — e a variante perigosa é a indireta: uma página web envenenada, um e-mail ou um ticket de suporte que o agente lê pode carregar instruções que ele então executa com as suas credenciais. Confused deputy é o formato do estrago: um agente com permissões amplas, manipulado para usá-las mal em nome de um atacante. As mitigações são disciplina de segurança antiga mirando um ator novo — credenciais de menor privilégio, com escopo do usuário (nunca dê ao agente mais do que o usuário da tarefa já tem), tools negadas por padrão e de escopo estreito, sandboxing e aprovação humana em tudo que for irreversível. O enquadramento mais importante de todos: o backend, não o prompt, é a fronteira de segurança. Um prompt pode ser injetado; uma checagem de permissão no servidor não pode ser convencida a deixar de se aplicar.

Como projetar tools que um agente não consegue usar mal

Como as tools são o seu backend, design de tool é segurança de backend com o volume no máximo. Torne cada tool idempotente onde possível (um reembolso repetido não deve reembolsar em dobro), de escopo estreito (uma ação clara, não acesso cru ao banco), com permissões (ela roda sob a identidade do usuário e as ACLs dele se aplicam) e com schema claro — as descrições que o modelo lê para decidir se e como chamar uma tool merecem tanto cuidado quanto os seus prompts, porque uma descrição vaga de tool é um bug que o modelo vai encontrar. Exponha ações, não tabelas: refund_order(id) com as próprias checagens, nunca run_sql(query).

Casos de uso comuns

• Operações de atendimento — um agente resolvendo um objetivo de suporte de ponta a ponta via tools com permissões, com aprovação humana em reembolsos e cancelamentos.
• Assistentes de código — lendo um repositório, rodando tools, iterando até uma mudança sob revisão.
• Pesquisa e síntese — recuperação e resumo em múltiplos passos, quando o caminho não é conhecido de antemão.
• Workflows de dados com julgamento — passos que precisam de raciocínio entre eles, não só de um pipeline fixo.
• Agendamento e coordenação — objetivos que atravessam vários sistemas, cada um alcançado por uma tool com escopo.

Você deveria construir um agente? Matriz de decisão

Limitações e trade-offs

• Autonomia troca confiabilidade por capacidade. A liberdade que permite ao agente lidar com objetivos abertos é a mesma que compõe erros — limite-a deliberadamente.
• Loops custam dinheiro e tempo. Cada iteração são mais chamadas de modelo; agentes são mais lentos e mais caros que uma chamada única por design — imponha tetos e monitore ambos.
• Não-determinismo resiste a testes. Um workflow você testa com unit tests; um agente você avalia estatisticamente, ao longo de muitas execuções, porque a mesma entrada pode seguir caminhos diferentes.
• O raio de explosão são as suas credenciais. Um agente é tão seguro quanto a permissão mais estreita que você deu às suas tools; acesso amplo demais é o incidente esperando para acontecer.
• Impressionante ≠ confiável. Uma demo empolgante é uma cadeia com sorte; produção é o trabalho chato de guardrails, aprovações e caminhos curtos.

Agentes de IA no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A tese de que “tools são funções de backend” é a integração inteira: as tools de um agente são funções Cloud Code e, como elas rodam sob a sessão do usuário que chama, as ACLs e permissões de classe da plataforma filtram cada leitura e escrita que o agente tenta — como mostram as abas de código, um agente sequestrado ou vítima de prompt injection não consegue exceder as permissões do próprio usuário, porque o raio de explosão do confused deputy é limitado pelo controle de acesso, não pelo bom comportamento do modelo. O resto decorre daí: exponha ações com escopo (refundOrder), não dados crus; mantenha a chave do modelo no servidor; padronize a superfície de tools com MCP quando vários agentes a compartilham; e deixe o backend dizer não. O agente propõe; o backend dispõe — que é exatamente onde a segurança de um sistema autônomo deveria morar.