Enterprise AI Integration Layers: from user intent to governed context

4A.1 The layered integration model

Layering prevents responsibilities with different trust and failure characteristics from being mixed together. The user interface should not own authorization. The model gateway should not decide business entitlement. Identity should not be inferred from conversation text. Retrieval should not silently widen access. Each layer receives a defined input, applies a defined control, and produces evidence that the next layer can trust.

The first five layers convert an ambiguous human or machine request into a governed task envelope. That envelope identifies the authenticated principal, tenant, application, selected record scope, task class, risk tier, permitted model class, allowed capabilities, policy decision, and approved context sources. Downstream orchestration should not have to guess any of those facts.

The practical benefit is containment. A defect in presentation does not automatically become a permission defect. A model-routing change does not change the user’s business authority. A retrieval optimization does not alter tenant isolation. The architecture can test and operate each responsibility independently while preserving a simple user experience.

4A.2 Layer 1 — Experience and presentation

The experience layer is the surface through which a person or system expresses intent and receives evidence. It includes chat, embedded copilots, web and mobile applications, service portals, email-assisted workflows, API clients, scheduled jobs, and event-triggered processes. Its primary engineering responsibility is not visual design alone. It must preserve operational context and make state transitions visible.

A production interface should identify the current user, tenant, application, selected records, workflow state, and attachments. An embedded assistant inside a CRM should pass the account identifier and user-visible scope explicitly instead of forcing the model to infer the customer from text. An incident assistant should know the selected incident and environment. A procurement assistant should receive the legal entity, cost center, supplier record, and approval chain as structured context.

The interface should distinguish facts retrieved from authoritative systems from model interpretation. It should also distinguish recommendation, draft, approval request, committed action, failed action, and reversed action. A single conversational message such as “done” is not sufficient evidence that a business operation was committed and verified.

High-impact actions should move from free-form conversation into a structured confirmation view. The user should see the exact capability, target system, resource, parameters, expected side effects, required approval, and recovery path. This is especially important for payments, access changes, production operations, customer communications, employment decisions, and legal or compliance workflows.

Human correction is part of the architecture. The experience should allow the user to identify whether the wrong source was used, whether the interpretation was wrong, whether a proposed action was inappropriate, or whether the downstream result did not match the intended outcome. These corrections should feed evaluation and incident processes rather than disappear into chat history.

The experience layer also owns graceful uncertainty. When required data is unavailable, the interface should identify the missing system or stale source instead of presenting a complete-looking answer. When the user lacks permission, the system may explain that some evidence could not be accessed without revealing protected content. When policy requires an approver, the interface should show who owns the decision and the status of the approval.

Interaction patterns should match the work. Conversational interfaces are effective for exploration and explanation. Embedded copilots are effective where the application already supplies record context. Structured workflows are preferable when a process has mandatory fields, deadlines, approvals, and regulatory evidence. Event-driven interfaces require workload identity and event provenance because no human may initiate the task. API interfaces require strict versioning, quotas, schemas, and machine-readable outcomes.

4A.3 Layer 2 — Enterprise AI Gateway

The Enterprise AI Gateway is the controlled ingress and egress boundary for model and agent traffic. It sits between user-facing channels, agent runtimes, model services, knowledge services, and external destinations. The gateway creates one logical policy path even when its responsibilities are implemented by several products such as an application gateway, API-management platform, model gateway, service mesh, firewall, secure proxy, or data-loss-prevention service.

At ingress, the gateway validates the calling application or workload, propagates authenticated identity, identifies the tenant, assigns a trace identifier, limits request size, protects against denial of service, and classifies the request for routing. It should reject malformed or unsupported requests before they consume model capacity.

Traffic policy protects both service reliability and budget. Useful controls include request rate, concurrent sessions, token limits, context size, attachment size, daily or monthly budget, and priority class. Quotas should have accountable owners. A shared unlimited endpoint makes it difficult to attribute cost, contain abuse, or preserve capacity for critical workflows.

Model routing is a policy decision, not only an optimization. A routing rule may depend on task type, data classification, region, contractual restrictions, context size, required modality, latency objective, risk tier, and current service health. A fallback model must be approved for the same data and task category. Silent failover to any available model can violate data-residency, safety, or quality requirements.

