Engenharia de agentes de IA que criam e publicam software real: por dentro da arquitetura da Jobbit

A maioria dos "agentes de IA" não passa da conversa. Respondem, e depois é uma pessoa que faz o trabalho. O problema de engenharia interessante, e genuinamente difícil, é construir agentes que fazem o trabalho: escrevem uma aplicação full-stack, executam-na, corrigem os próprios erros e publicam-na em produção. É nesse problema que a equipa de engenharia da Jobbit e a sua divisão de I&D, a Jobbit Labs (jobbitlabs.com), trabalham todos os dias.

Este artigo é um mergulho de engenharia nos padrões por trás dos agentes de IA que criam e publicam software: a arquitetura, os modos de falha e as lições aprendidas. É deliberadamente prático e independente de fornecedor: quer esteja a construir sobre LLMs, orquestração multiagente, chamada de ferramentas (tool calling) ou RAG, estes princípios aplicam-se a todos.

Os chatbots respondem; os agentes agem

O salto de um chatbot para um agente é o salto de gerar texto para tomar ações no mundo. Um agente tem de planear uma tarefa de múltiplos passos, chamar ferramentas, ler os resultados e decidir o que fazer a seguir, e repetir isto até o objetivo estar cumprido. Esse ciclo, frequentemente chamado de ciclo agêntico (ou ciclo de raciocínio e ação), é o coração do sistema.

O desafio de engenharia é que cada passo pode falhar. O modelo pode inventar (alucinar) uma função que não existe, escrever código que não compila, interpretar mal a saída de uma ferramenta ou desviar-se silenciosamente da tarefa. Um chatbot que erra produz uma frase má; um agente que erra produz um deploy quebrado. A fiabilidade, e não a capacidade bruta, é o verdadeiro trabalho de engenharia.

A arquitetura: planeador, executor, ferramentas

Uma plataforma de agentes robusta separa o planeamento da execução. Uma camada de planeamento decompõe um objetivo ("construir uma app de reservas com pagamentos") em passos concretos; uma camada de execução leva cada passo a cabo usando ferramentas. Manter estas responsabilidades distintas torna o sistema depurável: pode inspecionar o plano de forma independente de como cada passo correu.

O uso de ferramentas (tool use) é onde um agente ganha mãos. As ferramentas são funções bem definidas que o modelo pode chamar: ler um ficheiro, escrever código, executar uma build, consultar uma base de dados, fazer deploy. A disciplina de engenharia aqui é o desenho da interface: cada ferramenta precisa de um esquema rigoroso e inequívoco, entradas validadas e saídas estruturadas que o modelo consiga interpretar de forma fiável. Interfaces de ferramentas pouco rigorosas são uma das principais fontes de falhas dos agentes; as rigorosas são o ganho de fiabilidade mais barato disponível.

Em trabalhos complexos, um único agente cede frequentemente lugar à orquestração multiagente: agentes especializados que planeiam, escrevem código, revêem e verificam, coordenados por um orquestrador. A decomposição traz foco (cada agente tem uma função restrita e um contexto restrito) e paralelismo (subtarefas independentes correm em simultâneo). O compromisso é a sobrecarga de coordenação, por isso a camada de orquestração tem de ser determinista onde pode e resiliente onde não pode.

Executar e publicar código real, com segurança

Um agente que escreve software tem de executar esse software, e executar código gerado por modelos é um problema de segurança antes de ser qualquer outra coisa. A resposta é a execução de código em sandbox: o código não confiável corre num ambiente isolado, com recursos limitados, sem acesso a segredos e com fronteiras de rede apertadas. A sandbox é o que permite a um agente iterar (compilar, testar, ler o erro, corrigir) sem pôr em risco a plataforma ou os outros utilizadores.

O deploy é o passo que transforma uma app gerada num produto. Um verdadeiro construtor de apps com IA (AI app builder) controla o caminho do código até um URL ativo: build, provisionamento do alojamento, ligação de um domínio, terminação de TLS. Fazer bem esta engenharia significa tornar os deploys repetíveis e reversíveis: as mesmas entradas produzem o mesmo resultado, e um deploy mau pode ser revertido. Idempotência e rollback limpo não são glamorosos, mas são o que torna o deploy autónomo fiável.

Contexto, memória e recuperação

Os LLMs têm contexto finito, e os projetos reais não cabem nele. Por isso, um sistema de agentes sério investe fortemente em engenharia de contexto: decidir o que o modelo vê em cada passo. Empurrar tudo para o prompt é dispendioso e contraproducente: demasiado contexto irrelevante degrada o raciocínio.

É aqui que o RAG (geração aumentada por recuperação) e as bases de dados vetoriais justificam o seu lugar. Em vez de despejar uma base de código inteira no contexto, o sistema recupera os poucos ficheiros, símbolos ou documentos relevantes para o passo atual. Combinada com memória estruturada (um registo das decisões, a especificação em evolução e o que já foi tentado), a recuperação mantém o agente ancorado ao longo de uma tarefa longa sem rebentar a janela de contexto. Uma boa recuperação é muitas vezes uma alavanca de qualidade maior do que um modelo maior.

Fiabilidade: evals, verificação e guardrails

