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

An enterprise AI programme often follows a familiar path:

• Choose the models. Select one provider or several, open or closed models, and hosted or self-hosted deployment. Add data retention, residency, and network boundaries.
• Choose the operating layer. Use the provider's framework or build a layer for routing, conversation history, tools, and guardrails.
• Connect the data. Build retrieval pipelines, map business records into context, expose tools, and reproduce access rules.
• Prove the pilot. Test a narrow application on controlled questions, then build production confidence across models, prompts, tools, and wider use.
• Meet production. Manage concurrency, latency, cost, evaluations, and traces.
• Maintain another representation. Keep the AI stack's mappings, permissions, tools, prompts, and test cases aligned with the systems people use to run the company.

Each step is reasonable on its own. Together they can create a second model of the business that must stay in sync with the first.

The earlier parts of this series built the other way round. Part 2 brought data into Foundry. Part 3 modelled the business in the Ontology. Part 4 added analytics. Part 5 added applications. Part 6 added workflows.

Now we can ask the practical question. How does Palantir handle all six on one operational foundation, and which step becomes smaller?

Foundry brings those decisions together on one operational foundation. Companies can choose models, build the operating layer, connect AI to the business, test behaviour, and run production while keeping each use case connected to the same model of the business.

1. Choose the models and boundaries

Foundry turns model choice from a series of provider projects into a portfolio decision. A company can use available closed and open models through one governed access layer, choose the best model for each job, and change that choice without rebuilding the application around another provider.

• One governed gateway to many models. For Palantir-provided models available through the AIP Model Catalog, the commercial and integration relationship runs through Palantir instead of becoming a separate provider project. Teams can mix closed and open models, then use the right one for each workload.
• Bring another model, including on your infrastructure. Companies can bring their own model through an external REST service or a Foundry compute module. Foundry's self-hosting path lets open-source and custom models run on customer-controlled infrastructure, including on-premise and air-gapped deployments.
• Insert your own control layer. A customer-built proxy or federation layer can redact sensitive data, add instructions, translate provider API formats, or route requests across providers behind one registered model based on cost, latency, or availability.
• Models don’t train on your data. AIP applies Foundry's access controls, encryption and auditing to model use. Before making a third-party-hosted model available, Palantir says it secures technical and contractual guarantees that the provider will not retain prompts or completions, use them for training, or give its personnel access.

Not every problem needs a large language model. Forecasting demand, predicting failure, or classifying risk may be better suited to traditional machine learning. Model Studio provides a no-code route for forecasting, regression, and classification. One model could produce a slip-risk signal; an LLM could then explain it or help the user act on it.

2. Build the operating layer

Once a company chooses a model, it still needs context, tools, guardrails, conversation handling, and a surface for the user. Foundry provides those pieces around the model.

• Build a repeatable assistant. AIP Chatbot Studio creates assistants that can use Ontology objects, documents, and custom tools.
• Put business rules in a controlled function. AIP Logic combines models, tools, conditions, and actions inside a tested function.
• Automate when conditions are met. Automate checks time-based or Ontology conditions continuously or on a schedule, then submits actions, triggers Logic or Foundry functions, or sends notifications.
• Investigate an open question. AIP Analyst can search the Ontology, create object sets, transform data, and produce summaries or visualisations from natural language.
• Place AI inside the operating application. Workshop puts the assistant beside the records and actions where the decision happens.

The choice depends on the job. A defined, repeatable task fits Chatbot Studio or Logic. An open investigation fits AIP Analyst. A decision inside an operating screen fits Workshop. Consequential actions can require user confirmation, while Logic keeps business rules in a tested function instead of hiding them in a prompt.

These different user experiences share one business foundation, governed data, and reusable context.

3. Connect AI to the model of the business

Language models understand language; the Ontology gives them context about how the company works.

Foundry's Ontology turns connected data into a model of the business: objects, relationships, actions, and permissions, kept current by pipelines. AI can use that shared context to reason across the company, retrieve only what the user may see, cite supporting records when configured, and use governed actions with confirmation when needed.

The shared Ontology lets that business context be maintained once and reused across AI applications.

4. Prove behaviour before production

A useful demo establishes the use case. Production confidence requires repeatable testing across prompt edits, model changes, tool failures, and wider use.

AIP Evals turns expected behaviour into reusable test cases and evaluation criteria. Teams can use it to:

• compare models;
• test variation across repeated runs;
• compare a proposed version with the current version; and
• rerun the same checks after later changes.

An evaluation suite gives the team a repeatable standard for comparing models and approving later changes.

5. Run and improve the production system

Production adds concurrency, capacity limits, latency, cost, failures, and the need to explain what happened. Foundry keeps those controls beside the applications and models that create the work.

• Trace an answer. Chatbot Studio records executions as structured events. Ontology and AIP observability adds metrics, execution history, distributed traces, logs, and search through Workflow Lineage.
• Protect capacity. LLM capacity management controls tokens and requests per minute at enrollment and project levels.
• Attribute cost. AIP token usage shows consumption by model and resource, so owners can see which applications create the bill.
• Improve the system without tuning blind. AIP Evolve starts with the function or workflow to improve, a goal such as lower cost, lower latency, or a better evaluation result, and a validation strategy. Groups of AI FDE agents explore candidate changes, test them against those checks, and return a proposal with the evidence for a person to review before accepting it.

6. One business, not two

Buyers still choose the models, boundaries, permissions, tests, and operating limits. What becomes smaller is the sixth step from the opening: building and maintaining another version of the business just for AI.

Foundry keeps models, assistants, tools, objects, actions, permissions, evaluations, and traces connected to the same company model. The AI sees the same business that the applications and workflows see, and works through the same governed actions.

Data, analytics, applications, workflows, and AI can build on one company model instead of each carrying its own.

Part 8 covers how developers build applications on all of this, inside and outside Foundry: Developer Console, OSDK, and MCP for custom applications, Pilot for generating them, and AI FDE for helping developers explore, build, and test changes faster