Eight layers. Three Fires. The architecture every CTO wishes they had before Monday morning

Four more layers, and why none of them are optional

Part 2 of the Enterprise Intelligence Platform - Read part 1 here.

The concepts of the Enterprise Intelligence platform are complex and difficult to navigate. My previous article leant towards the academic. Applying that to real world situations and challenges was left as a task for the reader - a task that wasn't exactly trivial.

A Tuesday morning at ‘Intellisurance Ltd’

09:20

Jane Doe is six months into her role as CTO of Intellisurance Ltd, a mid-cap commercial insurer with 1,200 employees and 140 years of underwriting history. She inherited the AI strategy from her predecessor along with the company laptop and a polite warning from the Chief Operating Officer that the technology team had been "quite ambitious recently."

She has a board meeting at ten o'clock. Three things are expected of her in the 40 minutes before.

The claims-triage agent, which was supposed to cut handling time on low-complexity motor claims by 40 percent, is settling those claims at 12 percent above the rule-based system it replaced. The head of claims wants it switched off by lunchtime.

The broker-facing chatbot rolled out by the distribution team last quarter has been quoting policies the carrier does not actually write. Two brokers have logged complaints. One is threatening to take it to the regulator.

The executive dashboard says Intellisurance has 8,400 active commercial customers. The submission filed with the regulator last week said 7,900. The chief actuary thinks the right number is 9,100. The board chair has asked, in writing, which is correct.

Jane does not yet know why any of these fires are burning. She has the symptoms. She does not have a diagnosis. The brief from her predecessor named the AI estate "Project AI McTacticalFace" and described it as production-ready in two phases. Looking at it from inside, Jane suspects production was the first phase and ready was the second. By the end of the day, the board will need something more useful than that.

My first article in this series mapped five layers of an enterprise intelligence platform that, taken in order, would have given Jane one answer to her three questions instead of forcing her to invent three independently. Part 1 also closed with a confession: five layers was not enough. Four more are missing. Operating without those four is what put Jane in the chair she is sitting in this morning.

This piece adds those four layers. It reframes the trust layer from Part 1 as a wrap that permeates everything rather than a tier of its own - See Reference 1. It draws on two ideas that have sharpened how I think about the whole platform: Structural Intelligence, articulated by Sotiris Melioumis, and context engineering, articulated by Jeremy Daly. It closes with the question most readers will want answered: how to scale the architecture down when the use case does not justify the full eight tiers.

The route is Jane's morning. She has 40 minutes. She will not walk the stack from one to eight in textbook order. She will follow each fire to its origin, top-down from the failing surfaces to the missing substrate, then back up to a synthesis. Each layer enters when her diagnosis reaches it.

By 10:00 she will know.

Reference 1 - Numbering map for Part 1 readers. Ontology becomes Layer 3, Knowledge Graph becomes Layer 4, Semantic Layer becomes Layer 5, Context Graph becomes Layer 6 (renamed; see the L6 section). Trust is no longer numbered. Layers 1, 2, 7 and 8 are new in this piece.

"What should we do next?" - Layer 7, the agentic tier

09:23.

Jane opens the triage agent's telemetry. The settlement decisions are technically deterministic. They cite "policy v2.1" as their source for severity bands. There is no record of which deck or document or workflow constitutes policy v2.1. The agent is settling claims with confidence against a citation no human can produce.

Retrieval is doing the rest of the damage. When the agent needs "similar past decisions" to inform its own, it searches a pile of historical settlement letters and grabs the ones that read most like the case in front of it. The pile has not been deduplicated. Letters from the rule-based predecessor sit alongside letters from the new agent's first weeks. The agent is now learning from its own early outputs as if they were precedent.

This is what an agent looks like without the substrate underneath it. The agentic tier is where the intelligence platform stops describing the world and starts changing it. Done properly, autonomous and assisted agents read the lower layers, apply policy, take action, and write decisions back into a structured memory that becomes tomorrow's precedent. The discipline that distinguishes a real agentic tier from a chatbot with delusions of grandeur runs on three concerns.

