Pyrana vs Palantir AIP

Architecture

Palantir AIP and Pyrana are the closest pair in this library. Both treat AI as a participant in governed applications rather than a chatbot beside them. Palantir builds on the Ontology, a modeled operational layer of the enterprise inside Foundry. Pyrana builds on an App configuration that names the pages, operations, agents, and policies of one application, composed on a platform built once. The difference is where the model of the business lives.

What Palantir AIP is designed for

Palantir describes the Ontology as an operational layer for the organization that sits on top of data sources. It has semantic elements (object types, properties, and link types) and kinetic elements (action types and functions). AIP's builder tools, AIP Logic, AIP Chatbot Studio (formerly AIP Agent Studio), and AIP Evals, build AI-powered workflows, agents, and functions on top of the Ontology and Palantir's developer toolchain. Workshop builds interactive applications for operational users that read from and write back to the object layer. The result is an enterprise-wide model on which many applications can be built, and Palantir has years of production depth behind it.

What Pyrana is designed for

Pyrana is built once and configured per application. An application is one App configuration plus a frontend experience: declared pages (surfaces), operations (targets), versioned resources, agents, workflows, tool bindings, access profiles, and approval policies. Every call, from a page, the copilot, the API, MCP, a schedule, or an external event, passes the same eight-step gate. Pyrana does not ask the enterprise to model itself first. It asks what one application needs and configures that.

Two governed-application approaches

Pyrana's view is that both approaches are coherent. Palantir's front-loads modeling: integrate data into Foundry, map it to objects and links, define actions, then let applications and AI operate on that layer. Pyrana's front-loads the application: declare the surfaces, targets, and policies a process needs, bind tools that query data where it already lives, and let the shared platform supply identity, authorization, storage, orchestration, approvals, and audit. The first suits an enterprise that wants one operational model across many domains. The second suits an enterprise that wants governed applications on the data platforms it already runs.

Context and knowledge

In Palantir AIP, context comes from the Ontology: objects, their properties and links, documents, and the functions that compute over them. In Pyrana, structured data stays in source systems and is queried live, while business knowledge lives in cortIQ as typed, classified, evidence-backed Context Units, with what each run retrieved, injected, and cited recorded.

Data in place or data in the platform

Foundry integrates data through pipelines and maps it into the Ontology, which gives every application one consistent view. Pyrana agents query Databricks, Snowflake, ODBC, REST, and MCP sources through tools specific to the job: the agent passes the entity and the period, and the tool holds the query. The user's own principal passes through to Snowflake and Databricks, so warehouse row-level security applies to the same person.

Knowledge with provenance

cortIQ is built for the rules and policies an agent applies. Each Context Unit carries a claim, its evidence passage with source and location, a knowledge type, a classification that governs how it may change, and a content-hash identity. Changes supersede and never overwrite; regulated units wait for a person. Citations are content-addressed, so the exact business context used in a run is provable.

Agent capabilities

Palantir offers AIP Logic, a no-code environment for building, testing, and releasing LLM-powered functions that take Ontology objects as inputs and can make Ontology edits; AIP Chatbot Studio for interactive assistants that use the Ontology, documents, and tools; and AI FDE for operating Foundry in natural language. Pyrana agents are configured in plain language, belong to an App, and run inside durable workflows that fan out per entity.

Fan-out and durability

In Pyrana, one workflow dispatches many specialized agents per entity and group in parallel. Each pulls only what its job needs, reads what siblings and prior runs published, and publishes versioned resources back to the App. Workflows run on Temporal workers, so a run waiting on an approval survives a restart or deploy and resumes. Palantir's guidance points repetitive, well-defined processes to AIP Logic or AIP Automate rather than chatbots, which is a similar separation of conversational and procedural work.

Models

Palantir provides models from several providers inside AIP and lets customers self-host open-source or custom models through compute modules. Pyrana assigns a model per agent through adapters for Azure OpenAI, OpenAI, Anthropic, Fireworks, Google Gemini, and others, with the client's own keys.

Governed actions and approvals

Palantir governs writes through action types: a defined set of edits to objects, properties, and links applied as one transaction, with permissions, submission criteria, and side effects such as notifications. When AIP Logic is automated, edits can be applied automatically or staged for human review. Pyrana governs writes through targets and tool approval policies, which freeze the exact invocation and route it to a named lane.

