The problem Custodia solves

Giving an AI agent your wallet to act on your behalf is currently an all-or-nothing choice: either hand over full control and hope it doesn't overspend or pay the wrong party, or supervise every single transaction yourself which defeats the point of automation in the first place.

Custodia gives people a middle ground: a Mandate, a real on-chain spending permit with a hard cap, an expiry, and a fixed list of allowed task categories. An agent can act freely and autonomously within that boundary, and the boundary itself is enforced by a Move smart contract, not by trusting the app's frontend to behave.

What people can actually use it for:
Hiring specialists without micromanaging payment. Ask for something done like a document translated, a contract reviewed, an item picked up and repaired and the agent finds a real specialist, escrows payment, and only releases it once delivery is verified. You never manually wire money or chase an invoice.
Multi-step jobs that need different specialists in sequence. A single request like pick up my broken laptop, get it repaired, send it back gets split into several linked deals which is pickup, repair, return. Each automatically triggering the next once the last one's delivery is proven on-chain, with no manual hand-off required.
Trusting who you're hiring, without a middleman. Specialists are ranked by a reputation score built entirely from real completed-vs-disputed deals, not a profile they wrote themselves, not a platform's opaque rating.
Keeping sensitive job details private. Task briefs and delivered work are encrypted so only the client and the assigned specialist can ever read them, not a backend, not Custodia itself, because there is no backend holding that data.
How it makes things safer, concretely:

Money can never move outside the Mandate's cap, categories, or expiry, enforced on-chain, not just in the UI.
Payment and proof-of-delivery are locked together in one atomic transaction, so there's no window where a specialist gets paid without delivering, or delivers without ever getting paid.
Every reputation score is a real, auditable history of completed and disputed deals, not a number anyone can inflate by hand.

Challenges we ran into

Package upgrades broke object lookups silently. When we upgraded our Move package to add a new module, an older module's objects were still typed under the original package id, not the new one but our query used the new id. Transactions succeeded every time; our own code just never found what it created. We found the real cause by pulling the raw transaction JSON via the Sui CLI and reading the object's actual type string.

Seal requires the original package id, always. After that same upgrade, encryption started throwing InvalidPackageError. Turned out Seal's SDK hard-requires the package's version-1 id specifically, even though the function itself works fine on the newer package. We only found this by reading Seal's own SDK source.

A budget check passed, but the real transaction still failed. Our on-screen "Mandate check passed" message and the actual escrow transaction were silently reading two different Mandate objects, one freshly fetched, one cached from earlier in the session. Once a user had two Mandates, the check and the real transaction could disagree.