Content controls can include malware inspection, file-type validation, data-loss-prevention checks, sensitive-field detection, moderation, prompt-injection signals, and destination restrictions. These controls do not make untrusted content safe by themselves. They provide signals and enforcement points that the orchestration and policy layers can use.

Egress control is essential for agentic systems. A runtime that can call tools should not automatically obtain unrestricted internet or enterprise network access. Outbound destinations should be allowlisted, resolved through controlled DNS, routed through a proxy or firewall, and logged. External websites, APIs, model endpoints, and tool servers should have owners and risk classifications.

The gateway should create structured telemetry without turning logs into a second sensitive-data store. Record trace ID, tenant, principal, application, task class, selected model, route, latency, token count, quota result, rejection reason, and cost-allocation metadata. Prompt bodies and retrieved documents may require redaction, encryption, or restricted evidence storage rather than ordinary operational logs.

The gateway also creates provider portability. Applications and agents call a stable enterprise endpoint while routing, credentials, model deployment names, quotas, and provider-specific behavior remain behind the boundary. This does not eliminate provider differences, but it reduces coupling and centralizes policy.

4A.4 Layer 3 — Identity and authentication

{
  "initiator": {"subject":"user_19482","tenant":"enterprise-eu"},
  "agent": {"id":"incident-remediation-agent","version":"2.7.3"},
  "delegation": {
    "mode":"on_behalf_of",
    "resource_scope":["service:payments-api"],
    "expires_at":"2026-07-23T17:30:00Z"
  }
}

Enterprise AI introduces several actors into one task. A request may originate from a human, business application, scheduled process, monitoring event, or another agent. The system may then invoke an agent identity, orchestrator workload, knowledge service, and connector identity before reaching a target application. The architecture must preserve this chain instead of collapsing every actor into one shared API key.

The initiating principal represents the person or process responsible for the request. Authentication should use the organization’s identity provider and appropriate assurance such as multi-factor authentication for privileged work. Identity, role, tenant, group, and authentication strength should arrive as verified claims, not as statements inside the prompt.

The application identity identifies the channel or system that submitted the request. This matters because the same user may have different permissions or context in different applications. The application also has an owner, environment, client configuration, and credential lifecycle.

The agent identity represents a registered autonomous or semi-autonomous actor. It should have an owner, sponsor, version, lifecycle state, approved environments, model policy, permitted knowledge scopes, allowed capabilities, evaluation suite, and retirement process. An agent should be independently disabled without disabling the whole orchestration platform.

The orchestrator identity runs shared workflow infrastructure. It should not inherit broad business authority merely because it coordinates many agents. The connector or target workload identity should obtain a narrowly scoped, preferably short-lived credential for the approved action and resource.

Delegation defines the relationship among these identities. In an on-behalf-of model, the agent can perform only actions within the initiating user’s delegated scope. In a process identity model, the agent operates under separately approved organizational authority, such as an incident-response service account. These modes should be explicit because they have different accountability and access-review requirements.

Authentication proves who or what is acting; it does not prove that the requested action is permitted. Identity claims become inputs to the authorization layer. A user with access to view a customer account may not be allowed to issue a refund. An incident agent with permission to gather telemetry may not be allowed to change production configuration.

Credential handling should remain outside model-visible context. Secrets should not appear in prompts, memory, tool descriptions, or generated code. A connector should receive or exchange credentials at execution time using workload identity, token exchange, or a secrets service. Credential scope and expiration should be included in audit evidence.

Lifecycle governance is as important as runtime authentication. When an agent owner leaves, a business process changes, a model deployment is retired, or an incident occurs, the organization needs a reliable way to discover all affected identities, capabilities, permissions, and credentials.

4A.5 Layer 4 — Authorization and policy enforcement

{
  "principal":"user_19482",
  "agent":"customer-support-agent",
  "capability":"billing.refund.create-draft",
  "resource":"customer:AC-1092",
  "decision":"allow_with_approval",
  "maximum_amount":5000,
  "policy_version":"refund-policy-v6"
}

