Saturday, ten in the morning, and the man on his knees in a stranger's bathroom has the back panel of a washing machine pried open. The grime inside is thicker than he expected, which means forty more minutes he did not quote for.
The customer stands in the doorway with his arms folded. At that price, do you take the drum out?
Depends, he says.
Then take thirty off. Fine.
On the stairs he does the arithmetic again. Forty minutes. Thirty yuan. He has one more job that afternoon and the same question will come, and he will give the same answer, and lose the same thirty.
He knows exactly what the number is. Drum comes out, forty extra. The reason he does not say it out loud is not that he hasn't worked it out. It's the face. The customer's face changes, and the man starts to look like someone climbing the price on the doorstep. So he stays vague, and vagueness keeps costing him thirty at a time.
We build a long-running agent that lives in the cloud. You describe a job in words, it runs on our machines, a finished document arrives in your inbox or your chat, nothing installed. This post is about the sheet he asked for that evening — one page telling people who have already booked what is covered and what is not — and about the half of the first draft that was not wrong so much as inhabited by a different business.
The first half was right on the first try
He typed eight lines at seven in the evening, sitting in his car with his tool bag in the back, because he did not want to explain this again next week. Roughly: I do in-home appliance cleaning, on my own. One sheet for people who have already booked, so they know before I arrive what's covered and what costs extra. Don't be too polite. Sound like a person. Send it to my email.
Next morning there was one page in his inbox.
The first half of it was good, and boringly so. We come to you. We take it apart. We wash it. We put it back. We test it. One line each. Nothing in there that a competent person could argue with, and nothing in there that needed inventing, because every line corresponded to a thing he actually does three times a day.
That is the part everyone expects from a generator, and it is the part that stopped being interesting a while ago.
The second half was the other thing.
The second half was a company he doesn't run
In the second half the page had written: response within two hours.
He cannot do that. One traffic jam is forty minutes. He does three jobs a day at most, and the phone is in his pocket while both his hands are inside a machine.
It had also written: exterior high-rise windows can be arranged separately.
He read that line twice. He has not mentioned exterior windows to a customer in two years. He says it on site, and then he gets stopped in the doorway with the question that costs him the job: why didn't you say so earlier.
Neither sentence is a hallucination in the usual sense. Nothing on that page was invented out of nothing. Both sentences are real, common, correct sentences that appear in thousands of service documents written by companies that have a phone line, a booking system and someone whose job is to answer. The page had reached into the average of how this kind of document is written in the world and pulled out two provisions that belong to that average, and dropped them into the sheet of a man who works alone.
That is the failure mode I care about, and it is not the one people usually test for. Ask a generator for something false and it will usually be careful. Ask it for something incomplete and it will be fluent, because fluency is what fills a silence. Under-specification is not read as a gap. It is read as permission.
Why the wrong half survives review
The two-hour response line survived his first read for exactly the reason it should have been caught: it reads like competence. Politeness passes review. A promise of a fast reply looks like good service rather than a promise you cannot keep, and a provision about high-rise windows looks like thoroughness rather than a service you have never offered.
The thing that makes a borrowed provision dangerous is not that it is wrong. It is that it is plausible enough to ship. It sounds like the document doing its job.
He caught it anyway, and the reason is worth writing down: he was reading for what he could deliver, not for what sounded good. Most review does the opposite. You read your own document looking for sentences that embarrass you, and a borrowed promise never embarrasses anyone. It only embarrasses you later, at a doorway, with a customer holding the sheet.
The corrections were subtractions
He changed five things that morning and cut three pieces of politeness — dear customer, thank you for your understanding, we apologise for any inconvenience. Two of his own rules had never been written down anywhere, and one of them he cannot actually keep and had been quietly assuming for months.
That second one is the interesting item. A rule you assume silently is not a rule. It is a promise you make at the door with your face, and it holds until the first time someone asks you to honour it in writing.
Getting it written down matters more than getting it well written.
He said a version of that himself, and I think it is the whole post. The output quality of a first draft is not the scarce thing any more. The scarce thing is a document that contains every constraint the person actually operates under, including the ones they would rather not say out loud, because those are precisely the ones the customer will find.
Put the exclusions at the top
Then he moved the two characters for "not included" to the very top of the page, on their own line.
Not into a section. Not into the fine print at the bottom, where every service document in the world puts it. To the top, before the offer.
That is a small typographic decision with a large structural consequence, and I have started looking for it in every generated document since. A page that opens with what is covered is a page that has to be read to the end before the reader learns what it costs. A page that opens with what is not covered answers the reader's actual question first, and everything after it is detail.
The people reading that sheet are not comparing vendors. They have already booked. Their live question is not "why should I choose you", it is "what did I just buy, and will there be a surprise on the day". The order of the page follows from who is holding it.
There is a general version of this: the exclusions are the part of a document that carries the risk, and risk belongs where the reader's attention actually is, which is the first screen, not the last paragraph.
"Not included" became "not covered"
By the third revision he had changed the heading. Someone told him they did not understand "not included", so it became "not covered".
Three revisions, and the last one was a vocabulary change rather than a content change. I like that detail more than any of the big ones, because it is the kind of thing no first draft can know. You find it out by handing the page to one person and watching their face.
A correction is a diff, and this one kept its diff
The reason he could do any of this in an evening is that the corrections never had to be re-explained from the beginning. The job stayed the same job; what changed was the page. Five edits and three deletions, one at a time, on a document that already existed.
This is the unglamorous argument for generating a new document rather than editing something you already have: the first version is cheap enough to throw at the wall, and the second version inherits the wall. He never had to describe his trade to it twice. He described it once, badly, in eight lines, and then spent the evening subtracting things the average of the world had added.
He could not have handed it three years of quotes as screenshots. It cannot open those. It cannot read his phone, his notes app, or the photo of the price list he keeps in his tool bag. All it ever gets from him is words — which turned out to be the right constraint, for a reason I did not expect: the words were the part that needed the work.
The measurement that changed
Two months in, his first message back from a customer who received the sheet was not "how much".
It was: does my machine count as the second tier.
He used to open every conversation with the price. Now he opens with which bucket he is in. That is a small sentence and it is the only number in this post: a question that used to cost a doorway conversation now arrives before the man has left his car.
I would not build a dashboard around one customer. But the shape is right: the sheet moved the argument from the doorstep, where he is standing with a wrench and losing thirty yuan at a time, to a text message, where he can answer in one line and keep the price.
A pre-flight list for anything that carries terms
If you are generating any document that another person will hold you to — a scope sheet, a runbook, an SLA, a quote — these are the checks that came out of that evening. They are cheap and they are all about the second half.
- Read the draft looking for what you cannot deliver, not for what sounds weak. Promises survive review precisely because they sound like competence.
- For every line that is a commitment, ask who on your side performs it. If the answer is "someone answering the phone", the line belongs to a business you are not running.
- Put the exclusions on the first screen. Where the reader's attention is, not where the convention puts them.
- Count the lines you never wrote down in words before. Those are the ones no draft can get right, and the ones a customer will find.
- Have one person outside the trade read the heading. Vocabulary is the last revision you will make, and the only one that requires a reader.
What this doesn't solve
He still loses the thirty yuan sometimes. Having the sheet does not make him better at saying the number out loud in a doorway; it just means the number arrives in writing, before the doorway, and the customer has already agreed to it.
The first draft will keep putting fluent, plausible, borrowed provisions into the gap between what you said and what you meant. Nothing in the generation removes that. What removes it is a person reading the second half for the thing they would have to go and do.
And the page is still a piece of paper in the lid of a toolbox, wrapped once around with clear tape, corners worn white, three revisions deep. That is what a good generated document looks like after it has been used: not pristine, corrected.
Where it sits
CloudPal runs long jobs on our machines and hands back a finished document. Nothing to install, nothing asked of your computer, nothing read from the files you already keep. You describe the job the way you would describe it to a colleague, badly and out of order, including the parts you only notice on the second reading, and the result arrives where you already look, on a schedule.
It is in limited preview: new accounts get a dollar of credit, enough to run something real, and the number of new accounts per day is capped. It costs a few times less than the comparable tools and you pay for what you use, which matters most for the documents nobody wanted to write in the first place.
If the thing you are generating carries terms — for yourself, for a customer, for whoever is on call at two in the morning — the property worth measuring is not how the page reads. It is whether every line on it can be performed by the people who actually exist on your side, and whether the part you cannot perform is on the first screen.
CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.
Earlier in this series: it can't read anything on my laptop, a direction is not a spec, four sentences in, seventeen pages out, the requester is not the reader, the first run is a demo, the ninth is the product, the meter, not the price, we deleted the install step.
Top comments (1)
The insight that "under-specification is read as permission" is the most precise description of LLM failure modes I've seen. It's not hallucination—it's the model defaulting to the statistical average of how those documents are usually written, which happens to belong to a business with a phone line and a receptionist.
The checklist at the end is gold, especially the "read for what you cannot deliver" rule. Most review reads for embarrassment, and borrowed promises never embarrass anyone until the customer asks.
One question: when a user does provide explicit negative constraints upfront (e.g., "I cannot guarantee a 2-hour response"), does CloudPal actively mask or penalize those tokens during generation, or does it still rely on the prompt to steer away from the default statistical average?