Grounding is the difference between an agent that sounds informed and one that is. A grounded agent consults from a canonical definition rather than trying to infer what "claim severity" means from raw training data. It finds data from a typed precedent store instead of trying to retrieve "similar past decisions" by vector-matching against an unstructured corpus. Jane's agent is doing neither. Every settlement decision it makes is technically a hallucination dressed up in a workflow.

Constraint is the difference between a sticky note on a cliff edge and a railing. A constrained agent operates inside policy boundaries enforced by the architecture, not the prompt. Tool access is scoped. Promotion of provisional facts to durable ones requires verification rather than enthusiasm. Jane has sticky note prompts. She does not have a railing.

Orchestration is what gives a multi-agent estate coherence. Different agents share definitions, evaluations, traces, and rollback. Without it, the estate is 12 copilots in a trench coat. Intellisurance is currently running three copilots in three different trench coats with no shared anything.

Switching the triage agent off is a tactical answer to a structural failure. The architectural cause sits below it. Jane does the next thing a working CTO does. She follows the failure down.

"What does this mean to us?" - Layer 5, the semantic layer

Jane looks for the canonical definition of "low-complexity motor claim." She finds three. The agent's prompt specifies one severity threshold. The underwriting handbook specifies a different one. The policy administration system enforces a third. The numbers have been disagreeing quietly for eighteen months. Nobody has been given the authority to declare which is right.

This is the semantic layer's absence. I went into detail on the semantic layer as it’s such an important part of the intelligence platform back in Part 1 so go refresh if you need (Five layers of enterprise intelligence (And why the order matters) ). The semantic layer is the governed translation interface between organisational facts and the language the business actually uses. Names and relationships describing what is an active customer, a severity band, an eligible matter, an exposure. One definition, one calculation, one source of truth. Every consumer (human, agent, dashboard) reaches into the same library, understands the same ‘thing’ the same way.

Intellisurance has no library. Each consumer has built its own. The agent's hallucinations are downstream of an architectural absence, not an upstream prompt error.

"What is true?" - Layer 4, the knowledge graph

Jane pulls the customer record for the claim the agent settled this morning. The marketing automation system has the customer flagged as in-dispute over a renewal. The claims system did not see the flag. The policy administration system has a third version of the relationship status. The broker portal has a fourth.

Four overlapping records of one commercial counterparty in four systems, none resolved into a canonical entity. Another of the layers covered previously in Part 1. The knowledge graph is the population of the ontology with real entities and real relationships, resolved across source systems and reconciled into canonical form.

Intellisurance has no resolution. Jane can’t tell the board chair how many customers they have because the resolved entity (or value in this case) does not exist anywhere. The agent settled a claim against a customer the rest of the business considered in dispute. There is no architectural place where that conflict could have been caught.

"What can exist?" - Layer 3, the ontology

Jane asks the Chief Architect for the world model. He produces a Visio file from 2018: 47 boxes, no relationships, no constraints, no version. The file is titled "Conceptual Data Model v0.4 (DRAFT)." It has not been opened in two years.

The ontology is the empty blueprint. Part 1 covered it as the formal specification of what exists in the enterprise's world: the entity types, the relationships, the constraints. Customer, account, policy, claim, broker, party, jurisdiction. The schema of the world model. No data.

Without it, every downstream system shapes the world its own way. Policy administration treats Motor Claim as a Claim with a line-of-business code. Claims handling treats it as a distinct claim type. Marketing automation has no Motor Claim at all, only campaigns tagged "motor" attached to Counterparty records. Three systems with three different shapes for one idea. The job of this layer is structural, not interpretive. It declares what Motor Claim is, not what makes one "low-complexity." That work lives two tiers up in the semantic layer. The agent's confident wrongness, the chatbot's quoting of policies that do not exist, the disagreement on customer count: all have the same architectural origin. There is nothing for the rest of the stack to point to.

