A chatbot and a tool-using assistant are not the same thing

Start with the distinction that matters most.

A plain chatbot only reasons over the text it has been given. It can summarise a report you paste in, restate what a transaction looks like, or explain a concept. But it has no live access to the chain. If you ask it about a specific address, it is working from training data and whatever context you supplied — not from a current lookup.

A tool-using investigation assistant is different. During the conversation it can call dedicated blockchain-analysis functions: pull an address's risk profile, trace where funds moved, check a sanctions list, look at the counterparties on a bridge. Those tool calls happen during the conversation — a function returns structured data, and the model then explains what that data shows.

That difference is the whole game. A chatbot that sounds confident about an address it never queried is not conducting an investigation. It is generating plausible text.

When a vendor says “AI,” the first thing to establish is which of these two architectures you are actually buying.

What tools an investigation agent can actually call

A capable assistant is only as good as the functions underneath it. In broad terms, those functions fall into recognisable categories:

Address analysis / risk triage — summarise what is known about an address and surface risk signals.
Fund tracing — follow value from one address through subsequent hops.
Cross-chain checks — detect movement across bridges and between networks.
Sanctions checks — compare against designated-address and sanctions data where it is available.
Pattern detection — flag structures such as peel chains, mixing behaviour or wash activity.
Exchange-deposit analysis — identify likely off-ramp or deposit relationships.
Block-level analysis — inspect what happened in a specific block or transaction.
Report / context retrieval — load previously generated analysis back into the conversation.

The point of listing them generically is that the categories are portable across vendors. The implementation details differ, but the shape is the same: a language model sitting on top of a set of real analysis tools, calling them as the investigation demands.

What matters is not the length of the tool list. It is whether the tools return real, current analysis — and whether you can tell when one was actually used.

Tool results and model interpretation are not the same layer

This is the distinction most likely to cause trouble, and the one most worth getting right.

When an agent answers a question, two very different things are happening. A tool returns a structured result — a traced path, a risk score, a list of counterparties. Then the model writes a sentence describing it. Those are separate artefacts, and they should stay separate.

Structured blockchain-analysis results and model interpretation should remain distinct. The tool/data output is an analysis result or source input; the sentence around it is model interpretation. Collapsing the two — presenting the model's summary as if it were the raw finding — is how a confident narrative quietly outruns what the data actually supports.

It is tempting to assume every tool output is a hard fact. It is not. Many analysis results are themselves probabilistic or heuristic: an entity label, a clustering inference, a risk score. So there are really three layers to keep apart — the raw on-chain observation, the analytical result derived from it, and the model's natural-language interpretation of that result.

A trustworthy system keeps tool/data outputs separable from the language the model generates around them, so a reviewer can always ask: what did the tool return, and what did the model add?

What an AI-assisted investigation workflow looks like

Put the pieces together and a realistic flow looks something like this:

An analyst starts with a suspicious wallet.
The assistant runs an initial analysis to triage what is known and what the risk signals are.
It traces the funds outward, hop by hop.
It inspects counterparties, bridges and any risk signals along the path.
It retrieves supporting context — earlier report data, prior findings — where relevant.
The model summarises what the tools returned.
The analyst evaluates the conclusion and decides what, if anything, it supports.

The analysis steps are grounded in tool and data calls rather than unsupported model guesses. The model is the connective tissue, stitching the results into a readable narrative, but the substance comes from the analysis functions.

The last line matters as much as the first. The workflow ends with a human evaluating the conclusion, not with the agent declaring one.

Why evidence provenance matters

In an investigation, how you know something is part of the finding.

If an agent tells you an address is linked to a sanctioned entity, that statement is only useful if you can trace it back to its source. Provenance means being able to answer, for any conclusion:

what data or tool produced the finding;
what was the model's interpretation rather than the tool's output;
what is still a hypothesis;
and what evidence was simply unavailable.

Without that, a fluent summary becomes impossible to check. Two investigations can reach the same sentence — “these funds reached an exchange” — with completely different evidentiary strength behind it. One traced the path directly; the other inferred it. Provenance is what lets a reviewer tell those apart.

This is also where good design and good marketing diverge. A single confidence score is easy to display and hard to defend. A conclusion you can unwind back to its evidence is harder to present and far more useful when someone challenges it.

