Multi-agent systems research has long explored decomposing complex tasks across autonomous or semi-autonomous agents; agentic AI extends this by combining foundation models with planning, tool use, and iterative execution. Yao et al. demonstrated the interleaving of reasoning and action in language-model agents (ReAct), and subsequent frameworks explored structured multi-agent coordination — Li et al.’s CAMEL through role-based communication, and Wu et al.’s AutoGen through conversational orchestration. Guo et al. survey this space along the dimensions of agent roles, communication, and collective problem solving.

These frameworks establish agents as controllers of multi-step workflows rather than text generators, and Liu et al.’s AgentBench and related evaluation work emphasize that agent capability spans planning, tool use, memory, and reliability, not output quality alone. However, task coordination does not by itself define an enterprise delegation model. Production agents may access proprietary information or trigger consequential actions, so the technical capability to perform an action must be distinguished from the organizational authority to perform it — a distinction is not the primary focus of these frameworks.

Agents that consume tools, external information, and persistent memory carry a different risk profile than conventional LLM applications. Debenedetti et al.’s AgentDojo shows that indirect prompt injections where untrusted external data alter an agent’s subsequent reasoning and tool calls — remains a practical vulnerability even for capable agents. Zhang et al.’s Agent Security Bench extends this to vulnerabilities in instruction handling, tool use, and memory retrieval, arguing that agent security cannot be reduced to output filtering; the capabilities, information sources, and actions available to an agent are themselves part of its security boundary. Survey work by Yehudai et al. and Mohammadi et al. similarly frames evaluation around planning, tool use, memory, and safety as system-level properties rather than static benchmarks.

This literature motivates treating delegation as a lifecycle rather than a one-time grant based on offline evaluation — capabilities should be evaluated before production use, progressively expanded as reliability is demonstrated, and revocable when conditions change. RCaS operationalizes this lifecycle in Section 4.1.

Lewis et al.’s Retrieval-Augmented Generation established the standard mechanism for coupling generation with externally retrieved knowledge, and subsequent work on long-term agent memory — Zhong et al.’s MemoryBank and the survey by Zhang et al. extended retention and reuse across interactions. Enterprise risk advisory, however, generates heterogeneous knowledge (assessments, expert judgments, taxonomies, regulatory mappings, procedures) that differs in authority and governance requirements; information from one interaction should not automatically become reusable organizational guidance. This literature addresses retrieval mechanics but gives limited treatment to which knowledge should be promoted, validated, versioned, or retired — the gap RCaS addresses through governed episodic, semantic, and procedural memory (Section 4.6).

Governance frameworks such as the NIST AI Risk Management Framework, its Generative AI Profile, and ISO/IEC 42001 provide organizational approaches to managing AI risk across the system lifecycle, and the EU AI Act codifies analogous obligations — risk management, documentation, human oversight, monitoring — for high-risk systems. Novelli et al. and Laux argue for accountability and meaningful human oversight as core governance requirements rather than post-hoc controls.

These frameworks establish what governance should achieve but generally provide less architectural detail on runtime enforcement. Recent work on Agentic AI governance similarly distinguishes an agent’s technical capabilities from the autonomy it is authorized to exercise, emphasizing that permitted autonomy should be determined by risk, oversight, accountability, reversibility, and organizational readiness rather than by technical capability alone. Agentic systems add a further concern: risk depends not only on individual agent behavior but on which capabilities are combined within a single agent — an agent that both processes untrusted input and can execute consequential actions carries materially higher risk than one restricted to a single capability class, a concern reinforced by the agent-security findings in Section 2.2. RCaS builds on these governance foundations through capability separation, least-privilege authorization, provenance, and EITL escalation, implemented as a runtime architecture (Section 4) rather than a set of standalone controls.

RCaS is also compatible with established enterprise security principles such as least-privilege access, separation of duties, and zero-trust enforcement, but applies them at the level of agent capability composition and delegated execution, where recent work highlights the need to preserve authorization across delegation, data retrieval, synthesis, and changing authorization boundaries. The distinction is that RCaS treats the combination of capabilities within an agent as an explicit governance boundary: access to untrusted inputs, sensitive institutional intelligence, and consequential actions is not treated as an undifferentiated permission set. This capability-composition view complements resource-level authorization by constraining how high-risk capabilities may be combined before runtime authorization is granted.

