The trust line isn't about the task, it's about who has to clean up if it's wrong

Building on the agent side myself, and Aarav's question hit something I think about a lot from the engineering seat, not just the user seat.

From where I sit, the hardest part to build isn't the trust boundary, it's making the failure visible enough that trust can even be extended safely. Most "I'd never let it touch X" answers aren't really about the action itself, they're about the fact that when a drafting task goes wrong, you see the draft before anything happens. When a booking or a send goes wrong, you find out after, sometimes from someone else.

So as an engineer, I've started thinking the real product problem isn't expanding what the agent can do, it's shrinking the gap between an action happening and you knowing about it. A reversible action with zero visibility feels riskier to a user than an irreversible one with a clear receipt and an undo window.

Curious how this lands for other builders here: are you spending more engineering time on capability, or on legibility, making sure the user can see and trust what happened after the fact?