Feedback Loop Architectures for Multi-Agent Production Systems

A feedback loop in a multi-agent production system only works if it can trace a failure back to the specific layer that caused it, prompt, tool schema, memory retrieval, or routing logic, and then route that diagnosis into a change that gets tested before it ships. If a team monitors agents without this attribution step, they are not running a feedback loop. They are watching dashboards and guessing.

The improvement cycle in multi-agent systems

A single agent that fails gives you one place to look: its prompt, its tool calls, its one context window. So attribution is no longer a matter of local inspection, but a search problem across the whole run.

Because the output of one agent becomes the input that conditions the next agent's reasoning, a small error early in a chain does not stay small. Cascading hallucination of this kind is one of the hardest problems multi-agent systems face, because nothing in the final trace shows where the error entered the chain.

The consequence for any team trying to improve these systems is blunt: without structured attribution and routing, improvement work is likely to target the wrong layer. The fix looks reasonable, but the metric does not move, and the real cause stays in place until the next incident forces another round of guessing.

How architecture choices determine where signal lives and gets lost

Architecture is not only a question of latency or cost.

Sequential pipelines make failures visible at stage boundaries: if stage two produces a bad result, you know which stage to inspect. The boundary tells you where to look. It does not tell you what you'll find there.

Supervisor/worker patterns concentrate coordination in one place, which makes them the most debuggable pattern commonly used in production, since logging, rate limiting, and error handling all have a natural home in the supervisor layer. A supervisor that routes silently is a single point of failure with no record of why it chose the path it chose.

Hierarchical patterns add delegation levels, and signal can get lost at each one. Systems that tangle perception, reasoning, and action logic together into a single undifferentiated layer compound this problem: a change to a memory module can break the reasoning layer in ways no one anticipated, and debugging becomes a matter of trial and error.

Unstructured inter-agent communication deserves particular attention here, because it is a specific, avoidable architectural decision. A failed outcome in a multi-agent system demands trajectory-level attribution, pinpointing which agent's prompt, tool invocation, memory retrieval, or routing decision caused it. This is precisely the problem production-trace-driven platforms like Moda are built to solve: ingesting the full span hierarchy across agent boundaries and surfacing which layer in the chain is responsible, turning opaque coordination noise into actionable signal.

The decisions that matter here get made before a system ever ships: modular decomposition, structured message schemas, trace ID propagation, and explicit routing layers. If that structure is not in place from the start, no debugging tool, however capable, can reconstruct what actually happened.

What step-level tracing must capture to make attribution possible

A pass/fail health check tells you almost nothing about an agent in production. Step-level tracing is the minimum signal required to say anything meaningful about why an agent behaved the way it did.

A trace worth the name captures intent and process, not just the input and the final output. Every span in that structure needs to record the model version, the prompt version, the tools called, the tokens consumed, and the cost incurred, because any one of those can shift between deploys and quietly change how the agent behaves without any corresponding change in the code.

None of this holds together without a shared trace ID emitted on every run and propagated across every agent boundary the run touches. Without that ID, there is no way to reconstruct the multi-agent trajectory that produced a given outcome end to end. OpenTelemetry's GenAI semantic conventions are emerging as a widely adopted standard at this layer, giving teams a portable export path that keeps traces usable across different tooling.

As agents run longer and attempt more complex tasks, their logs can reach millions of tokens, and the handful of steps that actually explain a failure may be sparse and scattered across distant parts of a long trajectory. A complete trace, one that captures reasoning, tool decisions, arguments, responses, tokens, and latency across every agent boundary, is the raw material a feedback loop needs. That raw material is only useful if its structure supports search across the whole trajectory, not just sequential replay from the top.

Attributing a failure to a specific harness layer

Knowing a run failed tells you almost nothing on its own. What matters is whether the fault belongs to the prompt, the tool schema, the memory retrieval, the workflow routing, or the model itself, because each of those layers calls for a different fix, and fixing the wrong one leaves the actual cause sitting untouched in the system.

Fault needs to be assigned to the component actually responsible, model, harness, or environment, because that assignment is what directs the intervention. Collapse these categories together and every fix becomes a shot in the dark.

Attribution of this kind is a trajectory-level search problem, because the evidence that explains a failure can appear far earlier in the run than the bad output itself, scattered across distant parts of the trace. The Continual Search framework, introduced in the paper "Root-Cause Attribution Is a Search Problem," addresses this directly by forcing a judge to keep exploring unresolved evidence instead of anchoring on the first plausible explanation it finds. That design choice targets a specific and common attribution failure: premature closure, where an investigator settles on a convenient cause before the actual one has been ruled in or out.

What makes a diagnosis useful is structure. A typed diagnosis, one that carries a root cause, supporting evidence, a confidence score, and a recommended fix, is something a team can act on. An unstructured log note saying a run "looked off" is not.

The obvious objection to all this is cost: attribution at this level of granularity sounds expensive to run on every failure. Cost-aware triage is the answer. Depth analysis using LLM-as-judge methods is reserved for the cases that pass that initial triage and still need deeper investigation, so the majority of traffic never incurs the full cost of a detailed trajectory search.

The three failure categories that most often defeat harness attribution in multi-agent systems

