Without Production Verification, an AI Agent Improvement Loop Is Still a Hypothesis

A model can rewrite a system prompt in seconds. A playground can compare outputs. A test suite can show that a challenger beat a baseline on a chosen dataset. A prompt registry can promote the new version to production. Each step is useful, but none answers the final causal question by itself: did this exact change improve the targeted behavior on new production traffic without causing a material regression elsewhere?

That question crosses organizational boundaries. The failure may live in an observability tool, the candidate in a playground, approval in GitHub, deployment in a prompt registry, production outcomes in another analytics system, and customer feedback in a support queue. Unless those records share one change identity and one outcome contract, the loop becomes a sequence of screenshots and handoffs.

First, the loop needs change identity. The proposed fix, approved artifact, active production version, measurement window, and rollback must all refer to the same immutable change. “We updated the prompt last Tuesday” is not enough lineage when three other changes landed nearby.

Second, it needs a stable target. A fix should name the failure pattern and the metric that would change if the diagnosis is correct. Measuring only an overall score makes it easy for unrelated traffic mix or a strong secondary metric to hide the result.

Third, it needs comparable evidence. Pre-deploy simulation should compare baseline and challenger on the same cases. Post-deploy measurement should use the same detection rule before and after the change and disclose whether the traffic is actually comparable.

Fourth, it needs a confounder policy. Model upgrades, other prompt edits, routing changes, seasonality, and instrumentation changes can all move the outcome. A mature loop records “cannot attribute” rather than giving the latest deployment automatic credit.

Fifth, it needs a terminal next action. Verified should preserve the win and its regression cases. Not fixed should reopen diagnosis with the failed attempt attached. Confounded should request a cleaner measurement window or a better-isolated rollout. A green score with no downstream state is a report, not a learning loop.

A pull request is excellent governance. It makes the proposed change reviewable, keeps a diff, gives an engineer authority over what ships, and can trigger tests and deployment. It proves that a change was proposed or merged. It does not prove that the production agent began serving that version, that the targeted users encountered it, or that the failure rate changed because of it.

Treat the PR as the approval and lineage boundary. Then attach the deployment marker and production evidence to the same change. This preserves human accountability without asking a reviewer to manually reconstruct the outcome weeks later.

Teams often design evaluation systems that can only celebrate. That creates pressure to reinterpret a weak change as a win. A production verdict needs a legitimate negative outcome. “Not fixed” means the system measured the target and the failure persisted; that is valuable evidence about the diagnosis or intervention.

“Confounded” is different. It says the observed movement cannot be assigned cleanly to the change. Keeping those two outcomes separate prevents a failed fix from being confused with a failed experiment and prevents ambiguous traffic from becoming a marketing claim.

Start with one agent, one expensive failure pattern, one immutable change ID, one approval boundary, and one post-deploy decision rule. Do not begin by inventing a universal reliability score or automating every deployment. The smallest complete loop is more valuable than a broad dashboard with no terminal decision.

Once the same evidence chain works repeatedly, routine low-risk changes can earn more automation. Autonomy should expand because the loop has learned where it is reliable and how to recover, not because the approval button feels inconvenient.