Native tool use

1. Bundled tools
2. Why results carry a source URL
3. Bounding the loop
4. What the model is told

The reference providers expose the research tools to the model using the provider’s native function calling. The model decides which tool to call; the provider executes it and feeds the result back, looping until the model returns the final findings JSON.

prompt + tool schemas ─► model
   ▲                        │  "call registry_lookup{capability: 'beneficial_owners'}"
   │                        ▼
   └──── tool result ◄── provider executes ResearchTool::execute()  (result carries source URL)
            (repeat up to maxToolHops, then the model returns findings JSON)

Bundled tools

Tool name	Class	What the model gets
registry_lookup	RegistryTool	the capability-routed registries for this counterparty
verification_report	ReportLookupTool	the hard facts already gathered (read-only)
web_search	WebSearchTool	adverse-media results (needs a WebSearchClient)

RegistryTool and ReportLookupTool are context-aware: the strategy binds them to the counterparty/report under verification before the run, so the model cannot research a different entity.

Why results carry a source URL

Every ToolResult includes the source URL of its data. When the model derives a finding, it is told to cite that URL. The strategy then only promotes grounded findings (those with a URL) to Evidence; anything ungrounded becomes a reason for human review, not a fact.

Bounding the loop

maxToolHops (default 4) caps how many tool round-trips a single research run may make, so a confused model cannot loop forever. After the cap the provider asks for the final answer.

What the model is told

The versioned prompt instructs the model to:

• produce advisory context only and never contradict the report;
• ground every claim in a tool’s source URL, or omit it / mark low confidence;
• return strictly the findings JSON schema (which is then validated).

If the output does not parse, the provider retries; it never trusts un-parsed prose.