Schema drift is one of the most dangerous failure categories because it tends not to announce itself. A GitHub bug report, issue #25276, filed after an upgrade from v2.4.7 to v2.6.3, documented a case where the platform began generating invalid tool schemas, with a type field set to 'None' instead of 'object', in its tool calls. Schema drift often shows no visible error in the trace itself. It produces a malformed-but-plausible response that passes downstream unnoticed until a person finally catches a wrong output and starts asking why.

Adjacent-tool ambiguity is a quieter version of the same problem. The agent then attempts to execute that tool, hallucinates the arguments it's missing to make the call work, and produces a result that defeats attribution efforts because the trace shows a tool call that technically succeeded.

Workflow loops round out the third category. The resulting trace shows a long sequence of individually successful steps, which makes the loop invisible to anyone inspecting the trace span by span.

What unites all three categories is a shared structural property: each produces a trace that looks locally healthy while the run itself is globally broken. That gap is why attribution has to operate at the trajectory level. Two harness-level controls catch the first and second categories before they ever reach a trace worth investigating: typing and validating every tool argument before the call leaves the agent, and returning structured errors instead of raw exception traces when something goes wrong.

Three layers of evaluation that catch failures before and after shipping

A feedback loop only closes if evaluation operates across three distinct layers: pre-ship validation, per-release quality checks, and continuous production sampling. Each layer exists because it catches a class of failure the other two cannot.

Unit evals run on every CI pass, so they catch plumbing regressions and schema drift before code ever reaches a release branch. LLM-as-judge suites run per pull request or per release, so they catch the subjective quality regressions that unit tests, by design, cannot see. Production sampling runs continuously after shipping, so it catches distribution shift, real-world drift, and the long-tail failures that no pre-ship test suite was built to anticipate, because these appear only once real users start sending real traffic.

The mechanism that makes this loop genuinely closed, rather than merely reactive, is simple: every incident that clears initial checks and reaches production anyway becomes a frozen eval case. That conversion means the exact same failure cannot ship a second time, because it is now a permanent fixture of the regression suite rather than a one-off incident that gets fixed and forgotten. None of this works, though, if the eval dataset stays too small. A thin golden set produces noisy signal, and it can hide systematic regressions sitting in edge cases the sample never touches. If you embed evaluation probes directly inside the agentic workflow, instead of relying only on offline batch analysis after the fact, you get real-time auditability, and every run generates evaluation signal, not just the subset that happens to get sampled.

Harness continual learning and the feedback loop

If a feedback loop only fixes discrete, identifiable failures, it is not yet a continual improvement system. Input distributions shift over time, so a harness configuration that worked reliably last quarter can degrade silently this quarter, with no single incident sharp enough to make anyone notice that performance has slipped.

Harness Continual Learning, or HCL, names this problem directly. Because prompts, memories, tools, skills, and routing rules all jointly shape how an agent behaves downstream, a change to any one of them can disrupt previously reliable behavior even when the underlying model never changes. That raises a genuinely hard question: how does an agent continually improve the state that sits outside the model, the harness itself, without losing behavior it had already learned to do well?

The ReHarness framework answers this under a strictly online streaming protocol. After an agent handles each instance, the resulting trajectory becomes feedback that revises the reflections retrieved for that instance, so the correction propagates backward through the harness's textual state. That backward propagation corrects reflections that have become overgeneralized or simply outdated as the environment shifts, improving both the stability of what the harness already does well and its plasticity in adapting to what has changed.

Memory makes this problem sharper in multi-agent systems specifically. A stale, context-specific memory is often more damaging than no memory at all, because it injects confidently wrong context into an agent's reasoning without ever triggering an error that would flag the problem. Continual learning from recurring failure patterns has to be engineered deliberately. You need explicit mechanisms that detect when a previously reliable behavior has started to degrade, attribute that degradation to a specific harness layer, and propagate a correction backward before it accumulates into a systematic failure mode that shows up across many runs at once.

The feedback loop architecture when all the pieces are in place

A complete feedback loop architecture is a pipeline, and not a collection of separate tools bolted together. Once shipped, it becomes a regression case that runs continuously from then on, feeding back into the same trace stream that started the cycle.

Five structural requirements hold this pipeline together: low-friction trace capture that preserves full trajectory context, typed attribution that names the responsible layer along with its evidence and confidence, generated fixes that are reviewable and inspectable rather than black-box outputs, replay validation against real traces before any change ships, and continuous production sampling that feeds new signal back into the attribution layer once the fix is live. Runtime governance enforces this structurally: the Microsoft Agent Governance Toolkit enforces governance decisions deterministically before actions reach the wire, making certain blocked actions structurally impossible. The same principle extends naturally to shipping unvalidated harness changes: the architecture should make it hard to ship a fix that hasn't been replayed against real traces, not just discourage it.

The harness is the highest-leverage place to intervene in this whole system. A complete trace, one that captures reasoning, tool decisions, arguments, responses, tokens, and latency across all agent boundaries, is the raw material this entire cycle runs on, but only once it's structured richly enough to be replayed and interrogated step by step. Moda is built around this exact pipeline: it ingests production traces, attributes failures to the specific harness layer responsible, whether that's prompt, tool, workflow, memory, model, or product logic, generates concrete and reviewable improvements, and validates them against historical traces before recommending what to ship, closing the loop from a broken trace to a verified fix without requiring model retraining or manual log review.

It is a different process entirely, one that produces improvement by accident when it produces improvement at all, rather than by design.