'Agentic engineering' parou de ser uma palavra de LinkedIn

Um founder posta um screenshot de uma função Python, um system prompt e uma chamada de API para uma ferramenta de calendário. A legenda diz: agentic engineer. Na mesma semana, um agent diferente, construído com as mesmas quatro linhas de glue code, lê o email de cancelamento de um cliente como um pedido de reagendamento e remarca a reunião quatro vezes antes que alguém perceba. Os dois agents foram lançados. Só um deles sobreviveu ao contato com um usuário real.

Se você fosse procurar uma definição de agentic engineering seis meses atrás, encontrava a legenda do LinkedIn. Agora encontra um workshop.

Agentic engineering é a disciplina em nível de sistema de rodar muitos agents de forma confiável em produção: verificação, guardrails, observabilidade. É a camada que transforma o sistema de registro de uma empresa num sistema de ação.

Este post defende uma afirmação estreita: o gap entre a versão de LinkedIn de agentic engineering e a versão real não é vibe, são três disciplinas de engenharia específicas aplicadas a todo agent que toca produção, e o campo acabou de ganhar prova institucional de que pessoas que estudam sistemas de software para viver, não só pessoas que os vendem, levam a distinção a sério.

Uma definição de agentic engineering, cortesia do ICSE

A leitura ingênua trata “agentic engineer” como um título que você se concede no dia em que conecta um modelo a uma ferramenta. Nada checa a alegação, então a palavra significa o que quer que quem postou queira que ela signifique, e é exatamente aí que ela falha: um título sem checagem externa não é uma disciplina, é uma fantasia.

Aqui está o fato que muda o argumento. O ICSE, a International Conference on Software Engineering, está co-localizando o International Workshop on Agentic Engineering, AGENT 2026, em 14 de abril de 2026, no Rio de Janeiro. A lista de tópicos publicada não é texto de marketing, é uma agenda de pesquisa: design arquitetural para sistemas agênticos, verificação, validação e testing de sistemas agênticos, AgentOps como o DevOps dos agents, metodologias de avaliação e benchmarks, e avaliação de risco de responsible AI. Isso é um espaço acadêmico revisado por pares, não uma legenda, e nomeia as mesmas três qualidades às quais este post não para de voltar, verificação, guardrails sob risco de responsible AI, observabilidade sob AgentOps, como o verdadeiro problema de pesquisa. Uma conferência não co-localiza uma trilha de workshop em torno de uma hashtag; ela co-localiza uma em torno de uma disciplina com problemas em aberto que valem um paper.

No momento em que um espaço revisado por pares constrói uma trilha de verificação em torno de uma palavra, a palavra saiu do marketing e entrou na engenharia.

Verificação: a diferença entre alegar concluído e estar concluído

A versão ingênua de verificação é o agent reportando o próprio status. Ele termina uma task, declara que terminou, e o pipeline segue em frente. Isso falha por uma razão estrutural, não por azar: um sistema que avalia sua própria saída não tem nenhuma pressão adversarial sobre ele, então converge para o que quer que passe na própria barra, não na do usuário. Esse é o mecanismo exato por trás de pilotos que demonstram bem e depois morrem em produção, um padrão que este pilar já rastreou em por que seu piloto de IA falhou e em a maioria dos pilotos de IA morre em produção: a falha nunca foi visível para o sistema que se autoavaliava, só para o usuário real que bateu no caminho que o demo nunca cobriu.

A resposta de agentic engineering é mecânica, não filosófica: verificação só conta quando a coisa que avalia não é a coisa sendo avaliada. Isso pode ser um teste determinístico com o qual o agent não consegue negociar, um segundo agent avaliando contra uma rubric que ele não escreveu, ou um humano clicando pela superfície real. Um trabalho formal recente sobre contratos de agent, arXiv 2601.08815, aponta a mesma desconfiança para um alvo mais estreito, o consumo de recursos de um agent: ele especifica limites de input/output, orçamentos de tempo e critérios de sucesso para um agent delegado antecipadamente, e então impõe leis de conservação para que um sub-agent nunca consiga gastar além do orçamento do contrato do seu parent, um design que manteve zero violações de lei de conservação em toda a delegação multi-agent na própria avaliação do paper. Um contrato tem que ser checável por algo diferente do agent vinculado a ele, seja o que está sendo checado a resposta ou o gasto.

