Most agent code is tested by running it and eyeballing the output — because testing agents properly is genuinely hard. Pydantic AI's whole design has been quietly building toward making it easy: type safety, dependency injection, and test models combine so you can unit-test agent logic deterministically, offline, without ever calling a real LLM. This is arguably the framework's biggest practical advantage.
Most agent code is tested by running it and eyeballing the output, because testing agents properly is hard. Pydantic AI's design builds toward making it easy: type safety, dependency injection, and test models let you unit-test agent logic deterministically, offline, with no real LLM.
Offline evaluation tells you whether a change is promising; production tells you whether it actually works. Once your system is serving real users, evaluation becomes continuous: online experiments, guardrail metrics, drift monitoring, and gating deploys on eval scores. This closing post moves evaluation from the lab into the running system and ties the whole series into a working loop.
Offline evaluation tells you whether a change is promising; production tells you whether it works. Once you're serving real users, evaluation becomes continuous — online experiments, guardrail metrics, drift monitoring, CI gating. This closing post moves evaluation from the lab into the running system and ties the series into one loop.
A fine-tune that looks great on a handful of hand-picked prompts can be quietly broken — overfit to your training data, worse than the base model you started from, or catastrophically forgetful of skills it used to have. Without real evaluation you can't tell, and shipping a fine-tune you haven't measured is shipping a guess.
A fine-tune that looks great on a handful of prompts can be quietly broken — overfit, worse than the base model, or catastrophically forgetful. Without real evaluation you can't tell, and shipping a fine-tune you haven't measured is shipping a guess.
Every frontier method is a search, and a search is only as good as the evaluator that ranks its candidates — so at the frontier, evaluation stops being a measurement and becomes the single most dangerous component in the system.
Every frontier method is a search, and a search is only as good as the evaluator that ranks its candidates — so at the frontier, evaluation becomes the single most dangerous component in the system.
The pieces from this series — routing, query transformation, graded retrieval, multi-hop, and evaluation — assemble into one system that reasons about retrieval as carefully as it reasons about the answer, while spending only as much as each question needs.
Routing, query transformation, graded retrieval, multi-hop, and evaluation assemble into one system that reasons about retrieval as carefully as the answer — while spending only as much as each question needs.
Automated metrics and LLM judges are scalable proxies for the thing that actually matters: whether a human finds the output good. Human evaluation is the ground truth those proxies are calibrated against — and getting it right is its own discipline, full of subtle traps around agreement, bias, and how you ask the question. This post is about doing human eval well, and about how human preference became the signal that trains models themselves.
Automated metrics and LLM judges are scalable proxies for the thing that matters: whether a human finds the output good. Human evaluation is the ground truth those proxies are calibrated against — a discipline full of traps around agreement, bias, and how you ask — and human preference is now the signal that trains models themselves.
Every agentic technique in this series adds cost and complexity, so the only way to know any of it is worth it is to measure — and RAG needs measurement on two fronts at once: did it retrieve the right things, and did it answer faithfully from them?
Every agentic technique adds cost, so the only way to know it is worth it is to measure — and RAG needs measurement on two fronts: did it retrieve the right things, and did it answer faithfully from them?
A benchmark score is trustworthy only if the model hasn't seen the answers and no one has optimized directly for the test. Both assumptions fail constantly. Training data contamination inflates scores by rewarding memorization; optimizing for a benchmark turns it from a measure into a target and destroys its meaning. This post is about the ways evaluation gets corrupted — and how to defend against them.
A benchmark score is trustworthy only if the model hasn't seen the answers and no one optimized directly for the test — and both assumptions fail constantly. Training-data contamination inflates scores by rewarding memorization; optimizing for a benchmark turns it from a measure into a target. Here's how evaluation gets corrupted, and how to defend it.
The claim that agents should write code isn't just aesthetic — Hugging Face backs it with measured results: code agents take fewer steps, make fewer LLM calls, and score better on hard benchmarks. This post examines the evidence and the mechanism, so you understand not just that code actions win but why.
The claim that agents should write code isn't just aesthetic — Hugging Face backs it with measured results: code agents take fewer steps, make fewer LLM calls, and score better on hard benchmarks. This examines the evidence and the mechanism.
The pieces from this series — memory, self-refinement, a skill library, and an evaluation gate — combine into one modest architecture that actually gets better as it runs, without the hype and without the footguns.
Memory, grounded self-refinement, a verified skill library, and an evaluation gate combine into one buildable architecture that gets better as it runs — safely.
The scores that dominate model announcements — MMLU, GSM8K, HumanEval, and the rest — are benchmarks: standardized public tests that let the whole field compare models on common ground. They've driven enormous progress, but a benchmark is only as good as its design, and a number without understanding of what it measures is easy to misread. Knowing how benchmarks are built, and what makes a good one, is how you read a leaderboard critically instead of credulously.
The scores in model announcements — MMLU, GSM8K, HumanEval — are benchmarks: standardized public tests for comparing models on common ground. They've driven huge progress, but a benchmark is only as good as its design, and a number without understanding is easy to misread. Here's how they're built and what makes a good one.
DSPy's optimizer improves whatever your metric rewards, which makes the metric the single most consequential thing you write — get it right and compilation makes your program better; get it wrong and it optimizes confidently toward the wrong target.
DSPy's optimizer improves whatever your metric rewards, which makes the metric the single most consequential thing you write — get it right and compilation makes your program better; get it wrong and it optimizes toward the wrong target.
Naive RAG trusts whatever it retrieved, which is how it produces confident answers grounded in the wrong documents; self-correcting retrieval adds the step it was missing — checking the results before using them.
Naive RAG trusts whatever it retrieved, which is how it produces confident answers grounded in the wrong documents. Self-correcting retrieval adds the missing step: check the results before using them.
A system that changes itself can improve itself right off a cliff, so the evaluation and guardrails are not an afterthought to self-evolving agents — they are the thing that makes them safe to run at all.
A system that changes itself can improve right off a cliff. Measuring evolution honestly, reward hacking, drift and collapse, and the guardrails that keep it safe.
Metrics and judges are ingredients; a harness is the kitchen. An evaluation harness is the system that takes a dataset of test cases, runs your LLM system over them, scores the outputs, and reports the results — reproducibly, every time. Building one well is what turns evaluation from a one-off spreadsheet into an engineering asset you run on every change, like a test suite.
Metrics and judges are ingredients; a harness is the kitchen. An eval harness takes a dataset of test cases, runs your system over them, scores the outputs, and reports results — reproducibly, every time. Building one well turns evaluation from a one-off spreadsheet into an engineering asset you run on every change.
The question this phase answers is simple and unforgiving — can you change the system without breaking it? — and the control you cannot skip is that no ungated change reaches users.
Can you change the system without breaking it? Phase 6: automated pipelines for code, models, and prompts, with eval gates, a registry, and automated rollback — no ungated change reaches users.
When there's no reference answer and no rule to check, you can ask a strong model to grade the output — LLM-as-a-judge. It's the technique that made open-ended evaluation practical at scale, and it's also a minefield: judges have systematic biases, can be gamed, and agree with humans only when you design the grading carefully. Used well it's indispensable; used naively it produces confident numbers that mean nothing.
When there's no reference and no rule to check, you can ask a strong model to grade the output — LLM-as-a-judge. It made open-ended evaluation practical at scale, and it's a minefield: judges have systematic biases (position, verbosity, self-preference), can be gamed, and agree with humans only when you design the grading carefully.
Asking a model to check its own work sounds like free improvement, but whether it actually helps depends entirely on where the feedback comes from — and getting this wrong is the most common way self-evolving agents fool themselves.
Self-critique is tempting but dangerous: without a real external signal, models often fail to self-correct and can get worse. Where self-critique works and where it drifts.
Before you can score an LLM, you have to decide what "good" even means for your task — and that choice determines everything downstream. Metrics fall into a few families, from exact string matching to reference overlap to semantic similarity to task-specific checks, each measuring something different and each with blind spots. Picking the wrong metric is worse than no metric: it gives you a confident number that points the wrong way.
Before you can score an LLM you must decide what "good" means — and that choice determines everything. Metrics fall into families (exact match, reference overlap, semantic similarity, task-specific), each measuring something different with different blind spots. Picking the wrong metric is worse than none: it points confidently the wrong way.
AI systems are non-deterministic, so "it looked good in the demo" is not a quality signal — evaluation is the control system for the entire lifecycle, and if it doesn't gate releases, nothing does.
AI is non-deterministic, so 'it looked good in the demo' is not a quality signal. Phase 4: evaluation as the control system that gates every release — measurable and gating, or it's decoration.
Building something with an LLM is easy for a weekend and hard for a year. The wall almost everyone hits is not the model, the prompt, or the framework — it is knowing whether a change made things better or worse. Without a way to measure quality, every improvement is a guess and every deploy is a gamble. Evaluation is the discipline that turns "it seems better" into "it is better, by this much," and it is the real bottleneck in shipping AI systems.
Building with an LLM is easy for a weekend and hard for a year, and the wall almost everyone hits is knowing whether a change made things better or worse. Without measurement every improvement is a guess — evaluation is the discipline that turns "it seems better" into "it is better, by this much," and it's the real bottleneck in shipping AI.
Turning red-team attacks into metrics you can act on and track over time — attack success rate, coverage, severity, and trend — plus the honest limits of what any of those numbers can tell you.
Turning attacks into metrics: attack success rate and why it's subtle, scoring success (rule/classifier/LLM-judge with its biases), coverage across the taxonomy, severity weighting, tracking trends per model/prompt version, and honest reporting of residual risk.
The capstone of this series — assembling roles, a use-case inventory, lifecycle gates, and policy-as-code into a right-sized governance program that produces evidence instead of paperwork, without crushing the velocity of a two-person team or failing an enterprise audit.
The capstone: assemble a right-sized governance program — roles and accountability, a model/use-case inventory as the backbone, lifecycle gates, and policy-as-code that blocks deploy when an owner, risk tier, model card, eval pass, or monitor is missing.
Part seven of the AI Security Engineering series: DevSecOps for AI systems — securing the secrets, network, supply chain, prompts, and CI/CD gates that surround the model, so a hardened model doesn't sit inside a soft pipeline.
DevSecOps for AI: secrets in a manager not code, least-privilege runtime identities (no ambient prod creds for agents), egress control, rate/spend limits against model DoS, supply-chain verification in CI, prompts-as-code, and a security-eval gate that fails the build.
Why enterprises pick watsonx for its governance story, what watsonx.governance actually gives a Python team, and how to wire monitoring, factsheets, and generative-quality metrics into an LLM feature — honestly, as the platform-heavy work it is.
Governance is why many enterprises pick watsonx: model inventory, automated factsheets, monitoring (quality, drift, bias, and generative metrics like faithfulness), explainability, and EU AI Act-aligned risk workflows — with the ibm-watsonx-gov evaluation SDK and what to log.
The last post in the series: what changes when the LLM system you built across posts 1-14 has to run for real — reliability, security, cost, observability, evaluation gates, and versioning, from a Go engineer's seat, with code where it earns its place.
The capstone: running an LLM system in production from a Go engineer's seat — reliability (timeouts, retries, fallbacks), security (injection, least-privilege tools, secrets), cost and observability, CI eval gates, and versioning models and prompts.
The three trustworthy-AI properties regulators and users press on hardest — where bias enters a system, why the fairness definitions contradict each other so you must choose one deliberately, and why an explanation you can read is not the same as an explanation you can trust.
The trustworthy-AI properties regulators care about: where bias enters, why fairness notions conflict (you must choose one), disaggregated evaluation, mitigation with Fairlearn/AIF360, and explainability (SHAP/LIME) — with the honest caveat that LLM rationales are not faithful explanations.
Two tightly-linked OWASP LLM risks that turn a clever prompt injection into real-world damage — and the Python patterns that shrink the blast radius: treat model output as untrusted input, and give agents the least agency they can get away with.
Two OWASP risks that turn an injection into damage: insecure output handling (model output is untrusted input — never eval/shell/SQL it unescaped) and excessive agency (least-privilege tools, allow-lists, human approval for irreversible actions, audit logs).
The capstone of the Evaluating Agents in Go series: how to score a conversation instead of a single reply, how to attribute errors across a coordinator and its sub-agents, and how to build rubric, safety, and hallucination judges in Go when the framework hands you no eval package.
The capstone of the Evaluating Agents in Go series: how to score a conversation instead of a single reply, how to attribute errors across a coordinator and its sub-agents, and how to build rubric, safety,...
Governance is only as real as your ability to measure it. This is the MEASURE function of an AI risk program made concrete — a versioned eval set, the metric families that matter for an LLM system, and a CI gate that fails the build when quality regresses instead of just logging a warning.
Governance enforced through evaluation — the Measure function made real: build a versioned eval set, pick the metric families (quality, faithfulness, safety, bias, PII, cost/latency), and turn eval into a CI quality gate that fails the build on regression.
How to know whether an LLM system actually works — building an eval dataset, the four metric families (deterministic checks, text overlap, embedding similarity, LLM-as-judge) in Go, task-specific eval for RAG and classification, and wiring a scored regression gate into CI so you measure instead of vibe.
How to know whether an LLM system works when outputs are non-deterministic: build an eval dataset, score with deterministic checks, embedding similarity, and LLM-as-judge (with its biases), evaluate RAG and classification, and gate regressions in CI.
How to wire agent evaluations into continuous integration in Go — running a slow, model-calling eval harness under `go test`, setting per-metric thresholds that fail the build on a regression, and living honestly with the fact that these gates are softer than unit tests.
How to wire agent evaluations into continuous integration in Go — running a slow, model-calling eval harness under `go test`, setting per-metric thresholds that fail the build on a regression, and living...
The evidence layer of AI governance — how model cards, datasheets, system cards, and automated FactSheets turn "trust us" into an auditable paper trail, and why the EU AI Act makes these artifacts the actual deliverable.
The transparency artifacts that make AI governable: model cards, datasheets, and system/use-case documentation — plus a Python snippet that auto-captures lineage (model version, prompt hash, dataset version, eval scores, git SHA) into a card at build time, so docs are generated not hand-maintained.
Where good eval cases actually come from — seeding by hand, harvesting from production telemetry, and curating a golden dataset in Go that doesn't rot the moment your prompt changes.
Where good eval cases actually come from — seeding by hand, harvesting from production telemetry, and curating a golden dataset in Go that doesn't rot the moment your prompt changes.
How to score an agent's final answer against a reference — from exact string match, through ROUGE-1 unigram overlap, to an LLM judge — with original Go you can drop into a test suite. Part 5 of Evaluating Agents in Go.
How to score an agent's final answer against a reference — from exact string match, through ROUGE-1 unigram overlap, to an LLM judge — with original Go you can drop into a test suite. Part 5 of Evaluating...
Once an agent can call tools, the next questions are what it can read, what it returns, how long it can run, where its facts come from, how it's defined, and whether it actually works — this guide answers all seven.
Once an agent can call tools, the next questions are what it can read, what it returns, how long it can run, where its facts come from, how it's defined, and whether it actually works — this guide...
A working definition of AI governance for engineers — what it means, how it differs from security and compliance, why you already own a slice of it, and the frameworks and lifecycle map that anchor the rest of this series.
The opener to a governance series for engineers: what AI governance is and how it differs from security and compliance, why engineers produce the evidence (docs, evals, monitors, audit trails), and the frameworks used throughout — NIST AI RMF, the EU AI Act, and ISO/IEC 42001.
How to score what an agent did, not just what it said — building trajectory metrics in Go from an exact-match baseline up to arg-aware, order-tolerant scoring, with a readable diff of expected vs. actual.
How to score what an agent *did*, not just what it *said* — building trajectory metrics in Go from an exact-match baseline up to arg-aware, order-tolerant scoring, with a human-readable diff of expected vs....
The core of the series: a minimal, original evaluation harness in Go. Run an agent under test through adk-go's runner, capture the tool-call trajectory and the final response behind an adapter you own, and score them with `go test`.
The core of the series: a minimal, original evaluation harness in Go. Run an agent under test through adk-go's runner, capture the tool-call trajectory and the final response behind an adapter you own, and...
Before you can evaluate an agent in Go, you need a mental model of what "evaluating an agent" even means. This post unpacks the conceptual core of Google's Agent Development Kit eval framework — cases, trajectories, metrics, thresholds — the parts that are language-agnostic, so the rest of this series can implement them as plain Go types and functions.
Before you can evaluate an agent in Go, you need a mental model of what "evaluating an agent" even means. This post unpacks the conceptual core of Google's Agent Development Kit eval framework — cases,...
The opener to a series on evaluating agents in Go: why an agent isn't a function you can unit-test, why "it worked in the demo" doesn't survive contact with production, and the two things actually worth measuring — the steps it took and the answer it gave.
The opener to a series on evaluating agents in Go: why an agent isn't a function you can unit-test, why "it worked in the demo" doesn't survive contact with production, and the two things actually worth...
Fundraising, stripped of mystique, is a sales process — you're selling equity to investors — and it runs on the same fundamentals as any sale: a compelling pitch, momentum, and the leverage that comes from having options. Most founders approach it as supplication (please fund me) rather than as a mutual evaluation between parties choosing each other, and that framing costs them. And the relationship doesn't end at the wire transfer: your investors are your partners for years, so how you choose and work with them matters long after the round closes.
Fundraising, stripped of mystique, is a sales process — you're selling equity — and it runs on a compelling pitch, momentum, and the leverage of having options. Most founders approach it as supplication rather than mutual evaluation, and that framing costs them. And the relationship doesn't end at the wire transfer.
The reference capstone for the 26-part series — every canonical ADK term, defined concisely.
The capstone of the series: every core ADK concept defined in one place — agents and orchestration, tools, sessions/state/memory, context and callbacks, runtime and streaming, models, grounding, evaluation, protocols, and deployment.
Treat agent output quality like a test. A baseline file plus a gate that fails the build on regression turns "the agents got worse" into a red X.
Agent systems rot because nobody catches quality regressions until users do. A committed baseline plus a gate that fails the build turns the agents got worse into a red X and a reviewable diff in the pull request.
How ADK turns "did the agent behave correctly?" into a number you can gate a merge on.
Measuring agent quality: eval sets, scoring both the trajectory (right tools, right order) and the final response, criteria configs, and the adk eval CLI — a Python-first workflow today.
How to combine a deterministic rules engine with an ML risk model in a single decision: rule precedence, score bands, shadow mode, and champion/challenger evaluation with feedback labels.
Teaches how to combine a deterministic rules engine with an ML risk model in one decision path: rule-precedence and overrides, model score bands, shadow mode, and champion/challenger evaluation with feedback labels.
How to keep books in more than one currency — transaction-date versus settlement-date rates, unrealized and realized FX gain/loss, and the period-end revaluation run that keeps the balance sheet honest.
Teaches how to keep books in multiple currencies with a functional/reporting currency: transaction-date vs settlement-date rates, unrealized/realized FX gain-loss postings, and period-end revaluation runs.
I built memory, communication, security, governance, and evals from scratch first. Then I deleted most of it and used the Microsoft Agent Framework-native packages. Here is the audit table and what survived.
Single-turn evals check one decision. Multi-turn evals check the whole trajectory. A Python harness with three evaluators, an offline test suite, and the judge prompt that actually works.
How to instrument multi-agent systems with OpenTelemetry, propagate trace context across an in-memory bus, and build a layered evaluation pipeline — from real-time policy gates to async LLM-as-judge to SLO-based trust scoring. Everything I learned building Genie.
Build a GDPR Article 22 compliant explanation endpoint in Go that turns audit logs and eval stores into regulator-friendly answers for AI decisions.
How a single sprint of specialty-rule work — guided by a benchmark that wasn't afraid to print embarrassing numbers — turned a 'demo respiratory differential' into a five-condition rule-based diagnostic engine.
Microsoft's Multi-Agent Reference Architecture in Go. Protocol, registry, bus, governance, orchestration, observability, evaluation — and how the seven hold each other up.