Agent Quality Is a Loop Engineering Problem

Why enterprises need bounded, observable, and governed improvement loops for production AI agents, and how the open-source ASSERT framework engineers the half of the loop everything else depends on.

TL;DR: Enterprises manage AI agent failures as isolated defects - patch the prompt, rerun the failed case, deploy, and then watch another behavior regress. The failure is loop design, not prompt skill. Production agent quality depends on two engineered loops: the runtime loop the agent executes and the improvement loop the organization executes. The improvement loop’s foundation is verification, and that half now has a fully open-source engine: ASSERT compiles written behavior requirements into stratified, trace-level, policy-cited evaluation suites - locally runnable, framework-agnostic, and inspectable end to end. Improving the agent against that measurement remains the organization’s loop to engineer: diagnose, change one configuration layer, rerun the full suite, gate, ship versioned. The recommendation: write the behavioral contract first, compile it into a calibrated suite, and convert every production incident into a permanent regression case. Evaluators are the ceiling on everything downstream.

The direct answer

Enterprise agent failures recur because organizations apply a local repair model to systems whose behavior is globally shaped by configuration. Reliable agents come from engineered loops with explicit goals, evidence, limits, decision rights, and exit conditions: a bounded runtime loop governing how the agent acts, and a governed improvement loop controlling how it changes.

The verification half of that system now has an open-source engine. ASSERT defines and measures correct behavior, compiling written policy into stratified, trace-level evaluations with policy-cited verdicts and it runs locally against any agent framework. Improving the agent against that measurement is the organization’s loop to engineer: diagnose the failure, change one configuration layer, rerun the full suite, and let a human gate decide what ships.

The pattern executives already recognize

Most enterprises manage AI agent failures as isolated defects. An agent misses an escalation. It calls the wrong tool. It approves an exception that should have gone to a human. The team examines the trace, changes the prompt, reruns the failed case, and deploys the apparent fix.

Then another behavior regresses.

This is often described as a prompt-engineering problem. It is more accurately a loop-engineering problem. Production agents operate through loops - observe context, select actions, call tools, inspect results, decide whether to continue, stop, or escalate. The teams improving those agents are also operating a loop: observe a failure, diagnose it, propose a change, test it, decide whether to deploy it. The quality of the agent depends on the quality of both loops. Anthropic’s agent-evaluation guidance names the trap from the vendor side: without strong evals, teams get stuck in reactive loops, catching issues only in production, where fixing one failure creates others.

The executive implication is straightforward:

Reliable agents do not emerge from better prompts alone. They emerge from engineered loops with explicit goals, evidence, limits, decision rights, and exit conditions.

What is Loop Engineering and what does existing usage miss?

Loop Engineering is the discipline of designing the recurring control cycles through which an AI system acts, verifies, learns, and improves. A production-grade loop must answer six questions:

1. What objective is the loop trying to improve?

2. What evidence determines whether progress occurred?

3. What actions may the loop take?

4. What limits constrain cost, time, authority, and retries?

5. When must a human intervene?

6. What conditions cause the loop to stop, ship, roll back, or escalate?

The term entered mainstream practitioner discourse in mid-2026, and existing treatments - practitioner guides defining it as the design of agent execution cycles, vendor explainers framing loop design as the real quality differentiator, and academic work on Agentic Loop Engineering as disciplined orchestration, focus almost entirely on the runtime loop: how a single agent perceives, acts, verifies, and stops. That work is necessary and correct as far as it goes.

What it misses is the second loop. The organization improving the agent is also running a recurring control cycle, and that cycle determines whether the enterprise becomes more reliable over time or merely faster at reacting to incidents. Without explicit answers to the six questions, organizations do not have a quality system. They have repeated experimentation.

Why incident-by-incident debugging fails

Traditional software defects have an address: a test fails, a stack trace points at a function, engineers patch it and confirm the fix. Agent failures are different. Microsoft’s own account of the pattern describes a travel-approval agent that approves a $4,800 trip without the required executive review. The trace shows the infrastructure worked, tools available, workflow completed, answer confident. The agent simply never called the budget-check tool. The team adds a stronger cost-threshold instruction; the original case passes; emergency travel requests begin escalating unnecessarily; another revision restores the exception and weakens two unrelated scenarios.

