Putting an AI between you and your client

Summarizing feedback with a model fails in a very particular way. It does not produce nonsense you would catch. It produces something plausible. It reads "the top section feels heavy", concludes that this means less padding and no background image, and writes a crisp, confident, actionable item. You build it. The client says that is not what I meant.

The bill for that lands on the relationship rather than on the model, and you pay it twice: once rebuilding, once in a client who now reads every list you send with suspicion. Fixing the wrong thing confidently is worse than not knowing what to fix, because at least not knowing prompts a question.

So the interesting question is not how good the model is. A better model guesses more convincingly. The question is what it is permitted to do at all, and whether you can check afterwards that it stayed inside that.

A feature is something added to make the output better. This rule does the opposite on purpose: it makes the output look worse. A model allowed to fill gaps hands back a tidier list — every line sharp, nothing dangling, the whole thing ready to work through. What you get instead is a list with holes in it, items that still read as questions, tagged (unclear — ask the client) and sitting there unresolved because your client is the only person who can resolve them.

Those tags are the visible price of the constraint, and they are the part of the output doing real work on the days it matters. A guessed item and a correct item look identical right up until somebody has built the wrong one. The tag is the only thing standing between those two states, which is why it is worth more than the tidiness it costs you.

The constraint is also narrow enough to audit, which is the reason for writing it as a rule instead of an aspiration. Open a generated item, follow it back to its pin, read what your client typed. If the item asks for something they did not ask for, that is a defect to report at /support, not a rough edge you are expected to absorb by proofreading everything before you use it.

You are, and there is no setting that moves it. Nothing generated reaches your client on its own. There is no auto-responder, no agent answering threads overnight, no scheduled summary going out under your name. The drafted replies sit in the output until a person posts them, and that person is you.

This holds when an AI agent is driving as well. Connect a coding agent over MCP and it can read the feedback, post a reply, or move an item's status — but those are actions you asked for, in a session you started, with a tool you connected. Treat a reply an agent drafts exactly as you would treat one drafted by a junior colleague: read it before it goes out, because your client cannot tell the difference and should not have to.

One habit falls out of all this, and it is the only workflow advice on this page. Read the unclear items before anything else. They are the short list of places where the project can go wrong for a reason no amount of careful implementation will fix. The rest of the pass is organizing work you would otherwise have done by hand, and if it gets something slightly wrong you will notice while you are building. The guessed requirement is the one you only notice when the client sees it.