Sidebar: Structural Intelligence

09:34.

A digression is warranted, because the principle that makes the chain Jane just walked work has a name. Say that three times fast. My point is that what we’ve described, the triage route and the principles that Jane has travelled. They all have a name.

Sotiris Melioumis, CEO of SN2 UK and IDEaaS, has been articulating an idea he calls Structural Intelligence. The argument runs across two recent pieces, Artificial vs Structural Intelligence: Why Only One Has a Path to Cognition and Stop Calling It Intelligence, with the formal treatment in his Zenodo paper Informational Unit Ecologies. The thesis is uncompromising. Modern AI spans four families: statistical models including LLMs, symbolic systems, world-model architectures, and agentic frameworks. They differ in technique. They share one foundation: they all operate on representations of past data or predefined rules. None form structural invariants. None have a cognitive path.

His metaphor is the cleanest expression of the gap. Imagine a hill during a rainstorm. Predicting water flow from previous rains fails because the hill itself has changed: vegetation, soil, erosion, alteration. The water follows the present gradients, not the historical ones. Statistical systems perceive the memory of past storms. They do not perceive the structure of the hill. The hill is where the answer lives.

Structural Intelligence, in his framing, begins where these systems end. It relies on the present configuration of the system: gradients, constraints, tensions, stability fields, path-of-least-resistance dynamics. Cognition, operationally defined, is the ability to maintain and reuse structural invariants across transformations and uncertainty. The legacy paradigms extend the past. Structural Intelligence extends the possible using understood ‘physics’ of the world.

I take Melioumis's claim about cognition seriously. I am not claiming the enterprise platform in this article achieves it. The relevant move is more modest and more useful. The platform is what an enterprise architecture looks like when it is organised in the direction of structural invariants. The four intelligence layers, taken together, are where structural intelligence sits. The agentic tier, on its own, is exactly the family Melioumis names as a dead end: a chain of statistical and symbolic extrapolations dressed in autonomy. Wrapping it in the four intelligence layers is the only available technique for making the action layer behave as if it has a cognition it does not actually possess on its own.

Jane's triage agent is naked. There is nothing wrong with the model. The problem is what the model is being asked to do without the structural scaffolding underneath it. Wrapping it in the right layers is the fix. Improving the prompt is not.

I credit Melioumis for the framing. The enterprise architecture application is mine. Read his work directly. The argument deserves the original voice.

"What did we do about it?" - Layer 6, the decision memory layer (see Reference 2)

Jane wants the precedent. Who signed off on the original triage agent's settlement bands? Under what conditions? Against what risk appetite? She asks the Chief Actuary. He remembers a conversation with the previous CTO. He cannot find the deck. He thinks there might have been an email. The Chair of the board's risk committee remembers approving "something" about settlement bands. She does not remember the conditions.

Part 1 covered this layer under the name "context graph." The name may have evolved, but the job has not changed. It captures how decisions were made: the evidence consulted, the policy applied, the precedent referenced, the reasoning, the outcome. It is the institutional memory most organisations carry in heads and email threads. Learning lives here too, because patterns across decision traces are the only honest signal that a system is reproducing the policy it was supposed to enforce.

Intellisurance has no decision memory layer. A regulator inquiry about a single approved claim takes 45 minutes of phone calls and three different stories before anyone produces an answer. The reasoning that authorised the agent in the first place is now distributed across heads, emails, and a deck nobody can find.

This is also where bias accumulates structurally. Automating decisions on historical precedent reinforces whatever biases exist. If the policy authors of 2022 would not endorse what the system is doing in 2026, the absence of a layer recording "this was approved under policy version X" makes the drift impossible to detect. Jane's agent is not auditable, because the substrate the audit needs has never existed.

Reference 2 - Renamed from "context graph." Part 1 borrowed the term because it was in circulation. The term was doing too much work. Foundation Capital uses it to mean a decision-trace store. Technical literature uses it to mean an AI-optimised subgraph. Vendor decks use it to mean whatever they want this quarter. The job that layer actually does is institutional memory of decisions. That is decision memory, not context. The function is unchanged.