The engineers are not failing at debugging. They are applying a local repair model to a system whose behavior is globally influenced by configuration, every prompt edit, tool description, or model change can alter behavior across the entire evaluation surface. A quality issue may originate in the system instruction, the model, a tool description, a skill definition, orchestration logic, or an interaction among several at once. Dozens of changes might repair one scenario; many quietly weaken another. Without a structured loop, the process becomes prompt thrashing, failure, patch, spot-check, deploy, regress, repeat and at portfolio scale that is not an engineering process. It is an expanding operational liability.

The way out is not a smarter patch. It is a regression surface wide enough that any patch is scored against everything the agent must still do, which is precisely the artifact most teams never build, because hand-writing it is slow and keeping it current is slower.

The two loops executives must govern

The runtime loop is the loop the agent executes while performing work: observe → decide → act → verify → continue, stop, or escalate. A well-engineered runtime loop has bounded authority, it knows which tools it may call, how many attempts it may perform, what evidence is required before acting, and when control must return to a human. A poorly designed one retries indefinitely, treats tool success as proof of task success, or returns a confident answer despite incomplete verification.

The improvement loop is the loop the organization executes to improve the agent: specify → evaluate → diagnose → change → gate → ship → observe. A well-engineered improvement loop converts production experience into durable reliability. A poorly designed one optimizes against vague requirements, tests only the incident that triggered the change, promotes changes on one aggregate score, or allows the same failure to recur because it was never added to the regression suite.

These loops are connected. Production telemetry from the runtime loop improves the specification and evaluations used by the improvement loop; changes approved by the improvement loop alter the runtime loop. That connection is what closes the system and it is why eval value compounds over the lifecycle of an agent rather than depreciating like a point-in-time test suite.

In Loop Engineering terms: ASSERT engineers the verification arc - specify and evaluate. The rest of the improvement loop is yours to operate, whether the change step is a developer editing an instruction, a team refactoring tool descriptions, or an automated search tool proposing candidates. The verification arc is the right place for the open-source, portable component, because every downstream step inherits its quality. An improvement process scored against a weak suite produces confident noise regardless of how the changes are generated.

What is ASSERT, and how does it work?

ASSERT - Adaptive Spec-driven Scoring for Evaluation and Regression Testing - is an open-source framework from Microsoft’s Responsible AI team that converts natural-language behavior requirements into executable evaluations for models, agents, and application workflows. Three properties make it the right foundation for an enterprise verification loop: it is open source on GitHub, it is framework-agnostic - the integration boundary is a callable target that works for any agent or multi-agent system, with any LiteLLM-supported provider (OpenAI, Anthropic, Bedrock, Vertex, Ollama, and others) and it runs locally, producing artifacts a team can inspect, version, and audit without sending traces to a managed service.

Instead of starting from generic metrics such as helpfulness or relevance, it starts from the behavior the business expects. A product requirement like “the support agent may issue refunds below $100, must escalate refunds above $100, suspected fraud, and requests without a verified order number” usually lives in a document or a system prompt. ASSERT turns it into a testable quality system.

The specification is the quality lever. ASSERT’s output depends heavily on input specificity, and its authors caution that vague specifications produce vague scenarios. “Be a safe and helpful support agent” is not testable. “Do not issue refunds above $100; escalate suspected fraud; verify the order number before calling the refund tool” is the specification must contain observable decisions, not broad intentions.

Systematization expands the requirement. A single policy statement usually contains multiple distinct failure modes. For “respect tool-use governance,” the framework identifies patterns and boundaries, missing required tool use, unnecessary tool use, unauthorized tool use, incorrect tool order, calls made without sufficient evidence, calls influenced by malicious tool output, following the concept-grounding method of Agarwal et al.

The taxonomy is an editable governance artifact. ASSERT converts the expanded concept into a taxonomy of permissible behavior, impermissible behavior, edge cases, and expected escalation and a product owner, policy specialist, or compliance reviewer can inspect and modify it before any test is generated. The intermediate representation is visible rather than hidden inside a generation prompt, which is one of the framework’s most useful governance characteristics: it hands risk and compliance teams a familiar artifact, a reviewable document describing permitted, prohibited, and escalated behavior.

Test generation is stratified, not random. The framework instantiates the taxonomy into single-turn and multi-turn cases - normal, boundary, adversarial, and prompt-injection across dimensions the developer declares. For a refund agent:

