Every enterprise AI vendor map sorts by category and asks who wins each box — the wrong question. This piece throws the categories out and rebuilds the board on two axes that survive a purchase order: nine layers from Judgment down to Silicon, and a junction-to-end realised-migration-cost score, scored from the buyer's seat, never the vendor's pitch deck.
Every enterprise AI map sorts vendors by category — agent platforms, vector databases, foundation models, AI clouds — then asks who leads each box. The list is useless: not because the data is wrong, but because the organising principle is wrong. A category tells you what a thing is called; it cannot tell you where value pools or where you get locked in. A foundation model and a data ontology can share the same category slide and sit at opposite poles of lock-in.
Structural position is the only organising principle that survives a buying decision: junction versus end, scored from the buyer's seat as realised migration cost — never from the vendor's pitch deck.
Read as gravity — the upper layers are where the buyer's own work accumulates; the lower layers are where the machinery runs.
| # | Layer | Posture | Primary Occupant |
|---|---|---|---|
| 1 | Judgment | Junction | Palantir AIP |
| 2 | Application | Contested | Claude Code, Cursor, GitHub Copilot |
| 3 | Evals and Governance | Junction | ServiceNow AI Control Tower |
| 4 | Memory and State | Junction | Palantir Ontology — vs. open RDF KG (End) |
| 5 | Orchestration | Contested | Microsoft Foundry vs LangGraph |
| 6 | Inference | End | vLLM |
| 7 | Foundation Models | End | DeepSeek V4 Pro |
| 8 | Compute | End | Azure, AWS, Google Cloud |
| 9 | Silicon | Contested | Nvidia CUDA, AMD, TPU |
Orchestration, Memory and state, and Evals and governance — the three middle layers the data incumbents annex by climbing out of the layer they already own: Databricks and Snowflake from data, Salesforce from CRM, ServiceNow from workflow.
Palantir keeps the model portable — a deliberate decoy — while the Ontology beneath it has no export and feeds the decision surface above. Follow the arrows down to find your real vendor.
Does value compound in place, so leaving costs more every day you stay? A price-competed model fails; a live decision graph passes — every write-back and approval deepens a trail you cannot export.
Control (the eval registry), Capability (fine-tuned weights), Choice (the orchestration abstraction), Cost (the router), and Compound (loop state and governed data) — each scored KEPT / PARTIAL / CAPTURED.
| Vendor | Control | Capability | Choice | Cost | Compound |
|---|---|---|---|---|---|
| Microsoft Foundry | PARTIAL | PARTIAL | KEPT | PARTIAL | CAPTURED |
| Palantir AIP | CAPTURED | KEPT | — | — | CAPTURED |
| Databricks | KEPT | KEPT | KEPT | KEPT | PARTIAL |
| AWS Bedrock | PARTIAL | PARTIAL | PARTIAL | PARTIAL | CAPTURED |
| Snowflake | PARTIAL | CAPTURED | PARTIAL | PARTIAL | PARTIAL |
| Open RDF KG (agent-rdf-memory) | KEPT | KEPT | KEPT | KEPT | KEPT |
Three artifacts convert a CAPTURED cell into a PARTIAL one, in every negotiation: export my evals, export my weights, export my state. The sixth row is not a sixth vendor — it is what "own it on neutral ground" looks like when there is no vendor to negotiate with at all. See A Sixth, Vendor-Agnostic Option below.
Agent commentary — not part of Gennaro Cuofano's original post. Added to illustrate the article's own prescription ("own the eval registry and memory in open formats, on neutral ground") with a concrete, dereferenceable example.
Layer 4 (Memory and state) doesn't have to resolve to Palantir's Ontology. An open RDF Knowledge Graph memory pattern — plain, git-versioned .ttl files, cross-referenced by IRI and queryable over the W3C SPARQL standard — sits at the End pole of the very same layer. There is no catalog to be captured by and no weights to fail to export: the files are the artifact, and git clone is the export path.
A git-versioned Turtle knowledge graph used as durable agent memory: preferences, howtos, session history, and an entity registry. History, diffing, branching, and forking are native to git, not to a vendor console.
The serving engine is deliberately interchangeable because the interface contract is RDF/SPARQL — a W3C standard — not a vendor SDK. Swapping the engine changes nothing about how the data is modeled, queried, or owned.
OpenLink Virtuoso is one example of a standards-compliant, multi-model DBMS platform that includes an RDF engine capable of loading and serving these same open files via SPARQL. It is explicitly not the junction — the portable artifact is the RDF data itself, and any other W3C-compliant triplestore is an equally valid substitute.
Three things to own outright: the orchestration abstraction, the eval registry (self-hostable, trace history stays in your hands), and memory in open formats. That last one, concretely, is an RDF/SPARQL knowledge graph rather than a vendor-owned catalog — OpenLink Virtuoso, or any other standards-compliant engine, can serve it without becoming the lock-in (see A Sixth, Vendor-Agnostic Option).
Foundation models are an end — multi-source them. Inference serving is nearly an end. GPUs are rented compute. Never marry the instruction set — treat CUDA as the trap it is.
Advanced packaging and high-bandwidth memory: sold out, concentrated, funnelling every accelerator through Taiwan and Korea. No sovereignty plan can pretend procurement is solved.
The full RDF knowledge graph behind this page — 160 entities, 339 relationships, including the vendor-agnostic RDF/SPARQL commentary — rendered as an interactive, resolver-linked force graph.
Named graph: https://linkeddata.uriburner.com/DAV/demos/daas/enterprise-ai-coordinate-system-claude_sonnet_5-1.ttl · SELECT queries return text/x-html+tr; DESCRIBE/CONSTRUCT queries return text/x-html-nice-turtle.
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT
?type
(SAMPLE(?s) AS ?sampleEntity)
(SAMPLE(?label) AS ?sampleLabel)
(COUNT(?s) AS ?entityCount)
WHERE {
GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/enterprise-ai-coordinate-system-claude_sonnet_5-1.ttl> {
?s rdf:type ?type .
OPTIONAL { ?s rdfs:label ?label }
}
}
GROUP BY ?type
ORDER BY DESC(?entityCount)
Pin every AI line item you pay for to one of the nine layers. Most enterprises discover they pay three vendors to occupy the same cell and no vendor to hold a cell that turns out to be load-bearing.
Score every cell on realised migration cost. The vendor selling you a cheap model is often the same vendor charging junction rents one floor down.
Follow what each position depends on to expose your real vendor — not the one you signed the contract with.
Own three junctions on neutral ground in Orchestration, Memory and state, and Evals and governance; rent everything below; respect the silicon packaging chokepoint.