Three Ways to Ask

My abstraction. I use documents_search, ontology_search, and function_search as plain names for three retrieval modes. These are not official Palantir tool names. Document and object search exist in my prototype; discoverable function search is future work.

Suppose I ask an agent, “Is this appliance still under warranty, and what should I do next?”

The agent may need the warranty document, the appliance's current fault history, and a calculator that applies the coverage rules. Those are not three versions of the same search. They are three kinds of knowledge.

If the agent sends everything to document retrieval, it may find a policy and miss the current object. If it only inspects objects, it may see a green status without the evidence behind it. If it writes new checking logic, it may duplicate a function that already exists.

This search is for explanations, policies, research, meeting notes, manuals, and prior decisions. It should return passages with citations and enough source context to judge freshness and authority.

For the warranty question, it might retrieve the receipt, policy, and repair manual. Its answer is narrative: here is what the relevant material says, and here is where it came from.

My existing knowledge systems already do versions of this through keyword, semantic, and graph-aware retrieval. The important contract is that an excerpt remains attached to its source.

This search is for objects, properties, state, and relationships. It can answer which appliance failed, when it was bought, which repairs were recorded, which warranty covers it, and who owns the next decision.

In my local prototype, this capability appears as object search followed by explicit link traversal. I call the broader idea ontology_search because the agent is querying the model of the world rather than passages about it.

The result should be structured enough to drive the next step: stable identifiers, typed properties, named relationships, and the actions available on the object.

This search is for capability. It should help the agent discover a tested function for calculating coverage or comparing repair cost with replacement cost before it invents another implementation.

A useful result needs more than a function name. It should include the input and output contract, version, owner, test status, permission boundary, and examples of where the function is already used.

I have a versioned function registry in the prototype, but the agent cannot yet search it as a first-class tool. This part is a design direction, clearly ahead of the current implementation.

Real tasks use more than one route. The warranty question may start with the appliance object, retrieve the policy, find the coverage calculator, run it, and then prepare a repair decision for review. The sequence matters because each result narrows the next choice.

Giving an agent three tools does not tell it when to use each one, how to combine their results, or when to stop and ask for authority. That is the role of the coordination layer.

Palantir uses AIP for this part of its platform. The next essay explains the pattern without treating AIP as magic and without claiming my research prototype is the finished product.

• Previous: When the Work Should Continue Without You
• Next: How AIP Puts the Pieces Together
• Related: From Company Knowledge to Verified Changes