What is Palantir Part 7: The AI stack that starts with your business

An enterprise AI pilot can answer a question well before anyone has worked out who will maintain it. There's the model to choose, but also the work around it: connecting business records, controlling access and testing changes.

You can build that stack outside Palantir Foundry. You'll need to manage conversation history and the tools an assistant calls. Once people use it, request limits and latency matter, and someone has to account for the cost.

The part I'd look at closely is how much business context you're maintaining twice. Supplier records and orders already exist across the systems running the company. Connecting them for an AI application also means carrying over their relationships and access rules. When those change, anything you've reproduced elsewhere needs attention too.

Earlier parts of this series built the foundation in a different order. Part 2 brought data into Foundry, which is the job a warehouse gets bought for. Part 3 modelled the business in the Ontology, a step without a neat product category.

Part 4 added analytics in place of a business intelligence stack. Parts 5 and 6 added applications and workflow. AI arrives after all of that, so what I want to work out is which AI components are still worth adding.

Model choice and boundaries

Foundry gives you four routes, which you choose per workload:

• The AIP Model Catalog, where the commercial relationship runs through Palantir. You accept a provider's terms, then enable or disable it. When we explored the catalog in our developer series, it included models from DeepSeek and Moonshot alongside the other providers.
• Your own model, reached through an external REST service or a Foundry compute module.
• Self-hosting, for open-source or custom models on your own infrastructure, including on-premise and air-gapped.
• A proxy or federation layer you build, which redacts, adds instructions or routes across providers behind one registered model.

The application doesn't need rebuilding each time you choose another provider. The prompt may need more work, because two models can read the same instruction differently. I'd rerun the application's tests after the swap.

The buyer sets the boundaries: model access, data residency, network controls, and the jobs a model handles. Foundry's access controls, encryption and auditing apply while those models run. Palantir says it secures technical and contractual guarantees from a provider before offering a hosted model. Those guarantees cover retention of prompts and completions, model training, and access by provider personnel.

In our developer series, we used a small Hugging Face model to classify sentiment. We packaged it in a Docker container, brought it into a compute module and exposed a function. We ran that function in Foundry and got a sentiment result back.

For forecasting I'd reach for a traditional model before an LLM, and the same goes for plenty of classification and regression work. Model Studio gives you a no-code route to it. For a shipment forecast, I'd use it to estimate the risk of delay before asking an LLM to explain the result.

Where AIP Logic fits

We ran an email-processing proof of concept, and AIP Logic is where that kind of job sits.

For anyone who writes code, the setup will look familiar: a function with inputs and outputs. You choose which tools the model gets and the actions it's permitted to take. A message goes in and the application gets an output it can use. You test the function before an application calls it.

In our AIP Chatbot Studio demonstration, we started with four PDFs and added tools for querying the Ontology. We could select actions we'd already built and make those available to the assistant. I kept coming back to giving the chatbot a specific job. Adding more documents and tools also gives it more to sort through.

The other tools handle scheduling and how people use the application:

• Automate watches a schedule or an Ontology condition, then submits an action or triggers Logic.
• For an open question, AIP Analyst searches the Ontology and builds object sets as it works.
• Workshop puts these tools beside the records and actions where the person decides.
• Realtime audio supports spoken interaction. Voice doesn't change the user's access permissions.

Access to a chatbot doesn't grant access to all the data behind it. The assistant still has to work within the user's permissions. For a supplier-switch assistant, that means retrieving the records the planner is allowed to see and configuring it to cite them. I'd have the assistant propose the switch, then require the planner's confirmation before the governed action runs.

The business view AI can use

A language model turns up knowing nothing about your suppliers, your open orders, or who's allowed to approve a change. Foundry's Ontology gives it business records to work with, along with their relationships and the actions available.

I'd model the Ontology around how the business looks at the organisation. Copying the source schema across is a mistake I would avoid in a first version. A planner doesn't care how many systems hold the supplier record. They care which plant it serves, which orders are open, and what they're allowed to do next.

Your first Ontology will need changes when real data lands. Say the business expects a column to be filled, but you find empty values. The access rules might need adjusting too. You fix the shared model, and the AI applications built on it use those corrections.

Testing a change

When we tried Model Catalog's comparison screen, a participant asked whether the answers were grounded in our Ontology. We were testing a generic prompt there. To judge the application, we needed to run it with its actual business context and tools.

We also ran the same Logic function against two models using AIP Evals, comparing correctness, duration and token use. Those last two matter when deciding whether a model is worth using for the job.

Anyone who has written a business rule will recognise the idea of keeping tests with the code. With a model, the answer's wording can vary across runs. The tests need to check whether business rules and approval requirements hold. I'd keep those tests with the function after deployment.

With reusable cases and evaluation criteria, you can:

• Compare two providers on the same cases.
• Check a proposed version against the one already running.
• Run the same input repeatedly to see how much the answer moves.
• Rerun all of it after someone changes the prompt or a tool.

What production adds

Foundry's production controls cover:

• Ontology and AIP observability provides execution history, metrics, traces, logs and Workflow Lineage. A reviewer follows a wrong action back through the run that produced it.
• LLM capacity management sets token and request limits at enrollment and project level.
• AIP token usage shows consumption by model and resource, so an owner can see which applications account for the usage.

AIP Evolve takes a function or workflow, an improvement goal, and a way to validate the result. AI FDE agents try candidate changes and come back with a proposal and the evidence behind it. A person decides whether to accept it.

The part I find useful

You may keep your own model gateway or specialist tools alongside Foundry. I'd look at what they add once the business records and governed actions are already available.

In the final developer session, we watched AI FDE inspect the existing Ontology before proposing a solution design. It worked from resources we'd already built. Later in the session, we reviewed a generated application that still needed real data connections and cleanup before production.

Part 8 moves to what developers build inside and outside Foundry: Developer Console, OSDK and MCP, then Pilot and AI FDE.