Vishesh Patel and Anchey Peng, engineers at Palantir who lead AI work with civilian agencies, walk through how they build agentic workflows for the IRS that hold up in production. Using a composite example of taxpayer correspondence, they contrast a naive build (one agent, one large prompt, a RAG index over a thousand-page rule book, and direct calls into legacy systems) with the architecture they run today. That version turns the rule book into a decision tree of deterministic rules and narrow LLM nodes, grounds every step in a governed semantic layer, tests each node with evaluations and unit tests, and stages every action for an examiner to review. They tie it back to three tenets: replicability through determinism, context through a semantic data layer, and accuracy through evaluations.

Vishesh Patel:

Hey, everyone. My name's Vishesh. I'm an engineer, technical lead at Palantir. I'm joined by my fellow colleague, Anchey, and we're engineers at Palantir who've been leading our AI work, especially related to our partnerships with civilian agencies. This past year, we've been partnering with the IRS to bring agentic workflows into the compliance space. Think fraud detection, case selection, tax processing, the whole shebang. And the IRS is at the forefront of AI adoption when it comes to Palantir's partnerships with civil agencies. I'm sure you've all seen crazy AI demos, things moving around screens, people interacting with chatbots, agents summarizing series of documents. Those are all useful, useful demos, but that's not the topic of our conversation today. We want to show you how to build complex AI workflows that hold up in production and actually become a part of the lives of daily users and workflows. As you all know, the bar is higher in government.

Workflows must run reliably and produce results that people can verify. And there's a lot of failure modes that can happen when trying to first build AI and introduce it to an agency. Imagine I run an AI workflow on some input and it outputs some answer, but then tomorrow I run the same AI workflow on the same input and I get a different incorrect answer. It's going to result in users stop trusting the platform and stop trusting AI. We also shouldn't be giving agents free rein to take catastrophic actions on their own. One bad result, one bad letter to a taxpayer or one incorrect adjustment to someone's taxes is an irreversible action that is damage and would result in the agency losing trust in AI. So we've built our architecture around three major tenets to prevent these hazards from happening.

Anchey Peng:

So these three tenets, which we'll explain more throughout the talk, the first is replicability through determinism, followed by context through a semantic data layer, and finally, accuracy through evaluations. At Palantir, we don't believe that AI proficiency just comes from the model provider you use or the specific model you're using. Models are only a component in a larger system. Lasting value comes from what you build around the model, how decisions route through it, and how humans stay accountable for their actions. We tend to follow a general principle when introducing AI agentic workflows to a new agency. Pick a workflow where you already know what strong human performance looks like. This way, you can compare the human performance to human assisted with agentic performance and measure the same task and see that it's done faster and more accurately. You can't encode determinism into a process you don't understand.

So it's important to keep this in mind when you're choosing a workflow, you want to move into the AI agentic space.

Vishesh Patel:

So today we're going to go through a fictional composite example that we have come up with that's pretty adjacent to what we already have in production at the IRS today. So as you may know, taxpayers are able to send mail to the IRS. The first question that comes to mind is what are taxpayers actually sending to the IRS and why are they sending those things? These taxpayers can be sending a wide variety of mail. They could be agreeing to a change in their taxes that the IRS is proposing. They could be disagreeing to a change in their taxes that the IRS is proposing. They could be reporting identity theft that their identity was stolen. They could be requesting a change or amending their tax return. They could be adding a dependent, changing their address or anything else tax related. And mail imposes few constraints. People could be submitting incomplete forms or not attaching the appropriate forms for what they're trying to accomplish.

And sometimes these correspondences are just notes scribbled on like a post-it note. What does the examiner have to do when they receive this mail? Well, they have to potentially read tens of hundreds of pages of taxpayer correspondence. They have to then go look at a thousand page rule book on how they should process this correspondence. They have to then look up the taxpayer's account, their previous filings, their previous encounters and correspondence with the IRS in legacy systems, potentially many of them, and then they have to come to a corrective final action, whether it be making an adjustment to the tax return of the taxpayer, sending another letter to the taxpayer, or rerouting the case to a different team. These complex cases It can take hours. And most of the time is spent actually reading the correspondence, reconciling against this thousand page rule book, and then actually looking up the taxpayer's history in these legacy systems, reconciling all those things and then taking the corrective action in the legacy system.

