HKUST team's LedgerMind forces multimodal agents to cite tools

There's a paper on Hugging Face this week that goes at one of the more embarrassing failure modes in multimodal agents, the one where the model reaches the right answer via intermediate reasoning that quietly makes things up. The pitch, from a team spanning HKUST-Guangzhou, the University of Hong Kong, Tsinghua and Sussex, is a training-free runtime called LedgerMind. It sits in front of a frozen backbone and forces every reasoning or decision claim to cite a specific tool-returned entry in a structured evidence ledger, rather than a free-form scratchpad. You can read the paper on Hugging Face.

The mechanic is straightforward once you look at it. Tool outputs are normalized into typed ledger entries carrying source, epistemic type, a rule-normalized fact and a lifecycle status. Downstream claims are checked at three layers: token overlap with cited evidence, an entity consistency check, and a numeric coherence check that requires exact match for years and counts. A separate typed repair engine comes with what the authors call a Provenance Non-Amplification guarantee, meaning any repair operator can only introduce entries whose provenance traces to a tool output. That is a bounded, checkable property, which is not something you often see stated formally in agent papers.

The numbers are worth taking as reported rather than as settled. On the authors' Hard-200 stress set, LedgerMind reportedly adds +11.2 to +19.7 points on top of every backbone tested. On the BrowseComp-VL sub-source specifically, the weakest backbone in the lineup, Kimi-K2.6, jumps from 19.5% to 46.0%. On VTC-Bench with Gemini-3-Flash the framework hits 58.9%, which the paper claims as a new SOTA. It was evaluated across six frontier MLLMs from four vendors, spanning OpenAI, Google, Anthropic and Zhipu.

The honest caveat is that these are the authors' own numbers on a mix of public benchmarks and an in-house Hard-200 set, and the ablations show at least one domain, coding on EMMA, where the framework actually loses a fraction of a point against Gemini 3.1 Pro. The paper also does not surface a latency or token cost for the ledger and verification loop, which for any real deployment is the number you actually want to see. What is interesting is the direction. Rather than a bigger model or a fine-tune, this is runtime-only plumbing that appears to lift frozen frontier models on tool-heavy tasks, and the people who benefit first if it holds up are teams shipping agent stacks in regulated settings, where provable citation lineage is currently a very hard sell.