Authorization determines whether a specific initiating principal and registered agent may use a specific capability against a specific resource under current conditions. This decision must be deterministic, independently testable, and enforced outside the model.

Enterprise AI decisions are often attribute-rich. Policy can depend on tenant, user role, group, agent owner, resource relationship, environment, geography, data classification, transaction amount, incident severity, time, model class, source evidence, approval status, and separation-of-duties rules. Role-based access control remains useful, but many workflows also require attribute-based or relationship-based policy.

The model can propose an action and explain why it appears useful. It must not be the final policy decision point. Natural-language instructions such as “only refund active customers up to five thousand dollars” do not reliably enforce amount limits, tenant isolation, approval requirements, or regulatory restrictions. Those rules belong in policy and domain services.

Useful policy outcomes extend beyond allow and deny. A request may be allowed only in read-only mode, allowed to create a draft, allowed after approval, allowed with fields removed, allowed for a smaller resource scope, or escalated to a specialist. Returning a constrained scope is often safer and more useful than a binary denial.

Policy enforcement should occur at multiple points. The gateway can reject an unapproved model or tenant route. The orchestration layer can hide unauthorized capabilities. The capability layer can validate action-level entitlement. The connector can enforce target-system resource scope. Defense in depth is necessary because a policy decision that is not enforced at the side-effect boundary can still be bypassed by defects.

Every decision should record policy identifier and version, relevant input attributes, outcome, returned scope, approval requirement, and enforcement point. High-impact workflows should retain the approver identity, evidence viewed, exact action approved, and decision time.

Separation of duties deserves explicit modeling. The user who creates a payment, access request, supplier, or production change may not be permitted to approve it. An agent should not merge creator and approver roles simply because it can communicate with both systems. Approval must represent an accountable principal with the required authority.

Policy availability affects system behavior. Read-only informational workflows may degrade when policy services are unavailable only if a safe cached decision exists and remains valid. Write-capable or high-risk workflows should fail closed when current authorization cannot be confirmed.

4A.6 Layer 5 — Context assembly

{
  "task_id":"task_88421",
  "items":[
    {"id":"crm:account:AC-1092","authority":"system_of_record"},
    {"id":"policy:refunds:v6.1","authority":"approved_policy"},
    {"id":"memory:session:4","authority":"user_provided"}
  ]
}

Context assembly creates the evidence package used by a model or deterministic workflow. It combines the original request, application state, authenticated identity context, approved memory, retrieved documents, operational records, policy constraints, and descriptions of allowed capabilities. Because this package directly influences model behavior, context assembly is a security and data-integration layer.

The objective is not to include everything that might be useful. The objective is to include the minimum relevant, authorized, current, and attributable evidence needed for the task. Every context item should have a reason for inclusion, source identifier, owner where applicable, authority status, classification, access scope, retrieval time, and freshness status.

Application context should use explicit identifiers. An embedded assistant should pass account ID, incident ID, contract ID, environment, tenant, and selected objects rather than rely on names in the conversation. This reduces entity confusion and makes authorization enforceable.

Knowledge evidence includes controlled documents, policies, contracts, procedures, product documentation, and technical specifications. The retrieval pipeline should preserve version, approval state, effective date, owner, access-control attributes, content hash, and superseded status. A vector index entry is not authoritative by itself; it is a searchable representation of a source.

Operational evidence includes current records from CRM, ERP, service management, monitoring, identity, and other systems of record. These queries require field-level filtering, query timestamps, consistency expectations, and freshness rules. A warehouse snapshot may be acceptable for analysis and unacceptable for a transaction.

Memory should be separated by purpose. Conversation memory supports continuity. Workflow state records steps, timers, approvals, and outcomes. Agent working memory stores temporary plans and intermediate results. Domain memory stores reusable approved facts or preferences. Evaluation memory stores test cases, corrections, and incidents. These stores should not be mixed because their retention, authority, and access requirements differ.

Context isolation is particularly important in multi-agent and multi-tenant systems. Each agent should receive only the evidence required for its role. Handoffs should pass structured results, references, and confidence or uncertainty metadata instead of the entire conversation. This reduces data leakage, prompt-injection propagation, token use, and accidental coupling.