Refund amount:     $20 | $99 | $100 | $101 | $1,000
Order state:       verified | unverified | missing | disputed
Customer signal:   normal | urgent | angry | suspected fraud
Tool availability: all tools | verification unavailable | refund tool unavailable

The value comes from combinations. An agent may behave correctly for a $101 refund and fail when the customer also claims an emergency.

Execution captures the full trace. The recommended integration for non-trivial agents captures the agent’s OpenTelemetry spans through auto-instrumentation, so the judge can cite tool calls, routing decisions, model calls, and latency as evidence, distinguishing “the answer was wrong because the agent skipped a tool” from “the tool returned bad data,” “the orchestrator routed to the wrong sub-agent,” and “the answer was correct but the agent performed an unauthorized action.” The repository’s flagship example is a multi-agent LangGraph travel planner with five tools in a six-turn budget, evaluated across six failure-mode categories spanning quality (skipped tools, fabricated prices, budget violations) and safety (stereotyping, prompt injection, sycophantic agreement with invalid itineraries).

Judging produces evidence, not a checkmark. Each verdict includes a pass-or-flagged label, a rationale, the relevant policy citation, and the specific turn or action supporting it, materialized as inspectable local artifacts: taxonomy.json, test_set.jsonl, inference_set.jsonl, scores.jsonl, and metrics.json. And the scoring is decomposed rather than rolled up: in the travel-planner results, the same five scenarios produce 40% over-refusal and 60% policy violation - opposite failures, one too timid and one too permissive, that a single aggregate score would average into an apparently acceptable number.

The contrast with an ordinary LLM-as-judge setup is structural. A typical judge pipeline is input + final response → judge → score. ASSERT’s pipeline is written requirement → behavior taxonomy → stratified scenario generation → full agent execution and trace → policy-grounded judge → failure analysis. The critical contribution is upstream of the judge: it constructs the behavior surface being evaluated.

How reliable are the judges? Microsoft reports internal judge agreement with human annotators of approximately 80–90% across more than ten behavior concepts, against human inter-annotator agreement of roughly 90% - consistent with the MT-Bench finding that strong LLM judges reach human-level agreement - while noting that judge strictness and boundary sensitivity vary by model.

The operating standard: judges run the first pass for coverage, humans sample verdicts near subtle policy boundaries, and high-risk dimensions get deterministic evaluators or mandatory human review.

What ASSERT is not: a compliance certification, proof the agent is safe, a replacement for deterministic tests, a substitute for production telemetry, or an automatic agent-fixing system. It measures; it does not repair. Which raises the operative question - once the suite exists, how does the rest of the improvement loop run?

Closing the loop on top of ASSERT

With the verification arc in place, the improvement loop is a disciplined cycle any team can operate without waiting on additional tooling:

Diagnose before changing. The single highest-yield step is failure diagnosis, and the evidence for that claim is unusually strong. Microsoft’s optimization research found that the quality of the model diagnosing why an agent failed moved outcomes more than the agent’s own model and GEPA, the reflective prompt-evolution optimizer accepted as an ICLR 2026 oral, found natural-language reflection on execution traces outperformed reinforcement learning by up to 20% with up to 35x fewer rollouts. Better diagnosis beats better execution. ASSERT’s verdicts are built for exactly this step: a flagged case arrives with the policy it violated and the turn that violated it, so triage starts at the cause. A failure that looks like a prompt problem may actually be missing source data, a misleading tool description, an orchestration defect, an authority boundary that was never encoded, or an evaluator rewarding the wrong behavior. Root-cause classification before configuration change prevents a loop that repeatedly fixes the wrong component.

Change one layer at a time. Instructions first, then tool descriptions, then skills, then model selection. A tool-description change is often the most underrated lever - turning “Returns information about a department’s travel budget” into “Must be called before approving any travel request. Do not infer budget availability without calling this tool” encodes the constraint where the agent actually reads it. Changing every layer at once makes it impossible to understand why behavior moved.

Rerun the full suite, always. A change is not an improvement because it fixes the latest incident. It is an improvement when the complete regression suite, refund governance, escalation, tool-use correctness, injection resistance, over-refusal confirms nothing else broke. This is the Regression Testing in ASSERT’s name, and it is the entire difference between a fix and a new incident with better intentions.

