Enterprise AI's Real Moat: How Glean, Palantir, and OpenAI Build Context

Why Context Construction Determines Enterprise AI Success

BCG's 2026 report states: "Underlying technology converges in 2-3 years; durable advantage migrates downward to assets and structures beneath the technology." Models are commoditizing—every company can buy the same GPT, Claude, or Gemini. Real competition lies in Context. Gartner's July 2026 research adds: "Agentic AI without a robust Context Layer struggles to run reliably in real enterprise environments." AI agents that cannot understand semantic relationships, rules, and connections among enterprise data produce errors, hallucinations, and wasted compute.

Three representative companies offer three distinct, validated paths:

Glean route: Build an Enterprise Graph connecting enterprise knowledge, people, projects, and collaboration.

Palantir route: Build an Ontology modeling business data, entities, states, rules, and Actions.

OpenAI route: Around concrete professional tasks, layer in Metadata, semantics, knowledge, Memory, Runtime, Permission, and Eval.

Glean Route: Turn Enterprise Knowledge into an Enterprise Graph

Core Philosophy

Glean positions itself as a "system of context"—systematized organizational intelligence. Its core product is the Enterprise Graph: a knowledge graph that deeply understands projects, processes, and relationships, connecting enterprise data, people, and collaboration.

Glean indexes data from 100+ SaaS applications (Slack, Google Drive, Jira, Confluence, Salesforce) into a permission-aware knowledge graph, then builds enterprise search, AI assistant, and Agent platform on top.

Market Validation

June 2025: $150M Series F at $7.2B valuation.

May 2026: Surpassed $300M ARR , reaching $100M in just 15 months (89% YoY growth).

Fortune 500 customer count doubled year-over-year.

Processes 100M+ Agent actions annually.

850+ employees; Glean:GO conference attracted 10,000+ attendees.

Customers include Booking.com, Canva, Pinterest, Intuit, Zillow. Named Fast Company's 2025 Most Innovative Companies; recognized in Gartner reports for generative AI momentum.

Technical Architecture

Three layers:

Layer 1: Connector Ecosystem. 100+ SaaS connectors covering mainstream enterprise toolchains. Data indexed in real time, staying current.

Layer 2: Enterprise Graph Knowledge Graph. Data is not simply dumped into a vector database but "contextualized"—the graph understands how data, people, and processes collaborate to get work done. When an employee searches "refund rate analysis," Glean returns not only documents containing those words but also people who performed similar analyses, related projects, and collaboration history.

Layer 3: Permission Awareness. Users see only what they are authorized to access. Glean designed a complete authentication system from day one—every operation is authenticated, respects underlying data permissions, and is governed by enterprise guardrails. 2026 launch of Glean Protect adds proactive data/Agent defense.

Ecosystem Strategy

Glean's 2026 strategy shows clear open-ecosystem direction:

Partner with Dell to bring AI Agents and enterprise search to on-premises deployments.

Partner with Snowflake to let users and Agents access structured data insights.

Partner with Workday to simplify connecting AI Agents to work.

Partner with Palo Alto Networks to secure AI Agents in workflows.

Open APIs let customers export Context to company-wide AI projects—no data lock-in, no walled garden.

Essence of the Glean Route

Glean solves: "What does the enterprise know?" It weaves knowledge, people, and collaboration scattered across hundreds of apps into a queryable graph, upgrading AI from "understanding the world" to "understanding the company." This is a knowledge-centric route—build a shared company-wide knowledge foundation first, then layer search, assistant, and Agents on top.

Palantir Route: Turn Business into an Ontology

Core Philosophy

If Glean answers "what does the enterprise know," Palantir answers "how does the enterprise decide."

Palantir's core architecture is the Ontology—a governed, typed, living, bidirectional knowledge graph serving as the enterprise's authoritative digital twin. Palantir states: "Ontology represents the enterprise's decisions, not just its data."

Three Elements of Ontology

Unified design across three elements:

Data (Nouns): Objects and Links. Objects represent real-world entities (employees, equipment, trades, flights, patients); Links define relationships. This is the semantic layer.

Logic (Rules): Functions and Models. Business rules, ML models, optimization algorithms. Logic is bound to Ontology objects, not scattered across environments. This is the compute layer.

Actions (Verbs): Governed write-back operations. When a fraud analyst marks a transaction "confirmed fraud," the action executes as a governed, permissioned, auditable write-back through the Ontology. This is the execution layer.

"Databases or data lakes store information. Ontology explains what that information means and how each entity relates to others." — SuperML

AIP: When AI Connects to Ontology

Palantir AIP's key architectural decision: Agents natively perceive the Ontology. Agents query Object Types, not raw databases. Agents invoke governed Actions, not arbitrary operations. Agent outputs enter the Ontology's audit trail, not an unaudited void.

This fundamentally contrasts with typical enterprise LLM deployments. In traditional architectures, LLMs receive a pile of Context (documents, DB results) and produce answers. In Palantir's architecture, the LLM makes semantic decisions —it decides what "customer" means in this context, whether a subsidiary's trades roll up to parent exposure. These decisions belong to the semantic layer, not the language model.

When an AIP Agent queries "show all high-risk transactions linked to Customer X's household," the query resolves through the semantic graph—traversing household links, applying risk classification rules, returning a typed, bounded result set. The LLM's job is reasoning and communicating results, not constructing them.

Five-Layer Interaction Architecture

Palantir AIP's Agent-Ontology interaction decomposes into five layers:

Layer 1 Context Layer: System deterministically provides context; Agent does not "start blind." Layer 2 Query Layer: Agent actively queries objects and relationships. Layer 3 Logic Layer: Agent invokes functions, models, and business logic. Layer 4 Action Layer: Agent executes governed business operations. Layer 5 Governance Layer: End-to-end permissions, audit, and security constraints.

Key difference: queries operate on Ontology semantic objects and links, not SQL JOINs. The Agent's interface is business objects—"Shipment," "Carrier," "Warehouse"—not tables and columns. This lets LLMs drive queries via natural language reasoning rather than constructing SQL they are poor at.

Validation and Scale

Palantir's commercial validation comes from highest-stakes scenarios:

Lowe's runs a global supply chain digital twin on this architecture.

Defense agencies use Gotham + AIP in air-gapped networks for real-time threat analysis.

Fortune 500 manufacturers use HyperAuto to map SAP/Oracle tables to relational Ontology objects in minutes (not months).

March 2026 partnership with NVIDIA on Sovereign AI OS: Blackwell Ultra + Spectrum-X + Ontology.

UBS analysts note: "The Ontology layer is a key driver of competitive advantage," and "data mapping and decision mechanisms are highly complex, making the platform hard to replicate."

Essence of the Palantir Route

Palantir solves: "How does the enterprise run?" It unifies data, logic, actions, and security into a decision-centric semantic model, letting AI operate on a governed semantic layer instead of touching raw data directly. This is a decision-centric route—model the enterprise's operating mechanism first, then let Agents operate on top.

OpenAI Route: Complete Context Around Professional Tasks

Core Philosophy

If Glean enters from "knowledge" and Palantir from "decisions," OpenAI enters from "tasks."

February 2026, OpenAI published the Harness Engineering article. The team used Codex to build an internal product exceeding one million lines of code, almost no human-written code. They discovered the problem wasn't model intelligence but that the Agent's environment was insufficiently defined.

Core Findings from Harness Engineering

Three key findings:

Finding 1: Knowledge unavailable at runtime might as well not exist. Knowledge scattered in chats, docs, and heads must become Repository-local, Versioned Artifacts that Agents can read, verify, and execute. SOPs become Skills, business rules become Rules, operational experience becomes Playbooks, system capabilities become APIs/MCP/CLI.