A Apollo roda essa desconfiança como três camadas conectadas, não como uma esperança. As tasks, docs, registros de CRM e definições de agent de uma org vivem num único sistema de registro que todo agent e colega de time lê e escreve, então a linha que guarda o critério de aceite de uma task é a linha em que a saída de um agent tem que pousar. Um sistema de inteligência fica em cima: um segundo loop de agent independente avalia a saída do primeiro agent contra esse critério armazenado, nunca contra critério que ele mesmo escreveu, e o pipeline de tasks da Apollo é construído para que o status só possa virar de em andamento para concluído depois que esse loop separado o aprova. Essa virada escreve de volta no mesmo registro que todo agent e humano a jusante lê em seguida, o que é o que transforma uma camada de verificação num sistema de ação: o veredito vira o próximo gatilho, não uma nota lateral. Software sempre desconfiou de um componente que avalia a si mesmo; agentic engineering é essa desconfiança aplicada a agents em vez de a testes unitários, e registro-inteligência-ação é o que acontece quando essa aplicação é construída no runtime em vez de discutida num documento.

Verificação só conta quando o sistema que avalia não é o sistema sendo avaliado.

Guardrails são uma condição de fronteira, não um filtro de conteúdo

A versão ingênua de um guardrail é uma blocklist de prompt injection aparafusada no primeiro turno que um usuário digita. Isso falha porque um agent multi-etapa não para depois do primeiro turno: ele chama ferramentas, escreve na memória e frequentemente faz handoff para um segundo agent vários passos depois. Uma blocklist restrita ao turno um não diz nada sobre o turno seis, então a ação insegura acontece a jusante do único lugar em que alguém estava de olho, e quando ela aparece, o gatilho não se parece em nada com o input que o filtro foi construído para pegar.

O conserto é tratar um guardrail como uma condição de fronteira imposta a cada etapa: toda chamada de ferramenta checada contra o que aquela ferramenta pode fazer, toda escrita de memória checada contra o que pode persistir, todo handoff checado contra o que o agent receptor pode agir sobre. Guardrails e observabilidade são a mesma disciplina apontada em duas direções, uma restringe o que vem a seguir, a outra registra o que aconteceu. Nenhuma das duas sozinha pega uma falha que acontece entre duas chamadas de ferramenta que ninguém estava observando individualmente.

Observabilidade para um enxame, não uma única request

A versão ingênua de observabilidade é um logger de request-e-response apontado para o agent. Isso falha por uma razão específica: um trace único atrelado a uma chamada HTTP não consegue reconstruir um plano que gerou seis chamadas de ferramenta, duas retentativas e um handoff para um segundo agent. O log mostra um 200 limpo enquanto a decisão que produziu uma resposta errada visível ao cliente está quatro chamadas mais fundo, sem registro, exatamente o gap que observabilidade para agents é um esporte diferente já nomeia como a falha central de aplicar tracing restrito à request a um processo que pensa em planos, não em requests.

O conserto é um trace construído em torno da decisão, não da chamada: qual plano o agent escolheu, quais ferramentas ele invocou e em que ordem, o que ele escreveu na memória, quanto custou, e para qual outro agent ele fez o handoff. Essa é a diferença entre detectar que algo deu errado e conseguir dizer por quê, três passos depois, sem reexecutar a conversa inteira baseado num palpite.

Um sistema que você não consegue observar é um sistema sobre o qual você está chutando, não importa quão confiante ele responda.

Observabilidade para um enxame de agents significa rastrear o caminho da decisão, não só a request que o disparou.

A ponte que ninguém desenha: do contexto à ação

Context engineering, a disciplina que este pilar definiu em context engineering é o trabalho agora, responde a uma pergunta mais estreita: o que entra na context window de um agent para o próximo passo dele. O próprio enquadramento de Andrej Karpathy, retomado e estruturado numa taxonomia no blog de engenharia da LangChain, chama isso de “a arte e a ciência delicadas de preencher a context window com exatamente a informação certa para o próximo passo.” Isso é um ofício real, conquistado com esforço, e restrito a um único turno de um único agent.

