Palantir AIP Agents: How to Build Them With Logic, Chatbot Studio, Tools, and Evals

Last updated: October 8, 2026

By Omar J, Director, PAL4C Labs

TL;DR In Palantir AIP, agents are built from AIP Logic functions, AIP Chatbot Studio (the product formerly called Agent Studio), and pro-code agents written with SDKs like the Claude Agent SDK. They work through Ontology tools such as Actions and object queries, get tested in AIP Evals, and run on demand or through Automate. Start with one Action a person would approve, and build the eval set before the agent. That’s how our Palantir Foundry and AIP implementation team runs every agent build.

Agent Studio doesn’t exist anymore. Not under that name, anyway.

Palantir’s documentation now says plainly that AIP Chatbot Studio was previously known as AIP Agent Studio, and that AIP Chatbots were previously AIP Agents. Meanwhile the word agent has moved to something else entirely, code-first agents you write with an SDK and publish as a Foundry function. Most articles about Palantir AIP agents still describe the old setup, which is why teams show up to their first build confused about which tool to open.

This guide sorts that out. It covers the five ways to build an agent in AIP today, when each one fits, how tools and permissions keep agents from doing damage, how to test them with evals, and how AIP compares with Microsoft Copilot Studio and Salesforce Agentforce. It’s written for data and operations leads who need an agent that changes a decision, not a demo that answers trivia. If you’re earlier in the journey, our Foundry and AIP delivery work starts with picking that decision.

What Changed When Agent Studio Became Chatbot Studio?

Only the name and the meaning of the word agent. Chatbot Studio is the same interactive builder, renamed. In current Palantir docs, agent mostly refers to pro-code agents built with SDKs and published as Foundry functions.

The renamed product still does what Agent Studio did. You build a chatbot, give it retrieval context and tools, pick a model, and deploy it inside the platform or externally through the Ontology SDK and platform APIs. Old links redirect. Old screenshots mostly still hold.

What’s new is the code path. Palantir’s pro-code agents documentation describes a pro-code agent as custom logic written in a Foundry code repository and published as a Foundry function, and it supports the Claude Agent SDK, OpenAI Agents SDK, and Google ADK. So a team that already writes agents in Python can bring that skill into Foundry rather than rebuild everything in a visual editor.

Why does a rename matter? Because search results, vendor decks, and internal wikis now use three vocabularies at once. Before your first build meeting, agree on terms. It saves an hour of crossed wires, minimum. Our AIP and AI agents practice uses the current Palantir names throughout, and so does the rest of this post.

What Are the Five Ways to Build an Agent in Palantir AIP?

AIP Logic for structured LLM functions, AIP Chatbot Studio for conversational assistants, Automate for triggered runs, pro-code agents for SDK-built logic, and Ontology MCP for agents outside Palantir. Most production setups combine two or three.

Pick by the job, not the tool. AIP Logic is documented as a no-code environment whose functions take inputs like Ontology objects or text, return outputs, or make edits to the Ontology. That’s the workhorse. Most of what people call an agent in a Foundry deployment ends up as a Logic function, sometimes wrapped in a chatbot so a human can talk to it.

Pro-code agents are for the cases where a visual block editor gets in the way, like long reasoning loops, custom retries, or a team that already has an agent framework it trusts. Palantir notes that because these agents use scoped permissions, you don’t need to hand them a client ID, secret, or Foundry token. That’s a bigger deal than it sounds. Hardcoded secrets in agent code are a classic way to fail a security review.

Then there’s MCP. Palantir’s docs distinguish Ontology MCP, which enables controlled writes to Ontology data, from Palantir MCP, which lets external AI IDEs and agents work with Ontology structure. Different jobs. Mixing them up gives an outside agent more reach than you meant to grant.

AIP Analyst sits slightly apart. It’s an agentic interface for ad hoc analysis across the Ontology in natural language, good for exploration and less suited to production workflows that need the same answer every time.

How Do You Build a First Agent in AIP Chatbot Studio?

Create the chatbot, add retrieval context and application state, attach tools, choose a model, write the system prompt, set temperature, publish, and monitor. A first working version usually takes hours. Making it trustworthy takes longer.

Palantir’s getting started guide walks through the same core sequence. Here it is with the decisions that actually matter at each step.