Does Palantir AIP have human in the loop?

Yes. Staging AI-proposed Ontology edits for review is a documented pattern, and action types control who may make a change and under what conditions. This is a mature model for operational decisions on modeled objects.

What Pyrana adds to the approval

Pyrana's policy evaluates typed arguments: thresholds, membership, existence, and compound rules. When an invocation trips it, the platform freezes the operation, exact arguments, scope, and evidence under a hash and queues it to a named lane. Reviewer eligibility is checked at decision time, the frozen invocation is revalidated before dispatch, and dispatch is idempotent, so a retry reuses the receipt. The same policy applies to a page, the copilot, a workflow, or an outside agent over MCP.

Building the application

In Palantir, applications are built in Workshop on the Ontology, or as custom apps through the Ontology SDK. In Pyrana, the application is one App configuration and a frontend experience. The platform supplies the App shell, the copilot with exact page context, and personal pages that the copilot authors for one person, compiled without network or storage access and governed on every read.

Who builds it

Palantir's annual report describes embedding directly with customers and using AIP bootcamps to deliver real workflows on actual customer data in days; Palantir also employs forward deployed software engineers whose focus is "one customer, many capabilities." Pyrana is designed so a client team or partner authors the configuration. With clean data available, an application typically takes about a week to stand up, and the frontend experience is the main effort. Extensions give client-owned code a product boundary: a durable backend service in the same cluster, reachable only through the platform.

Governance and security

Palantir's platform security model governs AIP, and Palantir states that controls grant an LLM access only to what a task needs, with markings and classification-based access control for sensitive data. Pyrana enforces one authorization check per call, layered by tenant, App membership, access profile, and scope entitlement (OpenFGA), and writes the audit record before execution.

How each handles authorization

Palantir's documentation notes that row and column controls do not extend to model output or composed Ontology edits, and recommends markings for those cases. In Pyrana, unauthorized things read as absent rather than denied, reading a record and approving a change are separate permissions, and identity is explicit: an agent with its own identity, an agent on behalf of a user, or a workflow as a service principal, all on the same authorization path.

Operations

Palantir delivers software through Apollo, which its annual report describes as continuous delivery in the cloud, on-premises, or more rugged environments, and offers SaaS on AWS, Azure, Oracle, and GCP, a managed appliance, and self-hosted installations. Pyrana runs as SaaS on a dedicated private tenant or in the client's own infrastructure, on Temporal workers with separate pools for data fetching, file extraction, and the code interpreter.

Evaluation and change control

AIP Evals is a test harness for LLM-backed functions that compares results across versions. Pyrana captures every run's traces, tokens, and tool errors as JSON, runs deterministic checks first, then an LLM-as-judge stage in Agent Studio. Push compiles an immutable App version; activation is audited and requires an App owner; rollback is an activation of a prior version.

Cost structure

Palantir does not publish prices; contracts are negotiated, and AIP usage is tracked in Resource Management. Its annual report notes that pilots and bootcamps are often offered at low or no initial cost. Pyrana is enterprise platform pricing plus implementation. A first engagement, including SSO, access profiles, the approval policy, and loading the policy library into cortIQ, runs about six weeks.

What it takes to ship the same application

Reference application: an approval-gated procurement request. A person or agent drafts a purchase request; amounts above a threshold need a finance approver; the request waits durably for the decision; everything is recorded.

Palantir provides every layer here on one platform. The difference is the order of work: Palantir models the request in the Ontology first; Pyrana declares it in configuration and queries the data in place.

Using them together

An enterprise with Foundry can keep it as the operational model for the domains it already covers and use Pyrana for applications that sit closer to Azure, Databricks, or Snowflake. Palantir exposes the Ontology through platform APIs and the Ontology SDK, so a Pyrana App can reach Palantir data or actions as a tool source over REST or MCP, with every call admitted and audited. Pyrana's targets are reachable through its API and App MCP server.

When not to choose Pyrana

• You want one operational model of the whole enterprise that many applications share, and you are prepared to invest in building it.
• You need data integration, pipelines, analytics, and applications from a single vendor.
• You want vendor engineers embedded with your team to design and build the work.
• You operate classified, disconnected, or edge environments where Palantir's delivery model and accreditations are established.
• Your organization already runs Foundry broadly and the new application fits its existing Ontology.