Kaval
Verify what your AI agent believes before it takes action
Start new thread

Kaval - Verify what your AI agent believes before it takes action

by•
Your agent's worst mistakes won't look like mistakes. They'll be confident actions on cached facts, stored fields, and RAG chunks that quietly went stale. Kaval re-derives the truth the instant before your agent acts and returns a verdict to branch on: act, or don't. One MCP call, a typed pass/block with the proof.

Add a comment

Replies

Best
Maker
📌
Hey Product Hunt 👋 I'm Luis. Here's the moment that made me build this. Our support agent told a customer their plan included a feature we'd removed a few weeks earlier. The detail it used had been right when it was saved, and by the time the agent answered, it wasn't. Nothing errored, nothing looked broken. It just confidently told someone something untrue. The more I dug in, the more I saw the same thing everywhere. Agents rarely make things up out of thin air. They act on something that used to be true and quietly went out of date: a CRM field, a saved answer, a chunk from your knowledge base. By the time the agent uses it, the world has moved on and it has no idea. Kaval is a quick check you run right before your agent acts. You hand it the fact it's about to rely on ("Acme is on the Enterprise plan") and it re-confirms it against live sources, then tells you whether it's still current, stale, contradicted, or whether it honestly can't tell. If the answer isn't safe to act on, your agent pauses and checks again instead of charging ahead. A few things people seem to like: - It gives a straight answer your agent can act on, plus the evidence behind it, so you're not handing a model ten links to re-read in the middle of a task. - It actually understands that facts go out of date. An old job title or last quarter's price comes back as stale, even when it's still all over the web. - When it isn't sure, it says so instead of guessing. I'd rather it tell me "I can't confirm this" than wave something through. You can try it right now, no signup, at . Type any belief into the box near the top and watch it check it live. If you want to wire it into your own agent, there's an MCP server and Node and Python SDKs behind a free key. I'd genuinely love your help finding where it's wrong. Give it a fact it should catch and tell me if it misses, or one it flags that's actually fine. That's the most useful thing you can throw at me today, and I'll be in the comments all day. LAUNCH40 gets you free credits if you want to run it on your own agent. 🙏 Luis

How does Kaval handle the latency cost of re-deriving truth on every single agent action, especially for chains with hundreds of steps?

Maker

 

Good question, this is the core design constraint. We don't re-derive truth on every action:

1. Kaval gates beliefs, not steps. A 300-step chain usually rests on maybe a dozen beliefs (invoice is unpaid, this user is an admin, price is current). Reads and reversible ops pass through untouched. Only consequential actions hit the gate, and those check beliefs that are shared across most of the chain.

2. Freshness SLAs short-circuit. Every check carries an SLA (14d for an org chart, 60s for a price). If the belief was confirmed inside the window, verify returns from cache.

3. Monitors do the expensive work off the hot path. Register your belief store once and we sweep it in the background on the SLA, then webhook you only the newly-risky beliefs. At action time the gate is a cache hit against the last sweep. Full multi-source re-derivation only fires when something got flagged.

There are also per-call speed tiers (instant is cache/prior only with no network, fast is a cheap model, deep is full multi-source with citations), and if you pass the content hash from read time we catch changed-since-read with a hash compare before anything expensive runs.

Net: the hot path is a handful of cache-hit gates per chain. Re-derivation happens async where latency doesn't matter.

the re-derive step is the right instinct but what's the added latency per action in practice, and does it scale down for agents that fire dozens of tool calls a minute? feels like there's a tradeoff between catching stale facts and slowing the whole loop down, curious how you tuned that

Maker
Right tradeoff to worry about, and the answer is you don’t put it in the hot path of every tool call. Two things keep it cheap: It gates beliefs, not calls. An agent firing dozens of tool calls a minute is usually leaning on a small set of load-bearing beliefs, not re-deriving each one. You check those, and only when they back a consequential action, so most of the loop never pays the cost. And it’s tiered by stakes. A reversible read doesn’t get the full re-derivation; an irreversible write on a volatile fact does. So latency lands on the few actions where being wrong is expensive, not the whole chain. On hard numbers: I’m still gathering real per-check latency across usage patterns rather than quoting a benchmark, so I’d rather not throw out a figure I can’t stand behind yet. If you’ve got an agent doing dozens of calls a minute, that’s exactly the profile I want to test against, happy to run your worst case and share what I find.

spent a weekend stress-testing kaval against our agent's worst habit, hallucinating from stale data, and the typed pass/block with the proof feels like exactly what we needed to catch silent failures before they hit users.