Enterprise Intelligence Platform Playbook - Part 2: A Reference Architecture

This is Part 2 of the Enterprise Intelligence Platform Playbook series. Part 1 defined the eight-layer reference architecture. Part 2 is a specification: the deployable topology, the open-source tooling, the decision catalogue, and the phased build plan that turn the reference architecture into infrastructure. Part 3 covers the engineering disciplines that operate the platform.

Part 1 gave you the eight-layer reference architecture. This part shows you how to build it. We will translate those layers into a deployable topology with open-source tooling, define the decisions the platform must support, specify the operators the execution gateway exposes, and lay out a phased build plan. The question we are answering: how do you deploy this thing without handing your architecture to a single cloud vendor?

Those eight layers map onto three zones. Each zone has a distinct security posture, scaling model, and operational cadence. A platform engineering team treats each zone as an internal product with documented APIs, SLAs, and self-service onboarding. The tools recommended here are open-source unless noted otherwise. If you use a managed cloud service for any of these, the logical structure is identical – substitute the appropriate equivalent.

The Three-Zone Deployment Topology

Layer-by-Layer Tech Stack

Here is where each layer lives in the stack and what it does. The table shows what each layer provides, consumes, and outputs. Teams building on the platform interact with these interfaces. The platform team owns the implementation.

Layer 1 - The Compute Foundation

Every service in every zone runs on Kubernetes. Treat your K8s cluster as the platform’s platform - it is the first thing you build and the last thing you change.

Layer 2 - The Context Fabric

Layer 3 - The Enterprise Reality Model

When a team wants to add a new domain - say, supply chain or customer success - they contribute to the Enterprise Reality Model. They define the business objects, their relationships, and their current state. The platform provides the infrastructure. The team provides the domain knowledge. The Reality Model grows without the platform team rebuilding it.

Layer 4 - The Logic Engine

Layer 5 - The Execution Gateway

This is where the rubber meets the road. The execution gateway exposes business capabilities as operators. An agent does not call APIs. It calls operators. Each operator is a governed action that orchestrates multiple technical operations behind a single business outcome.

These twelve operators are the system calls of the execution gateway. Every business capability maps to one or more operators. The agent reasons in business language. The platform translates that into operator calls. The operators enforce idempotency, audit, and rollback. The agent never touches infrastructure directly.

Layer 6 - The Trust Guardrails

Trust is not optional. Every request and response passes through guardrails that enforce policy, redact sensitive data, and maintain an audit trail. This layer is what makes the platform enterprise-grade rather than a side project.

Layer 7 - The Agent Kernel

Layer 8 - The Collaboration Interface

Request Flow: End to End

Here is what happens when an agent processes a single enterprise request:

1. User submits: "Approve travel request #4412 for Alok"
       │
2. Kong authenticates via Keycloak, NeMo Guardrails inspects prompt
       │
3. LangGraph receives intent: APPROVE_TRAVEL
       │
4. Agent Kernel queries Context Fabric:
   ├─ Retrieve employee profile (PostgreSQL)
   ├─ Get travel policy (Qdrant vector search)
   └─ Check booking details (PostgreSQL via Debezium)
       │
5. Context is assembled, ranked, compressed by LangGraph
       │
6. OPA + Drools + Cedar evaluate: role-based approval limit, budget remaining, policy compliance
       │
7. If auto-approvable → execute via Temporal workflow
   │  ├─ Update booking status (PostgreSQL)
   │  ├─ Notify employee (NATS)
   │  └─ Log decision (PostgreSQL + OTel)
   │
8. If needs manager approval → Temporal pauses workflow
   │  └─ NATS notification → manager approves via web UI
   │     └─ Temporal resumes execution
   │
9. Result returned to user. Every step traced in OTel + Prometheus + Grafana.

Pseudocode

The flowchart above shows the high-level path. This trace shows the exact API calls through the eight layers for a refund request:

# Layer 8 & 6: Ingest and Screen
raw_input = CollaborationInterface.StreamChat(source="mobile_app_client")
# "I want a refund for order #9482. The ceramic vase arrived completely shattered."