A risk signal is not attribution, and attribution is not a legal conclusion

One of the fastest ways an investigation goes wrong is by letting a finding jump a category it has not earned.

These are distinct claims, in increasing order of strength:

A risk signal — an address shows a pattern or exposure worth attention.
Wallet control — someone controls that address. This is not automatically a real-world identity.
Identity — a named person or entity is behind it. This is not automatically a criminal role.
A legal conclusion — that person did something unlawful. This is a determination for people and processes, not a model.

Probabilistic or heuristic correlation is not ground truth. A clustering heuristic that groups addresses is a useful lead, not a confession. An entity label is an assertion with a source and a confidence, not a fact beyond question.

A disciplined agent — and a disciplined analyst — keeps these levels separate and lets unresolved hypotheses stay unresolved rather than promoting them into conclusions because a narrative reads better that way.

What a trustworthy audit trail should contain

If an investigation might ever be reviewed, escalated or relied on by someone else, the record of how it was conducted is part of the work.

As an industry best practice, a trustworthy audit trail for an AI-assisted investigation should be able to capture:

the source or tool used;
the query or operation that was run;
the time and context of that operation;
the resulting evidence;
the model's interpretation of it;
the analyst's decision;
and the revisions or paths that were rejected along the way.

That last item is easy to overlook and often the most revealing. An investigation that only records its final answer hides the branches it abandoned — and those branches are exactly what a reviewer needs to judge whether the conclusion was sound.

This is a description of what the category should aspire to, not a claim that any particular product ships all of it today. It is a standard to measure vendors against, including the one writing this article.

Where human approval belongs

Automation should compress effort, not ownership.

Some decisions should stay with a person regardless of how capable the tooling becomes:

attribution — deciding that a specific entity is behind an address;
escalation — moving a case up or out;
accusation — stating that someone did something wrong;
legal and compliance outcomes — filings, freezes, determinations;
and any external action taken on the strength of a finding.

An agent can gather, trace, summarise and propose. It should not be the thing that accuses. Across the serious vendors in this space, the recurring design principle is the same: the tool accelerates the analyst's judgement; it does not replace it.

How a good agent handles insufficient evidence

The hardest thing to build — and the easiest thing to skip — is the ability to say “not enough.”

Language models are trained to produce fluent answers. Left unchecked, that tendency is dangerous in an investigation, because a missing piece of evidence gets quietly filled with something that sounds right.

A good investigation agent must be able to stop, qualify its uncertainty, or decline to reach a conclusion when the evidence does not support one. “Insufficient evidence” is a valid, important output — not a failure of the system.

This mirrors a point from the evidence section: the inability to establish something is not proof of its opposite. If an agent cannot find a sanctioned link, that is not the same as clearing the address. A system that treats absence of evidence as evidence of absence will produce clean-looking reports that are quietly wrong.

A vendor checklist: questions to ask before you trust an investigation agent

If you are evaluating an AI investigation feature — in any product, not just this one — these questions separate substance from presentation:

Does it use real analysis tools, or does it only summarise text you give it?
Can you distinguish tool output from model interpretation in the answer?
Does it show the evidence and provenance behind a finding?
Does it preserve access controls when the context changes — so a lower access level never inherits data it should not see?
Can it say “insufficient evidence” instead of inventing a conclusion?
Are network and tool limitations stated explicitly, rather than implied away?
Are the final decisions — attribution, escalation, accusation — kept under human control?
Can a prior conclusion be reviewed, rather than silently regenerated into a new one?
For any given claim, can you tell which parts are heuristic and which are directly observed?

A product that answers these well is doing real investigative work. A product that deflects them is probably a chatbot with a confident voice.

How the category is converging

The useful signal in 2026 is that the established vendors are converging on the same principles — natural-language questions, real tool and data access underneath the model, evidence-grounded answers, refusal when data is thin, and human judgement kept final.

TRM Labs describes its Co-Case Agent as an assistant that carries out investigative steps from plain-language requests while keeping a record of each interaction and leaving conclusions to the investigator. Elliptic says its Decode agent answers questions about addresses and returns the evidence behind each answer, shows its reasoning steps, and does not close cases or decide an investigation's direction. Chainalysis describes its blockchain intelligence agents as built around deterministic workflows, audit trails, and human oversight for high-stakes decisions, positioning them as an evolution of its platform rather than a bolted-on chatbot.

