How to write AI agent prompts for AML investigations
A guide to Unit21's Agentic Task Builder, and what separates a good prompt from a vague one
When AI tools first arrived, getting a good answer took technique. Prompt engineering was the name for it: careful phrasing, ordered steps, incantations like "take a deep breath and work through this step by step." Then the focus moved outward to context engineering, less about the sentence you type than everything the model can see when it answers.
Either way, some basic principles hold. Say what you actually want, give the model enough to work with, check the output before you trust it. Frontier models have gotten better at figuring out what you mean, which also makes them better at confidently proceeding when they don't know. In compliance, that's a decision about a customer with no record behind it.
Alongside that, most regulatory evaluation frameworks are currently model-centric. How was the model trained, is your data being used to train it, how does it score on bias evaluations. Those are all worth asking. The more common reality is application-centric: nearly every AI product here runs on existing foundation models, ours included, because several different models, each tested for the one component of analysis it handles, beat asking one model to do everything.
What an auditor wants is something explainable, and that's your AI Agent configuration. Almost every problem customers hit comes down to whether the agent could reach the right data and whether the instructions were any good. An AI Agent is only as good as the context it's given, and the prompt is where most of that gets set.
What an AI task is in Unit21
An AI task is one analysis step in an investigation. You configure it once and it runs the same way across every alert, case, or filing you assign an AI Agent to review. You can chain several tasks onto one agent, and run several agents across your environment.
Unit21's Agentic Task Builder is where they get written, and it covers two kinds. Data Analysis works on a customer's own data inside Unit21. Online Search goes out to the open web. Same builder either way, and the difference is where the data comes from.
What follows is how that plays out in Unit21, plus what I've learned building tasks alongside customers.
The three layers of a Data Analysis task
A Data Analysis task is three layers, and most of the skill is knowing which layer an instruction belongs in.
Data gathering is deterministic. The prompt becomes a SQL query that pulls specified fields and runs identically every time. It also runs any calculations (since LLMs are generally not the best at math).
Data summary is where the language model comes in. A language model reading what came back and saying what matters about it, which is what models are actually good at. It won't state a figure it wasn't handed, and it describes scope qualitatively.
The narrative provides finalized analysis and decisioning across tasks. After your tasks run, narrative instructions shape the final write-up: your structure, your tone, cross-references between findings. It's the most precise layer, because it's the only one that sees everything at once.
The order of specificity I recommend: broad with your data gathering, specific with your data summary, exact in the narrative.
An extra field when instructing data gathering adds a column nobody reads. On the other hand, a missing field leaves the summary with nothing to work from, and no ability further down the chain to recover it with the same configuration. If the email address never got pulled, there's no finding about the email address.
What good AI agent instructions have in common
Four things, and the ones I see go wrong are almost always missing one of them.
The number. "Suspicious," "high risk," and "large" carry almost no information, and they mean one thing at your institution and another down the street. A team that cares about wires over $9,000 within three days of account opening is better off saying exactly that.
The time frame. "Recent" isn't a window. Ninety days is.
The data fields to pull. Be generous, for the reason above. Think of it as pointing in the direction you want: "pull all associated entity fields," "pull all transaction information," etc.
Include what the write-up should contain. What it shows, grouped how, ordered by what. This is the one that gets skipped most, and it's the hardest for the builder to infer, because there's no obviously wrong answer for it to bump into.
How the builder reviews your prompt and asks questions
Before building anything, an LLM reviews the prompt for three of those four: a missing number, a missing range, an unclear write-up. It also flags ambiguity in the data, like several fields holding a phone number. Then it asks, or rewrites the prompt for you to approve.
Data fields are the one gap it can't catch, since nothing in a sentence signals what got left out. When it does ask, that's the system working, surfacing a gap before it hardens into a decision.
No prompt review catches everything, though, which is why the builder has you validate against real alerts before anything goes live. The alerts you pick for that matter more than people expect.
Why to test an AI task across multiple alerts
The failure I think about most, because sometimes the prompt is fine.
A customer built a task to flag physical and email addresses on the flagged entities tied to flagged transactions. Right fields, right intent, clearly written. They previewed it on one alert, it looked correct, they turned it on. That alert happened to have a single flagged entity, so the query handled one entity at a time. Against production alerts carrying several, it did what it had been built to do and missed most of them.
Nothing about the wording changed. Same prompt, wider set of test alerts, and the query came out flexible enough for the real range.
The builder writes against whatever evidence it's given, so a sample of one produces something shaped around a coincidence. What I recommend is picking alerts that differ from each other, including the awkward ones. The more thorough you are up front, the less QA you inherit later.
Advanced prompt controls: field tagging and split instructions
None of what follows is required. A plain natural language prompt works, and it's what I recommend starting with. These are the levers for when you want more control.
Typing @ in a prompt lets you tag the specific data objects and fields you want referenced: Entities, Transactions, Instruments, and the individual fields on each. Worth doing when a name is ambiguous, or when the field is one of your own custom ones rather than a standard one.
Clicking Add data gathering instructions splits the prompt in two, so you write the gathering half and the summary half separately instead of letting the builder divide one paragraph. Online Search has its own controls for search terms, match strictness, and how results get ranked.
A newcomer can write a paragraph and ship a working task. Someone further along can reach for all of it. Whatever the comfort level, there's a way to build your own AI workforce.
What a prompt can't override
We meet with regulators including FinCEN regularly and build around their recommendations, so what the agent produces reflects regulatory requirements first and a customer's configuration second.
On the SAR filing agent, a customer's instructions reach the narrative writer as an additional layer, in addition to, never in place of, the FinCEN rules. Ask it to skip the "who" section and the requirement wins. No invented facts, no legal conclusions, no naming investigators, no speculation past the evidence, regardless of what anyone types.
FinCEN's requirements set the floor. Your instructions decide everything above it.
When more prompt detail stops helping
A prompt narrow enough that almost nothing matches produces a clean, technically correct result that says nothing, over and over, in a task nobody revisits. It looks like it's working.
Some of the best work I've done with customers has been taking tasks off their list. Tasks that fired constantly and told nobody anything. So the question I come back to is whether every piece of detail in a prompt is carrying weight.
Every gap you leave gets filled with something reasonable. Not wrong. Reasonable, and plausible, and plausible is what nobody thinks to check.
Write it like someone's going to read it back to you. Someone will.
Frequently asked questions
Is prompt engineering still relevant in 2026?
The phrasing tricks matter less than they did. Specification matters more. Frontier models are better at inferring what you meant, which also means they're better at proceeding confidently on an assumption you never wrote down. For anyone configuring an AI Agent rather than building one, the prompt is still the whole interface.
What's the difference between prompt engineering and context engineering?
Prompt engineering is about the instruction itself: the phrasing, the order, the framing. Context engineering is about everything the model can see when it answers, including retrieved data, examples, history, and available tools. In practice a good prompt is one part of good context.
Should an AI agent do calculations?
Put the math in the data gathering layer, where it becomes a SQL query and runs identically every time. Language models generate the most likely next token, which is a poor way to produce a transaction aggregate someone will cite in a filing. Leave the model to interpret the numbers rather than compute them.
Do you need to know SQL to build a custom AI task?
No. A plain natural language prompt works, and it's the recommended starting point. Field tagging and split gathering/summary instructions are optional controls for teams that want tighter control.
How many alerts should you test a task against before going live?
More than one, and specifically alerts that differ from each other. A task validated against a single unrepresentative alert can produce a query shaped around a coincidence in that alert. Include the awkward cases: the single-entity alert, the many-entity alert, the one with a sparse customer record.
Gal Perelman is the Product Marketing Lead at Unit21, where she spearheads go-to-market strategies for AI-driven risk and compliance solutions. With over a decade of experience in the fintech and fraud sectors, she has led high-impact launches for products like Watchlist Screening and AI Rule Recommendations.
Previously, Gal held marketing leadership roles at Design Pickle, Sightfull, and Lusha. She holds a Master’s degree from American University and a Bachelor’s from UCLA, and is dedicated to helping banks and fintechs navigate complex regulatory landscapes through innovative technology.
