How Palantir Unifies Claude, OpenAI, and Google Agents on a Shared Ontology

On July 9 2026 Palantir announced three Agent SDK templates for Claude Agent SDK, OpenAI Agents SDK, and Google ADK. Rather than merging the frameworks, the templates share project structure, parameter schemas, default MCP configuration, and publishing processes, while preserving each framework’s native agent loop and tool definitions. The key innovation is the standardization of the layer outside the frameworks: obtaining the Ontology SDK client, connecting to Ontology MCP and Palantir MCP, managing scoped credentials, and defining how published agents are invoked by Workshop, OSDK, or Automate.

01 – Palantir unifies the enterprise entry point, not the frameworks

Enterprise agent development is rapidly diversifying. Claude Agent SDK uses a query‑function‑driven loop, OpenAI Agents SDK relies on primitives such as Agent and run, and Google ADK organizes execution with Agent and InMemoryRunner. Palantir’s update does not eliminate these differences; the three TypeScript templates share structural elements but keep each framework’s native loop and custom tool syntax. The Google ADK template even invokes Gemini via the Foundry LLM proxy, avoiding a separate Google API key.

02 – Why Ontology becomes the stable enterprise layer

Large language models can parse natural language but do not inherently understand enterprise operations. A database row may represent an overdue order, a risky supplier, or a device awaiting repair. Ontology defines object types, attributes, and links that describe these business nouns, as well as Action definitions that govern controlled state changes and Function units that encapsulate reusable logic. When an agent works through Ontology, it interacts with semantically rich entities rather than raw tables, enabling actions such as reading an order and its inventory, computing impact via a query function, and invoking a pre‑defined, permission‑guarded Action to modify order status.

03 – OSDK, Ontology MCP, and Palantir MCP solve three distinct problems

OSDK targets code: developers select object types, actions, and query functions, generate a typed SDK bound to a specific Ontology, and use it to read or write data programmatically.

Ontology MCP serves the running model: after adding the Ontology SDK, Palantir creates an MCP that exposes object types, actions, and query functions as discoverable tools for the model. Write operations are performed via defined Actions, not by granting the model unrestricted database write access.

Palantir MCP focuses on platform construction. It provides AI IDEs and agent developers with access to code repositories, data transformations, and Ontology structures, and can modify Ontology schemas. However, it cannot directly write business data; that responsibility belongs to Ontology MCP.

04 – Permissions and action boundaries are truly scoped

The most hazardous part of agent integration is not a mistaken answer but unauthorized data reads or prohibited actions. Palantir supplies out‑of‑the‑box scoped permissions: the platform creates the necessary credentials for OSDK, Ontology MCP, and Palantir MCP, and the template resolves service addresses and auth headers at runtime, eliminating manual handling of client IDs or tokens. Nevertheless, agents operate only within the scope defined by the bound Ontology and application restrictions, ensuring that permissions are enforced by the platform rather than by prompt engineering.

05 – Published agents behave as asynchronous business functions

Agents are not real‑time chat interfaces. Each agent must be bound to an Ontology and given an API name before publishing. Once registered, Foundry treats the agent as an asynchronous function. The recommended trigger is Automate, though Workshop, OSDK, and Ontology Actions can also invoke it. A typical workflow: an Ontology object changes, Automate triggers the agent, the agent reads the object via OSDK or Ontology MCP, performs model inference, calls a controlled tool, and writes the result back to Ontology.

Palantir illustrates this with a claims‑dispute handling example: a rejected claim triggers the agent, which reads claim details, generates an explanation and remediation suggestions, and writes the outcome back to the claim object. Current limitations include agents returning void, lack of streaming or batch calls, and the recommendation to write results, logs, or evaluations back to Ontology for downstream consumption.

06 – What truly changes with this update

Beyond adding three templates, Palantir signals its intent to become the common foundation for Claude, OpenAI, and Google agent frameworks. Previously, each new framework required rebuilding data access layers, tool wrappers, authentication, permission checks, and state‑write logic—creating “silos.” Palantir moves the shared components into Ontology, OSDK, MCP, and the publishing runtime, allowing frameworks to focus on inference loops and tool orchestration. Migration still demands adapting loops and testing, but the burden of re‑modeling business objects and redefining permission structures is reduced.

07 – Production considerations

Agents are still in beta, with limited environment availability and evolving feature boundaries. Enterprises must plan for stability, regional availability, and version compatibility. While the framework‑agnostic layer reduces vendor lock‑in, business objects, actions, permissions, and publishing workflows remain tightly coupled to Palantir Ontology. Robust Ontology design—defining trustworthy objects, unified identities across systems, clear action permissions, and audit trails—is essential; poor definitions can be amplified by automated agents.

When Ontology MCP connects to external models or MCP clients outside Palantir AIP, data may be exposed to external systems, requiring careful governance, resource exposure policies, and audit requirements integrated into the agent architecture.

Conclusion

The most durable element for enterprise agents is not the model or the SDK but the business reality encoded in Ontology: objects, relationships, states, and governed actions. Palantir’s approach anchors diverse agent brains to a shared, stable execution layer, ensuring that as models evolve, the core business semantics remain consistent.

References

Palantir 2026‑07 announcement: Build, configure, and ship pro‑code agents

Palantir Agents Overview

Palantir Agent Templates

Palantir Scoped Permissions

Palantir Publish and Call an Agent

Palantir Agents Use Cases

Palantir Ontology MCP Overview

Palantir Ontology MCP Example Workflows

Palantir MCP Overview