An agentic pipeline is a chain of steps where a model decides something at one or more of them: which tool to call, what a document says, whether a result is good enough. Built well, it does in minutes what took a team days. Built loosely, it's a machine for producing confident mistakes at scale.
These six rules come from pipelines we've put into production. None of them depend on a particular model or framework.
1. Use rules first, models second, people third
Before you hand a step to a model, ask whether plain code can do it. Matching an ID, checking a total, validating a date format. Code is faster, cheaper and the same every time.
Give the model what code can't do: reading messy text, judging meaning, drafting language. Give people what neither should decide alone.
Most pipelines we build end up with more rule steps than model steps. That's a good sign.
2. Make each step do one narrow thing
A step that extracts fields, checks them against policy and writes a summary will fail in ways you can't untangle. Split it.
- One step extracts.
- One step validates.
- One step drafts.
Narrow steps are easier to test, cheaper to rerun and simpler to swap when a better model comes out. When something breaks, you know where.
3. Pass structured data between steps
Free text between steps is where pipelines rot. The next step has to guess what the last one meant.
Define the shape of each handoff: named fields, types, allowed values. Validate it in code. If a step returns something that doesn't fit, stop there. Don't pass the mess downstream and hope.
Keep the source location with every extracted value, such as the page, the row or the timestamp. You'll need it for review and for citations.
4. Add a second pass that checks the first
A model checking its own work in the same breath rarely catches much. A separate step with a different job does.
Give the checker the output, the source and a short list of things to verify. Let it return pass, fail or unsure, with a reason. On fail, retry once with the reason attached. On a second fail, send the case to a person.
Two passes cost more per case. They cost far less than a wrong answer nobody caught.
5. Set hard stops in code
Prompts are suggestions. Limits belong in code.
- A cap on steps and retries per case, so nothing loops forever.
- A cap on cost per run.
- A list of tools each step may call, and nothing else.
- Actions that change a record wait for a person to confirm.
If the agent hits a limit, it stops and says why. A pipeline that halts is annoying. One that keeps going is a problem. You can try an approval gate on our Diagnostic page.
6. Log the whole run
For every case, record the input, each step's output, which tools were called, what the checker said, who approved and how long it took.
That log answers the three questions you'll be asked: why did it do that, when did it start doing that, and what did it cost. It also gives you real failures to add to your test set.
Before you ship
Build a fixed set of real cases with known right answers and run the full pipeline against it on every change. Score each step, not just the final output. A pipeline can get the right answer for the wrong reason, and that kind of luck runs out. The method is in how to test an AI agent before production.
Start smaller than you want to
Pick one workflow. Build the rule steps first and see how far they get you. Add one model step where the rules run out. Add the checker. Add the stops. Then widen it.
We build agentic pipelines for document review, research and reporting, including agents on Palantir AIP and Foundry. If you have a workflow in mind, the Workflow Diagnostic measures it first.