1. Create the chatbot and give it one job. A dispatch assistant, not an operations assistant.
2. Add retrieval context. Documents, object types, or both. Less is better. An agent with 40 PDFs attached retrieves noise.
3. Connect application state if it lives inside a Workshop app, so it knows which shipment or patient the user is looking at.
4. Attach tools, starting with read-only object queries. Add Actions last.
5. Choose a model from what your enrollment allows.
6. Write the system prompt. Say what the agent must never do before you say what it should do.
7. Set temperature. Palantir’s range runs 0 to 1. For operational work, stay low.
8. Publish to a small group and watch the conversations for a week.

Step 8 is the one teams skip. Don’t.

The quality of everything above depends on the objects underneath. If the Ontology doesn’t model a Shipment with clean links to its Truck and Lane, no prompt will fix it. Our explainer on how the Palantir Ontology works covers object types, links, and actions in more depth.

Which Tools Can an AIP Agent Use, and Which Ones Are Risky?

Chatbot Studio supports Action, Object Query, Function, Update Application Variable, Command, and Request Clarification tools. Read-only queries are low risk. Actions change data, so they deserve confirmation steps, tight scopes, and the most testing.

Palantir’s tools documentation also describes two calling modes. Prompted tool calling works with any model. Native tool calling allows parallel calls but only on specific models and for four tool types. Don’t assume your favorite model supports native calling for the tool you need. Check first.

Actions are where the line gets drawn. A Palantir Community thread describes two behaviors. In one, the agent pre-fills the Action and asks the user to confirm. In the other, it applies the Action automatically. Start everything in the confirm mode. Every single time.

The same principle holds outside chatbots. AIP Logic lets Ontology edits be applied automatically or staged for human review, and Automate lets you decide whether consequential changes should be staged for review. Staging is cheap insurance. If you need help deciding which actions an agent should be allowed near, that’s a core part of our Ontology design and engineering work.

How Do You Test an AIP Agent Before Anyone Trusts It?

Use AIP Evals. Build a suite of test cases with expected outcomes, run your Logic, Chatbot, or code-authored function against them, score the results, and rerun whenever you change the prompt, tools, or model.

AIP Evals is documented as a testing environment for AIP Logic functions, AIP Chatbot functions, and code-authored functions. A suite holds test cases, the target function, evaluation functions that score each output, and metrics. Same idea as unit tests, adapted for outputs that aren’t perfectly deterministic.

Is this extra work worth it? Look at the odds. Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, citing costs, unclear business value, and inadequate risk controls. And McKinsey’s State of AI research found 23% of organizations scaling an agentic AI system somewhere, with no more than 10% scaling agents in any single function. Plenty of pilots. Few that stick.

Evals attack two of Gartner’s three reasons directly. They prove value with numbers instead of vibes, and they catch risky behavior before users do.

What goes into a good first suite? Fifty real cases is plenty to start, pulled from the decisions people actually make, including the awkward ones. A shipment with a missing arrival estimate. A request the agent should refuse. A user asking for something outside its permissions. Then run the same suite on two or three models, because the cheapest model that passes is the one you want in production.

Write the suite before you write the system prompt. It sounds backwards. It isn’t.

How Do You Choose a Model for an AIP Agent?

Choose from the models your enrollment and region allow, then let your eval suite decide. Palantir’s Model Catalog includes OpenAI, Anthropic, Google, and Mistral models, plus some hosted by Palantir, with availability varying by region and accreditation level.

Palantir’s Model Catalog lists providers including OpenAI, Anthropic, Google Gemini, and Mistral AI, and notes that some models, such as Llama and Mixtral, may be hosted by Palantir itself. The supported LLMs page shows that availability varies by region and enrollment, including separate lists for government impact levels. A model your colleague uses in a U.S. commercial tenant may not exist in your EU or IL5 environment.

Cost matters too. AIP converts tokens into compute-seconds, with output tokens costing several times more than input tokens, so a verbose agent costs more than a terse one on the same model. Our breakdown of Palantir Foundry pricing and compute-seconds shows the per-model math.

Short version. Shortlist two models, run the evals, keep the cheaper one if it passes.

What Does a Real AIP Agent Look Like? A Dispatch Example

A dispatch agent reads shipments, trucks, lanes, and warehouse status from the Ontology, recommends whether a truck should leave or wait, and lets the dispatcher approve. It’s the pattern behind our logistics decision intelligence work.

This one’s illustrative, built from the dispatch scenario on our logistics decision intelligence page rather than a specific client’s numbers.

The decision is the oldest one at a cross-dock. Leave now, or wait for more volume? The objects are Shipment, Truck, Lane, Facility, Load, and Dispatch Event. Here’s how we’d wire it.