I think the key point here is the examiner's judgment is not the bottleneck. It's all this document review, rule checking, reconciliation, and operational steps that are required. And we're going to show you an architecture for how to build this using AI. One, in a potentially not ideal way, and once in the way that we've done it in production over the last year.

Anchey Peng:

First, we'll start with the naive build. This is an architecture that might work for a demo or for a hackathon, but it'll never hold up in production. There's four main components to this architecture. First, there's a single agent with one large prompt. The entire taxpayer submission is passed in as a PDF for the agent to analyze. Secondly, the agent has a RAG index over the rule book. You chunk the rule book, embed it and store it in a vector database that the agent can query. Third, you give the agent read tools. The agent can query legacy databases to pull information like the taxpayer's account history, their previous filings, or even previous correspondence. And finally, you give the agent right tools. The agent can decide what to do and when. The agent can execute all those authorized actions that was just mentioned. It can send a letter to a taxpayer or makes a tax adjustment.

Essentially, this is a closed loop system. You get one thing in and one thing out. You pass in the entire submission PDF to the agent and it thinks, it consolidates information, and then it arrives to conclusion and takes that final action. Now I'll walk through what this actually looks like in an end-to-end execution. So again, the taxpayer submission comes in as a big scanned PDF file. The agent will begin to extract it to try to figure out what's going on. It pulls in relevant data and it tries to determine what the taxpayer is claiming and why they sent this in. Then the agent performs semantic search using RAG and other tools to find the most relevant procedure and then begins to follow that procedure. It calls tools to read legacy systems, pulling in taxpayer information, pulling in past filings like their address, their previous tax return, information like that.

Every time the agent looks up data, it has to contend with a legacy system structure. It has to figure out what payload to use, how to translate various terminology between what it sees on paper to what it sees in the legacy system. And finally, the agent consolidates all this information together. It pulls in all that information from the rule book, the filing, the past information, and makes a final determination. In this case, let's say it applies an adjustment to the taxpayer account. Now let's say we run the same agent the next day on a very similar submission, but this time the agent pulls in a few different rule book pages. It pulls in a few different parts of the taxpayer's history and arrives at completely different conclusion. Small details like what rule book page you read or what taxpayer history you pull in can have a drastic change in the final determination.

And this is a major problem, of course.

Vishesh Patel:

Yeah, that sounds like an awful architecture. So let's talk about why specifically this architecture would never work in production. The first is we are inevitably going to reach an accuracy ceiling. One prompt has to catch every single edge case. Every failure that happens in production, the engineers just go in and add an extra line to the prompt like please do not make a mistake or make sure you check every single requirement in the rule book. The prompt keeps growing, it consumes more context window and accuracy ends up plateauing. And the team at the end of the day is just prompting their way out of what is in fact an architectural problem with few ways to actually isolate and fix the part that failed. Also, rules aren't interpreted consistently. That's not a guarantee. There's no guarantee that the model checks every single requirement that the rule book requires for that correspondence, that it actually queries the right source system or actually verifies the account details that the rule book is saying is required. Let me give you an example. Let's say from the time of the last filing to the time of when the taxpayer submitted this correspondence, their address changed and the rule book says to check that. If the model doesn't check every single time that if the taxpayer's address has changed and the model decides to send a new letter to the taxpayer, that letter could go to the wrong address, which is a catastrophic action. Another problem is that rule books aren't self-explanatory. They need agency context. These tax examiners have been working at the IRS for numerous years and have tons of subject matter expertise that they've encapsulated. We need to be able to encapsulate that into the workflow. The other problem is the legacy system structure. At inference time, this agent has to come up with the payload and interact back and forth with what are age old legacy systems.

