A friend of mine, father of two, told me this last month and I've been carrying it around since.
On the third night he was telling them a bedtime story and fell asleep halfway through it. The nine-year-old shook him awake. Dad, what happened next? He couldn't say. He'd lost his place in his own story. The ones he'd already told, they remembered — and they would not sit through a repeat. Night two needed a new one. Night three needed another.
What makes that funny, in his telling, is not the falling asleep. It's the accounting. By the third evening the count had quietly turned into a requirement, and nobody wrote it down.
This piece is about that requirement, because it is the one part of a recurring task that is not about the model.
A story is a file. A nightly story is a state machine.
One story is a generation problem. You give it a premise, it gives you a story, you read it aloud, done.
A story every night for a year is not that problem repeated 365 times. It's a different problem, and the difference has a name: something has to know what last night was.
Attended tools hide this by using you as the storage. You remember what you asked for, you notice the repeat, you steer around it. Unattended, nobody is holding that thread. The run starts, produces something, ends. Nothing is left behind unless the system deliberately leaves something behind.
So the first design question for anything that runs on a schedule is not "how good is the output". It's "where does yesterday live".
Three ways to get continuity wrong
Ask for novelty and hope. "Tell me a new one" does produce different words every night. But novelty is not continuity. Night one, a bird that isn't very good at flying. Night five, the bird clears the roof. Night seven, it's a different bird that has never flown. A six-year-old tracks world state more carefully than most test suites I've seen. The output is fluently novel and quietly incoherent, and nothing anywhere raises an error.
Put the history in the prompt. Keep the last N deliverables and prepend them. This works at night two, which is exactly the trap. By night nine the context is eight documents long, and the thing that actually matters is three facts: the bird's name, that it flew three metres on day three, and that the ending is a question you can answer out loud. Signal-to-noise rots, cost climbs, and the failure stays silent, because the model fills the gaps confidently.
Template the series. Keep the shape, vary the slots. It never repeats, which is technically the requirement, and it's 30 variations of the same evening. The child notices. The parent notices first.
All three share a mistake: they treat the series as a repetition of the run instead of a thing the runs are contributing to.
What we actually needed: a record written for the next run
Not a transcript — there is no conversation to keep. One sentence in, one document out, every night.
What we needed was smaller and more specific: a structured record per person. What was delivered, when, in which language, plus the handful of world facts that must not drift. Two properties matter more than the format:
It's written by the run, for the next run. The write side is easy and it's the side everyone builds first. The read side is a separate thing, with its own tests, and the bugs live there.
It's bounded. A summary of what must stay true, not an archive of everything that happened. The distinction sounds like housekeeping. It's actually the design: unbounded history in the prompt is the failure mode above, moved inside your own storage.
The metaphor I keep coming back to is that this is not memory of everything. It's memory of what has to stay true.
"One story for each of them" is not one request
The sentence he typed contained two deliveries. Chinese for the six-year-old. English for the nine-year-old. Not too long, nothing scary, end it so they can fall asleep.
A nightly job that produces two artifacts. This is where unattended systems usually get sloppy, in a way that looks like good engineering and reads as neglect to a person: they make the batch the unit.
If one of the two succeeds, the batch is "partially successful". That is a meaningful state to a dashboard and a meaningless one at half past eight in a bedroom. One child has a story. The other has a promise.
So two rules fell out of it, and they are the same rule seen from two sides: the unit of the promise is the child, and the unit of reporting has to be at least as fine as the unit of the promise. Per recipient: delivered, late, or not delivered. "Mostly done" is not a state a person can act on.
It also, incidentally, is the whole argument for charging per artifact rather than per batch: one document, one line, and the line can name which document. I've written about the meter separately, so I'll leave it there.
The failures that have no error message
Continuity bugs are a strange class. Nothing crashes. The logs look fine. The output is good, and wrong.
Three we had to build against.
The repeat nobody catches. Within one night, a duplicate is a data problem and there are a dozen ways to see it. Across nights, it's invisible to the system and obvious to a six-year-old. The only defence that held was to compare against what was actually delivered — the artifact the person received, with its text — and not against what the run intended to deliver. Intent is not evidence.
The stale world. The record gets written, the evening goes out, and the next night the story starts over. This is the write-only-memory bug, and it doesn't look like a bug: everything returned 200. It looks like a system with amnesia and good manners.
The late artifact. One night the ninth story arrived at eleven. The text was fine. The evening was gone. On a promise that is about a moment — eight thirty, in bed, lights about to go off — late is not a slower success, it's a different outcome, and the silence around it is the expensive part. Delivering at eleven as if nothing happened is a worse product decision than saying, when we know, that tonight it will be late.
That last one has a cost shape worth naming, because it's the opposite of most systems: being available all day costs nothing, since idle time isn't work and nothing accrues while it waits. Being on time is the expensive part. Which means the honest engineering budget goes into the clock and the record, not the prose.
A test you can run in a week
If you're evaluating anything that claims to do something every day, the review question is not "was day one good". It's this:
- Ask for a daily output, then on day five ask what day four said. Can it tell you, and does the answer match the file you actually received?
- On day three, break it. Does it say "failed", does it say nothing, or does it invent a reason?
- Does day five continue day four, or restart from a template that happens to be different every time?
- Then leave it alone for two days. Does it invent a backlog, or does it quietly skip?
Four questions, and none of them are about writing quality. That's deliberate. Fluency is cheap now. Continuity isn't.
What this doesn't solve
Continuity is not quality. A perfectly coherent series can be boring, and a system that remembers everything about the world can still write a story nobody wants read twice.
One sentence is not a spec. "Not too long" means something different to a six-year-old and a nine-year-old, and the only way to resolve it is to fill the gap with a default you didn't choose. Good defaults are still guesses, and the honest version of that is to say so rather than present the result as what you asked for.
And arrival isn't value. The ninth story showing up on time proves the machinery works. It doesn't prove anyone was listening. The part we can build is the machinery.
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; it goes and does the reading and writing, and hands you the artifact. One run, one charge, and nothing accruing while it waits.
It's in limited preview: new accounts get a dollar of credit, which is enough to run something real, and the number of new accounts per day is capped.
If you're evaluating it as an engineer, the property to test isn't the prose. It's whether the tenth night knows what the ninth one said.
CloudPal.TuringCorp.net - create an Agent Pass, sign in, and say what you want done.
Earlier in this series: 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)