• A Logic function takes a Load, queries linked Shipments and their expected arrivals, checks Lane congestion and historical fill, and returns a recommendation with reasons. Say, hold 45 minutes, fill rises from 72% to 91%.
• Chatbot Studio wraps that function so a dispatcher can ask why, or what happens if the truck waits 20 minutes instead.
• One Action tool, Hold Truck, in confirm mode. Nothing moves without a click.
• Automate runs the Logic function every time a Load crosses 60% fill, so recommendations arrive before anyone asks.
• An eval suite of past dispatch decisions, including ones where the experienced dispatcher overrode the obvious answer.

Notice the order. Data and objects, then a function, then the chat layer, then automation. The most common failure we see runs it backwards, starting with a chatbot and discovering later that the arrival estimates don’t join to the loads.

Our own production proof sits a layer down. For a global logistics operator, we unified 18 disconnected warehouse and inventory systems into a Foundry Ontology and put AIP forecasting agents on top that trigger procurement actions. Procurement delays fell 34%, and the client saves $12M a year, per our Foundry case studies. The agents were the visible part. The 18 systems were the work.

How Does AIP Compare With Copilot Studio and Agentforce?

All three build agents with tools and guardrails. The difference is grounding. AIP agents work over a Foundry Ontology of operational objects, Copilot Studio over Microsoft 365 and connected sources, and Agentforce over Salesforce CRM and Data Cloud.

Microsoft describes Copilot Studio as a graphical, low-code studio for building and managing agents and workflows, with agents that draw on connected knowledge sources and use tools to take action. Salesforce’s Trailhead material explains Agentforce grounding through Data Cloud and actions built on existing platform features.

So which one? Ask where the decision’s data lives. If it’s in Salesforce, Agentforce is the shortest path. If it’s in email, Teams, and SharePoint, Copilot Studio. If the decision crosses an ERP, a WMS, a TMS, sensor feeds, and a few legacy databases, and changes need to be written back with a permission trail, that’s the job AIP was built for.

We’re a Palantir shop, so weigh our view accordingly. I’d still tell a sales team living entirely in Salesforce not to buy Foundry for this. More on AIP’s place in the stack in our guide to what Palantir AIP is.

Why Do Palantir AIP Agent Projects Stall?

Usually for reasons that have nothing to do with the model. No owner for the decision, no eval set, Actions switched to automatic too early, and Ontology objects that don’t match how the business talks.

Four patterns show up again and again.

The agent answers a question nobody asked. Someone builds a clever assistant for a team that never requested it, it gets a polite launch, and usage flatlines after three weeks.

Evals arrive after the incident. The agent runs fine for a month, then a prompt tweak breaks an edge case and there’s no suite to catch it. Trust goes, and it doesn’t come back quickly.

Too much autonomy, too soon. An Action flips to automatic because the demo went well, and the first wrong edit lands in a system of record. Recovery takes longer than the build did.

And the quiet one. The Ontology calls something a Consignment when the people using it say Load. Small thing? Users stop trusting the agent’s answers because it doesn’t sound like it understands the work.

Most of these get caught in operations, not development. Monitoring, eval reruns, permission reviews, and model updates are part of our platform operations and MLOps work for exactly that reason.

Start With One Action You’d Let an Agent Propose

Three points to keep. Agent Studio is now Chatbot Studio, and agent increasingly means pro-code work. Logic functions do most of the real reasoning, with chatbots and Automate on top. And evals plus confirm-mode Actions are what separate an agent people trust from one they quietly ignore.

PAL4C Labs is a Palantir-exclusive consultancy that builds Foundry pipelines, Ontologies, and AIP agents for logistics, supply chain, healthcare, and regulated operations teams. We measure the work by the decision it changes.

Pick one Action you’d let an agent propose, like holding a truck, flagging a supplier, or drafting an appeal. Bring us that and the data behind it, and we’ll scope the tools, permissions, and eval suite with you before anyone writes a prompt. Our AIP agent development services page shows how the build runs from there.

What Builders Ask About AIP Agents

What Happened to AIP Agent Studio?

AIP Logic vs Chatbot Studio, Does the Difference Actually Matter?

Can an AIP Agent Edit Data in the Ontology?

Which LLMs Can You Use in Palantir AIP?

Palantir MCP vs Ontology MCP, What’s the Real Difference?

Can I Build a Palantir Agent With the Claude or OpenAI SDK?

How Do You Run an AIP Agent on a Schedule?