PaperlayerView exact revision on arXiv

Source-linked AI summary

A Reference Architecture for Integrating Agentic AI into Enterprise Software: Responsibilities, Interactions, and Variability

Mingqin Yu, Fethi Rabhi, Liming Zhu, Qinghua Lu

arXiv:2610.14818v1cs.AI

TL;DR

Existing enterprise agentic architectures cover many capabilities but differ in scope, organization, interaction representation, and assumptions about which capabilities are required. This paper synthesizes them into a technology-neutral architecture with ten responsibilities, typed interactions, invariants, and variation points, then evaluates it through an ESG agent and an independent architecture mapping. The case and mapping provide initial evidence of applicability, not completeness.

  • Problem

    Existing architectures differ in how they organize enterprise agentic capabilities, represent interactions, and assume which capabilities are required.

    Source: §I · p. 1

  • Method

    The paper synthesizes architecture evidence into ten responsibilities, boundary invariants, typed interactions, and variation points, then evaluates an ESG agent instantiation and an independent architecture mapping.

    Source: §I · p. 2

  • Results

    The case realizes seven of ten responsibilities, and different questions activate different interaction paths and conditional controls while the probed boundary invariants hold.

    Source: A. Architectural Coverage · p. 8, C. Goal-Conditioned Variation and… · p. 8

  • Takeaways & Limitations

    The independent architecture maps to the proposed responsibilities without requiring an additional one, providing initial evidence for organization and applicability rather than completeness.

    Source: §VIII · p. 11

    The evaluation is a research prototype covering one domain and existing system, with consistency reported over three executions per question; it supports boundary enforceability and consistency, not superiority to alternative decompositions.

    Source: B. Limitations · p. 10

Abstract

from arXiv · show

Agentic AI moves generative AI applications toward systems that coordinate reasoning, enterprise context, model inference, and external actions. Integrating these capabilities into enterprise software introduces diverse architectural concerns, from orchestration, knowledge and memory, and model access to tools and actions, security, runtime infrastructure, and evaluation. Existing research and industry architectures address many of these concerns but differ in scope, abstraction, responsibility organization, interaction representation, and assumptions about which capabilities are required. This paper presents a technology-neutral reference architecture for enterprise agentic AI integration. We synthesize architectural capabilities from research publications, industry architecture guidance, and interoperability specifications by architectural purpose, organize them into ten responsibilities, and define boundary invariants, typed cross-responsibility interactions, and variation points that distinguish responsibilities from condition-dependent capabilities and replaceable realization mechanisms. We instantiate the architecture as an ESG portfolio-analysis and pre-trade compliance agent over an existing service-oriented ESG metric computation and reporting system, and complement the case with a mapping of an independently published agentic architecture. The case realizes seven of the ten responsibilities; different questions take different interaction paths, controls activate only under their conditions, and the probed boundary invariants hold. The independent architecture maps onto the proposed responsibilities without requiring an additional one. These results provide initial evidence for the architecture's organization and applicability rather than its completeness. The deployment and recorded results are available as a replication package.

I. INTRODUCTION

Enterprise agentic AI integration involves coordinating heterogeneous capabilities within existing software, data, security, governance, and operational structures. The paper addresses how to organize these capabilities, interactions, and conditional choices in a technology-neutral reference architecture.

I. INTRODUCTION

  • Integration means embedding agentic capabilities in existing enterprise systems and infrastructure, making their organization, connections, controls, and operation architectural concerns.This includes legacy systems, identity and access infrastructure, and governance.Source: §I · p. 1
  • Existing architectures cover relevant enterprise and runtime capabilities but differ in scope, abstraction, responsibility organization, interaction representation, and assumptions about required capabilities.Interoperability specifications also define particular interactions with tools, contextual resources, or independent agents.Source: §I · p. 1
  • The research questions ask which capabilities and decision conditions matter, how to organize them with explicit interactions and variability, how to build a concrete system, and how well the architecture represents concrete systems.Source: §I · pp. 1–2
  • The paper synthesizes capabilities into ten responsibilities and defines boundary invariants, typed interactions, and variation points that distinguish stable ownership from conditional capabilities and replaceable mechanisms.It instantiates the architecture in an ESG portfolio-analysis and pre-trade compliance agent and maps an independently published architecture.Source: §I · p. 2

A. Agentic AI System Architecture

Enterprise agentic architectures span different scopes and levels of abstraction, while interoperability specifications address particular interactions. The paper’s method synthesizes these sources into responsibilities, interactions, and variability, then evaluates the architecture through an instantiation and an independent mapping.

A. Agentic AI System Architecture

  • Agentic systems combine concerns such as reasoning, memory, tool use, environmental interaction, and action coordination, while enterprise deployment must coexist with existing information, services, and controls.Systems range from a single agent to multiple agents that communicate, delegate, or collaborate.Source: A. Agentic AI System Architecture · p. 2