Content from documents, tickets, webpages, email, and repositories should be considered untrusted even when it originates inside the enterprise. The pipeline can scan for injection patterns and suspicious instructions, but the primary control is architectural: retrieved content cannot grant new authority, reveal secrets, or override capability policy.

Context compression is often required because source material exceeds model limits. Summarization, extraction, chunking, and reranking are lossy operations. The compressed artifact should remain traceable to the original evidence, and high-impact decisions should support retrieval of the exact supporting passage or record.

The final context package should distinguish authoritative facts, advisory material, user statements, analytical data, and model-derived summaries. The model should not receive them as equivalent text. Structured labels improve reasoning and allow the interface to explain which conclusions are source-backed and which remain interpretations.

4A.7 Cross-layer contracts

{
  "trace_id":"tr_01J8...",
  "tenant":"enterprise-eu",
  "task":{"class":"incident_remediation","risk_tier":"high"},
  "allowed_agents":["incident-analysis-agent"],
  "allowed_capabilities":["monitoring.read","service.change.prepare"],
  "context_manifest_id":"ctx_55219",
  "policy_decision_id":"pd_10933"
}

The first five layers should communicate through stable structured contracts. Otherwise identity, policy, routing, and context become hidden inside prompts or framework code. The primary output is a governed task envelope.

A governed task envelope includes trace ID, task ID, tenant, initiating principal, application, authentication strength, agent scope, task class, execution mode, risk tier, allowed models, allowed capabilities, context-manifest reference, policy-decision reference, and approval requirements.

The envelope should be immutable or versioned after orchestration begins. If the task changes materially, the system should create a new classification and policy decision. Silent mutation makes audit reconstruction and retry behavior unreliable.

The context manifest is a separate contract listing every source and memory item used. The policy decision is another contract containing inputs and returned scope. Separating these records avoids placing excessive sensitive data in the orchestration payload while preserving traceability.

These contracts also support evaluation. Test cases can assert that a user received the correct task class, model route, capability scope, and context sources before evaluating the generated answer.

4A.8 Anti-patterns

Common anti-patterns include deriving identity from chat text, giving every task the same model route, exposing all tools to every agent, placing authorization rules only in prompts, sharing memory across users or tenants, treating generated summaries as authoritative records, silently falling back to an unapproved model, logging sensitive context indiscriminately, and recording approvals as ambiguous chat replies.

These approaches are attractive because they reduce implementation work. They also concentrate risk in a layer that cannot reliably enforce it. The preferred pattern is explicit identity, policy-driven routing, bounded capability discovery, deterministic authorization, purpose-separated memory, source-linked evidence, approved fallback rules, controlled logging, and structured approval records.

4A.9 Production readiness checklist

Before the downstream orchestration layer is connected, verify that every channel supplies authenticated principal, tenant, application, and record scope; that the interface distinguishes recommendation, draft, approval, execution, failure, and rollback; that gateway routing uses task, risk, region, and data policy; that traffic quotas have owners; that outbound destinations are controlled; that human, application, agent, orchestrator, and connector identities are distinguishable; that agent identities have lifecycle governance; that delegated authority is scoped and time-limited; that authorization is enforced outside prompts; that context retrieval preserves ACLs, provenance, version, classification, and freshness; that memory is isolated by user, tenant, workflow, and purpose; that context compression remains traceable; and that a versioned governed task envelope is passed downstream.

4A.10 Chapter summary

The first five integration layers establish the trust foundation for enterprise AI. The experience layer captures intent and makes evidence and state visible. The gateway enforces a consistent traffic, model, and network boundary. Identity distinguishes every actor. Authorization decides what each actor may do. Context assembly supplies only relevant, authorized, attributable, and current evidence.

When these layers are implemented correctly, orchestration receives a governed task rather than an ambiguous prompt. Models no longer need to infer identity, business authority, tenant, source ownership, or permitted tools. This makes downstream systems easier to secure, evaluate, operate, and change.

Enterprise AI integration therefore begins before the first model call. The safety and quality of every later agent action depend on whether the architecture correctly establishes the user, task, policy, and context at the beginning.