Se há uma ideia que separa a engenharia de agentes em produção das demonstrações, é esta: não se pode publicar o que não se consegue medir. Os sistemas agênticos são estocásticos, por isso a fiabilidade é construída através de evals: conjuntos de testes automatizados que pontuam o agente em tarefas representativas e detetam regressões antes dos utilizadores. Uma mudança que "parece melhor" mas que afunda as suas pontuações de eval é uma mudança que não publica.

Por cima dos evals ficam os guardrails e a verificação em tempo de execução. O padrão mais eficaz é a autoverificação adversarial: depois de um agente produzir um resultado (um pedaço de código, um plano, uma correção), uma passagem de verificação separada tenta refutá-lo. O código compila? Os testes passam? A saída corresponde ao esquema? Tratar a verificação como um passo distinto e cético apanha uma grande parte das falhas que uma única passagem confiante deixaria escapar. Retentativas com backoff, disjuntores (circuit breakers) e escalonamento humano tratam do resto.

Observabilidade que se consegue depurar

Quando um sistema autónomo toma dezenas de decisões por tarefa, é preciso conseguir vê-las. A observabilidade (o rastreamento estruturado de cada prompt, chamada de ferramenta e resultado) é inegociável. Quando um agente corre mal, o rasto (trace) é como encontra o passo exato que se desviou, o reproduz e corrige a causa raiz. As equipas de engenharia que tratam os rastos dos agentes como telemetria de primeira classe depuram em minutos; as que não o fazem depuram em dias.

A edge e a escala elástica

As cargas de trabalho dos agentes são intermitentes e sensíveis à latência, o que torna a computação na edge (edge computing) um encaixe natural. Correr próximo dos utilizadores (em plataformas como Cloudflare Workers e armazenamentos de dados na edge) reduz a latência de ida e volta e escala de forma elástica com a procura. A Jobbit Labs apoia-se nesta abordagem edge-first em partes da sua infraestrutura de dados e de produto: distribuída globalmente, com autoescalonamento e modelo de pagamento por utilização, para que a capacidade siga a carga em vez de ficar parada.

A camada com humano no circuito (human-in-the-loop)

A peça final da arquitetura é a que falta à maioria das plataformas de agentes: um caminho com humano no circuito (human-in-the-loop). A IA trata do volume e da velocidade, mas algumas decisões (lógica sensível em termos de segurança, redação jurídica, juízo de design) pertencem a uma pessoa. Fazer esta engenharia significa construir pontos de transferência limpos onde um especialista humano verificado pode intervir, com escrow a proteger a transação. O agente e a rede humana não são camadas concorrentes; são um plano de recurso desenhado de raiz que torna o sistema inteiro seguro de usar.

Lições para engenheiros que constroem agentes

Se está a construir sistemas agênticos, alguns princípios compensam o investimento muitas vezes.

Desenhe interfaces de ferramentas rigorosas. A maioria das falhas de agentes remonta a ferramentas ambíguas. Esquemas estritos e I/O validada são a fiabilidade mais barata que alguma vez vai comprar.

Verifique de forma adversarial. Não confie numa primeira passagem confiante. Acrescente um passo separado cuja função é refutar o resultado.

Meça com evals. Construa o harness de evals antes de escalar o agente. Não se pode melhorar o que não se consegue pontuar.

Faça engenharia de contexto, não despeje contexto. Recupere o que é relevante; lembre-se do que importa. Prompts maiores não são prompts melhores.

Coloque tudo o que não é confiável em sandbox. Se um agente executa código, o isolamento é uma pré-condição, não uma funcionalidade.

Mantenha um caminho humano. O sistema autónomo mais seguro é o que sabe quando perguntar a uma pessoa.

Leia a seguir

• 20 Dicas para Criar Melhores Apps com Agentes de IA em 2026
• O Glossário de Agentes de IA: 60 Termos de IA Explicados em Linguagem Simples (2026)
• O Que É a IA Agêntica? A IA Agêntica Explicada com Exemplos Reais (2026)

Perguntas frequentes

O que torna um agente de IA diferente de um chatbot?

Um chatbot gera texto; um agente de IA planeia e toma ações: chama ferramentas, executa código e itera em direção a um objetivo. A dificuldade de engenharia é a fiabilidade ao longo de muitos passos, onde um único erro pode quebrar o resultado.

Como se executa código gerado por IA com segurança?

Com execução de código em sandbox: o código não confiável corre num ambiente isolado, com recursos limitados, sem acesso a segredos e com rede restrita, para que o agente possa compilar, testar e corrigir sem risco para a plataforma.

Porque é que os evals são tão importantes para sistemas de agentes?

Porque os agentes são estocásticos, é preciso recorrer a evals automatizados para medir a qualidade em tarefas representativas e apanhar regressões antes de publicar. Sem eles, as "melhorias" são adivinhações.

O que faz a Jobbit Labs?

A Jobbit Labs (jobbitlabs.com) é a divisão de I&D e de dados por trás da Jobbit, focada na engenharia mais pesada, intensiva em dados e de nível empresarial: investigação, plataformas de dados e as fundações de agentes sobre as quais o produto é construído.

Tem curiosidade sobre a engenharia por trás de agentes que publicam software? Explore jobbit.uk e jobbitlabs.com.