Agent Assurance System (AAS): A Dual-Agent Framework for Independent Quality Assurance in AI-Assisted Software Development
Abstract
AI coding assistants have dramatically accelerated software development, yet their deployment creates a structural assurance concern: when an AI agent both generates and tests its own artifacts, no independent guarantee of correctness or safety is available from that agent alone. We introduce the Agent Assurance System (AAS), a dual-agent assurance framework in which a primary Builder agent produces code and a structurally independent Assurance agent, operating alongside a human Quality Assurance (QA) engineer, provides adversarial review before any artifact enters production. AAS is organized around three independence properties (model, context, and incentive isolation) and maps onto the financial sector's Three Lines of Defence (3LoD) governance model, offering a regulatory-legible vocabulary for discussing assurance architecture in high-stakes software systems. We give a formal decision protocol, a conceptual bound relating correlated failure to cross-provider disagreement, and a risk-stratified merge protocol connected to the conformal risk control literature. All empirical results in this paper are obtained on a fully synthetic benchmark of 1,200 annotated financial-software artifacts and should be read as a controlled proof-of-concept, not as evidence of production-grade or real-world performance. On this benchmark, AAS reduces the critical-defect escape rate from 18.7% (same-provider self-review) to 5.1%, with a per-artifact Assurance-agent latency of 8.4 seconds; a substantial share of this improvement (7.8% escape rate, i.e., roughly two-thirds of the total reduction) is attributable to cross-provider model independence alone, with the remaining governance and protocol machinery contributing an incremental 2.7-percentage-point reduction. We report this decomposition prominently, discuss the limits of our theoretical guarantees under distribution shift and adversarial pressure, and outline the real-world validation that would be required before any deployment or regulatory claim could be supported.