Verifiable AI Agent Commitments: A Refund Agent Demo
Your AI agent's logs can tell you what it did. They can't tell you what it promised.
That gap looks small until money is involved. An agent tells a customer "you'll get your €750 back." Who authorised that? Is the promise still valid? And if someone edits the database next week, would anyone notice?
If you're:
- putting AI agents in front of customers,
- letting agents move money or make offers,
- or responsible for auditing what those agents do,
this is the problem you'll hit first.
I built a small demo to make it tangible: an AI support agent whose refund promises become verifiable commitments. It's the €750 refund example from my SITP series, turned into something you can click through.
Logs record actions. Commitments need receipts.
A log line looks like this:
2026-11-03 11:41:54 refund-agent called offer_refund(order=88231, amount=750)
It answers one question: what happened?
It doesn't answer the questions that matter when a customer, an auditor or your finance team comes asking:
- Who is responsible for keeping this promise?
- Under whose authority did the agent make it?
- What state is it in now: offered, accepted, paid, disputed?
- Has anyone touched the record since it was written?
Logs are mutable, private and written by the same system you're trying to audit.
That's not a receipt. That's a diary.
The reframe: treat every promise as an object
SITP (the Staplit protocol) treats a commitment as a first-class object called a Staple. A Staple has:
- an owner (who owes it) and a counterparty (who it's owed to),
- the authority it was made under,
- a lifecycle with defined states,
- and a signed, hash-chained history that anyone can verify.
The demo applies that idea to one concrete job: handling refund tickets for a fictional online store, Northwind Gear.
A note on scope. This is an educational demo. The SITP behaviour runs on a small local simulation I wrote for it, not on the official Staplit relay. It uses the official SITP state names (
ISSUED,ACTIVE,RETURNED,DISPUTED,RESOLVED...), but the transition rules are the demo's own.
How verifiable AI agent commitments work in the demo
The core rule is simple: the agent never writes to the ledger directly. It asks, and the ledger decides.
Every time the agent tries to make or change a commitment:
- The agent calls a tool, such as
offer_refund. - The ledger checks the agent's certificate: human sponsor, allowed operations, spending cap, domain and expiry.
- It checks that the state change is legal and that the right party is making it.
- Only then does it append an entry, signed by the party that submitted it and by the relay, and chained to the previous entry's hash.
Rejected actions are never written. Legality is enforced at write time, not reconstructed afterwards.
👉 Want to see how Staplit approaches commitments for AI agents? Start at staplit.ai.
The agent leases its authority from a human
The agent doesn't own any authority. It borrows it from a named person: Laura Gómez, Finance Ops lead.
Here's the certificate the agent works under:
{
"id": "cert_refunds-02",
"agent": "agent:refunds-02",
"sponsor": "human:laura.gomez",
"operations": ["commitments.read", "refund.offer", "review.offer"],
"fiscalCap": { "perAction": 1000, "currency": "EUR" },
"domain": { "counterpartyPrefix": "customer:", "regions": ["EU"] },
"expires": "2027-02-01"
}
Issuing it is a ledger entry signed by Laura. Revoking it is too. Whether it's valid is always worked out from the ledger, never from a flag someone can flip in a database.
The agent's tools
The agent itself is ordinary. It can run on Claude with tool use or as a fixed script, and it gets four tools:
lookup_order // store data: item, amount, delivery status
list_customer_commitments // existing Staples for this customer (needs a valid certificate)
offer_refund // creates a Staple. Rejected above the fiscal cap
offer_human_review // commits to a human review instead. Moves no money
The interesting part isn't the agent.
It's what happens between the agent and the ledger.
The walkthrough: 6 scenarios in 5 minutes
1. The agent offers a €750 refund
Tom returned his laptop and wants his money back. The agent looks up the order, checks for existing commitments so it never refunds twice, and offers a refund.
A Staple is created in state ISSUED:
The commitment also comes as one line of SITP operators:
Refund €750 for order 88231 &refunds-02(2026-11-08) &&laura.gomez &$750 ^2 *support-refunds
Read aloud: refunds-02 is responsible for "Refund €750 for order 88231" by 2026-11-08, moving 750 EUR, at urgency 2, in the support-refunds workstream. laura.gomez observes every event.
| Operator | Meaning |
|---|---|
| &party(deadline) | Who owes this, and by when |
| &&party | Observer: receives every event |
| &$amount | Money moves with the commitment |
| ^1–5 | Urgency |
| *tag | Workstream |
2. The agent tries to accept on the customer's behalf
What if the agent "helpfully" accepts its own offer?
Rejected. Only the counterparty can accept a commitment made to them. Nothing reaches the ledger.
This is the kind of mistake that slips through when the rule lives in a prompt. Here it lives in the write path.
When Tom accepts, the Staple moves ISSUED → ACTIVE, the store pays, and the agent records ACTIVE → RETURNED. Each step is its own signed entry, made by the party allowed to make it:
3. A €1,800 refund hits the cap
Amira's sofa never arrived. She wants €1,800 back.
The agent tries offer_refund. The ledger rejects it: €1,800 is above the €1,000 cap bound into the certificate.
The agent doesn't argue, and it doesn't split the refund into two smaller ones. It does the only thing it's authorised to do: commit to a human review within 24 hours. That promise is a Staple too, with its own owner, deadline and state.
The customer gets an honest answer. Finance gets a commitment it can track.
4. Anyone can verify, without logging in
Every Staple has a public verification page. No account, no credentials.
It shows three things:
- that the commitment exists,
- that its record is intact (hashes and signatures check out),
- and its current state.
It doesn't show the terms. The amount, the order and the reason are readable only by the parties.
The seal is public. The contents are not.
5. Someone edits the database
Now the uncomfortable test. Someone with database access quietly changes the refund from €750 to €75, without touching the hashes or signatures (they can't re-sign as someone else).
Open the same verification link again:
The record no longer matches its hash chain. Verification fails exactly at the edited entry. With a plain log table, this edit would have been invisible.
6. Revocation takes effect immediately
Last scenario. Laura pauses the agent by revoking its certificate. The revocation is itself a signed ledger entry.
Then Jonas opens a ticket about the wrong shoe size:
The agent can't create commitments anymore, and it can't even read existing ones. It tells the customer a colleague will take over.
No ghost access. No "the token was still cached somewhere."
Key takeaways
- A log says what an agent did. A commitment says what it promised, under whose authority, and lets anyone check it hasn't changed.
- Put the rules in the write path, not the prompt. Caps, roles and revocation work because the ledger refuses illegal actions before they're written.
- Verification shouldn't need anyone's cooperation. Public integrity, private terms.
Final thoughts
AI agents are going to make promises on our behalf: refunds, purchases, deadlines, bookings.
The question isn't whether they'll make mistakes.
It's whether we'll be able to prove what they committed to.
This is the first of five demos I'm building around SITP. Next up: an agent that buys on behalf of a business, and what happens to its access when its authority is pulled.
If your agents already make promises to customers, suppliers or partners, it's worth knowing how they'll be held to them. Learn more about Staplit and SITP at staplit.ai.
FAQs
❓ What is a verifiable AI agent commitment? ✅ It's a promise made by an AI agent that is recorded as a structured object with an owner, a counterparty, the authority it was made under and a lifecycle. Each change is signed and chained, so anyone can check that the record exists, is intact and is in a given state.
❓ How is a commitment different from an AI agent log? ✅ A log records what the agent did, is usually private and can be edited by whoever runs the system. A commitment records what the agent promised and under whose authority, and its integrity can be checked by a third party without access to your systems.
❓ What is SITP? ✅ SITP is the protocol behind Staplit for recording commitments between people, companies and AI agents. Each commitment is a Staple with defined states such as ISSUED, ACTIVE, RETURNED, DISPUTED and RESOLVED. You can read more at staplit.ai.
❓ How do you stop an AI agent from making promises it isn't allowed to make? ✅ Give the agent a certificate leased from a named human sponsor, with allowed operations, a spending cap, a domain and an expiry, and check it before anything is written. In the demo, a €1,800 refund is rejected because the cap is €1,000, and the agent commits to a human review instead.
❓ What happens when you revoke an AI agent's access? ✅ In the demo, revocation is itself a signed ledger entry and takes effect immediately. The agent can no longer create commitments or even read existing ones, so there's no leftover access.
❓ Is this demo the official Staplit implementation? ✅ No. It's an educational demo that simulates SITP behaviour locally. It uses the official SITP state names, but the transition rules were written for this demo.
If you're a software or API company looking to explain your product through high-quality educational content (not marketing fluff), feel free to connect with me on LinkedIn: 👉 linkedin.com/in/kevin-meneses-gonzalez
Looking for technical content for your company? I write hands-on articles and demos like this one for developer tools and APIs. Get in touch.