Four evaluation engineering lessons learned from building agent plugins
The real challenge of building an agentic system isn't the construction, it's the measurement. Evaluation engineering is a critical foundation for building reliable AI systems.
The real challenge of building an agentic system isn't the construction, it's the measurement. Evaluation engineering is a critical foundation for building reliable AI systems.
I’ve run evaluation engineering initiatives for years at Google and developing the newly released Google Cloud Developer plugin served as a live testbed to stress-test these key principles across real-world developer workflows.
Here are four eval lessons we learned from building the new plugin that you can apply to your own builds.
1. Grade the execution steps instead of the summary When we first evaluated agents, we set up an LLM-as-judge to inspect the agent’s final text reply and scored it against a checklist. However, we quickly realized it’s fundamentally flawed because the grader only sees what the agent wrote, not what it actually did. When we ran our initial 11-prompt evaluation suite for the Google Cloud Developer plugin, the automated grader marked it as failing three prompts. But when we opened the raw tool-call logs and read the transcripts, the plugin had actually passed all three. On a Cloud Run cleanup prompt, for instance, our rubric required checking command syntax before running anything. The agent ran gcloud help run services list as its very first step. It did the work, but its final message was focused on warning the user about permanent data loss rather than reciting that it had checked the help docs.
The grader penalized the agent for doing the right thing simply because it didn’t brag about it in the summary. If your rubric line says "did it run X?", a LLM judge is guessing unless you evaluate the actual tool-call trajectory.
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Google Cloud Blog
- Published: 16/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por que importa
Um escritório de projetos vale pelas decisões que torna possíveis, não pelos relatórios que produz. Quando o PMO vira a área que persegue atualizações de status, já perdeu: a equipe aprende a preencher o formulário e a informação real volta a circular pelos corredores.
Leio essas coisas procurando onde o risco estava antes de virar incidente. Quase sempre já estava escrito em algum registro que ninguém revisava, com um dono atribuído que nunca soube que era. O risco identificado e não gerenciado é pior que o não identificado: dá a falsa sensação de que há controle.
O que costuma dar errado
O que mais vejo falhar é o patrocinador ausente. Assina o início, aparece na foto e depois só volta quando há problema. Sem alguém com poder real removendo obstáculos a cada quinze dias, o gerente de projetos acaba negociando de igual para igual com áreas que não lhe reportam, e perde.
O que observar
- Quem é o patrocinador e com que frequência real aparece — não no organograma, na agenda.
- Se o relatório de status mostra projetos em vermelho: um portfólio todo verde é um portfólio sem informação.
- Quais riscos estão identificados, quem é dono de cada um e quando foram revisados pela última vez.
Como leio esta publicação
A forma como eu traria isto ao chão é reduzindo o tamanho das entregas. Um projeto de dezoito meses sem nada visível antes do mês doze é uma aposta, não um plano. Prefiro seis entregas que sirvam separadamente, mesmo que o total demore um pouco mais, porque cada uma corrige o rumo.
A notícia original está publicada em outro idioma; o trecho é citado como o veículo o entrega e o comentário é escrito em português.
Comentários
Ainda não há comentários. O primeiro pode ser o seu.
Está vivendo isso na sua equipe?
Abra o chat e me conte como estão lidando com isso. Tenho interesse em comparar notas.
