The request came out as one long sentence, and it was a good sentence: every morning at seven, three to five things that have to do with her — weather, food prices, buses, the doctor; no words she won't understand; one item, one short paragraph; short enough that she can read it out loud. Then, at the very end, almost as an afterthought: not too long.
At twenty past seven the next morning the phone rang. She had read it, got halfway, gone out to buy vegetables, come back, and finished it. The verdict travelled back word for word: she went out to buy vegetables halfway through. Make it shorter.
There is a version of that exchange that is a story about a mother, a son, and a tablet he bought her six months earlier which now has two uses left — the photos and scrolling. This is the engineering version, and it starts with the thing that most scheduled systems are built to hide: the person who asks for the work is not the person who receives it.
Three people in every deliverable
When you build a nightly job for yourself, all three roles collapse into one body. You write the spec, you receive the output, and you notice when it is wrong. Every feedback loop you design is secretly assuming that.
Put a second person in the loop and all three roles separate. The son files the request. The mother receives the result. Neither of them sees what the system did in between, and the two of them do not agree on what "good" means — he thinks it means informative, she thinks it means short enough to finish before the vegetables.
Every consumer-facing recurring job has this shape. A weekly summary for a client. A digest for a team that never asked for it. The interesting engineering is not in the generation step at all. It is in the two gaps: spec-to-reality, and delivery-to-acknowledgement.
The spec arrives second-hand, and it is wrong in a specific way
Read the sentence he typed again. It is not vague. It contains a length constraint, a vocabulary constraint, a format constraint, a topic scope, and a delivery time. If a PM handed me that in a ticket I would consider it unusually complete.
It was also wrong in exactly the dimensions nobody writes down.
The topics were right. She did want to know about the road being dug up, the cold coming, eggs going up again. The register was right — flat, concrete, no adjectives doing work. What was wrong was length and vocabulary, and those two are almost never in a first-hand spec because they are invisible to the person writing it. He knows what "reserve ratio cut" means; it has never once occurred to him that it is a phrase a person might have to stop and decode while standing in a kitchen at seven in the morning.
That is the general form of the problem: second-hand specs are directionally right and dimensionally wrong. The requester can tell you the subject. Only the reader can tell you the size and the reading level, and the reader is not in the planning meeting.
The first week, she called after reading and it was nearly always the same question: what does this one mean. He explained it twice, and the second time he was vague himself. So he sent those two words back — don't use words like this. Say it the way she would say it — and the next day the sentence was: the banks have a little more money they can lend out.
The system had not become smarter. Somebody had translated one constraint correctly. "Say it the way she would say it" is a real, checkable requirement, and it took a human two rounds and a moment of being vague to find it.
An unopened envelope is not an error
Here is the failure mode that almost cost this thing its life, and it has no exception attached to it.
She had a mail icon on her phone. She had never opened it. If the brief had been wrong, or stopped arriving, or started arriving at nine, nobody would have filed anything. She would simply have stopped opening the envelope, and the system would have reported success all day long. No stack trace. No retry. No alert. A drop-out with a clean bill of health.
That is the defining property of a scheduled deliverable aimed at someone who is not an engineer: the failure is silence, and it is indistinguishable from the success state on every dashboard you own.
You cannot instrument this with opens. In our case we could not instrument it at all — the delivery channel is an inbox we do not own, so what we get back is a complaint or nothing. What we could do was watch the only signal that mattered, which is that she started calling him at seven with what's new today, and then started taking the phone downstairs to the pavilion where three people sit every afternoon, retelling the morning's items and ending with: I read this this morning.
That is the metric, and it is a bad metric by every standard we usually apply. It is not continuous. It is not per-user. It arrives through a phone call to a person who is not a customer. It cannot be aggregated. But it is the only reading that distinguishes "delivered" from "landed", and the difference between those two is the whole product.
The line we wrote on the whiteboard afterwards: you can tell whether something landed by whether it gets retold.
A correction has to become a diff
Both corrections he sent were complaints, not specs. "Too long" is not a number. "Don't use words like this" is not a word list. If you treat them as prompts — re-roll the last output with a stricter instruction — you fix tonight and rebuild the same complaint next week, with the extra cost that the two outputs now disagree about what the instruction is.
What we wanted was for each correction to land somewhere durable: the instruction that produces the brief changes, the change is visible to the person who asked, and the next run inherits it. Feedback becomes a diff against the request, not a patch against the artifact.
That sounds like a small refactor. It is not, because it makes the request a first-class object that accumulates edits and has to be readable by a non-engineer. He has to be able to see "shorter" and "plain words" in there and recognise them as his own words, otherwise the next correction will contradict a rule he never knew he had set. Versioning a prompt is easy. Versioning somebody's intent, in their own language, is a different piece of work.
A few days in, she was picking for herself — anything that had nothing to do with her, she skipped. That is the state you are actually aiming at, and no correction he sent got her there. The accumulated diffs did.
Deliver it where they already are
The reason this ever worked is one line in the story: nothing to install. Her phone already had a mail icon. He showed her once — tap the envelope, the top one.
Every delivery channel is a trade, and it is worth being explicit about the one we took. An inbox we do not own means we cannot count opens, cannot render-test every client, cannot guarantee the layout, and cannot page on failure. In exchange, it asks nothing of the reader beyond a gesture she has been making for twenty years.
The install step is not a technical cost. It is the churn point, and it is where the people you are trying to reach quietly leave. The version of this product that required an app, an account, and a login before the first brief would have produced exactly zero retellings, and we would have learned that from a dashboard showing healthy delivery.
The words you can't bluff
One exchange in the first week is the one I keep coming back to.
She read the thing about the reserve ratio, got it in the plain version, and then asked one more question: does that have anything to do with my savings? He could not answer. So he said what was true — that one isn't in there.
This matters more than it looks. A system that has to appear omniscient will fill that gap, and the sentence it produces will be plausible and wrong, and it will be believed, because it is seven in the morning and she has no way to check. The only honest move is to have a way of saying "not covered" that does not read as a bug.
That is a design constraint on the generator, not a disclaimer: what it produces has to be traceable to something it actually assembled, and where the answer is outside that, the output has to be allowed to stop.
What we would check first next time
If I had to compress this into a pre-flight list for the next scheduled thing we build for somebody who is not us:
- Who reads the output, and have they said anything about its size? If not, the first version will be too long, and the person who asked will not be the one to notice.
- What does failure look like from the reader's side? If it looks like nothing, we have no telemetry and need a human signal instead — a call, a reply, a retelling.
- Where do corrections go? If the answer is "into the next prompt", we are building the same week over and over.
- What does the reader already have open on their phone? That is the delivery channel, and the rest is a download we are asking them to make for our convenience.
- What can it say "not covered" about?
None of these are model questions. All of them were the difference between a job that ran and a habit that formed.
Where it sits
CloudPal runs long tasks on our machines and hands back a finished document — nothing to install, nothing asked of your computer, nothing read from files you already have. You describe what you want in one sentence, including the parts you did not think to specify; it goes and does the reading and writing; the result arrives where you already look.
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.
If you are evaluating it as an engineer, the property worth testing is not the prose. It is whether the second week's version knows what the first week's correction was — and whether the person on the other end can tell you about it without opening your app.
CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.
Earlier in this series: the first run is a demo, the ninth is the product, the meter, not the price, the request was one sentence, what breaks when an agent has to keep an appointment, and we deleted the install step.
Top comments (0)