The pattern extends beyond the compliance incumbents. AnChain.AI describes an investigation “skill” that triages a transaction, traces funds, and separates verifiable evidence from external reporting before presenting findings. Bitquery exposes typed blockchain tools — tracing, labels, risk screening, address dossiers — to external AI clients over the Model Context Protocol, so an assistant can query real data in plain English (its tracing docs walk through following a transfer hop by hop).

These are the vendors' own descriptions of their products, and their performance and scale claims are theirs, not ours. What is worth taking from them is the direction of travel: the credible version of an investigation agent is grounded in tools and evidence, transparent about its reasoning, and deferential to a human on the decisions that count.

Where OnChainRisk fits today

OnChainRisk's AI-assisted investigation workflow can call blockchain-analysis tools during a conversation, rather than relying only on a language model's stored knowledge. Crucially, the model-generated narrative stays a separate layer from the underlying analysis results.

The tools the assistant can invoke map onto the generic categories above: address analysis, fund tracing, peel-chain and cross-chain detection, sanctions checks, exchange-deposit analysis, specific pattern checks (such as privacy-protocol and NFT-wash analysis), block-level analysis, and retrieval of a previously generated report into context. Related analysis capabilities are also offered as endpoints in the blockchain analytics API, though the AI-assisted workflow and the public API are separate surfaces rather than the same tool set.

One detail is worth stating plainly, because it is easy to misread: the label-search tool searches the authenticated user's own private custom labels — the ones that user created. Analysis tools may return known entity, sanctions, exchange, or service attribution when that intelligence is available for the analyzed address or flow. But there is no direct agent search over the global intelligence database; search_labels is private-user annotation search.

Investigations and their conversation history are stored, so an existing investigation can be continued rather than restarted; plan-specific limits apply to how much AI investigation a given account can run. Tool calls and their results are part of the investigation's state and history, and the system relies on authenticated, server-side report and user authority rather than trusting ownership claims supplied by the client.

That last point drives a security property worth using as a teaching example. When report data is loaded into the assistant's context, that context is projected through the user's current, server-resolved access to the report. A user with Preview access is not served Full-only report context. And because previously generated assistant and tool history can itself contain Full-derived evidence, that history is not simply resurfaced when access changes: if prior history was Full-derived (or legacy and unknown) while current access is only Preview, the backend fails closed and resets or replaces the unsafe context rather than leaking it.

The principle generalises:

AI context should respect the user's current evidence access, and previously generated answers can themselves become sensitive evidence.

To be precise about the boundaries: this is access-respecting context handling, not “complete immutable auditability.” OnChainRisk supports analysis across a multi-network platform, with capability depth varying by network — the set of operations available for any given chain is not uniform. And the heavier promises some of the category is reaching toward — an immutable per-execution evidence ledger, a unique evidence identifier attached to every conclusion, deterministic replay of an entire investigation, autonomous cross-case correlation — are not claims we make today. They are useful goals to hold a tool to, including ours.

A note on investigation methodology

It helps to have a mental model for the arc of an investigation, independent of any product. One way practitioners describe it is a sequence: seed, trace, link, hypothesis, corroborate, attribute, act, revisit.

You start from a seed — an address, a transaction, a report. You trace value and link related activity. You form a hypothesis, then try to corroborate or break it. Only with enough support do you attribute, and only then might you act. And you revisit, because new evidence can overturn an earlier read.

This is a way of reasoning, not a claim that any system runs the whole sequence automatically as a state machine. Its value is in the discipline it encodes: wallet control is not identity; identity is not a criminal role; a probabilistic correlation is not ground truth; a false path should terminate rather than linger; a hypothesis is allowed to stay unresolved. Framed this way, the output of a good investigation is an evidence chain you can follow and challenge — not a single risk score presented as a verdict.

That is the problem we work on at OnChainRisk: giving an analyst real tools during a conversation while keeping the evidence, the interpretation and the open questions clearly separated — so the person, not the model, owns the conclusion.

AI Agents for Crypto Investigations: Tools, Evidence, Audit Trails, and Human Review