B. Reference Architectures for Enterprise Agentic AI

  • Prior architectures range from enterprise-transformation guidance to implementation-oriented runtime decompositions –, while MCP and A2A standardize specific interactions rather than broader responsibility organization.Application-specific and individual-agent architectures address narrower structures or design concerns,.Source: B. Reference Architectures for… · p. 2
  • Existing approaches assume different configurations, motivating an explicit, technology-neutral representation of responsibility boundaries, cross-responsibility interactions, and variability.Source: B. Reference Architectures for… · p. 2

III. RESEARCH METHOD

  • The four-activity synthesis process identifies and normalizes evidence, synthesizes responsibilities, analyzes interactions and variability, then instantiates and evaluates the architecture.The activities correspond to RQ1–RQ4, and the responsibilities, invariants, and interaction types were fixed before evaluation.Source: §III · p. 2

A. Evidence Identification and Capability Normalization

The paper reviews architectural evidence and normalizes capabilities by purpose, then synthesizes them into responsibilities and analyzes interactions and condition-dependent variation points.

A. Evidence Identification and Capability Normalization

  • The targeted architecture-oriented review covered research publications, industry architecture guidance, and interoperability specifications through September 2026, retaining sources on enterprise integration capabilities, relationships, controls, or configuration decisions and excluding model-algorithm-only or application-outcome sources.Source: A. Evidence Identification and… · pp. 2–3
  • Across 11 retained sources, 77 architecture-relevant items were extracted and consolidated into 44 normalized capabilities linked to their evidence.Items were normalized by architectural purpose, consolidating capabilities with shared purpose while preserving distinct responsibilities and decision conditions.Source: A. Evidence Identification and… · p. 3

B. Architecture Synthesis

  • Responsibilities group capabilities by primary purpose and ownership; implementation technologies and protocols remain replaceable realizations rather than responsibility boundaries.The inventory was checked so each retained capability had exactly one primary responsibility.Source: B. Architecture Synthesis · p. 3

C. Interaction and Variability Analysis

  • Cross-responsibility interactions are typed by exchange purpose and ownership without prescribing a fixed execution sequence, while variation points capture when capabilities or mechanisms apply.Conditions include agent topology, execution duration, integration requirements, external-effect risk, and operational constraints.Source: C. Interaction and Variability Analysis · p. 3

D. Instantiation and Evaluation

The architecture was evaluated through an implemented enterprise agent and a mapping of an independently published architecture. Its responsibilities and invariants distinguish stable ownership from deployment choices and runtime coordination.

D. Instantiation and Evaluation

  • Evaluation combines a deployed ESG agent’s recorded runtime interactions and boundary probes with mapping an independent architecture to the proposed responsibilities.The analyses examine representability, responsibility separation, and traceability from evidence through implementation and runtime interactions.Source: D. Instantiation and Evaluation · p. 4

IV. ENTERPRISE AGENTIC AI INTEGRATION REFERENCE ARCHITECTURE

  • The architecture has ten responsibilities, with L3 selectively coordinating L4–L6 during execution and L7 mediating asynchronous communication; L0 sets design requirements, L8 hosts runtime responsibilities, and L9 receives evidence.Source: §IV · p. 4

A. Boundary Invariants

  • Boundary invariants preserve logical ownership distinctions without requiring separate deployment; colocated components form enforceable security boundaries only when credentials, privileges, and failure domains are also separated.Source: A. Boundary Invariants · p. 4
  • L3 owns coordination while L6 authorizes and executes external actions, and L3 execution state remains distinct from L5 reusable knowledge across executions.Source: A. Boundary Invariants · p. 4
  • L2 establishes request identity and system access, while resource-owning responsibilities enforce their own retrieval, action, and network controls.Source: A. Boundary Invariants · p. 4
  • L1–L8 remain authoritative producers of local operational evidence, while L9 correlates that evidence for end-to-end observation, evaluation, diagnosis, and improvement.Source: A. Boundary Invariants · p. 4

B. Design Context, Interaction, and Access

The architecture separates enterprise agentic AI into responsibilities with distinct ownership, rather than treating them as one runtime step. Goal-directed execution separates coordination and inference from persistent context, external actions, and controls.

B. Design Context, Interaction, and Access

  • L0 translates business objectives and enterprise constraints into system requirements, ownership, accountability, risk, and governance decisions.These decisions constrain other responsibilities rather than acting as a runtime step.Source: B. Design Context, Interaction, and… · p. 4
  • L1 owns user and client interaction surfaces, while L2 establishes request identity, authority, tenant, and policy context at the controlled boundary.L2 propagates authority to resource-owning responsibilities, which retain resource-specific enforcement.Source: B. Design Context, Interaction, and… · pp. 4–5

