Built at The Agent Harness Hackathon

Regenerate

An agent recovers a denied synthetic insurance claim on TrueForge: it reads the claim through a local MCP connector, computes the correction in the sandbox, and pauses on a shielded tool before the only call that writes. TrueForge pauses on every shielded call, including retries. That is correct, and it is also the interesting part. Each approval references one specific pending tool call, so the same business operation can be approved twice and every yes is correct in isolation. Nothing in the approval layer relates one to another. The harness authorizes a tool call; the application cares about an operation. Different units. So the memory lives where the consequence lands. The payer mints the operation id server-side and fingerprints the exact payload at prepare time, then re-verifies that fingerprint at commit. A retry of the identical payload replays the original receipt instead of writing again. A tampered amount is refused before anything is written. That check does not depend on the model behaving well. In the demo I approve twice and the ledger holds one row, same receipt. Then I ask the agent to change the amount: it refuses on its own, and the end-to-end suite shows the payer would refuse it anyway. Three operations attempted, exactly one row written. Idempotency is not new. What is new is that the thing retrying is an agent and the thing approving is a person. Relating one approval to another is an application-side concern, confirmed as such by TrueFoundry before this was recorded. Uses MCP over Streamable HTTP, Code Mode sandbox, shielded tools, and one skill (safe-resubmission) carrying the retry policy. All data synthetic; the ledger is local SQLite with immutable rows.