Every tax season, a life and annuity insurer's service center fields the same three kinds of questions. Contract holders want the year-end fair market value of an annuity, an explanation of a 1099, or the required minimum distribution they have to take before a deadline. The answers sit in contract data the insurer already holds, but service reps had to assemble them from several systems and then word a tax-adjacent answer without crossing into tax advice. The insurer wanted an assistant that drafts each answer from its own records and stays inside what each role is allowed to see and say.
The assistant runs on Palantir Foundry and AIP. Our team mapped each data point the tax use cases needed, from year-end contract values to the inputs behind a required minimum distribution, to the insurer's existing contract and customer APIs, so the assistant answers from system-of-record data. We wrote the role-based access model and the guardrail rules for each user role, which set what the assistant may retrieve for a given user and how far an answer may go on a tax question. We also built a library of real service questions with expected answers, and every prompt revision was tested against it before a rep saw the result.
Discovery came first. The team wrote the use cases and scoping documents with the business leads who own the answers, and the backlog ran in two milestones with weekly status reports and a biweekly product call across the insurer's business and technical teams. Business leads validated answers against the test library, and go-live testing began about eight weeks after kickoff. The team stayed through refinement, working the defects and edge cases that live use surfaced.
Service reps have one place to ask a tax-season question and receive an answer drafted from the insurer's own contract data, limited by their role. The test library turns every future prompt or model change into a regression test, so the insurer can confirm that known-good answers still hold before a change reaches the service floor. The mapping from the tax use cases to the contract APIs is documented, which gives the next AIP use case a starting point instead of a blank page.
Client details in this case study are generalized, and in places combined across engagements, to protect confidentiality. The approach is the one our Palantir AIP and forward deployed engineering team brings to assistant builds, and our guide to what Palantir AIP is explains where the platform fits. Carriers weighing similar work can also look at our insurance software development practice, which covers the systems around it. We are glad to walk through comparable work under NDA.
