Agentic task builder: Build custom AI agent tasks, in plain English

Every fraud and compliance program is different. The checks a wire fraud team needs on an alert aren't the checks a KYB team needs, and the checks either of them needed last year probably aren't the checks they need today. Typologies shift, regulators update guidance, and new fraud patterns show up faster than any static rule set can anticipate.

‍

For most of the industry, that reality collides with how AI tools actually get built. A vendor ships a fixed set of capabilities. If your program needs something outside that set, you file a request and wait, on your engineering team if you're lucky enough to have the resources to build it yourself, or on your vendor's roadmap if you're not. Either way, the person who understands the risk best, your analyst or your compliance lead, isn't the person who can change what the AI does.

‍

We built the agentic task builder to close that gap. It lets you write custom AI agent tasks in plain English and have them run inside your existing alert agents, no code and no engineering ticket required. Two capabilities are live today: online search and data analysis. They share the same builder and the same underlying design principles, but they solve two different problems, so we're going to walk through each one in depth.

‍

The idea behind the builder

Before getting into the two capabilities, it's worth explaining what's actually happening when you write a task in plain English, because it's not just prompt engineering.

‍

Feeding a language model a loosely worded instruction and hoping for a good result is not a reliable way to build compliance infrastructure. The harder and more important problem is context engineering: making sure the model has exactly the information it needs to make a specific decision, no more and no less. Give a model too little context, and it lacks what it needs to decide correctly. Give it too much, and performance degrades, the same way a person given an overwhelming pile of unsorted information starts to conflate details and lose the thread.

‍

The agentic task builder is designed around that constraint. When you describe a task, the agent doesn't just try to satisfy the literal words you typed. It figures out what data actually exists, what fields are populated, what format will produce a defensible answer, and whether your instruction is specific enough to act on in the first place. If it isn't, the agent will tell you and propose something more concrete, rather than quietly guessing and handing back a result that looks confident but isn't grounded in anything real. You stay in control of that proposal. Nothing runs without your approval.

‍

That behavior, checking its own assumptions and surfacing uncertainty instead of hiding it, is the thread that connects everything below.

‍

Online search

Online search is built for the parts of an investigation that live outside your own systems: adverse media screening, sanctions and watchlist exposure, verifying that a business actually exists and operates where it claims to, confirming employment history, or just establishing a general online presence for an entity that's otherwise a blank slate. These are tasks analysts already do by hand, opening browser tabs, running searches, and copying findings into a case note. Online search automates that motion without automating away the judgment.

‍

How you configure it

You start from a template or from scratch. Templates cover the common cases (general online presence, adverse media, counterparty legitimacy, business entity profile, website validation, employment verification) and pre-fill a name and a starting prompt that you can edit freely. The prompt is where you describe, in plain language, what the agent should look up and how it should treat what it finds: which identifying details to search on, how to format the output, and what to do when there's a partial match instead of a clean one.

‍

‍

That last part matters more than it sounds. Names collide. A search for a common name will surface results belonging to other people, and a tool that can't tell the difference is worse than useless; it's actively misleading. So the prompt can instruct the agent to validate anything it finds against the specific identifying details on the entity: date of birth, address, phone number, email. If a result doesn't line up with those details, the agent is instructed to treat it as unrelated rather than presenting it as a match. Findings that are plausible but not confidently verified get separated into their own section instead of being blended in with confirmed results, so an analyst reviewing the output can immediately tell the difference between "we found this and verified it" and "we found something that might be related, use your judgment."

‍

‍

How it actually runs

Once you point a configured search task at a real alert, you can preview it before saving anything, so you're not guessing how it will behave on real data. When it runs, the agent generates its own search queries based on the entity's details and the instructions in your prompt, executes them, and works through the results. You can watch that process happen: which queries it ran, what it found, and how it reasoned about relevance.

‍

The output is a written summary, but every claim in that summary is tied back to a source. Not a generic citation at the bottom of the page, a specific link for each specific claim, so anyone reviewing the finding later can retrace exactly how the agent got there. If the search comes back empty, meaning there's genuinely no adverse media, no sanctions hits, and no meaningful online footprint, the agent says that plainly instead of padding the response with unrelated results to seem thorough. A clean result, clearly reported, is a valid and useful outcome. It closes out a check that would have otherwise sat in an analyst's queue.

‍

Where it fits in an investigation

Online search is typically one input among several. It's the fastest way to close out the "did we check the outside world" step of due diligence, whether that's part of onboarding, an EDD review, or periodic monitoring. Because it's built on the same task builder as data analysis, you can also chain the two conceptually: use online search to establish external context about an entity, then use data analysis to see how that entity behaves inside your own data.