Gate and ship versioned. A reviewer sees per-dimension diffs, the diagnosis, the configuration change, and a rollback plan the same discipline as a pull-request review, because that is what it is. The analogy holds across the whole loop:

Software engineering Agent Loop Engineering Requirements Behavioral specification Unit and integration tests ASSERT evaluation suite Runtime diagnostics Agent traces Root-cause analysis Failure diagnosis Code change Configuration change CI test run Full-suite rerun Pull-request review Human promotion gate Release version Versioned agent configuration Production incident New regression scenario

Observe, and feed production back. Synthetic cases miss real-world conditions; the suite is an approximation of production, never a substitute for it. Every material incident becomes a root-cause classification, a revised specification, a new regression case, and an evaluator-calibration input. When incidents do not change the quality system, the loop remains open and the organization repeats them.

The dependency underneath all of it:

An agent-improvement loop cannot become more reliable than the evidence and evaluators guiding it.

Whatever generates the changes - a developer, a team, or an automated search tool, the process pursues what the suite rewards. Reward polished responses and the loop produces polish; reward correct tool use, policy compliance, evidence, escalation, and completion together and the loop has a useful target. That is why the durable competitive asset is not model access. It is the accumulated quality system: behavioral specifications, production-derived cases, calibrated evaluators, failure taxonomies, traces, promotion records, and rollback discipline. These assets compound and because ASSERT’s artifacts are local files, they version, diff, and audit like any other engineering asset.

Where does the loop apply?

Customer-support and refund agents. The clearest fit, because expected behavior can be written as explicit boundaries. The suite tests refund thresholds, required order verification, fraud escalation, prompt injection inside customer-provided text, and over-refusal of legitimate requests. A $250 refund issued with a verified order but skipped manager approval is exactly the failure a policy-cited verdict names and the fix is usually an explicit approval procedure in the instruction or a stricter refund-tool description.

Financial, travel, and procurement approval agents. The suite tests amount thresholds, separation-of-duty rules, mandatory tool sequence, exception handling, and unauthorized approvals. The $4,800 travel incident resolves the same way at the configuration layer an explicit cost threshold and escalation ladder, but it ships only after the full suite confirms the emergency-exception case still passes.

Enterprise RAG and research agents. ASSERT inspects the retrieved context and execution trace, not merely whether the final answer sounds grounded testing whether every material claim is supported, restricted sources are excluded, conflicts are disclosed, and the agent abstains when evidence is insufficient. One boundary: the loop cannot compensate for a broken retrieval index. Bad chunking, stale data, and missing ACLs are infrastructure problems, not specification problems.

Multi-agent routing and handoffs. The suite tests correct agent selection, handoff timing, circular-handoff prevention, context preservation, and required human escalation. Trace capture is essential here, a correct final answer does not prove the routing path was safe or efficient, and the LangGraph multi-agent example demonstrates the integration shape.

Web-research and data-extraction agents. The suite tests that evidence exists for every accepted field, blocked or login pages are not treated as content, conflicting sources trigger review, and the agent abstains rather than fabricates. Deterministic schema validation, URL checks, and date parsing remain in code, behavioral evaluation covers the probabilistic parts, never replaces reliable deterministic controls.

Autonomous coding agents. The suite tests behavioral controls, the agent reads repository instructions before editing, does not modify protected files, does not claim success when tests fail, does not remove tests to make the suite pass, and stops after repeated unsuccessful repairs. It does not replace compilers, type checking, or security scanners. The layered model: deterministic checks (build, lint, tests, security), then behavioral checks (scope, instructions, evidence), then the human gate (architecture, maintainability, intent).

Long-running operations agents. The suite tests authority boundaries, required evidence before action, retry limits, escalation severity, and rollback behavior. The runtime must still impose deterministic limits on permissions, retries, cost, and destructive actions — prompt instructions alone are never the security boundary.

The build lifecycle

1. Build the smallest working agent - clear instructions, a few well-described tools, explicit permissions, trace instrumentation. Do not evaluate a vague or rapidly changing prototype.

2. Write the behavioral contract - must do, must never do, requires evidence, requires approval, stop conditions, escalation conditions. Keep each specification narrow: separate refund governance, fraud escalation, tool-use correctness, privacy, and injection resistance rather than one specification called “good customer support.”