sanitized_intent = TrustGuardrails.ValidateRequest(
    input_payload=raw_input,
    policy_context="external_customer_ruleset"
)

# Layer 7: Plan
execution_plan = AgentKernel.DecomposeQuery(intent=sanitized_intent)
# -> Step 1: Resolve Order 9482
# -> Step 2: Run Eligibility Check
# -> Step 3: Trigger Ledger Payout

# Layer 2 & 3: Contextualize and Hydrate Data
context_data = ContextFabric.SearchKnowledge(query="refund fragile items window")
order_record = EnterpriseRealityModel.GetEntity(entity_type="Order", entity_id="9482")
customer_record = EnterpriseRealityModel.GetEntity(
    entity_type="Customer", entity_id=order_record.customer_id
)

# Layer 4: Hard Rule Evaluation (No LLM hallucinations allowed here)
refund_decision = LogicEngine.EvaluateDecision(
    context=context_data,
    business_objects=[order_record, customer_record],
    policy_id="automated_returns_v4"
)
# Returns: { "status": "APPROVED", "payout_target": "original_visa", "amount": 45.00 }

# Layer 5: Execution Core
gateway_receipt = ExecutionGateway.OrchestrateAction(
    action_verb="PROCESS_REVERSAL",
    operators=["stripe_adapter", "sap_erp_adapter"],
    parameters=refund_decision
)
# Returns: { "stripe_status": "SUCCESS", "stripe_tx": "ch_3M8x", "sap_status": "SUCCESS" }

# Return Loop to Layer 8
CollaborationInterface.ExposeAPI(
    payload=(
        f"Refund of ${refund_decision.amount} successfully processed to your card. "
        f"Transaction ID: {gateway_receipt.stripe_tx}."
    )
)

When the decision is rejected, the flow changes at Layer 5:

# Layer 4: Decision returned REJECTED
refund_decision = LogicEngine.EvaluateDecision(...)
# Returns: { "status": "REJECTED", "reason": "outside_return_window" }

# Layer 5: Escalate instead of execute
if refund_decision.status == "REJECTED":
    ExecutionGateway.OrchestrateAction(
        action_verb="ESCALATE",
        operators=["human_review_adapter"],
        parameters=refund_decision
    )

The same eight layers handle infrastructure incidents. The trace is identical. Only the operators change:

# Layer 8 & 6: Ingest and Filter Threat Vector
raw_alert = CollaborationInterface.ReceiveWebhook(source="datadog_severity_1")
sanitized_incident = TrustGuardrails.ValidateRequest(
    input_payload=raw_alert,
    identity_context="systems_engineering_service_account"
)

# Layer 7: Generate Execution DAG
incident_dag = AgentKernel.PlanTask(intent=sanitized_incident)
# -> Step 1: Map Node Blast Radius
# -> Step 2: Query Failover Hard Rules
# -> Step 3: Await Human Sign-Off (if required)
# -> Step 4: Execute Infrastructure State Change

# Layer 2 & 3: Hydrate Live Operational Map
incident_context = ContextFabric.ResolveContext(target="DB-PROD-02")
live_infra_node = EnterpriseRealityModel.GetEntity(
    entity_type="DatabaseCluster", entity_id="DB-PROD-02"
)
downstream_apps = EnterpriseRealityModel.QueryRelationship(
    origin=live_infra_node, relationship="supports"
)

# Layer 4: Evaluate Deterministic Architectural Policies
mitigation_gate = LogicEngine.EvaluateDecision(
    context=incident_context,
    business_objects=[live_infra_node, downstream_apps],
    policy_id="production_failover_safety_rules"
)
# Returns: { "action_required": "FAILOVER", "requires_human_signoff": True, "blast_radius_cost": "HIGH" }

# Layer 8: Human-in-the-Loop Intercept
if mitigation_gate.requires_human_signoff:
    confirmed_payload = CollaborationInterface.ExposeAPI(
        target_channel="#ops-war-room",
        payload=(
            f"CRITICAL: Approve failover for DB-PROD-02? "
            f"Blast radius affects: {downstream_apps.names}"
        )
    )

