Palantir Unifies Three Agent SDKs on Ontology: The Stable Enterprise Foundation

On July 9, 2026, Palantir released three TypeScript agent templates—for the Claude Agent SDK, OpenAI Agents SDK, and Google ADK—that share a common project structure, parameter schema, default MCP configuration, and publishing workflow. Crucially, Palantir did not merge the frameworks; each template preserves its native agent loop and tool-definition style. The Google ADK template even routes model calls through a Foundry language-model proxy, eliminating the need for a separate Google API key.

01 Palantir Standardizes the Enterprise On-Ramp, Not the Frameworks

The templates unify the "outside-the-framework" concerns: how to obtain an Ontology SDK client, how to connect to Ontology MCP and Palantir MCP, how the platform supplies scoped credentials, and how a published agent is invoked from Workshop, OSDK, or Automate. The upper-layer frameworks remain swappable, while the underlying business objects, Actions, permissions, and runtime state do not need rebuilding every time the framework changes.

02 Why Ontology Becomes the Stable Layer for Enterprise Agents

Models understand natural language but not how a specific enterprise operates. A database row is just fields to a model; in the business it may represent an overdue order, a risky supplier, or a machine awaiting repair. Enterprises must further define object relationships, current states, allowed actions, and which identities may execute them. Palantir Ontology provides this mapping: object types, properties, and links describe the "nouns" and their relations; Actions define governed business mutations and execution processes; Functions encapsulate reusable logic callable by Actions or applications. Actions emphasize controlled state changes; Functions are closer to pure computation units.

When an agent works through Ontology, it sees not raw tables but a semantically rich, constraint-aware enterprise world. For example, an agent can read an order and its linked inventory, call a query function to compute impact scope, and—if a state change is needed—must invoke a pre-defined Action that is guarded by permissions and application restrictions. This goes beyond traditional RAG, which only answers "what can be retrieved." Ontology answers "what does the data mean," "how are objects related," and "which actions may execute." For production agents, these questions are often harder and more decisive than improving retrieval recall.

03 OSDK, Ontology MCP, and Palantir MCP Solve Three Distinct Problems

Palantir's templates expose all three interfaces, which are easily confused but serve different users and execution paths:

OSDK targets application code. Developers select object types, Action types, and query functions to generate an SDK bound to a specific Ontology, then use a typed client to read or write Ontology data. This suits tasks where code explicitly controls queries, parameters, and call order.

Ontology MCP targets the running model. Adding the Ontology SDK creates an Ontology MCP that exposes the same object types, Action types, and query functions as MCP tools the model can discover and invoke. The agent can read objects and query data; write operations go through pre-defined, allowed Actions—not arbitrary database writes.

Palantir MCP targets platform construction. It gives AI IDEs or developer agents access to Foundry context and platform tools: inspecting code repositories, data transforms, and Ontology structure; creating or modifying object types, link types, Action types, and Developer Console applications. Palantir MCP can change Ontology structure but cannot write actual business data; controlled production reads/writes belong to Ontology MCP.

Thus a single enterprise agent chain may contain two kinds of "action": a runtime business agent mutates order or ticket state via Ontology MCP, while a developer agent modifies code, fixes Transforms, or extends Ontology types via Palantir MCP. One does work inside the enterprise system; the other builds the platform that enables that work.

04 Permissions and Action Boundaries Are Pushed Down to the Platform

The most dangerous moment when an agent enters an enterprise system is not a wrong answer but an unauthorized read or an illicit write. A prompt instruction like "do not modify closed orders" is not a reliable production guardrail. Palantir supplies scoped permissions out of the box: the platform issues credentials for OSDK, Ontology MCP, and Palantir MCP at agent creation, and the template resolves service endpoints and authorization headers at runtime—no manual Client ID, Client Secret, or Foundry Token in agent code.

Platform-managed credentials do not grant unlimited access. The official documentation states that an agent can only reach resources allowed by its scope, which is determined by the Ontology binding chosen at publish time and the underlying client's Application Restrictions. Architecturally, this means critical permission boundaries no longer rely solely on prompts; they are pushed down to Ontology resources, application restrictions, Action permissions, and submission conditions. The model may propose an action, but whether it can read a given object type or invoke a specific Action is still decided by platform resources and identity permissions.

This design explains Palantir's emphasis on Ontology. Model vendors change, but orders, customers, devices, approval workflows, and permission systems have longer lifecycles. As long as these business contracts stay stable, enterprises can swap agent frameworks without re-wrapping the entire action layer.

