Palantir AIP makes it quick to stand up an agent on top of your Foundry ontology. That speed is the point, and it's also the risk. An agent that can read every object and run every action is easy to build and hard to defend when someone asks what it's allowed to do.
These are the five controls we set before an agent reaches real users.
1. Give the agent the smallest slice of the ontology that does the job
Start from the task, not the data. If the agent answers questions about work orders, it needs work orders and the two or three object types linked to them. It doesn't need the whole ontology.
A narrow scope does two things. Answers get better, because the model isn't sorting through objects that don't matter. And the blast radius of a bad answer shrinks.
The platform's existing permissions and markings still apply to the person using the agent. Confirm that with a test: run the same request as two users with different access and check that each sees only what they should.
2. Treat every action as a decision someone owns
Reading is low risk. Writing is not. For each action the agent can propose or run, decide three things:
- Who is accountable for it.
- Whether a person must confirm it before it applies.
- What validation the action enforces on its own, no matter what the model says.
Our default: anything that changes a record a person relies on waits for that person to confirm. Put the rules in the action itself, so they hold even if the prompt changes.
3. Version prompts and logic like code
A prompt edit is a production change. Keep prompts, tool descriptions and logic in a registry with a history: who changed what, when and why.
Promote changes through the same path you use for pipelines. Build on a branch, review, then release. When an answer looks wrong next month, you can see exactly what the agent was running that day.
4. Build the evaluation set before you build the agent
Collect 25 to 50 real requests with the right answer for each. Include requests the agent should refuse and requests where the data doesn't support an answer.
Run that set on every change to a prompt, a model or the ontology. Compare case by case, not just the average. A change that fixes five cases and breaks two needs a person to look at the two.
We walk through the full method in how to test an AI agent before production.
5. Log usage and review it weekly
Turn on logging from the first pilot user. You want the request, the objects retrieved, the actions proposed, what the user accepted and what they rejected.
Rejections are the most useful signal you'll get. Each one is a free test case. Review them weekly for the first two months and add them to the evaluation set.
What to watch for after launch
- Scope creep. Someone asks for one more object type, then another. Each one is reasonable. Re-run the evaluation set every time.
- Tool growth with no owner. New functions and actions appear and nobody knows who maintains them. Keep a simple list: tool, owner, last reviewed.
- Ontology changes upstream. A renamed property can quietly break an agent. Put the agent's evaluation run in the release path for ontology changes it depends on.
The point
None of this slows a team down much. Scope, owned actions, versioning, a test set and logs take days, not months. What they buy is an agent you can explain to a program lead, an auditor or a new engineer.
We build and run AIP and Foundry agents as a subcontractor on federal programs. See how we approach it under Palantir Foundry & AIP or, if you're a prime staffing this kind of work, on our federal and teaming page.