"How do we reach it?" - Layer 2, the integration layer

09:42.

The triage file is closed for the moment. Jane opens the broker chatbot trace.

The chatbot is calling the public website's content API. There is no governed seam between the chatbot and Intellisurance's policy data. There is no rate limit. There is no contract version. There is no identity propagation. The chatbot has been told, by the public website's CMS, that Intellisurance writes a directors-and-officers product the carrier discontinued in 2022. The CMS was never updated. The chatbot has been quoting a withdrawn product to brokers for six weeks.

Between the data layer and the intelligence layers sits the membrane between the intelligence and the data. It has many names: integration plane, service mesh, API layer, the bus. I call it data integration to make the point: the seam is where data is accessed in a governed manner at runtime, not later.

The seam is where MCP servers expose graph access to agents. Where REST and GraphQL endpoints serve synchronous queries. Where event-bus topics propagate change. Where WebSocket channels carry real-time signals. Where batch ETL seeds the initial graph. It is the place where every one of those access patterns is observable, versioned, rate-limited, and authenticated.

The reason to make this its own layer is that the access patterns are different from the storage patterns, and the governance burden is heavier. The storage layer cares about durability, indexing, cost. The integration layer cares about contract versioning, identity propagation, observability, replay.

In an agentic estate, this layer carries weight it never carried for human-driven applications. Humans are forgiving consumers. They retry. They tolerate stale data. They accept "service unavailable" with a sigh. Agents do not. An agent given a tool that returns inconsistent data over the same query will faithfully encode the inconsistency into a precedent, write it back into decision memory, and serve it up tomorrow as institutional truth.

Intellisurance's chatbot has been doing exactly this. Bad data flowing through a chatbot is an inconvenience. Bad data flowing through an agent that writes is a corporate liability. The chatbot is the second case dressed up as the first. The threatened regulator referral is the bill arriving early.

The architectural rule is plain. Every agent, every product, every human surface reaches data through the same controlled seams. No shadow integrations. No per-project point-to-point. No bespoke ETL flowing into a single team's data mart. The platform engineering community has been arguing for this discipline under the API gateway banner for the last decade. The reason to apply it here is that the consequences of skipping it are larger.

"What do we have?" - Layer 1, the data layer

Below the absent seam sits the substrate. Jane runs the inventory.

Policy administration on a Snowflake estate. Claims handling on a separate Postgres cluster the claims team treats as their own. Broker portal on a SaaS platform with read-only API access. Marketing automation on a third-party tool that thinks it owns "the customer." A warehouse that pulls from the first three on a six-hour ETL. Two SharePoint workbooks the underwriting team actually uses. The Chief Actuary's laptop, where the third customer count lives, refreshed by hand on the morning of every Board meeting.

The first thing every enterprise intelligence diagram should include, and the first thing every vendor diagram politely omits, is the data layer. The systems of record. The transactional databases, document stores, object stores, SaaS APIs, the warehouse, the lakehouse, the streams, the spreadsheets nobody admits to. This is the substrate from which the knowledge graph is hydrated.

Most enterprises have spent 20 years and three CIO tenures on this layer. The trap is to confuse trodden ground with stable ground. Most enterprise data layers are stable for the workloads they were built for: operational reads, periodic reporting, dashboards. They are not stable for what comes next. Hydrating a knowledge graph requires fan-out access patterns, change-data-capture across heterogeneous sources, identity stitching at ingestion time, and provenance metadata that source systems were never asked to emit.

Five properties of the layer matter most.

The layer has to be honest about what it contains. Shadow stores, exported spreadsheets sitting on personal SharePoints, the analyst's local Postgres: these are part of the data layer whether the architecture diagram acknowledges them or not. The Chief Actuary's workbook is part of Intellisurance's data layer. Until the architecture says so, Jane has no diagnosis.