‍

Data analysis

Online search investigates a bounded, external space, the open web, with a relatively well-understood shape. Data analysis investigates your own data: transactions, entities, counterparties, alerts, and whatever custom fields your program tracks. That space is unbounded, unique to your program, and constantly changing, which means the agent can't rely on a fixed template the way online search can.

‍

Data analysis is meant for exactly the kind of question that used to require an analyst to write a query, or wait for someone who could. "Show me wire activity with fraud indicators across our flagged entities." "Summarize prior SAR activity for this entity." "Find accounts with mule-like transaction patterns." These are open-ended, program-specific questions, and the answer depends entirely on what your data actually looks like, which fields are populated, which transaction types are relevant, and what a meaningful signal looks like for your specific typologies.

‍

How it handles an ambiguous ask

This is where the design differs most from a typical text-to-SQL tool. When you type a short, natural instruction, the agent doesn't treat it as a finished specification. It treats it as an intention that needs to be translated into something precise enough to act on responsibly.

‍

‍

In practice, that means the agent will explore the available data before it commits to an approach: checking which transaction types exist, which fields are actually populated versus nominally available, and what the schema looks like once you get past the surface-level field names. If your original instruction is too vague to produce a reliable, defensible result, the agent will say so and propose a specific rewrite, laying out exactly which transaction types it plans to treat as relevant, which fields it will use as fraud or risk indicators, and how it will format the output so it's actually usable. That proposal is a suggestion, not an autonomous decision. You review it, adjust it if needed, and approve it before anything runs against real data.

‍

We built it this way because "the AI understood what I meant" is not good enough for risk and compliance work. Understanding what you meant and being able to show exactly what it did and why are two different things, and only the second one is defensible in front of a regulator or an auditor.

‍

How it validates itself before you see a result

Once a task is approved, it doesn't run once and stop. You can backtest it against a set of real alerts before it's ever used in production, which means you see how it performs on your actual data instead of a hypothetical example. While it runs, it works the way a careful analyst would: sampling the data to confirm its assumptions hold up, checking column names and data types instead of assuming them, and correcting course when something doesn't match what it expected, like a field that turns out to be named differently than anticipated, or a data type that doesn't support the operation it planned.

‍

‍

After it produces a result, it doesn't just hand that result back. It reviews its own output for quality before presenting it, and it's explicit about the limits of what it found. If the underlying data doesn't have enough populated fields to support a real conclusion for a particular alert, it says that directly instead of stretching a thin result to look more conclusive than it is. That distinction, between "I found something real" and "I don't have enough here to tell you anything meaningful," is exactly the judgment call an experienced analyst makes constantly, and it's the part that's hardest to get an automated system to do honestly.

‍

‍

Why the output is structured, not just a paragraph

The result of a data analysis task isn't a wall of prose. It's organized so an analyst can act on it: grouped findings, the specific signals behind each grouping, and the evidence tying a conclusion back to the underlying transactions or entity attributes. That structure is deliberate. A summary that reads well but can't be traced back to specific evidence isn't an investigation output, it's a guess with good writing. Every grouping and every flag in a data analysis result should be traceable to something concrete in your data.

‍

‍

All glass box, no black box

Everything above comes back to one idea. An agent that occasionally tells you it doesn't have enough information, or that your instruction needs to be more specific, is more useful in a regulated environment than one that always sounds confident. Confidence isn't the same thing as being right, and in compliance work, the gap between the two is exactly what gets programs into trouble during an exam.

‍

Every step the Agentic task builder takes- what it checked, what it found, what it couldn't determine, and why- is visible and auditable. That's not a compliance checkbox we added after the fact. It's the actual design principle underneath both capabilities: humans stay in the loop, every decision is explainable, and the system is built to tell you what it's confident about and what it isn't, rather than optimizing for sounding certain.

‍

Built for how your program actually works

The Agentic task builder isn't a separate tool bolted onto Unit21. It's the same alert agents you're already running, with a new way to extend them. If your wire fraud team needs a check that doesn't exist yet, write it. If a new typology shows up next quarter, write that one too. If your KYB team needs a business verification workflow that looks nothing like your fraud team's wire fraud checks, that's fine; it's the same builder either way.

‍

You're no longer waiting on a roadmap to change what your AI does. You're describing the task, reviewing what the agent proposes, and approving the result.

‍

Online search and data analysis are live now inside your alert agents.

‍

See it in action / talk to your CSM →

‍