deed

We built a WhatsApp agent that takes orders for neighborhood stores in Honduras. Customers write, send a photo of a handwritten list, or send a voice note ("quiero 2 cocas y un pan"); the agent reads the order back with prices, and the customer confirms with a tap. Staff run each order from a web console: preparing, ready, dispatched, delivered. The owner manages products, prices and business info from the same console, in Spanish or English. Underneath it is Deed, and Deed is the actual contribution. Every agent today says "saved" with the same fluency whether the write happened, failed silently, or never ran. The next step treats that sentence as a fact, and nothing records which later decisions leaned on it. When it turns out to be wrong, or the owner cancels it, everything built on top keeps going. Deed is a double-entry ledger for an agent's effects. The agent's claim is one leg of the entry; the world writes the other. Three rules are enforced by the database, not by prompts: 1. A claim is not a fact. Model output only ever creates a draft. A fact exists only after a permitted person confirms that exact draft revision, and it is admitted together with its evidence: the inbound message, the media hash, the confirmation, the stock movements. 2. "Saved" cannot exist without the fact. The fact, its evidence, the stock movements, the job completion and the reply are one database batch. If any part fails, none of it exists, so no reply can ever claim an effect that did not happen. 3. Cancelling a fact blocks what depended on it. Facts carry dependencies and a validity window. A cancellation writes one closure row; liveness is derived from it, never cascaded. Every downstream decision that hung on the cancelled fact is refused at commit time, by a recursive query inside the batch. Mark an order ready after it was cancelled and the batch refuses: nothing is written, and the reply never goes out. Before any customer-facing message leaves, the engine re-reads the ledger and verifies every claim the reply makes: a price, a total, an order's state. A price the owner never confirmed is never quoted. The console shows this as a graph: each fact is a node, dependencies are edges, green is live, red is closed, grey is blocked by a closed ancestor. A verification feed logs every check with its reason. We attacked the engine nine ways (forged confirmations, duplicate deliveries, stale drafts, replays): zero false facts were admitted (scripts/adversary.mjs). The result for a store owner is simple: the agent can be wrong, but it cannot leave a wrong effect behind, and anything it says can be traced to the entry that backs it. Live: https://store-assistant.atiendeme.workers.dev — the bot runs on a WhatsApp test number, so judges see it in the video; we add any judge's number to the test list on request.