C. Agent Execution and Enterprise Integration

  • L3 coordinates goal-directed execution and state; L4 routes and performs inference, while L3 decides why inference is needed and how to use its result.Multi-agent collaboration and human intervention are optional L3 capabilities.Source: C. Agent Execution and Enterprise… · p. 5
  • L5 owns persistent enterprise information, retrieval, and context assembly; L3 determines how the retrieved context is used.Retrieval-augmented generation is one possible realization, not the definition of L5.Source: C. Agent Execution and Enterprise… · p. 5
  • L6 validates, authorizes, executes, and records enterprise-facing actions, returning observations that L3 treats as untrusted input rather than instruction.L6 can apply an action-policy or approval gate before consequential external effects.Source: C. Agent Execution and Enterprise… · pp. 5–6
  • Controls reside with the responsibility owning the checked decision, from boundary guardrails and retrieval constraints to pre-action verification and external monitoring.Grounding and execution-constraint checks sit in L3; L9 monitors outside the execution loop.Source: C. Agent Execution and Enterprise… · p. 6

D. Runtime and Operational Support

Runtime and operational support covers asynchronous delivery, the platform environment, and evidence-based evaluation and improvement. These responsibilities support execution without taking ownership of agent behavior or operations communicated through events.

D. Runtime and Operational Support

  • L7 supplies asynchronous and event-driven communication, including durable delivery, retries, ordering, and idempotency when execution requires temporal decoupling or background processing.It changes delivery semantics without owning the communicated operation.Source: D. Runtime and Operational Support · p. 6
  • L8 provides compute, connectivity, storage, resilience, and delivery infrastructure, while agent behavior remains owned elsewhere.Infrastructure autoscaling belongs to L8; terminating an over-budget task belongs to L3.Source: D. Runtime and Operational Support · p. 6
  • L9 links and analyzes operational and evaluation evidence across executions to support diagnosis and improvement, while L1–L8 remain authoritative for events within their boundaries.Its capabilities include telemetry, lineage, testing, cost analysis, and root-cause analysis.Source: D. Runtime and Operational Support · p. 6

E. Typed Interactions and Variability

The architecture describes cross-responsibility exchanges as typed interactions and separates stable responsibilities from condition-dependent capabilities and replaceable mechanisms. Its ESG case applies these choices through explicit control placement and bounded execution.

E. Typed Interactions and Variability

  • Typed interactions specify an exchange’s purpose and participating responsibilities without prescribing transport, deployment topology, or a fixed execution sequence.MCP, A2A, REST, gRPC, and messaging are alternative realizations for selected interactions.Source: E. Typed Interactions and Variability · p. 6
  • Variation points connect motivating conditions to architectural consequences and realization mechanisms, allowing capabilities and interactions to vary while responsibilities and invariants remain stable.Synchronous and asynchronous configurations retain L3 coordination and L6 action ownership; L7 mediates when needed.Source: E. Typed Interactions and Variability · p. 6

V. REFERENCE ARCHITECTURE INSTANTIATION

  • The case instantiates portfolio carbon analysis and pre-trade checking over an existing ontology-driven ESG metric computation and reporting system.The system computes company metrics through services and represents metric definitions in a knowledge graph.Source: §V · p. 6

A. Applying the Architecture

  • The case assigns interaction, access, coordination, inference, context retrieval, metric computation, and deployment to distinct responsibilities, reusing the existing knowledge graph and metric computation.A portfolio and compliance service deterministically computes WACI and checks trades against the fund mandate, which requests cannot change.Source: A. Applying the Architecture · p. 6
  • The model selects steps and performs inference, while conventional software handles other components; responsibility-level controls enforce entitlements and execution bounds.L3 assembles holdings and intensities from L6 results, and every answer number must come from the request or an L5/L6 result.Source: A. Applying the Architecture · pp. 7–8
  • The consequential trade-submission path rechecks the mandate and holds requested overrides for approval by an entitled principal other than the submitter.The cleared trade is recorded rather than executed because no order management system is connected.Source: A. Applying the Architecture · p. 7
  • Other conditional capabilities remain disabled because their triggering conditions are absent, including asynchronous processing, multi-agent collaboration, service isolation, and persistent memory.The requests finish synchronously in under a minute, use trusted first-party services, and are answered independently.Source: A. Applying the Architecture · p. 7

B. Worked Example

The worked portfolio question produces a WACI for the holdings with available data and identifies Micron as the largest contributor. Its recorded execution spans 27 interaction occurrences across five interaction types.