It has to come up with the payload. It has to know what cryptic IDs, keywords and field names mean. And I'll give you another example of that. Let's say there's a encoding of 000 on the taxpayer's account. Well, a subject matter expert, a tax examiner might know that that means identity theft, but the agent might not know that. And sure, we could chuck the entire data dictionary of the legacy system into the prompt, but that just eats context and it doesn't guarantee that the agent actually knows that that code 000 corresponds to an identity theft flag.

The fourth problem is giving full autonomy to an agent can erode trust at an agency. Let's say hypothetically the agent hallucinates and starts sending letters to everybody here in the audience. That would end up with the agency losing trust in AI as a whole. And once an error like that hits a taxpayer, it's irreversible damage. All of these four issues I think reduce to one common problem, which is that this architecture doesn't work and that it's an unreliable and unscalable architecture. It doesn't adapt to, it doesn't scale to large submission sizes of taxpayer correspondence. It doesn't scale to a large number of taxpayer correspondence. It doesn't scale to the complexity of the rule book or the complexity of the payloads and the responses of the legacy system. There's no evaluation loop. There's no semantic data layer. There's no way for engineers to actually improve and have an objective way of knowing if a change to the prompt or anything actually helped or if performance is drifting.

Operational failures are also ignored. What happens if a model provider is down? There's no retries. There's no runtime guaranteeing that every submission actually gets a response, which is paramount in government. If one taxpayer correspondence comes in and there's no response to it, that's catastrophic action. There's also a model provider risk. What happens if a model provider deprecates a model or reprices their model to increase costs? We have no way of knowing if we can substitute a different model or different model provider in this architecture. And the root cause is treating the LLM as the whole system instead of one component inside of a larger system.

Anchey Peng:

Great. Now we'll talk through how this architecture can be improved. This starts by turning the rule book into what we call a decision tree. This requires forward deploying, working directly with the users to understand what the tax examiners do and how they do it. This includes learning all the practical and tribal knowledge they've accumulated over the years and converting this into actual code and logic. AI can help here. Coding agents can help write functions and write rules based on what they're seeing. And you can also use agentic LLMs to understand the rule book, to read it easier and to pull out insights. Models can extract the fields from letters and forms, but ultimately you need to try to use as many deterministic functions as you can to actually apply those rules to what you're seeing. The rule book becomes a set of version testable functions rather than just a large prompt and rag.

When the rule book changes year to year, a coding agent can prepare a PR and draft that for review. Then engineers and policy agent, sorry. Agency policy experts can work together to review that PR. The rule book and tree always stay combined and they always stay synchronized. Now I'll walk through an execution on this decision tree. It's a little bit hard to read, but each of these steps is mapped out on the tree. First, the taxpayer submission arrives. It's a whole scanned PDF again, but this time we break that PDF into individual scanned image pages. We rotate, apply D Skew and other transformations to make sure those are as clean and readable as possible. Then we do a first classification pass. We turn that PDF and submission into a table of contents by classifying each page and to figure out what the taxpayer has actually submitted.

Then we go through and extract the fields from the forms and letters. We pull out information like the SSN, the name, various dollar amounts. We save that information into a governed semantic layer. This ensures that the schema is unified across years. The Form 1040 potentially the taxpayer just submitted will now save the exact same schema that they submitted their previous year's Form 1040. With the semantic layer, the agent is then able to form a consolidated view of the taxpayer. They're able to see their past filings, they're able to see their current filings and the submission altogether without having to query various legacy systems. Then the agent can move on to deciding what this is actually about, what the taxpayer is claiming using a mix of deterministic and LLM steps. And I'll give you two examples here. Let's say a taxpayer submits a form 14039. This is a form that indicates the taxpayer believes their identity has been stolen.

