The Three Pillars of Connected Enterprise Intelligence

Pilots succeed. Production does not. Across the industry, agentic platforms reach a demo, impress a steering committee, and then stall before they can be put in front of clients, regulators, or the board. The pattern is too consistent to be a model problem. The model is capable. What is missing sits beneath it.

Sources: IDC / Lenovo, S&P Global, Gartner, Gartner.

The gap is structural. An enterprise agent needs three pillars the bank has rarely built as connected systems: a semantic layer of how the bank actually runs, a context graph of the decisions the bank has already made (by people and by AI), and data, sourced zero-copy from the systems that already hold it, guided by the Semantic Layer, or modelled inside Neo4j where the data is naturally connected. Each unlocks a different class of outcome. Together they are what turns a capable agent into one a regulated bank can trust.

This paper introduces the three pillars, what each one unlocks, and why connection (not collection) is the work. A companion paper, The Four Phases of a Trusted Agentic Answer, shows how these pillars power the four phases of execution that every agentic answer moves through.

Graphs have a representation of knowledge that’s more precise and makes applications more reliable. My recommendation is for enterprises to build their own data layer to overcome silos.

Andrew Ng · DeepLearning.AI, Google Brain

Three pillars. One Knowledge Layer.

Together, these three pillars form the Knowledge Layer: the connected foundation an enterprise agent reasons against. Each pillar is a connected map of something the bank already has but has rarely joined up. On its own, each unlocks specific outcomes. Together, they are what makes agentic AI trustworthy at enterprise scale.

Pillar 1 · Semantic Layer

A connected map of how the bank actually runs: the business-facing terms and the domain model that names them, the people (roles, responsibilities, hand-offs), the processes (account opening, credit review, AML screening, broken into the activities that each one really involves), and the underlying systems that support them.

Unlocks Agents that know how the bank runs. Same processes, reused across business lines. Audit becomes possible.

Pillar 2 · Context Graph

A graph of the bank’s institutional memory: the context every significant decision was made in, the reasoning that shaped it, and the decisions themselves with the trails they leave behind. The why that used to live in chat threads and human heads, captured and queryable.

Unlocks A memory that compounds with every call. Audit trails the regulator can follow, agent observability the engineer can debug. Consistency across similar decisions.

Pillar 3 · Data

The data the agent needs, wherever it lives. The Semantic Layer points to the system that holds each answer (Snowflake, Oracle, Salesforce, S3) and the agent queries it directly: zero-copy, no replication. Where the data is naturally connected (customers and households, counterparties and beneficial owners, mule rings, identities and entitlements), it’s modelled inside Neo4j and queried there.

Unlocks No rip-and-replace. Existing systems stay the source of truth, with graph-native and runtime projections ready when the workload calls for them.

Governance runs through all three: semantic consistency and policy mapping in the semantic layer, decision traceability and human oversight in the context graph, lineage and access across connected data. One bank, one map, one set of controls.

Three pillars. Four phases. Every answer trusted.

These are the three pillars. Every answer an enterprise agent gives moves through four phases of execution: understanding the meaning, recalling what the bank already knows, choosing the right path, and reaching the credible source. Each phase draws on one or more of the pillars. Build the pillars once; every phase, every agent, every workload uses them.

Build the pillars, and every agentic workload the bank runs after this inherits them.

People. Process. Systems. Connected.

The Semantic Layer joins three things every bank already has but has rarely connected: People, Processes, and Systems. It’s system-agnostic, sitting above existing data sources, graph-native or not, and guiding the agent to where each answer lives.

Each component pays off on its own, and there is no predefined order. Some organisations implement all three at once, typically where executive sponsorship drives organization-wide alignment. Others take an incremental approach based on internal priorities.

People

Roles, reporting lines, group memberships, and system entitlements, connected. Who reports to whom, who has access to what, and the authority chain behind every permission.

Unlocks on its own Regulatory access reviews collapsed from months to days at NatWest. Permission-aware agents that don't surface systems the user can't see. Clean hand-off visibility across business units.

Process

Account opening, credit review, AML screening, access recertification: today scattered across runbooks, policy documents, and tribal knowledge. Codified into a graph the agent can walk instead of invent.

Unlocks on its own Same processes reused across Wealth, Commercial, Retail, Institutional. A new product launch inherits the map. Audit traceability by construction. The first step toward agentic automation.

Systems

Which application owns which task, which database is authoritative for which concept, what each business term maps to. Lineage from regulation down to the system that enforces it.

Unlocks on its own One canonical definition per business term. Lineage queries answered as a graph traversal, not a quarter of discovery. A foundation any data-product work can stand on.

Together these three core components of the Semantic Layer aid in unlocking agentic autonomy while honouring the regulatory procedures the bank already runs on.

The why behind every decision.

Every significant decision a bank makes has a why behind it. Today, that why lives as tribal knowledge, in chat threads, email approvals, and the heads of the people who made the decision. This whole process is lost the moment the outcome is stored in rows and columns.

The Context Graph turns that tribal knowledge into institutional memory by capturing three connected things: the context the bank was operating in, the reasoning that shaped the call, and the decisions themselves, with the trails they leave behind. Together they give the bank memory that compounds: every decision read by the next, every regulator question answerable as a query.

Context

Snapshots of the state of the world at decision time: which policies were in force, which thresholds applied, who held authority, what the upstream systems were saying. Without context, a decision is just a number on a screen; with it, the same number can be defended.

Unlocks on its own Answers to "what was true when?" without forensic reconstruction. Decisions that can be reread against the conditions they were made in, not today's.

Reasoning

The judgement calls, policy overrides, escalations, and precedents that shaped the answer. Why this customer got a $10K threshold and not $25K. Which prior case was leaned on. Where the analyst broke with the default, and on whose authority.

Unlocks on its own Consistency across similar decisions, even when the right answer differs by segment. Agents that honour the policies the bank has already decided, instead of re-litigating them each time.

Decisions

The decisions themselves, linked to the reasoning that produced them and the causal chains showing what each one set in motion. The full chain from question, through decision, to consequence, queryable as a graph.

Unlocks on its own Audit trails the regulator can follow; agent observability the engineer can debug. Same trace, two audiences: every action followable from question, through reasoning, to outcome.

Because an agent owns a decision end-to-end, its trajectory is a decision trace by construction: the institutional memory grows with every call.

The data the agent needs, wherever it lives.

The Semantic Layer tells the agent what to ask for. The Context Graph tells it what the bank has already decided. The Data pillar is how the agent actually reaches the records, using the bank’s existing data estate as it stands today. Two ways to do that today, plus an architectural shift to keep in mind.

Zero-copy

Zero-copy means exactly that; the bank’s data does not move. The Semantic Layer is the map: it knows which system is authoritative for which concept (Snowflake holds the warehouse, Salesforce holds the relationships, Oracle holds the ledgers). When the agent receives a question, the Semantic Layer tells it which systems to visit; the agent queries each one directly and composes the answer from live records.

What that means for a regulated bank: source systems stay as the system of record, with their existing access controls, audit trails, and data residency intact. The Knowledge Layer becomes useful on day one without the requirement to move and rebuild data assets.

When to use When the existing system is already the right place for the job, the warehouse the bank has invested in.

Graph-native

Where the data is naturally connected, customers and households, counterparties and beneficial owners, mule rings, modelling it inside Neo4j is the answer. The value isn’t speed alone, it’s that some answers only exist when the connections are first-class. Mule rings six counterparties deep, beneficial-ownership chains across jurisdictions, questions only a graph can answer.

When to use When you require relationships in your data to answer the question.