B. Worked Example

  • 163.59 is the WACI for the 80% of the portfolio with data, re-weighted to that portion; Micron contributes 84%.The answer also identifies TSMC as excluded because its revenue is unavailable.Source: B. Worked Example · p. 8
  • 45.47, 28.99, and 439.94 t CO2e per USD million are the reported intensities for STMicroelectronics, Infineon, and Micron, respectively.TSMC’s revenue is unavailable.Source: B. Worked Example · p. 8
  • The execution comprises 27 occurrences realizing five of the eight interaction types; each directed request and its return count separately.The example question concerns a portfolio manager’s four semiconductor holdings and their 2023 carbon intensity.Source: B. Worked Example · p. 8

C. Goal-Conditioned Variation and Conditional Capabilities

Seven portfolio and trade questions produced goal-dependent execution paths, with controls activated only when their conditions held. The evaluation also assessed architectural coverage and whether the responsibility boundaries held in the case and an independent mapping.

C. Goal-Conditioned Variation and Conditional Capabilities

  • The seven questions were each executed three times to examine goal-conditioned paths and whether conditional capabilities activated only when their conditions held.Table IV summarizes variation across the questions, with occurrence ranges reflecting the variation described in the text.Source: C. Goal-Conditioned Variation and… · p. 8, Table IV · p. 8
  • Execution paths ranged from 5 to 41 interaction occurrences; question requirements changed invoked capabilities and controls while responsibility ownership remained unchanged.Read-only questions bypassed both controls, and an unanswerable share-price question was declined without engaging L5 or L6.Source: C. Goal-Conditioned Variation and… · p. 8

VI. EVALUATION

  • The evaluation examined coverage, boundary separation, and traceability, using runtime interactions, invariant probes, and an independently published architecture mapping.Each dimension tested a distinct architectural claim: representation of system requirements, enforceable boundaries, and links from evidence to runtime behavior.Source: §VI · p. 8

A. Architectural Coverage

  • The case instantiated seven of ten responsibilities, covering 33 of 44 normalized capabilities and realizing five of eight interaction types; the independent mapping represented nine responsibilities.The 33-of-44 count is descriptive, not a completeness score, because capabilities are condition-dependent; L7 appeared in neither configuration because neither was asynchronous.Source: A. Architectural Coverage · pp. 8–9

B. Responsibility Separation

The probed boundary invariants were consistent with observed outcomes, with a qualification for I4. An independently published architecture mapped to the proposed responsibilities, and the case elements could be traced from source evidence to runtime interactions.

B. Responsibility Separation

  • All invariant probes produced consistent outcomes; I4 was assessed as consistent, not preserved, because the case lacked an L9 correlation service.The case showed evidence ownership and a shared correlation identifier.Source: B. Responsibility Separation · p. 9

C. Independent Architecture Mapping

  • All eleven elements in the independent architecture mapped within L0–L9: four directly, one conditionally, and six across boundaries, with none requiring another responsibility.Its execution engine, memory, and guardrails span ownership boundaries in ways consistent with the proposed invariants.Source: C. Independent Architecture Mapping · p. 9

D. Traceability

  • The case trace links source evidence through normalized capability, responsibility, and component to recorded interaction; the independent mapping links external elements to responsibilities.The deployment, scripts, recorded results, and Fig. 3 generator are available in a replication package.Source: D. Traceability · p. 9

VII. DISCUSSION

The architecture separates responsibilities to support independent evolution, but separation brings interface and operational costs and does not itself ensure confidentiality. The case provides initial evidence that the proposed boundaries can be applied, while the evaluation remains limited in scope and does not establish their superiority or completeness.

A. Architectural Implications and Trade-offs

  • Separating orchestration from model access, context, and action supports independent evolution but requires explicit interfaces and consistent propagation of execution and security context.Model-driven coordination remains within an execution harness where deterministic services, verifiers, and policy controls retain authority over consequential operations.Source: A. Architectural Implications and… · p. 10
  • Physical separation adds interfaces, latency, and distributed failure modes; separate components physically when credentials, trust, scaling, or change cadence differ.The worked example requires 27 exchanges for one question; otherwise, responsibilities may be colocated if ownership and enforcement points remain distinct.Source: A. Architectural Implications and… · p. 10
  • Separation alone does not ensure confidentiality: hosted-model context, persistent memory, and telemetry create disclosure paths requiring coordinated policy for retrieval authorization, provider data, and retention.Source: A. Architectural Implications and… · p. 10

B. Limitations

  • The evaluation uses a research prototype in one domain and system, and shows enforceable, consistent boundaries rather than their superiority to alternative decompositions.It does not evaluate quality attributes such as performance, maintainability, security, or cost; comparative evaluation remains future work.Source: B. Limitations · p. 10

VIII. CONCLUSION

  • The ESG case realizes seven responsibilities, with runtime paths and conditional controls varying by task and action conditions; an independent architecture maps without an additional responsibility.Source: §VIII · p. 11
Loading 2610.14818v1…