So now you could implement a deterministic rule. If the taxpayer submits a 14039, you know they're claiming identity theft. On the other hand, maybe the taxpayer just writes, "Oh, I think my identity has been stolen. I don't think I owe this much money," in the margin of one of their forms. Normally a tax examiner would catch this. In the previous architecture, maybe the agent doesn't, but now with a deterministic rule, you can check for conditions like this. An agent will read that and also know this taxpayer is claiming their identity has been stolen. So you have two different approaches, but you arrive at the same conclusion. Once you're able to figure out what the taxpayer is actually claiming, you have to apply some rules to actually figure out what to do. That goes back to pulling in the rule book and encoding that into a set of rules.

So again, let's say the taxpayer has submitted a change of $43,000 to their adjusted gross income and the model has extracted this already. Then we can compare this with their previous filings. Let's say there's a $10,000 increase in their AGI. We can run a tax calculator to find out how much additional tax they owe and then stage this as a recommendation. The agent will always produce a recommendation in this architecture. It provides evidence, it provides reasoning, and it provides a full trace of how it went through that decision tree to arrive at that conclusion. And rather than taking the action, the agent will present it for a tax examiner to review. The tax examiner can review all this evidence and they can choose either to reject or accept the decision. If they reject the decision, they have to provide feedback and this eventually improves the agent over time.

If they accept the recommendation, then this writes back to the source system and closes out the case.

Vishesh Patel:

Awesome. So let's talk about why this architecture actually works in production. The first thing is that decision tree, right now I've taken that thousand page rule book and I've actually composed it into a verifiable lineage where I can track exactly what steps the agent took to come to an action. And that decision tree is composed of both deterministic rules and also LLM nodes where a large language model is actually needed. And that's the key principle. Only use LLMs where they're actually needed. Don't use an LLM for deterministic logic. Use it for judgment calls that actually require reasoning that can't be expressed as code. Don't use it for deterministic checks like matching fields or checking against dollar thresholds, like doing math, which is what the single naive agent that we used in the first architecture was forced to do. When an LLM is necessary, always give it the smallest scope, the smallest decision to make with only the data and tools that it actually needs.

The second principle is that we used a governed semantic layer, what we at Palantir call the ontology. It gives the workflow a consistent vocabulary for case context and authorized actions. So now the agent and the tax examiner have the same view of the world. The agent is no longer coming up with confusing payloads or reading confusing responses from the legacy system. Instead, it sees the data the same way that the tax examiner sees it with a form 1040, a tax return, a tax module, a taxpayer, et cetera. Lastly, we want to also make sure that we use the right model for the right task. We want to always ensure that we're using the fastest, cheapest model for any of the LLM nodes. And that's what we term to be the KLLM approach, right model at every node tested at every single layer. Model selection is empirical. We at Palantir, Anchey and I, forward deployed engineers, we actually sit with tax examiners and build hundreds of real test cases with known answers. We start with the model that clears the bar for sure and then work down until accuracy drops to optimize speed and cost. Because every single node in the decision tree is bounded, we can tune it independently without regressing the rest of the nodes. And we should only be using frontier models for genuinely work that requires a lot of reasoning and whether they're actually needed.

We have three test layers. We have evaluations per each LLM node in the decision tree, unit tests for every single deterministic node, and then end-to-end integration test to make sure that the entire decision tree flows as planned. Why does this matter? It allows us to cut costs. It allows us to avoid lock into one model provider, which is critical in FedRAMP environments where model availability is constrained. It also opens the door for people to build their own models, bring their own weights, a term we call AI sovereignty. It makes the question of whether the AI is good away from a vibe check or a feeling and more into a metric that oversight teams can actually govern against.

And the last important principle is that we always stage actions for human review. That decision tree just produces a recommendation and stages the write-back action of sending the letter or making the exact adjustment. It doesn't actually take the critical action itself. It writes a proposed action to a staging area where an examiner comes in, looks at this purpose-based interface, corrects anything that's wrong, and then actually clicks to write to the production system. The job of the examiner has totally changed though. Before they would spend hours reading the correspondence, looking up the information in the rule book. This job was only possible by examiners who have spent years training, but now it's a 10 minute judgment call where all the information is presented to them, they can see and trace the lineage in the decision tree, and the true hours actually go to super specific edge cases instead of retyping account details, doing all this research and reading messy handwriting.

