What actually happens when a customer asks you to change something
What happens when a customer asks to change something: confirmation first, then one durable, idempotent step — never a guess.
"Can I move my meeting to next week?" looks like a single sentence. Underneath, Kav treats it as a write — a category of request the platform is deliberately more careful with than a read, because a write changes something real.
Confirmed before it runs
A write capability is declared as a write explicitly, and it requires a confirmation turn: Kav shows exactly what it's about to do — the specific change, in a rendered card — before doing it. Nothing is executed on the model's say-so alone.
Durable, and idempotent
Once confirmed, the change runs through a durable, transactional step, and it carries an idempotency key with a dedupe window — so a retried request (a flaky connection, a doubled tap) is never applied twice. If a request looks like it might already be in flight, it isn't silently re-guessed; it routes to a declared possibly-duplicated outcome for a person to check, rather than executing again.
Why the read/write split exists at all
Most of what a customer asks is a lookup — a balance, a status — and Kav answers those synchronously with no write machinery involved, because paying the cost of a durable step for every question would be real waste. The platform documents this split openly: reads are cheap and fast; writes get the careful treatment a change to a real system deserves.
What a customer never sees, and should never have to
The retry logic, the transaction, the dedupe window — none of it is visible. What's visible is a confirmation card, and then a result. The complexity exists so the result is trustworthy.