The layer has to expose change, not just state. The knowledge graph is a living artefact. It needs to know that an account moved, a contract was amended, a referee was added, a lawyer left the firm. Source systems that emit only current state force the higher layers into expensive polling and brittle reconciliation. Intellisurance's policy administration system emits state and only state, which is one reason the broker chatbot is so confidently wrong: the underlying retrieval has no sense of what changed last week.

The layer has to carry provenance, not let it be inferred. When a fact lands in the knowledge graph, the trust wrap needs to know which source system asserted it, when, and under what authority. If that metadata is reconstructed downstream, it is already a guess.

The layer has to support fan-out at agent speed. Human-driven applications query a handful of records at a time. An agentic estate fans out across hundreds of entities per run, joins them across stores, and does so concurrently with every other agent in the building. Storage tiers tuned for periodic reporting fall over under that load. Most enterprises discover this the morning after the first agent goes live.

Identity stitching has to start at ingestion. Resolving "Acme Corp" in the marketing system to "Acme Corporation Ltd" in the policy system is a problem that gets harder, not easier, the further downstream it is deferred. The data layer is where source-of-truth identifiers and the resolution lineage between them ought to be captured. Pushing that work entirely into the knowledge graph turns reconciliation into a perpetual rebuild.

The data layer is unglamorous. It is the cheapest place to fix a problem that becomes catastrophic four layers up.

Sidebar: Context Engineering

09:48.

The substrate is identified. The seam is identified. Jane now has the architectural shape of why her agents are misbehaving. She does not yet have the runtime discipline by which a corrected architecture would behave reliably. That has a name too.

Jeremy Daly published an essay in February titled Context Engineering for Commercial Agent Systems. It is the clearest articulation I have read of what production-grade agent infrastructure actually requires. The most quotable line in the piece is the one that frames the rest of it: "Models are commoditised. Context is not."

Context engineering is the discipline of assembling, constraining, compacting, and discarding state across agent runs. It is not prompt engineering. Prompt engineering tunes what one model sees in one shot. Context engineering is the infrastructure layer that decides, for every run, what enters the model's working set, how it is scoped, where it persists, when it is garbage-collected, and how it is replayed.

Daly's framing maps directly onto this intelligence platform.

His memory taxonomy is two-axis: scope (global, tenant, user, session) and type (policy, preference, fact, episode, trace). "Memory without scope is exposure. Memory without type is entropy." Scope is enforced by the trust wrap. Type is enforced by the decision memory layer.

His truth-versus-acceleration distinction is critical. The canonical event log and the structured memory store are truth. Vector indexes and object stores are projections, rebuildable and disposable. "If you cannot rebuild it from canonical truth, it should not be trusted." That is the knowledge-graph-as-spine principle, expressed in operational terms.

His promotion gate is the most under-appreciated idea in the piece. Moving a fact from session to durable memory is the most dangerous operation an agent performs. Drift starts in promotion, not in inference. Promotion requires verification. The decision memory layer is where this discipline lives.

His trace envelope is the canonical replay primitive: pinned identity, policy version, prefix hash, retrieval artefact IDs, tool contract versions, promotion decisions, cost. That is the artefact the trust wrap demands and the decision memory layer captures.

Read Daly's piece. The point of citing it here is that the agentic tier is not implementable without a context engineering discipline running through it. The four intelligence layers give an agent the substrate. Context engineering is what turns substrate into reliable runtime behaviour. The architecture is necessary. It is not sufficient. Context engineering is what makes it sufficient.

The point on which I will press, because Daly does not, is that the canonical truth he refers to has to be ontologically grounded. A canonical event log on a data layer with no shared ontology is a more reliable swamp. The intelligence layers are what make the canonical truth canonically meaningful. The two disciplines complement each other.

"How does the outside world meet the system?" - Layer 8, the presentation tier

09:51.

Jane opens three tabs. The executive dashboard. The threatened regulator filing. The Chief Actuary's workbook. Three numbers. Three definitions. Three teams answering three different questions.