Finding 2: Same model, different Harness, 3x capability gap. In ARC-AGI-3 testing, just two Harness designs—retained reasoning + context compaction—lifted GPT-5.6 Sol score from 13.3% to 38.3% while cutting output tokens ~6x. The model didn't get smarter; the system around it got better.

Finding 3: Harness is the real moat. What a team builds in six months of Skill libraries, Eval loops, Memory patterns, and permission structures does not transfer to a competitor who merely copies the model choice. Harness, not model weights, is the moat.

Ten Components of Harness

Industry consensus Harness includes ten components:

System Prompt (instructions), Tool Registry, Sandbox, Permission Model, Memory, Context Management, Sub-agents, Hooks, Observability, Evals.

Key design principle: Planner / Generator / Evaluator separation —planning, execution, and judgment separated to eliminate Agent self-scoring bias. This mirrors Palantir's Proposal-based pattern (AI proposes → human reviews → execute).

Agent Improvement Flywheel

OpenAI's May 2026 Agent Improvement Loop closes the Harness engineering loop into a five-stage flywheel:

Run Agent → Collect Traces → Attach Feedback → Generate Evals → Diagnose Patterns → Codex Handoff → Run Again

Each Agent run produces structured Traces; human and LLM attach feedback; feedback generates reusable Evals; Eval results prioritize Harness changes; Codex implements changes. SWE-bench improved 16 points purely through Harness improvements, zero model weight changes.

Essence of the OpenAI Route

OpenAI solves: "How to do this task well?" It does not first build a company-wide knowledge graph or enterprise Ontology. Instead, around concrete professional tasks, it layers in required Context—Metadata, semantics, knowledge, Memory, Runtime, Permission, Eval. This is a task-centric route—start from the task, build Context on demand.

Deep Comparison of Three Routes

Different Entry Points

Glean enters via enterprise search—employees "can't find things" is the most universal pain point. Solve information accessibility first, then add AI assistant and Agents.

Palantir enters via operational decisions—"how decisions get made" is the highest-value scenario. Build the enterprise decision semantic model first, then let AI operate on it.

OpenAI enters via professional tasks—"how to do this right" is the most concrete scenario. Build a solid Harness around high-frequency tasks like coding, then gradually generalize.

Different Context Organization

Glean uses Graph—entities are documents, people, projects; relationships are collaboration, references, participation. Leans knowledge graph, leans read-only analysis.

Palantir uses Ontology—entities are business objects (orders, customers, equipment), relationships are business relations, plus Actions (executable operations) and Logic (business rules). Bidirectional, living, writable.

OpenAI uses Harness—entities are tasks, tools, Skills; relationships are execution flows. Dynamically assembled per task, no pursuit of company-wide unified modeling.

Different Suitable Scenarios

Glean fits knowledge-intensive enterprises—consulting, tech, finance. Pain: "knowledge scattered everywhere, can't find or use it."

Palantir fits operations-intensive enterprises—manufacturing, logistics, defense, energy. Pain: "data exists but decisions can't land."

OpenAI fits engineering-intensive enterprises—software R&D, data analysis. Pain: "tasks doable but unreliable, non-repeatable."

How Enterprises Should Choose: Not Pick One, But Layered Combination

The three routes are not mutually exclusive. A mature enterprise AI architecture may need all three capabilities simultaneously:

Glean Layer: Enterprise knowledge search and AI assistant. Solves "what does the company know"—lets everyone quickly find documents, people, projects, best practices.

Palantir Layer: Core business operations Ontology. Solves "how does the company run"—lets AI make decisions and execute on a governed semantic model.

OpenAI Layer: Professional task Harness. Solves "how to do this task"—builds reliable execution environments around coding, data analysis, and other professional tasks.

Key judgment: not every business needs Ontology-weight. Knowledge search works with Glean-style Graph; core operational flows need Palantir-style Ontology governance and auditability; professional tasks need OpenAI-style Harness—lightweight but reliable.

Practical Recommendations