3. Generate the first ASSERT suite and review it - inspect generated cases and judge rationales before trusting any aggregate score. The CLI ships a conversational config assistant (assert-ai init) that drafts the evaluation config from a plain-language description of the agent.

4. Add curated cases - production incidents, product-owner examples, handwritten edge cases, reviewer overrides. Generated tests give breadth; curated tests preserve the business’s most important known truths.

5. Calibrate the evaluators - measure false passes, false failures, and disagreement near policy boundaries. High-risk dimensions may need deterministic evaluators or mandatory human review rather than a general judge.

6. Freeze a meaningful baseline - a suite is decision-ready only when it reliably separates good runs, bad runs, and the failure types that matter to the business.

7. Iterate one layer at a time - diagnose from the verdicts, change instructions or tool descriptions or skills or model, and rerun the full suite after every change.

8. Review each change as a change set - configuration diff, failure diagnosis, per-dimension scores, newly failing cases, authority changes, rollback plan. Treat it like a pull request.

9. Ship versioned and reversible - controlled rollout for consequential agents, with rollback the moment production evidence disagrees.

10. Close the loop - every material incident becomes a root-cause classification, a revised specification, a regression case, and an evaluator-calibration input for the next cycle. Without that final connection, ASSERT is only a periodic test generator.

When the loop is not the answer

Not every failure calls for the behavioral-evaluation loop. Manual, targeted intervention remains right when the agent is early-stage and lacks traces; when the failure is infrastructure, latency, or missing data; when one agent has one narrow, well-understood defect; when the task exceeds the model’s reasoning capability; or when the cost of building and operating the suite exceeds the business value of the workflow. Sometimes the correct exit from the loop is a different model, a fixed data source, reduced agent authority, or a return to a deterministic system. A mature loop can reach those conclusions. A team that only rewrites prompts cannot.

Frequently Asked Questions

What is Loop Engineering?

Loop Engineering is the discipline of designing the recurring control cycles through which an AI system acts, verifies, learns, and improves. It decomposes into two connected loops: the runtime loop the agent executes (observe, decide, act, verify, escalate) and the improvement loop the organization executes (specify, evaluate, diagnose, change, gate, ship, observe). Existing industry usage covers the runtime loop; the improvement loop is where enterprise governance lives.

Does ASSERT require Azure or any specific agent framework?

No. ASSERT is open source and framework-agnostic: the integration boundary is a callable target that works for any agent, multi-agent system, or application workflow, and any LiteLLM-supported model provider works - OpenAI, Anthropic, Bedrock, Vertex, Ollama, and others. It runs locally and writes its taxonomy, test set, traces, verdicts, and metrics as inspectable files, which matters for regulated teams that cannot ship traces to a managed service.

How reliable are the LLM judges inside the loop?

Vendor-reported validation puts judge agreement with human annotators at 80–90% across more than ten behavior concepts, against human inter-annotator agreement of roughly 90%. The operating standard: judges run the first pass for coverage, humans sample verdicts near subtle policy boundaries, high-risk dimensions get deterministic evaluators or mandatory human review, and judge-model choice is treated as a calibration decision because strictness varies across models.

How does the agent actually improve once ASSERT finds failures?

Through the improvement loop the suite makes safe to run: diagnose the root cause from the policy-cited verdict, change one configuration layer - instruction, tool description, skill, or model, rerun the full suite, and gate the change on per-dimension results. The diagnosis step carries the most weight; Microsoft’s optimization research and GEPA both found that the quality of failure diagnosis moves outcomes more than the capability of the agent’s own model. Automated configuration-search tools can slot into the change step later; the suite is what makes any of them trustworthy.

So What?

Choose the production agent associated with the most recent quality incident and ask two questions.

What loop allowed this failure to occur? Was it the runtime loop that acted without enough evidence, exceeded its authority, or failed to escalate? Or was it the improvement loop that deployed a change without sufficient evaluation, diagnosis, or regression protection?

Then ask: what permanent change will close that loop? The answer may be a clearer behavioral specification, a new evaluation case, a stronger verifier, a retry limit, a human gate, or a tighter authority boundary. The first step is not another prompt revision or a larger model. It is designing the loop through which the system acts and the loop through which the organization allows it to improve, starting from artifacts that already exist, with an open-source spec-to-eval compiler you can clone and run against your own agent this week.

That is how agent quality becomes an operating capability rather than a recurring sequence of incidents.