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.
Editorial analysis by NHI Mgmt Group, based on content published by Fiddler: “Automating Eval-Driven Development Workflow for Agentic Applications”.
Key questions
Q: What breaks when agentic applications are tested with pass or fail methods only?
A: Traditional pass or fail tests assume stable outputs, but agentic applications can produce different valid or invalid responses on each run.
Q: Why do non-deterministic agent outputs need quantitative evals?
A: Quantitative evals create a repeatable way to compare outputs when exact matching is unrealistic.
Q: What do security teams get wrong about monolithic agent workflows?
A: They often treat one large prompt and tool loop as easier to manage, but that design hides which step caused the failure.
Practitioner guidance
- Define scored evals before deployment Write quantitative eval cases for the specific agent behaviours you expect, including acceptable output variation and the failure modes that should block release.
- Split monolithic agents into testable nodes Refactor workflows so metric discovery, tool execution, query generation, and response synthesis can each be evaluated separately.
- Add regression rollback to the eval loop Use stop conditions that compare each run against the best seen score and revert prompt or harness changes when quality drops.
Bottom line: Agentic applications cannot be governed reliably with traditional output checking because non-deterministic behaviour makes pass or fail logic too coarse.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:24 pm
Eval-driven development is becoming a governance control, not just a developer workflow. The article shows that scoring agent output is no longer a nicety for prompt tuning. It is the mechanism that makes non-deterministic behaviour reviewable, comparable, and safe to change. For identity and security teams, the same principle applies wherever runtime behaviour cannot be trusted without a measurable boundary.
A few things that frame the scale:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: When should teams stop automating eval-driven development and bring in human review?
A: Human review should take over when scores plateau, regress, or fail to improve after repeated iterations. At that point, prompt edits alone are usually exhausted and the issue is more likely architectural, such as poor context design, weak tool boundaries, or missing decomposition. The automation should stop before it normalises a broken pattern.
👉 Read our full editorial: Eval-driven development is changing how agentic apps are tested