A versão enterprise dessa ambição fica na margem distante. O enquadramento da a16z sobre a próxima camada de orquestração enterprise a descreve como “não um chatbot e não uma ferramenta isolada, mas um sistema coordenado de agents que roda o workflow e entrega resultados reais em toda a empresa.” Isso ecoa o chamado anterior da própria a16z pela mudança de um sistema de registro para um sistema de inteligência, estendida um degrau além pela Bessemer Venture Partners para um sistema de ação, software que age sobre os dados em vez de só armazená-los. A QAD operacionaliza esse movimento na camada de ERP, construindo agents que, nas próprias palavras da QAD, “não só preservam histórico, eles influenciam proativamente resultados futuros iniciando e executando as próximas melhores ações.” Nem a a16z, nem a BVP, nem a QAD inventaram esse enquadramento dentro dos muros da Apollo; a síntese, detalhada em o sistema de registro vira o sistema de ação, é o que a Apollo é construída para rodar: verificação, guardrails e observabilidade como uma única camada, conectada ao caminho registro-para-inteligência-para-ação acima, não três soluções pontuais no formato de fornecedor aparafusadas depois do fato.

Agentic engineering é o vão entre essas duas margens. Sem ele, context engineering continua sendo um truque de agent único que funciona num demo, e a visão de sistema-de-registro-para-sistema-de-ação continua sendo um slide, porque nada prova que o meio se sustenta quando uma dúzia de agents age sobre o estado real da empresa ao mesmo tempo. Essa camada intermediária tem que ser construída sobre a mesma premissa que este post não para de repetir: agentic engineering é a disciplina em nível de sistema de rodar muitos agents de forma confiável em produção: verificação, guardrails, observabilidade. É a camada que transforma o sistema de registro de uma empresa num sistema de ação, a mesma camada de confiabilidade que mantém um agent honesto, mais perto do que o loop se fecha dentro de um único sistema argumenta do que de uma stack de ferramentas separadas costurada às pressas.

O que isso custa, honestamente

Nada disso é grátis, e fingir o contrário é a mesma jogada de marketing que este post rejeitou já na abertura. Um verificador de verdade, uma camada de guardrails que checa cada etapa, e um schema de trace que sobrevive a um handoff entre agents é overhead que um demo não precisa e que a maioria dos times pula exatamente porque o demo funciona sem isso. É mais lento lançar a primeira versão, e essa lentidão não desaparece: alguém tem que ser dono do verificador, alguém tem que ser dono do schema de trace, e nenhum dos dois papéis vai embora depois que o agent entra no ar. Ser dono de verificação, guardrails e observabilidade como uma camada conectada também significa abrir mão da capacidade de plugar uma única ferramenta pontual best-of-breed para qualquer uma das três sem reconectar como ela conversa com as outras duas, um custo de acoplamento real, não hipotético.

A troca vale a pena porque as duas curvas de falha apontam em direções opostas. A velocidade do piloto é um número de uma vez só que parece igual, disciplinado ou não o agent por baixo. A confiabilidade em produção se acumula, ou se corrói, a cada dia que o agent continua rodando contra usuários reais, e só um desses dois caminhos sobrevive além do primeiro trimestre.

A virada

Por trás de cada uma dessas etapas falhas existe uma pessoa, não uma métrica: o cliente cuja reunião foi remarcada quatro vezes, o funcionário que confiou num número errado que um agent enterrou três chamadas de ferramenta abaixo, o usuário que nunca abre um bug report e simplesmente para de confiar no produto, em silêncio. Uma disciplina é o que um campo constrói quando decide que essas pessoas não são dano colateral aceitável de um demo. Agentic engineering é a disciplina em nível de sistema de rodar muitos agents de forma confiável em produção: verificação, guardrails, observabilidade. É a camada que transforma o sistema de registro de uma empresa num sistema de ação, ficando entre uma pessoa e um agent que falha em silêncio. O ICSE co-localizar um workshop com trilhas nomeadas para verificação, avaliação e avaliação de risco é o campo admitindo que a legenda do LinkedIn nunca foi suficiente para manter a reunião daquele cliente marcada de uma vez, corretamente, da primeira vez.

---

A Apollo é construída para o segundo agent daquela cena de abertura, o que tem que sobreviver a um email de cancelamento real, não o que fica bonito num screenshot. A verificação, os guardrails e a observabilidade não são funcionalidades aparafusadas depois do lançamento, eles são a razão pela qual um agent chega a tocar no calendário de um cliente sem supervisão, para que a reunião seja remarcada corretamente uma vez, em vez de quatro.