AI has been applied across enterprise risk tasks, including operational risk, compliance, and business risk, with persistent challenges around data quality, explainability, and governance. As AI systems increasingly evolve toward agentic operation, these challenges also extend to autonomous planning, action, coordination, and human oversight within enterprise processes. Existing AI-enabled risk applications are typically organized around a single risk domain or analytical capability, whereas enterprise risk consulting spans evidence collection, multimodal analysis, retrieval, scenario analysis, expert review, and organizational learning as a continuous lifecycle. The distinction between AI-enabled risk analytics and a continuously operating advisory capability — one requiring orchestration, institutional knowledge, and governed human decision-making rather than an additional isolated model — motivates RCaS’s platform framing.

Table 1 summarizes the gap: existing research addresses agent coordination, evaluation and security, persistent memory, governance, and risk analytics as largely separate layers. RCaS’s contribution is their integration into a single governed operating architecture for high-stakes enterprise delegation — treating delegation as a lifecycle in which capability separation, institutional memory, runtime authorization, evidence provenance, and human oversight operate as coordinated components, rather than as independent mechanisms layered after the fact.

The distinction is summarized in Table 1.

Autonomy, agency, and authority: RCaS separates three dimensions of agent operation. Autonomy is an agent’s ability to interpret evidence and generate a decision without immediate human review — it does not imply unrestricted operation, as output remains subject to escalation on confidence, policy, and materiality. Agency is an agent’s ability to execute an action that changes an enterprise system or external environment (updating records, sending external notifications). Authority is the policy-granted permission to exercise autonomy, agency, or both within a defined scope, determined by organizational policy, operational risk, action materiality, and reversibility — not by model capability alone. In RCaS, autonomy and agency describe capabilities available to an agent, whereas authority determines whether those capabilities may be exercised in a particular context. This separation lets an organization grant substantial analytical autonomy without granting equivalent system-modifying authority and conversely allows narrowly scoped agency for low-risk, reversible actions while consequential decisions remain subject to human approval.

Progressive delegation: Capabilities are configurable runtime permissions, not permanent agent properties. A candidate capability typically enters shadow mode — evaluated against human decisions or predefined criteria without affecting production outcomes — before progressing through: Observe → Shadow → Recommend → Execute with Approval → Bounded Autonomous Execution. Transitions depend on demonstrated reliability, materiality, and reversibility; capabilities can equally be reduced or revoked as performance, policy, or conditions change (Figure 2). Authority allocation follows the same risk logic: high analytical confidence does not automatically authorize a consequential action, while a narrowly scoped low-risk action may be delegated even while the broader workflow stays under human review.

The deployment implications of progressive delegation are discussed separately in Section 5.

Beyond bounding what a single agent may do, RCaS constrains which high-risk capabilities may be combined within one agent. The CSC identifies three capability classes — (1) processing untrusted external inputs, (2) accessing sensitive institutional intelligence, and (3) executing consequential external actions — and no single agent is granted unrestricted access to all three simultaneously. Formally, if U denotes unrestricted processing of untrusted inputs, S denotes unrestricted access to sensitive institutional intelligence, and C denotes unrestricted consequential-action execution, the constraint is ← (U ∧ S ∧ C) for a single agent. This is a capability-composition constraint rather than a replacement for least-privilege authorization: an agent may still be restricted to a single capability class, or to a bounded combination, according to policy and risk. Workflows requiring multiple classes are decomposed across independently governed agents connected through controlled interfaces (Figure 3): for example, an agent that extracts and classifies an externally supplied document does not simultaneously receive unrestricted institutional-memory access or system-modification authority; a separately governed agent performs any resulting retrieval or approved action, subject to its own authorization. Transitions between capability domains are protected by policy evaluation, least-privilege authorization, provenance tracking, and EITL approval where required — making capability separation a structural, architecture-level control rather than a prompt- or output-filtering safeguard. The CSC is intended as a risk-reduction design constraint rather than a complete security model: it does not by itself address identity compromise, authorization errors, tool-level vulnerabilities, or cross-agent attack paths, and additional controls (Sections 4.3 and 4.7) remain necessary alongside it.

