Offline evaluation tells you whether a change is safe to ship; online evaluation tells you whether it actually worked. No matter how good your eval set is, production always surprises you — real users send inputs you never imagined, and the gap between your offline scores and real-world quality is where LLM apps quietly fail. This post is about measuring quality on live traffic and turning user behavior into the feedback that makes the system improve.
Offline evals say a change is safe to ship; online evals say whether it worked. The intrinsic offline–online gap, deploying to measure (canary, A/B, shadow), capturing explicit and implicit feedback, and the pipeline that turns production behavior into continuous improvement.
The single practice that separates teams who improve their LLM apps from teams who just change them is evaluation. Without a trustworthy way to measure quality, every prompt tweak is a gamble — you fix one case, break two others, and never know. Eval-driven development makes the eval set the center of gravity: you build it before you optimize, you gate every change on it, and you treat it as the most valuable asset the project owns. This post is about building evaluation you can actually trust.
The practice that separates improving an LLM app from merely changing it. The curated eval set as the core asset, how to score open-ended output (deterministic checks, reference metrics, LLM-as-judge, human review), and how to gate every change on evals and compare B vs A.
In an LLM application the prompt is the source code — it's where behavior is defined and where most changes and most bugs happen. Yet teams routinely paste prompts inline, edit them in production, and have no idea which version produced last week's output. Prompt and version management is the unglamorous discipline of treating prompts as the first-class, versioned, tested artifacts they actually are. It's the foundation the rest of the lifecycle stands on.
In an LLM app the prompt is the source code — where behavior is defined and most bugs happen. Treat prompts like code: version the whole configuration (template + model + parameters + context strategy), decouple them from app code, and route every change through review, eval, rollout, and rollback.
Post 1 argued an LLM application is never "done." This post gives that idea a shape: the LLMOps lifecycle, the repeating loop of develop → evaluate → deploy → observe → improve that a production LLM system lives inside. Seeing the whole loop at once is what turns a pile of practices — prompt management, evals, guardrails, monitoring — into a coherent operating model, and it's the map for the rest of the series.
The LLMOps lifecycle — develop, evaluate, deploy, observe, improve — as a loop an LLM app lives inside, not a line it runs once. Why evaluation is a first-class stage appearing twice, why production feedback flows backward, and why the loop turns whether you act or not.
A pilot that works is not a system the customer can run. Productionizing AI means making it reliable, affordable, fast, and observable enough to be real infrastructure — and then handing it over so the customer operates it without you. The forward deployed engineer's goal, in the end, is to make themselves unnecessary: a deployment that only works while you're standing next to it hasn't actually been delivered.
A pilot that works is not a system the customer can run. Productionizing AI means making it reliable, affordable, fast, and observable enough to be real infrastructure — then handing it over so the customer operates it without you. The FDE's goal, in the end, is to make themselves unnecessary. Cost, latency, drift, observability, and a handover that transfers the eval discipline, not just the code.
You cannot ship AI you cannot measure, and no enterprise grants a probabilistic system authority over real work on faith. Both problems have the same answer: evaluation. Building the customer's own evaluation set — real examples, their definition of correct — is how the AI forward deployed engineer turns "it seemed good in the demo" into a reliability number, and that number is how trust gets earned.
You cannot ship AI you cannot measure, and no enterprise grants a probabilistic system authority over real work on faith. Both problems have the same answer: evaluation. Building the customer's own eval set — real examples, their definition of correct — turns 'it seemed good in the demo' into a reliability number, and that number is how trust gets earned. Offline/online eval, safe failure, and trust.
A recommender that scores well offline can flop in production, and a metric that looks like success can quietly harm the product. Evaluating recommenders is genuinely hard: offline metrics only approximate real behavior, the only ground truth is a live A/B test, and the very act of recommending shapes the data you learn from next. This post covers offline metrics, online testing, the gap between them, and the feedback loops that make evaluation a moving target.
A recommender that scores well offline can flop in production, and a metric that looks like success can quietly harm the product. Evaluation is genuinely hard: offline metrics only approximate real behavior, the only ground truth is a live A/B test, and the very act of recommending shapes the data you learn from next. Offline metrics, online testing, the offline-online gap, and feedback loops.
A voice demo that works in a quiet room with a good headset is a long way from a voice agent that survives a noisy phone call from a real customer. Production voice AI has to handle bad audio, unpredictable humans, failures at every stage, and the peculiar demands of telephony — and it has to be evaluated in ways text systems never require. This closing post is about making a voice agent real.
A voice demo that works in a quiet room with a good headset is a long way from a voice agent that survives a noisy phone call from a real customer. Production voice AI has to handle bad audio, unpredictable humans, failures at every stage, and the peculiar demands of telephony — and be evaluated in ways text systems never require. Making a voice agent real.
How good is a coding agent, really? The honest answer requires evaluation — measuring whether an agent can actually resolve real software tasks, not just produce plausible-looking code. Benchmarks like SWE-bench made coding-agent progress measurable by testing agents on real GitHub issues verified by real tests, and understanding how coding agents are evaluated (and the pitfalls) is how you cut through the hype to what agents can actually do. This post is about measuring coding-agent capability honestly.
How good is a coding agent, really? Because code is verifiable, you can measure task resolution by tests on real issues — which is what SWE-bench does. The pitfalls that inflate numbers (contamination, overfitting, weak tests, cherry-picked demos), and why your real tasks are the real benchmark.
Two questions separate real AI governance from theater: can you stop a model that fails its checks from reaching production, and can you prove, after the fact, that the checks were done? The first is an evaluation gate; the second is evidence. Together they turn governance from a set of good intentions into something enforceable and auditable. This post is about the mechanics of gating AI systems on quality and automatically capturing the proof that it happened.
Two questions separate governance from theater: can you stop a model that fails its checks, and can you prove the checks happened? Evaluation gates that fail closed (with teeth and legitimacy), and evidence — the automatic audit trail that governance-as-code produces for free — for regulators, auditors, and incident reconstruction.
A defense you haven't tested is a hope, not a control. The final discipline of LLM security is treating your guardrails as a system to be measured, attacked, and monitored continuously — because the threat evolves, your application changes, and a defense that worked last quarter can silently rot. This closing post covers red-teaming your own system, operating it in production, and the honest state of the art.
A defense you haven't tested is a hope, not a control. The final discipline of LLM security is treating your guardrails as a system to be measured, attacked, and monitored continuously — because the threat evolves, your application changes, and a defense that worked last quarter can silently rot. Red-teaming, production monitoring, and the honest state of the art.
Most data in the world is unlabeled, and labeling it is expensive — so some of the most useful machine learning finds structure in data with no answer key at all. Unsupervised learning groups similar things, compresses high-dimensional data, and flags the anomalies, all without being told what "right" looks like. This post covers the main unsupervised techniques and, just as importantly, how you tell whether they worked when there's no label to check against.
Most data is unlabeled, and some of the most useful ML finds structure without an answer key. Clustering, dimensionality reduction (the root of embeddings and semantic search), anomaly detection, and the hard problem of evaluating when there's no label to check against.
The most dangerous number in machine learning is accuracy, because it's the one everyone reaches for and the one that most often misleads. A fraud model that's 99.9% accurate by never catching any fraud is useless and common. Choosing the right evaluation metric — and understanding what each one hides — is the difference between a model that looks good and a model that works. This post is about measuring models honestly.
The most dangerous number in ML is accuracy — a 99.9%-accurate fraud model that catches nothing is common. The confusion matrix, precision vs recall (a business decision), F1/ROC, regression metrics, segment-level evaluation (how bias is caught), and why every offline metric is a proxy (Goodhart's law).
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.
You changed the ranking function and the results look different — but are they better? Search quality feels subjective, yet the entire field rests on measuring it rigorously, because you cannot improve what you cannot measure. Evaluating search means quantifying relevance with metrics that respect what users actually care about: not just whether the right documents appear, but whether they appear near the top. This post is about measuring relevance honestly, offline and online.
You changed the ranking and results look different — but are they better? Precision and recall ignore order (fatal for a ranked list), so rank-aware metrics (precision@k, MRR, NDCG) rule. Offline test collections for fast iteration, online A/B tests as ground truth — the same metrics that evaluate RAG retrieval.
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.
The single most common way to build a forecaster that looks brilliant and fails in production is evaluating it wrong — and time-series evaluation is riddled with ways to accidentally let the future leak into the past. Getting evaluation right, through proper backtesting that respects time order, matters more than the choice of model. This post is about measuring forecast quality honestly, which is the skill that separates real forecasters from people who fool themselves.
The #1 way to build a forecaster that looks brilliant and fails in production is evaluating it wrong. Why random train/test splits are catastrophic (future leakage), how backtesting (walk-forward validation) respects time order, and why you must always compare against naive baselines. Evaluation matters more than the model.
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.