I Forgot to Design the Read-Back


I Forgot to Design the Read-Back
Last week I broke my own product.
I gave Nova, the AI agent inside Outcomet, write access to a few core entities. The kind of permissions that let her actually move things instead of only suggesting them. I did it on a Sunday morning, because Sunday mornings are when founders make the decisions that Monday mornings have to live with.
Within an hour I was watching records appear in the UI that I had not asked for, attached to objects I did not remember opening, with no obvious way to find out which call had created them or how to put them back. Everything technically worked. Nothing felt safe.
That was the moment I realized I had built only half of the feature.
The Agent Is the Easy Part
Every product team I talk to right now is shipping agentic features. Or planning them. Or pretending not to be while quietly shipping them under feature flags. The framing in those rooms is almost always the same. Which model, which tools, which prompt, what is the scope of the actions the agent can take.
Nobody is asking the second question.
The second question is what the user sees while the agent is working, and what they see after the agent is done. The read-back. The mirror that tells the human what just happened on their behalf.
It turns out that part is not garnish. That part is the product.
The reason teams skip it is structural. The agent is the interesting engineering problem. The read-back is a pile of small UI decisions that look like polish. So the agent gets a sprint, the read-back gets whatever time is left on the Friday before launch, and the team ships a feature where the user is asked to trust an opaque process because the trustworthy version was scheduled for "v1.1".
Glass for the Builder, Black Box for the User
If you sit next to the developer who built the agent, the system feels reassuring. They have the prompt in one window, the tool call log in another, a diff of every change in a third. They can replay a session, inspect the reasoning, see exactly which function fired in which order. The whole machine is glass.
The user gets none of that. The user gets a chat thread, a spinner, and then a screen that has quietly changed.
This is the trust gap, and it is the actual product problem most teams are not solving.
The agent is what you build. The read-back is what the user actually buys.
In the old non-agentic world, the read-back was free. The user clicked a button, the button caused one thing, the thing was visible on the next screen. The action and the consequence sat next to each other. You did not need a separate UI to explain what just happened, because what just happened was what the user did.
Agents break that contract. The user says one short sentence. Behind it, five tools fire, three records change, one email gets queued, and an audit row gets written. If the only feedback is "Done", the user has no way to know if "Done" means done, partially done, or done in a way they will regret in twenty minutes when somebody from sales emails them about it.
What Gets Lost When the Read-Back Is Missing
I noticed something in my own usage of Nova after the Sunday incident. I started double-checking everything. Every time she did anything, I clicked into the entity she touched, scrolled the activity log, looked for the change in the database admin tab.
The agent was saving me time on the action. I was spending that time, plus a little extra, on verification. The net was negative.
This is the failure pattern almost nobody is measuring. Senior product teams have dashboards for adoption, latency, retention, even hallucination rate. Almost no one has a metric for how many seconds the user spends verifying what the agent did. And yet that metric, if you tracked it, would tell you whether your agentic feature is creating value or only the appearance of it.
The teams that ship agents without read-backs are not shipping a faster product. They are shipping a product that asks the user to do the verification work the UI used to do for them. It is offloaded labor, dressed as automation.
The Checklist I Wish I Had Started With
After I cleaned up Sunday's damage, I wrote down the surfaces any agentic feature has to ship with before I let a real user near it. Not as a nice-to-have. As the actual definition of done.
- A stop button, visible at all times, not buried in a menu.
- A diff display showing what changed, in language a non-developer can read.
- A tool trace, light enough to ignore, deep enough to inspect when something feels off.
- A cost line, because tokens are real money and the user has a right to know.
- An undo, especially for destructive actions, and "delete this record" counts as destructive even when the agent thinks it's tidying up.
These are not five separate features. They are one feature. They are the read-back. And they are what turns "the model called a tool" into "I, the user, did a thing, I can see it, and I can take it back".
What I find interesting is that when I went back through Nova's own tool set with this list in hand, more than half of the tools failed it. I had built an agent that could do things faster than I could explain them. That is the wrong order of operations.
The fix, by the way, was almost too on-the-nose. I asked Nova to audit her own tools against the checklist, exported her findings, and then handed the list to a separate coding agent to do the rewrites. AI fixing AI, while I drank coffee and watched. Two days of work I had been quietly avoiding, done in an afternoon.
The Read-Back Is Where Agentic Products Will Compete
The current AI product wave is going to flatten quickly on the agent itself. Everyone will have similar models, similar tools, similar capabilities. The differentiator will not be what the agent can do. It will be how legible the agent's work is to the person whose name is on the account.
The product operating model for agentic features is not "ship the agent, then the polish". It is "the polish is the agent". The trust layer is not the wrapper around the product. The trust layer is the product. The model is the engine. The read-back is the dashboard. Nobody buys a car with no dashboard, no matter how good the engine is.
The teams that figure this out first will quietly take the agentic category from the teams who think the work ends when the model returns its response. The rest will spend the next year wondering why their adoption numbers look fine in week one and collapse in week four.
The question I'd ask any team shipping agentic features this quarter is simple. If you removed the agent entirely and only kept the read-back, would the user trust your product more, or less, than they do today.
If the answer is "less", you have not built the read-back yet.
Related Posts
The Question Five Agents Never Asked
This week five AI agents worked for me in parallel for thirty minutes. The idea was half-botched from the start. They executed it beautifully anyway, and not one of them stopped to ask whether we were building the right thing. That missing question turned out to be the whole job.
Discovery Is Three Jobs Wearing One Word
A B2B team I watched ran textbook discovery: prototype, show, learn, adjust, repeat. The loop was clean. It still walked us into a wall, because one word was hiding three completely different jobs and we were only doing one of them.


The Bug That Shows Up on the Bill
A session I designed for ten messages ran to forty. Nothing crashed. The only place the problem surfaced was the invoice. That is when I noticed a design decision I had been treating as cosmetic: show the user a token meter, or quietly compact the context behind it.