Governance is enforced through a zero-trust runtime control architecture (Figure 4): agents hold no persistent, unrestricted privileges, and access is evaluated per protected operation. On launch, an agent receives an enterprise workload identity authenticated through the enterprise identity infrastructure; the Governance and Control Layer then evaluates whether the requested operation is permitted in context and, if so, issues a short-lived, narrowly scoped authorization credential for that specific action, scope, and validity window, which the receiving enterprise service independently validates before executing. The resulting control sequence — identity → authentication → policy evaluation → scoped authorization — can be re-evaluated whenever tenant, resource, policy, risk, or operating context changes.

This layer is the primary operational interface between users and the platform, coordinating agents across assessment execution, evidence collection, multimodal analysis, simulation, and reporting. Rather than a fixed questionnaire, the workflow adapts to enterprise context, available evidence, and remaining uncertainty, with governance controls determining whether outputs proceed automatically or require EITL intervention.

Assessment and context. The Risk Assessment Execution Agent manages adaptive questioning, response validation, preliminary risk identification, and confidence-aware escalation, producing analytical observations rather than final decisions. The Industry- and Location-Aware Context Service establishes the contextual envelope (industry, asset profile, jurisdiction, applicable regulation, environmental hazard). The Customer Interaction Memory Agent retrieves relevant historical responses and rationale, ranked by relevance, recency, and governance policy.

Evidence processing. The Multi-Pass Document Extraction Agent processes engineering documentation using complementary perception passes with spatial consistency validation; fields meeting stability thresholds are promoted downstream, while uncertain fields are escalated for targeted expert validation. The Evidence Analysis Agent integrates structured, textual, multimodal, and regulatory evidence with citation-enforced generation, preserving traceability and exposing confidence and conflicts rather than resolving them silently.

Simulation and review. The Simulation and Trade-Off Evaluation Agent evaluates alternative mitigation strategies (scenario, sensitivity, resilience, cost, compliance analysis) as advisory output requiring validation before adoption. The Risk Report Synthesis Agent combines validated evidence, analysis, and expert-approved rationale into citation-enforced reports. When EITL intervention is triggered, the platform passes the expert a structured decision context — validated evidence, reasoning trace, confidence, applicable policy, and unresolved uncertainty — rather than raw conversation history.

This layer extends the platform beyond point-in-time assessment by monitoring regulatory, environmental, and customer-operational change, initiating targeted reassessment rather than requiring full reassessment when material change is detected. It supports two functions under the same runtime authorization and EITL controls used elsewhere: knowledge evolution, which proposes updates to questionnaires, risk knowledge, and mitigation guidance from external intelligence and operational experience, subject to governance review before reuse; and continuous customer re-evaluation, which compares historical assessments against current conditions and emerging intelligence, updating risk posture and generating alerts where warranted.

The Institutional Memory Layer converts validated organizational experience into reusable knowledge across three forms distinguished by purpose and governance requirement: episodic memory captures historical assessment experience — evidence, expert interventions, outcomes, semantic memory captures stable organizational knowledge — taxonomies, regulatory mappings and domain relationships, and procedural memory captures validated learning about how risk should be assessed and mitigated, including which recommendations or mitigation strategies were effective or ineffective, the conditions under which they were applied, implementation considerations and observed outcomes.

Procedural memory therefore allows the platform to learn not only what was recommended, but what happened after the recommendation was implemented. For example, a mitigation recommendation that repeatedly produces the desired risk reduction under a particular operating condition may become a validated procedural pattern, while a recommendation that is ineffective, difficult to implement, or produces an unintended outcome can be marked accordingly and prevented from being treated as a preferred future intervention. This creates a governed feedback mechanism from recommendation → mitigation action → observed outcome → validated learning → future recommendation.

Memory is not an autonomous, self-learning mechanism. The Knowledge Curation Agent identifies candidate knowledge from completed assessments, expert interventions, mitigation outcomes, and operational feedback. Candidates are evaluated for evidence quality, consistency, expert agreement, outcome support, and policy alignment before promotion. Procedural knowledge receives the strictest governance because it can directly influence future recommendations and system behavior; changes require appropriate expert approval, version management, audit logging, and rollback capability. Historical observations or agent-generated conclusions therefore do not automatically become authoritative organizational knowledge.

