Measuring Real Agent Improvement Over Time

If an agent is supposed to improve itself, there needs to be a way to measure whether it is actually getting better.

This turns out to be harder than it sounds - and most approaches to it are quietly inadequate.

Why Task Count Is Not Enough

The obvious first metric is how many tasks the agent completes. But this measures activity, not quality. A system can complete more tasks while producing worse answers on each one. Volume is easy to optimize for in ways that do not correspond to genuine improvement.

Better Signals

The more meaningful signals require longitudinal tracking:

Human correction frequency - how often does a user have to correct or override the agent's answer? A declining correction rate is one of the clearest signals that the agent is actually improving.

Prediction accuracy - for agents that make predictions about system behavior, how well do those predictions match what actually happens? This can be measured precisely.

Problem resolution speed - is the agent resolving recurring problem types faster than it was three months ago? This requires tracking the same problem categories over time, not just point-in-time performance.

Novel problem handling - when the agent encounters a situation it has not seen before, does it handle it better than it would have earlier in its development? This is the hardest to measure but the most important.

The architecture already captures the signals needed to do this honestly. The EventEvaluation interface records reward score, user feedback, self-assessed quality, and whether the output was hallucinated - all attached to the original ExperienceEvent:

// packages/core-types/src/experience.ts

/** Evaluation metadata used by the reinforcement engine. */
export interface EventEvaluation {
  readonly rewardScore: number
  readonly userFeedback?: 'positive' | 'negative' | 'neutral'
  readonly selfAssessedQuality: number
  readonly hallucinated?: boolean
}

And RetrievalFeedback captures whether a specific retrieved memory was actually useful - not just whether it was retrieved:

// packages/core-types/src/memory.ts

export interface RetrievalFeedback {
  readonly feedbackId: string
  // NOTE: article omits timestamp field present in source: readonly timestamp: string;
  readonly querySummary: string
  readonly retrievedMemoryId: string
  readonly usedInResponse: boolean // was it actually used?
  readonly helpfulnessScore: number // did it help?
  readonly hallucinationDetected: boolean
  readonly futureWeightAdjustment: number // how to adjust retrieval priority
}

Aggregating these feedback records over time gives you the signal you need to measure whether retrieval quality is improving. A declining hallucinationDetected rate, an increasing helpfulnessScore average, and a rising usedInResponse fraction are all concrete indicators of real improvement - not benchmark scores on a fixed test set.

The Benchmark Problem

Standard benchmarks measure performance on fixed test sets at a single moment in time. They tell you how capable a system is today. They say nothing about whether the system is improving.

A system can ace every benchmark while failing to improve at all in the environment where it actually operates. The benchmark and the real task are different things.

Being Honest About This

Real improvement measurement means defining upfront - precisely - what "better" means for your specific use case. That definition forces uncomfortable specificity about what the agent is actually for and what success looks like.

If you cannot define it precisely, you cannot measure it. And if you cannot measure it, claims about self-improvement are speculation dressed up as engineering.

This is the uncomfortable middle of building genuinely self-improving agents. The next article covers where all of this leads.