The dashboard counts any commercial counterparty with a record in the marketing system. The regulator filing counts any counterparty with a live policy on inception date. The actuary counts any counterparty with paid premium in the last 12 months. None of the three numbers is wrong. None passed through a semantic layer because Intellisurance has no semantic layer to pass through. The Board chair is right to ask which is correct. The answer is that the question has no architectural place to land.

Every conversation about AI architecture eventually surfaces a request for "the dashboard." The dashboard is not the architecture. The dashboard is the presentation tier. So is the writer workbench, the researcher console, the subscriber product, the embedded experience inside an existing application, the AI Index that serves a structured projection of the system to enterprise search and external agents.

The presentation tier is the layer most enterprises unintentionally start with. A stakeholder wants a chart. A team builds the chart. The chart needs data, so the team builds a pipeline. The pipeline needs definitions, so someone hard-codes them. Six months later the company has 11 dashboards each with a slightly different definition of "active customer", and the question of which is correct cannot be answered because there is no layer at which the answer lives. This is the spine-last failure mode. It is the architectural shape of Jane's third fire.

The fix is the spine-first principle. The presentation tier is downstream of the intelligence layers, never upstream of them. When the layer is built right, every surface queries the spine. The internal workbench, the external subscriber product, the AI agent calling via MCP all reach the same knowledge graph, against the same semantic layer, through the same governed integration. Different surfaces, same truth.

Adoption is also won and lost at this layer. A workbench that saves four hours a week per writer and is used by 70 percent of writers pays for itself. A workbench that saves four hours a week and is used by nobody, because it is slower than the spreadsheet they already had, is an expensive ornament. Adoption is an architectural concern, not a change-management afterthought.

The cleanest test of a presentation tier is whether the presentation tier is missed when removed. If the underlying graph, semantic layer, and decision memory survive a presentation rebuild, the spine is real. If a rebuild requires re-deriving definitions, re-stitching identities, and re-encoding precedent, the spine never existed.

"Should we?" - The wrap, not a layer

09:54.

Jane has been seeing the same absence in different costumes all morning.

The chatbot has been calling an unverified CMS with no rate limit and no contract version. That is the integration layer's trust face missing. The settlement bands cite a "policy v2.1" that no human can pin to a document. That is the decision memory layer's trust face missing. The chief actuary's workbook has been refreshed by hand on the morning of every board meeting for two years, and no audit log knows it exists. That is the data layer's trust face missing. Nobody can name the person allowed to modify "low-complexity motor claim." That is the ontology's trust face missing. Three customer numbers reach three surfaces and no one knows who saw which on what date. That is the presentation tier's trust face missing.

Trust does not get a numbered slot.

The cleanest mental model is to stop drawing trust as a layer at all. It is the air every layer breathes. It permeates each tier the way an operating system's permissions model permeates every process and every file. Every one of the eight layers has a trust face that enforces something specific, logs something specific, and fails differently when the discipline lapses. The full breakdown sits in the reference table at the end of this piece.

The wrap is everywhere because the failures are everywhere. Bolting governance on after the agents are in production is the most expensive failure mode in the entire architecture. It is also the most common. Intellisurance's chatbot is in production. The wrap is not.

The diagnosis

09:56.

Three fires, one absence in three places.

The triage agent is operating without grounding because no semantic layer, no resolved knowledge graph, no canonical ontology, and no decision memory layer exist for it to ground in. The broker chatbot is reading from a knowledge graph Intellisurance does not own, through an integration seam Intellisurance has not governed, against a substrate Intellisurance has not made fit for purpose. The customer count disagrees with itself because three presentation surfaces have built their own definitions in the absence of a layer where definitions could have lived.

None of this is a technology problem in the sense the board is expecting. All of it is the same architectural absence, surfacing in three places.

The fix is sequencing, not money. The next six months are a single foundation laid in the right order, starting at the substrate and moving up.