First, start from the deepest pain point. If biggest pain is "can't find things," start with Glean-style enterprise search; if "decisions slow and inconsistent," start with Palantir-style Ontology; if "professional tasks unreliable," start with OpenAI-style Harness.

Second, knowledge layer before decision layer. Glean-style knowledge graph investment is lighter, faster to value. Let AI "understand the company" first, then let AI "make decisions."

Third, build Ontology only for core business. Not all data needs Ontology-level semantic modeling. Build Ontology for core operational flows (supply chain, risk control, production); build Graph for knowledge management; build Harness for professional tasks.

Fourth, Context is a shared foundation, not silos. Whichever route, underlying data, knowledge, permissions, identity should be uniformly governed. Glean's open APIs, Palantir's OSDK, OpenAI's MCP all point the same direction: Context should be exportable, reusable, not locked in.

Conclusion: Context Is the Enterprise Moat in the AI Era

Though entry points differ, three routes converge on the same endpoint: Enterprise AI's core competitiveness lies not in models, but in Context.

Glean's Enterprise Graph proves: structuring enterprise knowledge creates $300M ARR and $7.2B valuation. Palantir's Ontology proves: semanticizing enterprise decisions serves highest-risk defense and finance scenarios. OpenAI's Harness Engineering proves: engineering the task environment triples the same model's capability.

Models can be rented, technology bought. What cannot be bought is your enterprise's decade-accumulated knowledge, processes, rules, decisions, and experience—they constitute Enterprise Context, the most durable moat in the AI era.

Common lesson from three routes: Don't start with "which model to choose"; start with "how to build my enterprise Context." Whether Graph, Ontology, or Harness, the core is turning the enterprise's own knowledge, rules, and experience into structured assets that AI can understand, consume, and execute.

Context first, Agents follow. This is the most pragmatic first principle for enterprise AI adoption.

References

Glean, Series F Announcement (2025.06) — https://www.glean.com/blog/glean-series-f-announcement

Glean, $300M ARR (2026.05) — https://www.glean.com/press/glean-surpasses-300m-arr

Glean, Enterprise Graph Guide — https://www.glean.com/blog/the-definitive-guide-to-ai-based-enterprise-search-for-2025

Palantir, Connecting Agents to Decisions — https://blog.palantir.com/connecting-agents-to-decisions-277dee8ddb40

Palantir, AIP Architecture Overview — https://palantir.com/docs/foundry/architecture-center/aip-architecture/

Palantir, Platform Overview — https://palantir.com/docs/foundry/platform-overview/overview/

Towards AI, Inside Palantir AIP — https://towardsai.com/p/machine-learning/inside-palantir-aip-how-the-worlds-most-controversial-ai-platform-actually-works

SuperML, Ontology: The Missing Semantic Layer — https://superml.dev/ontology-ai-palantir-enterprise-knowledge-graph-2026

OpenAI, Harness Engineering (2026.02) — https://openai.com/index/harness-engineering/

Saneel, Five Lines to Infinity (ARC-AGI-3) — https://saneel.xyz/collections/five-lines

Harness Engineering Complete Guide — https://amux.io/guides/harness-engineering

Codex CLI Agent Improvement Loop (2026.05) — https://codex.danielvaughan.com/2026/05/18/codex-cli-agent-improvement-loop-traces-evals-harness-engineering-flywheel

BCG, Which Companies Will Capture Value From AI (2026) — https://www.bcg.com/publications/2026/which-companies-capture-value-from-ai

Gartner, Enterprise Context Layer (2026.07)

Code example

Codex CLI Agent Improvement Loop (2026.05) — https://codex.danielvaughan.com/2026/05/18/codex-cli-agent-improvement-loop-traces-evals-harness-engineering-flywheel
BCG, Which Companies Will Capture Value From AI (2026) — https://www.bcg.com/publications/2026/which-companies-capture-value-from-ai
Gartner, Enterprise Context Layer (2026.07)