# Layer 5: Kernel Level System Call Execution
gateway_receipt = ExecutionGateway.OrchestrateAction(
    action_verb="RECOVER_PRODUCTION_SERVICE",
    operators=["terraform_cloud_adapter", "pagerduty_api"],
    parameters=confirmed_payload
)
# Returns: { "terraform_status": "APPLIED", "traffic_rerouted": True, "incident_status": "RESOLVED" }

Two traces. Same architecture. Same API calls. Different operators. The platform does not care whether the decision is about a refund or a failover. The decision model changes. The operators change. The eight layers do not.

Decision Catalogue

This is the heart of the platform. These are the questions the Logic Engine answers. Each row is a decision type. Each column is the industry-specific form that decision takes.

The decision catalogue is not documentation. It is a living specification. Every decision in this table must be implemented as a versioned decision model in the Logic Engine. When the business adds a new decision type, it enters this table first, then the platform builds it.

Build Order and Profiles

Do not build all three zones at once. The dependency graph dictates the sequence. Each phase adds an internal platform product with a clear owner, documented API, and self-service onboarding path.

You do not need a cluster to prove the architecture works. Start at the Developer profile and evolve as adoption increases.

Developer validates the architecture works. One agent, one model, one context source, one action. No Kubernetes. You are testing whether the decision-to-action pipeline makes sense before investing in infrastructure.

Team ships a K8s cluster with GPU Operator, Kong gateway, and basic observability. Multiple agents share infrastructure. Context retrieval and memory become shared services. The team owns its agents. The platform team owns the platform.

Enterprise means every zone is independently deployable and recoverable. The platform team has multiple engineers per discipline. Agents are onboarded via self-service. The action catalog is shared. The governance plane enforces policy across every agent.

The dominant cost driver is not just GPU compute, it is context retrieval and storage in terms of performance. A platform that optimizes context freshness, caching, and compression will spend 60-70% less on infrastructure than one that does not.

Platform Engineering Checklist

Before putting the platform in front of users, verify each of these. Each item represents a platform engineering concern, not just a configuration checkbox:

• Inference gateway is the only path to models (no direct model API calls)
• Prompt injection and PII detection run on every request, both directions
• All actions are idempotent with documented failure modes
• Context retrieval has a freshness SLO and staleness metadata exposed to agents
• Token usage is tracked per request, per agent, per team
• Model fallback routing is configured (premium -> standard -> batch)
• Cost circuit breakers pause non-critical agents when aggregate spend exceeds threshold
• Agent execution has max duration, max cost, and max retry limits enforced at the platform level
• Human-in-the-loop gates all destructive actions via Temporal signals
• OTel tracing covers the full request lifecycle across all three zones
• Every zone has independent disaster recovery and can fail over without cross-zone dependency
• Platform onboarding documentation exists for: new agent, new action, new data source, new model
• Helm charts and Terraform/Tofu modules are versioned with PR-based change management
• Load testing confirms p95 latency under 2x model inference time for the critical path
• GPU autoscaling policy is defined: min/max replicas, scale-up threshold, cooldown period
• K8s cluster upgrades are tested and documented (control plane, node pools, add-ons)
• Pod resource requests and limits are set for every service across all three zones
• NetworkPolicies enforce zone isolation (no cross-zone traffic except through gateway)

What You’re Actually Building

The eight-layer architecture from Part 1 is the reference. This specification is how you build it. The decision catalogue defines what decisions the platform must support. The operator catalogue defines what actions the execution gateway exposes.

I want you to think about the tools listed here as replaceable – PostgreSQL might become MongoDB, Qdrant might become Milvus, Temporal might become Camunda etc. It is the specification and discipline what endure.

In part 3 of the series we will cover the disciplines that operate this platform: Context Engineering, Decision Engineering, and Action Engineering. Those disciplines are what will make this static specification an “intelligent” platform.