How to condense the intelligence platform when the use case is smaller

09:58.

Not every organisation needs all eight layers built to industrial standard. Most do not. Sequencing matters more than size. A team of five running an internal triage agent does not need the same architecture as a global insurer running a continuously-updated platform. What matters is that the layers exist, in order, sized to the use case.

The order is non-negotiable. The depth is. Every layer can ship as a thin version of itself, and none can be skipped. Skipping a layer is what produces Jane's morning. A semantic layer can begin life as a Notion page with twelve definitions and a named owner. An ontology can be a single-page entity-relationship diagram with constraints written in plain English. A decision memory layer can be a spreadsheet with five columns: decision, evidence, rule, who, outcome. None of these are good enough at scale. All are good enough to start, because they exist.

Layers can be combined when the consumer count is small. A pilot with a single agent does not need a separate governed integration layer; one MCP server with audit logs and a contract version does the job. A pilot with no external surface does not need a presentation tier; the agent itself is the surface. A small team can run the trust wrap as a checklist rather than a tooling estate. Combination is allowed. Omission is not.

Trust scales with consequence, not with scope. A medical-device company building a single triage agent needs a heavier wrap than a marketing team building a dozen agents on internal data. The wrap is calibrated to what happens when it fails.

Three practical patterns, in increasing order of seriousness.

A single-agent internal pilot can carry layers 1, 3, 5 and 7 as one-page artefacts. Layer 2 can be a single MCP server. Layer 4 can be deferred. Layer 6 can be a spreadsheet. Layer 8 is omitted because the agent is the surface. The trust wrap runs as a checklist. This ships in weeks. It does not generalise.

A departmental rollout moves layers 1, 2, 3, 5 and 7 into real form. Layer 4 is hydrated for one domain only. Layer 6 is a structured table with a named owner. Layer 8 is a single internal product surface. The trust wrap has three or four named faces. This ships in a quarter. Most enterprises should stop here if the use case is bounded.

An enterprise platform runs the full eight layers under permanent ownership. The governance wrapper has permeated every layer and face of the enterprise. Multiple agents serve multiple surfaces against a shared spine. This is the answer to the Intellisurance-shaped problem.

A few things cannot be condensed regardless of scale. The ontology and the knowledge graph cannot be conceptually conflated. A graph without an ontology is a swamp. An ontology without a graph is a vocabulary list. They are distinct artefacts even when a single tool exposes them as one. The layer distinction matters especially when a single platform appears to remove it. Palantir's Foundry Ontology is the useful counterexample here: it unifies type definitions, instance data, and the actions you can take on them inside one runtime, and it works precisely because the schema and the populated entities are kept distinguishable underneath the unified surface. The merger is implementational, not conceptual. Tooling that hides the seam between the two is a convenience for builders. The layers are still doing different jobs.

The semantic layer is not optional once more than one consumer exists. As soon as two systems read the same data, they will disagree about what it means, and the layer has to exist to hold the agreement. Trust is never retroactive. A wrap added after agents are in production is a wrap that does not protect the production traffic.

Board meeting

10:00.

Jane walks in with a single architectural diagnosis. The board was expecting another round of pilots, another vendor demo, another six-month roadmap of unrelated experiments. She does not have any of those.

The triage agent is operating without grounding. The broker chatbot is reading from a knowledge graph Intellisurance does not own. The customer count disagrees with itself because nobody has been given the authority to declare which definition is canonical. None of those is a technology problem in the sense the board is expecting. All of them are the same architectural absence, surfacing in three places.

She tells them so. The chair asks how much it will take to fix. Jane says the fix is sequencing rather than money, and the next six months are a single foundation laid in the right order, starting at the data layer and moving up. The room goes quiet for longer than is comfortable. The chair asks her to come back next month with a phased plan.

With tactical AI deployment, Jane Doe didn't know. Now she does. Tactical AI is what you ship when you skip the intelligence layers. Strategic AI is what you ship when you don't.

Reference - The eight layers, one wrap