A Multi-Agent LLM System for Autonomous Detection, Diagnosis and Repair of Micro-Frontend Integration Failures

Abstract

Modern web applications are increasingly assembled at runtime, not build time. A micro frontend architecture stitches a single user-facing product together out of fragments — a product list, a cart, a checkout flow — each built, deployed and owned independently by a different team. It's a pattern already in production at DAZN, Ikea and Starbucks. It is also a pattern that fails in ways no single fragment can see on its own: a shell requests a shared library version a remote no longer exports; a renamed event field silently corrupts data in two other fragments that were never touched; one remote's CSS bleeds into another's layout. These are integration failures, not code defects, and today they are found by a human staring at a broken page — or not found at all. We set out to measure, not assume, how visible these failures actually are, and then to close the gap with a system that watches for them, works out which fragment is genuinely at fault, and fixes it without a human in the loop. The measurement came first, and it was uncomfortable. Of five representative micro frontend integration failures we injected into a working application, two — a violated event contract and a leaked stylesheet — wrote nothing to the browser console in a production build. Every agentic diagnosis system we could find in the literature, including systems already deployed at Google and Meta, is built around exactly that signal. That's not a flaw in those systems; it's a boundary of the domain they were designed for. It means log-based diagnosis has a structural ceiling here that no amount of tuning removes. So the system we built doesn't start from logs. Detection is deterministic and runs across five independent probes — console, network, DOM structure, computed style, and the event contract itself — so a failure that only speaks through a corrupted layout or a silently reshaped payload is still caught. Only once something is detected does a model get involved: a Diagnoser agent reads the deployment manifests and reasons its way to the specific fragment at fault, and a Repair agent proposes an anchored source edit. Every proposed patch is checked twice before it is accepted — once behaviourally, by re-running the detector against the live, patched application, and once structurally, against the architectural declarations (shared-dependency singletons, in particular) a repair is never allowed to delete just to make the symptom disappear. Evaluated at ten runs per failure scenario on a Module Federation testbed with a fully reversible fault injector, the system named the correct culprit fragment in 67 of 70 diagnoses and repaired 50 of 50 injected faults on its first attempt. We report two findings that qualify those totals rather than polish them. Accuracy on one fault class drops to 7 of 10 once properly measured, where an earlier single-run evaluation had reported it flawless. And under a deliberately induced failure, behavioural verification alone accepted a patch that "fixed" the application by deleting the very shared-dependency declaration whose misconfiguration had caused the failure in the first place — a known limitation of validation-based repair, caught here in a form that emitted no error signal at all, and only partially closed by the structural check described above. Everything needed to check those numbers is released alongside the paper. The archive contains the full Module Federation testbed and its reversible fault injector, the source of all three agents, the evaluation harnesses, and the raw output of all 122 billed runs—cost, token usage, outcome and the complete reasoning trace for every one of them. Every figure reported in the paper can be recomputed directly from this artifact.