Every correction they make becomes a new evaluation case for us to train the decision tree, for us to look at each node in the decision tree and write new evaluations. The last point I want to highlight on the slide is that all this stuff, this decision tree, this KLM approach, it all only works if you use a durable runtime that's actually designed for agents. Real cases at the IRS stay open for days or weeks. We often have to wait for a taxpayer to respond. Sometimes the model provider might be down or the model provider might be rate limiting you. You have to have retries in your runtime to ensure that every single correspondence eventually completes, that you get eventual success, even if it takes a while.

Anchey Peng:

Great. Now let's tie this back to the three tenets we talked about originally. Replicability through determinism is achieved by that decision tree architecture. Rather than a single giant prompt, we have a set of specialized agents, each with their own narrow task, tailored prompt, and clearly defined scope. Each of these can be tuned and evaluated independently. The model no longer has to deal with an entire rule book at runtime. Every decision point has a clear node in the tree, a mix of deterministic and mix of LLM nodes. When something goes wrong, you can simply adjust a node or add a new branch. There's far more levers now to add incremental improvement to this pipeline. Secondly, context through a semantic data layer ensures that agents get the context they need rather than having to improvise calls and figure out how to deal with a legacy system. There's a shared vocabulary which grants a precise understanding of previous filings, account data and correspondence.

This removes the ambiguity and decouples the workflow from legacy systems. This also provides an abstraction layer. Let's say those legacy systems go away in five or 10 years, your agent workflow doesn't go down now. You can use this abstraction layer to swap out some data behind the scenes and the agent is just as good as it was before. And finally, accuracy through evaluations was achieved through that KLM approach Vishesh was talking about. Rules as code plus bounded model steps guarantee the same submission produces the same recommendation, whether you run it today, tomorrow, or even after you swap some models out. The system will log every single model, prompt, extraction in every branch it takes so you have full traceability. If you want to review a result eight months later, you can now look into the logs and replay the actual record. You don't have to just guess about what happened.

Vishesh Patel:

Awesome. So this table on the screen summarizes the difference between the naive build and the build that actually works. And I think the key things to highlight are the fact that the rules aren't just found at semantic time at the inference time. They're not codified version deterministic. One model doesn't do everything. We're using the best model and the cheapest and fastest model that has the best accuracy constraints for each task. Now we have a clear lineage. If we were to run the same input twice through this decision tree, we'd be guaranteed to get the same answer. Legacy systems are no longer being called via confusing payloads and responses. We're not using a governed semantic data layer in ontology to abstract that information away from the agent. The agent's not directly writing to production and examiners reviewing and making sure that what the actions that the agent is recommending are correct. Quality is not a vibe check. We're writing evaluations. We're making sure that everything is as best as compared to the golden data sets that we've generated. Failure handling in the naive build was a prayer. Now we have retries a durable runtime that's guaranteed to eventually succeed and the human, the tax examiner is not replaced. Their workflow has been accelerated from before taking hours to now minutes. To close out, the demo was never the hard part. I'm sure we could give an enterprise large language model to a 15-year-old kid and they could cook up a great demo. The real test is 10,000 correspondences a day with 10,000 different decisions, the terribly formatted submission that needs rotation and enhancing, and the review that needs to happen eight months later to make sure that the AI actually took the right action on each correspondence. AI in the government space isn't judged in some sandbox.

It's judged by the worst case scenario and at the highest scale. And the failure mode is using the LLM as a standalone system. It's just the model to make decisions for the government autonomously. The better outcome is AI that helps the government make decisions more consistently, faster, and with a complete trail that a human can review. What does this mean? Deterministic rules where answers should be deterministic, tailored models where judgment is actually needed, a durable runtime where we're guaranteed that eventually these correspondences are processed, a complete lineage for every recommendation and a human click before any critical action is taken. At Palantir, we believe there's a super big difference between an impressive demo and a system that actually survives contact with the mission. So really appreciate you guys listening to us today and yeah, we'll be in the back if you guys have any questions.

‍