The four layers form a closed but governed learning cycle: external and customer signals → governed intelligence → assessment → evidence and analysis → expert validation → operational outcomes → governed knowledge curation → institutional memory → future assessments. Learning therefore occurs through controlled updates to knowledge, procedures, and policy: validated evidence about which mitigation recommendations were effective, ineffective, or condition-dependent can influence future retrieval, recommendation guidance, workflow routing, and escalation criteria. The underlying foundation models remain unchanged in production; adaptation occurs through the governed information and control layers surrounding them. This preserves model version control, auditability, and rollback while allowing the operating environment and organizational knowledge to evolve. Delegated capabilities can consequently expand, constrained, or revoked independently of any model retraining.

The platform was developed and progressively transitioned into production over approximately six months (pilot validation → controlled client expansion → scaled production), with governance policy, institutional knowledge, and workflow configuration refined through expert-approved changes during this period. This was followed by approximately six months of steady-state production operation, from which the results in this section are drawn. No online modification of foundation-model parameters occurred in production (Table 3).

Approximately 70% of routine advisory activity (evidence ingestion, document processing, preliminary risk identification, report preparation, workflow coordination) was automated, calculated as the share of predefined routine activities executed without manual intervention against the production workflow taxonomy. Judgment-dependent and consequential activities remained under EITL review. The denominator is the set of predefined routine activities in the production workflow taxonomy, rather than all advisory activities. These gains reflect the integrated operation of automated evidence processing, adaptive workflows, retrieval-supported reasoning, and selective escalation collectively, not any single model or agent.

Document extraction: Extraction accuracy was assessed by comparing extracted field values against expert-reviewed reference values for the evaluated document sample, with a field counted as correct when its extracted value matched the reviewed reference. Accuracy improved across three successive processing configurations:

Values reflect production observations showing the progression across successive configurations, not a controlled benchmark. Conventional OCR underperformed on engineering documents with complex layouts, tables, and annotations; deterministic multi-pass processing with spatial/consistency validation produced the highest observed accuracy, with the added benefit that uncertain fields remain linked to source location for targeted expert verification rather than silent propagation.

Multimodal evidence and traceability: Production observations indicated improved evidence completeness and fewer inconsistencies between reported conditions and visual evidence when multimodal observations shared a common evidence foundation with textual and structured data — interpreted as evidence of operational usefulness rather than a controlled accuracy estimate. Evidence provenance was maintained end-to-end, supporting traceability, reproducibility, and accountability as governance outcomes rather than performance metrics.

Across 950 expert-reviewed recommendations, acceptance (recommendations accepted without material modification, excluding formatting changes) ranged from 90–97%, higher where evidence was rich and institutional knowledge mature, and lower for novel or under-documented environments — an indicator of usefulness and expert agreement, not of realized risk reduction or absolute correctness.

Selective, confidence- and materiality-based EITL escalation reduced the proportion of recommendations requiring comprehensive expert review by ~50–70% relative to the prior workflow, with the reduction calculated against the corresponding review proportion under the prior process. Higher-risk or lower-confidence cases remained subject to comprehensive review — making this a workflow-efficiency measure, not evidence that expert review is no longer needed. Continuous runtime policy validation, in turn, was associated with a 30–50% relative increase in identified policy non-conformance events compared with the prior validation process, calculated on the same production validation population used for the comparison. This reflects more deviations identified during execution, not a measured change in the underlying prevalence of violations.

Validated outcomes, rationales, and mitigation strategies were curated into episodic, semantic, and procedural memory following multi-expert review. The deployment observed a 25–40% reduction in new risk-engineer onboarding time, measured as time to reach the established operational-readiness criterion used by the deployment, and reduced redundant evidence collection for recurring engagements via customer interaction memory — suggestive of value beyond retrieval efficiency, though the evaluation does not isolate memory’s independent causal contribution.

Consistent with the governance model, the deployment shifted — rather than eliminated — expert effort: routine evidence processing and preliminary analysis moved to agents, while risk professionals concentrated more on exception handling, governance, and consequential judgment. This is a descriptive observation of the deployment, not a causal productivity estimate.

The document-extraction comparison (Table 4) offers the clearest component-level evidence within the deployment, since successive processing configurations were compared directly; the remaining results should be read as outcomes of the integrated architecture rather than attributable to any single mechanism, and do not constitute a controlled ablation study (Section 7.1).