Notifications
Clear all
Topic starter
19/08/2026 3:47 pm
TL;DR: Traditional testing breaks down for agentic applications because LLM outputs vary run to run, according to Fiddler. The practical issue is not whether evals help, but whether modular agent design gives teams enough isolation to govern failures before production.
NHIMG editorial — based on content published by Fiddler: Automating Eval-Driven Development Workflow for Agentic Applications
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing credentials.
Questions worth separating out
Q: How should security teams govern agentic applications that learn through eval loops?
A: Security teams should treat eval loops as part of the control framework, not just the development workflow.
Q: Why do non-deterministic agent outputs create governance problems?
A: Non-deterministic outputs make it hard to prove repeatability, assign blame, or detect regressions from one run to the next.
Q: What breaks when an agent is built as one monolithic loop?
A: A monolithic loop hides which step failed when the final output is wrong.
Practitioner guidance
- Define scored evals for each agent node Create separate test sets for discrete steps such as retrieval, generation, validation, and execution so failures map to one control boundary.
- Add stop conditions and auto-revert logic Set a minimum acceptable score, preserve the best-seen run, and restore the previous version automatically when a change regresses performance.
- Treat modular decomposition as a security control Refactor monolithic agent loops into testable components so you can isolate tool use, context construction, and output generation.
What's in the full article
Fiddler's full blog post covers the operational detail this post intentionally leaves for the source:
- The step-by-step EDD loop used to automate reruns, score comparison, and revert decisions.
- The PromQL generation example and dataset structure used to test a modular agent node in isolation.
- The concrete OpenCode workflow for analysing failures and updating prompts or harness logic.
- The stopping conditions that determine when the agent should plateau, revert, or present changes for review.
👉 Read Fiddler's deep dive on automating eval-driven development for agentic applications →
Eval-driven development for agentic apps: are your tests keeping up?
Explore further
19/08/2026 4:24 pm
Eval-driven development is becoming the governance pattern agentic AI actually needs. The article correctly frames EDD as a response to non-deterministic behaviour, but the deeper issue is governance, not developer convenience. Once an agent can vary its output across runs, policy enforcement must move from anecdotal review to measured control. That makes evals part of the control plane for agentic systems, especially where tool use or data access has identity implications. The practitioner conclusion is simple: if you cannot score it, you cannot reliably govern it.
A question worth separating out:
Q: How do teams prevent eval-driven changes from causing regressions?
A: Use a baseline score, rerun the full eval suite after every change, and automatically restore the previous version if performance drops. That keeps local prompt gains from masking broader failures. In production, pair that with access review so behaviour improvements do not conceal privilege creep.
👉 Read our full editorial: Eval-driven development is changing how agentic apps are tested