05 Published Agents Behave Like Async Business Functions

Palantir's current Agents capability is not a real-time chat product. Every agent must be bound to an Ontology at publish time and receive an Agent API name (defaulted from the repository name, but editable). Once published, Foundry registers the agent as an asynchronous function. The recommended invocation path is via Automate, though Workshop, OSDK, and Ontology Actions can also trigger it. A typical flow: an Ontology object changes, Automate fires the agent; the agent receives the object primary key, re-reads the object and related context via OSDK or Ontology MCP; the model reasons and calls governed tools; finally the result is written back to Ontology.

Palantir illustrates this with a claims-dispute example: a denied claim triggers an agent, which reads the claim details and denial reason, generates an explanation and remediation suggestion, and writes the result back to the claim object. The agent's output becomes new state in Ontology, ready for downstream applications and processes.

Current limitations are explicit: the agent function returns Void and cannot serve as a query function returning direct results; streaming and batch calls are unsupported. Therefore, Palantir advises writing execution results, conversation logs, or evaluation outputs back to Ontology objects for subsequent reads by applications or workflows. This makes the agent more like an "async business function with model reasoning" than a chat interface. From this write-back pattern, Ontology emerges as a state-exchange, memory, and tracking layer between agents, applications, and headless agent workflows—a role the Ontology MCP documentation explicitly describes as the "Headless Agent's Memory and Tracking Layer."

06 What This Update Really Changes

Viewed only as a developer-tool update, this is "three new templates." From an enterprise-architecture perspective, it signals that Palantir does not intend to compete with Claude Agent SDK, OpenAI Agents SDK, or Google ADK at the framework layer, but to become the shared enterprise action foundation they all depend on. Historically, each new agent framework forced enterprises to rewrite data-access layers, tool wrappers, authentication, permission checks, and state write-backs—creating fresh silos as models and frameworks evolve rapidly. Palantir moves the common pieces into Ontology, OSDK, MCP, and the publishing runtime, letting frameworks focus on reasoning loops and tool orchestration.

This does not make framework migration a one-click operation. The three templates still differ in agent loops, tool definitions, and MCP return types, so migration requires adapting the integration layer and re-testing execution behavior. What is reduced is the need to re-understand every underlying table, re-model objects, re-encapsulate business actions, and rebuild a separate permission system for each framework.

For enterprises, models may change due to capability, cost, compliance, or vendor strategy; agent frameworks may churn with ecosystem competition. What deserves long-term maintenance are the business objects (orders, customers, devices), their relationships and states, which actions can run automatically versus requiring human approval, and how every action is audited.

07 Three Remaining Hurdles Before Production

Beta maturity: The Agents capability is still in Beta, may not be available in all Palantir environments, and its feature boundaries will shift. Enterprises planning production use must factor in stability, regional availability, and version compatibility.

Framework neutrality ≠ platform neutrality: Enterprises can choose Claude, OpenAI, or Google frameworks on Palantir, but business objects, Actions, permissions, and publishing flows become deeply tied to Palantir Ontology. This reduces lock-in to a single model or agent framework while further embedding the enterprise action layer in the Ontology platform.

Templates cannot replace Ontology engineering: Enterprises must still define which objects are trusted, how the same entity across systems is unified, which Actions can run automatically, which parameters must be validated, and which steps need human approval. Wrong object definitions, vague action boundaries, and over-broad permissions will not disappear because MCP is connected; they may be amplified when agents execute automatically.

Data governance for external models: When Ontology MCP connects to externally hosted models or MCP clients outside Palantir AIP, enterprise data may leave the environment. Model deployment location, data-governance policies, resource-exposure scope, and audit requirements must be designed alongside the agent architecture—not patched at launch.

Conclusion: The Stable Core of Enterprise Agents Is Not the Model or Framework

Over the past year, most attention in the agent space has focused on model reasoning, tool calling, and multi-agent orchestration. But when agents enter real enterprise processes, the hardest part to replicate is not a single inference—it is the business world behind it. That world requires explicit definitions of what objects exist, how they relate, what state they are in, which actions can execute, and who may execute them under what conditions. Claude, OpenAI, and Google can supply different agent "brains"; Palantir aims to guard the object, permission, state, and action layer that all these brains will depend on once inside the enterprise. Models and frameworks will keep changing rapidly. For enterprise agents, the truly stable part may be exactly the business reality that Ontology represents.

References

Palantir July 2026 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