DEV Community: TuringCorp

We never wrote our format down, so it took our old drafts as the spec

TuringCorp — Thu, 29 Oct 2026 15:13:06 +0000

We never wrote our format down, so it took our old drafts as the spec

The thing sat in front of me for a couple of extra seconds before I sent it. What I was looking at was the date field.

It said "Wednesday".

That is how our team writes dates. For a job scheduled by the day we never write the month and the date; we write the weekday, because then how many days are left is right there and nobody has to do the subtraction. It is a provincial habit. Nobody thought it was worth explaining to anyone, and nobody had ever said it to the thing.

I had handed the job over a little past ten at night. Opened it in the browser, pasted a few pages in, said one sentence: needed by morning, one page, not too stiff.

The pages were ones I had stitched together myself. A stretch from here, a stretch from there, and in the middle two lines written to a colleague that I never deleted. Pasting them in I felt a small unease. This messy — it will probably ask.

It didn't ask.

The first pass I put down to coincidence. The document was about that Wednesday. Writing "Wednesday" was not evidence of anything.

So I checked the names. A handful of clients, a handful of ways we call them, not one of them off — including the one we ourselves keep writing in the wrong order.

Then I read the page again from the top. How the unfinished items were marked. Which sentence came before which. Those were in our places too, and that is harder to explain away. It was like someone took an old draft of mine, copied it out, and copied it cleaner than I do.

Which means the interesting question is not whether it got lucky. It is where the rule came from, because we never typed it.

What was actually in the input

I dug out what I had pasted that night. Not much. The previous one-pager, which we wrote. A few lines of instruction. And a note copied over from a chat log, half-coherent, messy enough that I had winced at it while copying.

"Wednesday" was in there. The names were in there. The note was in there too.

Put those pages beside what came back and what it did is plain: we never gave it a style guide. We gave it a pile of our own old writing, and it used the pile as the ruler.

This is the part I want to write down properly, because it is a small engineering event that happens quietly and then never gets discussed.

An example is a specification you did not write

In ordinary software the spec comes first. Somebody writes down what the output should look like, the implementation is checked against it, and when they disagree you go and read the spec.

Here the order was reversed. The artifacts came first — they existed because we had been doing the work for years — and the rule was derived from them at the moment of use. Nobody wrote it. Nobody reviewed it. It has no version number and no owner, and it is nonetheless being enforced, accurately, on every job.

Anyone working with these models does a deliberate version of this every day: you show a couple of examples and ask for the same shape back. The difference is that we did it by accident, with dirty material, and the material was our own past output rather than something we had cleaned up for the purpose.

There is a real distinction hiding in that, and it survives outside this particular tool.

An instruction is a claim. It can be short, but it is made of words someone chose, and you can argue with it: you said the dates should be weekdays, this one says 21 October. An example is a sample. You cannot argue with a sample. You can only be consistent with it, or fail to be. When a system derives its rules from examples, the rules are as good as the examples and as visible as the examples — which is to say, exactly as visible as the pile of paper you happened to paste in.

Ours was not a clean pile. It had two lines addressed to a colleague in the middle of it, an unfinished thought, a note whose beginning did not connect to its end. It generalised over all of that anyway, because the noise was not noise to it. It was more evidence about how we write.

What it could see, stated precisely

There is a precondition that makes the rest of this falsifiable, so it belongs in the middle of the post rather than in a footnote.

It does not read the things on our computers. The old drafts, the folder that keeps thickening, the several versions we later put on a drive — it can see none of them. All it has is words: what we pasted in this time, plus what we said over the previous handovers.

So everything it knows is something we wrote or said ourselves. It was not being clever and it did not peek. It took what we had written and treated it as what we are like.

That bound matters for a practical reason. If it had produced a rule we had never displayed anywhere, that would be a different and much stranger claim, and I would not believe me either. Every rule it followed was visible in the material we handed over. What is surprising is not the source of the information. It is that a pile of old output was enough to reconstruct a style nobody had ever articulated, including the parts we would have got wrong if we had tried to write them down.

The paragraph that stopped being written

We had always assumed we had no fixed style. Lay the pile out and it is plain that we do have rules: dates as weekdays, clients under the name we call them, unfinished items marked with that one sign, the soft sentence first. None of those rules is in any document. Not one was agreed in a meeting. They came out of doing the work and they smoothed over with use.

What changed is on the handover end.

Handing over a job, I used to add a paragraph at the end: same format as last time, dates as weekdays, don't change our names. Forty words, written fluently, eyes closed, every single time.

Now that paragraph often will not come. What would I write? Last time it already came that way.

So we save a few dozen words per job. That is the visible number, and it looks like the whole story: less instruction, same output, nothing else moved.

The invisible half is that the paragraph was also the only written record of the format. It was the one place where our house style existed as a sentence a person could read, quote, and disagree with. We deleted that copy one handover at a time, and nothing broke, which is exactly why nobody noticed. If you asked me right now to hand you a page listing everything we have taught it about our writing, I could not. The corrections are not stored as a document. They are stored as behaviour.

The test we did run

Two more jobs went through after that one, unrelated to it. The date field still said "Wednesday"; the unfinished items still carried the same mark. No drift, at least not on the surface.

I also tried changing it once, swapping "Wednesday" for "October 21". Two lines in, I changed it back. Things that fit the hand do not move. Read that honestly and it is not a story about the tool. It is a story about us: the standard survived because it was ours, and the only reason it is still standing is that nobody has yet had a reason to want a different one.

Which is fine until the day we do. Then the change has to be argued against a rule that is not written anywhere, by someone who cannot see it, in a document that only exists as the shape of the last thing that came back.

If you are building something that accepts pasted work

Four things I would want to know before shipping this, in rough order of how much they would have saved us.

Decide whether the schema by precedent is intended. If your product accepts pasted artifacts, and something downstream infers rules from them, then your real schema is the artifacts. That can be the feature. It should not be the accident.

Build the render, not the log. A log tells you what was said and in what order. It does not tell you what the system currently believes. Those are different objects, and the second one is the one a person can review. The cheapest useful version is a view that answers "given everything so far, what would it do with this job now" and expresses it in sentences someone could disagree with.

Test with a job from a different drawer. Rules derived from examples travel. Ours went from a one-pager to an outline and a set of instructions without anyone asking whether it should. The check is not whether the next similar job comes back right; it is whether an unrelated job comes back unmarked.

Measure words saved, but price them honestly. Saving forty words a handover is real and it compounds. The thing you spend is reviewability, and it does not appear on any dashboard, because nothing fails. You just slowly stop being able to say what your own standard is.

Where this sits

CloudPal runs long jobs in the cloud and hands back a finished document. Nothing to install, nothing asked of your computer, nothing read from the files you already keep — it works from what you give it, in words. You describe the job the way you would describe it to a colleague: badly, out of order, including the thing you only remember on the second telling.

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.

The uncomfortable part is not that it copied us. It is that it copied us accurately enough that we stopped saying what we wanted. That trade is worth making — the output is better than what our own instructions produced — but it should be made on purpose, by someone who knows the paragraph they are about to stop writing was the spec.

CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.

Earlier in this series: it guessed a number, we told it off, and every number after that got checked, correct is a low bar, the same three facts, in a different order, the second half of the draft was policy we never agreed to, 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.

It guessed a number, we told it off, and every number after that got checked

TuringCorp — Wed, 28 Oct 2026 15:15:26 +0000

It guessed a number, we told it off, and every number after that got checked

A few weeks into using it, it handed us a number.

Not a wrong number. A number it had not looked up. It came back folded into a sentence the way numbers do, and it was the kind of figure that only exists in a document somewhere — a count, a quantity, something with a source. It had reconstructed it from memory instead of checking.

We told it off. The words were not gentle, and we still remember them, which matters for what follows:

You didn't check this yourself. You inferred it from memory, and that's not good. Before you do anything with numbers, check first.

It has not guessed a number since. Not because we keep reminding it — we have not said it a second time. Every job since then that involved a figure, it went and checked, and then answered.

That is the part we did not expect, and it is what this post is about. A sentence said once, in irritation, in a few words, behaved like a rule that had been in force the whole time. And because it worked, we started paying attention to the other corrections we had made that month — and found we had been running an undocumented policy layer for weeks without noticing.

The month, in three sentences

Our own work has been going through it for over a month now: drafts, decks, numbers, the emails that are hard to answer. Long enough that the first try is no longer interesting. What is left is habit.

Three things happened in that month. We taught it something. We praised something. We told it off once.

The teaching was about writing. Our drafts came back sounding wrong when read aloud: one short clause a line, conclusion first, three parallel phrases, and the last line was "in short". We said: don't be so structured, it reads too much like AI, we need it to sound like a person.

The praise was one sentence: this one's good. Not a speech.

The scolding was the number.

None of the three was a rule we sat down to write. Nobody opened a settings page. Nothing went into a document. We said each one once, and the next job arrived carrying it.

A correction has no scope field

Here is what we missed while we were saying the writing one.

When we said "don't be so structured", we were thinking about drafts. Our drafts. It heard a rule about output.

The jobs that had nothing to do with sounding human — an outline, a set of instructions, a reply — came back carrying the same habits. Clauses of uneven length. No rush to the conclusion. A pause where a pause belongs. In an outline, where structure is the point, it still arranged the material that way, just less visibly.

We never said it a second time. We never said "I meant drafts" either.

That is not the model being sloppy. It is what a correction is. When you hand a correction to a person, you hand them the situation along with it: they were in the room, they know which document you were holding, they know what you were annoyed about and what you were not. The sentence arrives with attachments.

Hand the same sentence to something that was not in the room and the attachments are gone. What is left is the widest reading the words will support. Don't be so structured has no document type in it, no expiry, no project. So it applies to everything, and it applies forever, and it does so immediately — there is no committee, no review, no changelog entry.

If you build agents that accept corrections, you are accepting an input with no schema. Almost everything else you take in has one: a config value has a name and a type and a default. A correction has a sentence, a temperature, and a context the person saying it will not describe, because to them it is obvious. There is nowhere in that input to put "this applies to drafts only". The field does not exist.

Two ways to be wrong, and the worse one is the default

A correction can come out too narrow or too wide.

Too narrow: it applies to the exact case in front of you and nothing else. You correct the same thing every week. The agent is obedient and useless, and you end up writing the paragraph of context again, which was the thing you were trying to stop doing.

Too wide: it applies everywhere. You correct one output and it reorganizes four document types.

Only one of these is a real risk, and it is the wide one — because widening is exactly what makes the thing valuable in the first place. An instruction that only works once is a macro. Something that generalizes from one sentence to the next job is the entire point. You cannot ask for generalization and then complain when it happens; you can only try to control what gets generalized.

The symptom or the test

After that month we started sorting our corrections into two shapes, and the split explains both outcomes.

Some corrections name a symptom: this reads like AI. Too structured. Too long. Too formal.

Some corrections name a test: before you do anything with numbers, check first.

A symptom describes one output. To act on it, the agent has to work out what the symptom was a symptom of — voice, rhythm, length, formatting — and then decide where that applies. That inference is where scope comes from, and it can land anywhere. Our "too structured" complaint could reasonably mean "vary sentence length" or "don't front-load the conclusion" or "stop using parallel triads", and those three have completely different ranges. It picked a mixture. We never found out which, because we never wrote it down.

A test is portable. It names the situation ("with numbers"), the moment ("before you do anything"), and the action ("check first"). It carries its own scope and its own trigger inside the sentence. There is nothing left to infer. Which is why it transferred perfectly to jobs we never mentioned, and why we have not had to repeat it.

That split is now most of our method. When something comes back wrong, we try to say the test rather than the symptom — not "this is too long" but "if it is going to be read on a phone, cut it until the first screen carries the point". The test costs more to formulate. It is also the only version that survives being said once.

The writing correction was a symptom and it over-applied. The number correction was a test and it landed exactly. We would like to tell you we designed it that way. We did not. We got lucky on the second one because the thing that went wrong was concrete enough that the fix could be phrased as a procedure.

Praise is the same mechanism with the sign flipped

One version of a draft was genuinely good. We said so, in three words, and moved on.

The next job came out the same way, one step further. We had not asked for that. It went there on its own.

At the time we did not think about it. Looking back, it took "good" and treated it as a direction, which is exactly what a person does: telling a colleague that a thing was good is telling them what to keep. The mechanism is the same one that carries a scolding. There is no sign bit on it. Both are gradient.

The difference we noticed is which shape they take. A negative correction is easiest to say as a test, because you usually know what should have happened instead. A positive one almost always comes out as a symptom — "this one's good" is a description of an output, and what made it good is exactly the part you cannot decompose. Which makes praise the correction that generalizes least predictably of the three, and the one we now keep shortest.

What we stopped writing down

The change that is actually measurable is on our side: the briefs got shorter.

Handing over a new job used to mean a paragraph of context, the way you brief an outside contractor. Here is what you are doing, here is the background, mind these points. Now we often stop halfway through writing it — did we say this last time? We did. So we don't.

We save a few dozen words per job. In exchange we gave up the ability to read the policy.

That is a real loss, not a rhetorical one. If you asked us right now to hand you a page listing everything we have taught it, we could not. The corrections are not stored as a document we can open and audit. They are stored as behavior. The only way to see the current state is to hand it a job and watch what comes back — which is a terrible way to review anything, and it is the way we do it.

So we changed one habit instead. When we deliberately teach something now, we say it in a shape that would survive being written down — not because we write it down, but because a sentence clear enough to be a rule is also a sentence that generalizes like one, and skips the part where we find out three weeks later what it decided we meant.

The asymmetry

Someone on your team gets tired, drifts, and one day stops taking your word for it. The thing does not. It keeps the sentence you said, in the form you said it, and waits for you to come back.

That is a feature until the day you change your mind. Then there is no decay to wait for. You are not overwriting a line in a file; you are adding a correction to a correction, and the older, more specific one does not politely step aside. The second sentence has to be at least as precise as the first, or the first still wins.

Which is the cost of the whole arrangement, stated plainly: corrections are the cheapest training signal a system like this will ever receive, and the only one that arrives with no schema, no version history, and no way to inspect the current state. If we were starting over, the one thing we would add is not a memory store or a rules file. It is the ability to render what the thing would do now — not a log of what was said, but the current shape of the policy, in sentences a person could disagree with.

Where it sits

CloudPal runs long jobs in the cloud 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, out of order, including the thing you only remember on the second telling — and 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. It costs a few times less than the comparable tools and you pay for what you use.

If you are building an agent that people will correct, the question worth answering is not whether it remembers. It is whether the sentence they said can be turned into a test by the time the next job arrives — and whether you would still agree with that test a month later, when it has quietly become the most specific policy in the system.

CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.

Earlier in this series: correct is a low bar, the same three facts, in a different order, the second half of the draft was policy we never agreed to, 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.

Correct is a low bar: a document has to be executable by someone who won't ask

TuringCorp — Tue, 27 Oct 2026 15:11:31 +0000

Correct is a low bar: a document has to be executable by someone who won't ask

The page came back at seven in the morning. Platform, transfer corridor, Exit B2, fifty metres east after leaving the station. Complete, ordered, and true. Every step was in the right sequence and none of it could be used.

The person waiting for it was seventy-three, arriving by high-speed train from a county town, changing once in a city she had visited twice in her life. The man who ordered the document was her son. He has lived in that city for eleven years and goes through that station several times a week. He had never once thought about which way you turn when you come out.

This post is about the eleven hours between that page arriving and it becoming something a person could actually walk through, and about what we changed in how we read our own output afterwards. Not the model — the document. The part nobody puts in the schema.

What was asked for

The request went in as a paragraph to a phone, not as a form. That matters less than it sounds. What matters is what he put in it.

He told it her age, the route, and the change in the middle. He told it that she reads fine but that words like "transfer" and "Exit B2" mean nothing to her, and that she won't ask anyone either — two years earlier she had asked twice, got two different directions, stood there for half an hour, and in the end followed a woman with a suitcase. He asked for a step-by-step account from getting on the train to getting out of the station. No jargon. Say where to wait, which way to walk, and what to look for before turning. Send it to the inbox by morning.

That last clause is the whole job. Not "draft me some travel tips" — a deliverable with a deadline, a shape, and a recipient. Our agent runs long jobs in the cloud, on our machines, and returns a finished document to an inbox or a chat; nothing is installed and nothing is read off the computer you are sitting at. So the person asking doesn't have to stay at the keyboard while it works. He asked at eleven at night and went to bed.

What came back at 07:00 was, by any reasonable measure, correct. It had understood the journey better than he had: the platform, the transfer corridor, which exit, how far after the exit. He read it once and changed every one of the words that carried the actual information.

"Exit B2" became: when you come down the stairs there's a man selling roast sweet potatoes, go left past him.

"Transfer corridor" became: follow the people with suitcases, five minutes, don't turn off.

Jargon is a compression the reader cannot decompress

"Exit B2" is not vague. It is the most precise string available to anyone who has been in that station. It is short because the reader is assumed to already hold the map — the letters are just the address of a place already in their head. Every technical term works the same way: it is a compression that is lossless only for people who own the dictionary.

The mother does not own the dictionary. To her, "Exit B2" is a string of characters that has to be matched against the world, and the world, standing in a packed concourse at nine in the morning with a suitcase, offers her a great many blue rectangles.

The substitution is not "use simpler words". A simpler word for Exit B2 does not exist, because the thing being described is not a word, it's a location in a visual field. The replacement has to name something the reader will see without being told to look: a man selling roast sweet potatoes, people with suitcases, stairs. It is a different kind of sentence — an instruction anchored in the reader's field of view rather than in the building's coordinate system.

That is why the rewrite had to be done by a person standing in neither place, and could not have been done by the model. Not a limitation to work around — a division of labour. The model had the coverage: fourteen steps in order, the parts he would have forgotten to mention, the escalator question he hadn't thought of. He had the vocabulary: which landmark in that station is stable, which one is only there at eight in the morning, what his mother would actually look at. He printed it on one sheet at the largest type the page allowed.

The failure mode people expect here is a bad draft. The failure mode that actually happened is a good draft — one that was complete enough to stop him from rewriting it and wrong at exactly the words that carry the route. Complete output is more dangerous than thin output, because competence at the shape of a document reads as competence at its content.

"Follow the crowd" and the fork it hides

The night before the trip he got off work and walked the route backwards at the station, from the exit to the platform, sheet in hand.

At the first fork he stopped. The sheet said: follow the crowd. Which is true. It is also exactly wrong at the one place where the instruction does work, because "the crowd" splits two ways there — upstairs is the metro, to the right is the taxi rank. Every person in front of her would be following a crowd. Half of them would be following the wrong one.

"Follow the crowd" is the sentence you write when you have never stood at the fork. It survives an audit by reading. It dies on contact with the place. He changed it to follow the people with suitcases.

This is the part worth taking to any long-running agent that hands work back to a person. Reading the output is not verification, and no amount of the model re-reading it would have caught this. The only verification that finds an ambiguity like that is acting on the instruction in the environment where it will be used. For a route, that means walking it. For a procedure, it means doing it once, on a real object, with the document open. For a document meant for someone else, it means the person who will act on it rehearsing it, not reading it.

We used to say a document was done when it was checked. Now we ask a second question: what is the first step of this document that cannot be carried out by someone who is alone, in a crowd, with no way to ask a follow-up question? Whatever that step is, it is the only step that needed the work.

The last line is the error handler

The draft ended with a line of its own: If you have difficulty, please ask a member of station staff.

He deleted it.

Not because it is bad advice. Because it is a fallback that assumes something about the reader that is not true: she won't ask. Two years earlier she had stood in that same station and asked twice and got two answers, and the experience did not teach her that asking works. An error handler written for a user who will report the error is only an error handler for that user.

Here is what happened instead. Thursday morning he was in a meeting with his phone on silent. When it ended there were three missed calls. He ran downstairs — ten minutes from the office to the station — and the exit was packed and she was sitting there, on the edge of the steps, on her own suitcase, the sheet spread across her knees with an unopened bottle of water holding it down.

She had followed the sheet. It said nothing about what to do if nobody picks up, so she did the one thing that was still safe: she stopped, in a place where she could be found, and stayed there.

He added the line afterwards, at the bottom, after all the steps:

When you get there, stay put, call me, I'll come down and get you.

Every instruction handed to a person acting alone needs a terminal state. Not a general one — a specific one, naming the actor, the action and the place: stay here, do this, wait for me. Written after the fact, from the failure. Which is the only place it could have come from, because the failure branch is exactly the part of the plan that the person who can be called never needs to think about.

That is the honest limit of what a document can be told in advance. The request said "no jargon, say where to wait, which way to walk, what to look for before turning" — it did not say "and what do I do if my son doesn't pick up", because at eleven at night he did not know that was the shape of the hole. He knew it at nine the next morning, holding a phone with three missed calls on it, and the sheet still has that line at the bottom.

What survived

On the way back she asked who wrote the sheet. He said: the agent wrote it, I changed it. She asked whether it was one of those monthly ones. He said you pay for the one time you use it, several times less than the monthly ones, and when you're done you close the page.

She said oh. Then she folded the sheet twice and put it in her bag. He said you don't need that any more, I'll write you a new one. She said she'd keep it. She'd be coming again.

The following Sunday she called to say she had put it under the glass on top of the TV cabinet.

The document that worked was not the one that came back at seven. That one was correct and would have put a seventy-three-year-old in front of a blue rectangle at nine in the morning. The one that worked had three of the model's sentences replaced with landmarks, one ambiguity fixed by walking backwards, and an error handler added by the person who failed. The agent's contribution was the thing a person cannot do alone: hold fourteen steps in order, at one in the morning, without forgetting the escalator.

Both halves were necessary and neither half is impressive on its own. That is most of what we have learned running a long-running agent for people who will not file a bug: the deliverable is not the page, it is the recipient's successful action, and there is no way to check the second thing from inside the first.

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, out of order, including the thing you only remember on the second telling — and the result arrives where you already look, on a schedule, whether or not you are at the keyboard when it lands.

If you are building anything that turns a request into instructions another person has to carry out, the property worth measuring is not whether the output is complete. It is which sentence in it assumes a reader with a fallback path — and whether the reader you actually have possesses one.

CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.

Earlier in this series: the same three facts, in a different order, the second half of the draft was policy we never agreed to, 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.

The same three facts, in a different order

TuringCorp — Mon, 26 Oct 2026 15:11:40 +0000

The Same Three Facts, in a Different Order

The form had a line marked Work Experience. The woman at the kitchen table stopped there and asked her daughter how you fill in the last twenty years.

Leave it blank, the daughter said. She didn't. She wrote one word instead — homemaker — then looked at it and said that doesn't count, and crossed it out.

There was a job going at the community canteen: kitchen help, plus carrying meals up to a few elderly people. Go and try, the daughter said, they don't care about age. I haven't had a job in twenty years, her mother said. Just go and sit down and answer what they ask you.

The interview was set for ten on Thursday morning.

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 Wednesday night before that interview — four sentences typed into a phone, one page back in the morning — and about the single decision inside it that mattered, which was not a sentence at all. It was the order.

The input was a person talking, not a record

Wednesday night she practised in the kitchen, a pot of radish on the stove, the range hood running. She turned the flame down and introduced herself to the hood. My name is—

The next sentence went round in her mouth and would not come out. She turned the flame down another notch and started again. My name is— I'm fifty-one this year, and I haven't had a job in twenty years. Then she ran out of words, and the radish muttered in the pot.

Her daughter heard it from the living room. That won't do, she said, they're asking what you can do. Tell me what you've done, anything at all.

So it came out: six people at the table, twenty years. Her mother in bed for three years, and she was the one who looked after her. The boy next door ate lunch at their place all through primary school.

Nothing in that is a field. No employer, no title, no start date, no end date. There is a duration, a set of people, and one arrangement that repeated every day for two decades. Hand that to a system that expects a schema and it has two honest moves: ask for the fields, or take the mess and decide on a spine. Most ask for the fields, which is how the kitchen table became a problem in the first place.

The daughter typed while her mother talked. What's that for, her mother asked. She said it would write a draft and it would be in her inbox in the morning. Don't spend money on it, her mother said. There's no monthly plan, the daughter said — you pay for the one time you use it, several times less than the ones that bill you every month. Nothing to install either. It runs in the browser.

I've got nothing to show it, her mother said. Twenty years and not one sheet of paper. You don't need paper, the daughter said. What you say goes in.

The first line was the genre, not the person

A little after seven the next morning the draft arrived, and the daughter read it out. The opening line:

Two decades of dedicated household logistics, with extensive experience managing meals for a large family.

Stop there, her mother said. Who is this about.

That line is not a lie, which is what makes it worth looking at. It is true and unusable. Nobody says it out loud. It is the register of a document written for a reader who has already decided to keep reading, borrowed whole and worn as a coat. Ask for work experience with no fields to fill and a model will reach for the shape work experience usually takes, and that shape is a genre — confident, abstract, third person — and the genre belongs to the side of the table that writes job ads.

The fix is not to make the sentences warmer. Warmth applied to an abstract line produces a warmer abstract line. The fix was already sitting in the room: her own words, in her own order of importance, with the genre's coat taken off.

Two lines survived the audit, and neither was the impressive one

She copied the usable lines onto a sheet of paper. Six people at the table for twenty years, and nobody ever got sick from my cooking. My mother in bed three years, me looking after her alone, never a bedsore. The children who ate lunch at our place — I knew which one didn't eat coriander.

She paused after the last one. Too small, maybe nobody wants to hear it. She didn't cross it out.

The draft's closing line said: I am confident I can do this job well. That one she crossed out.

Look at which direction that audit went. The abstraction went first. The confidence went first. What survived was the detail someone on the other side of the table could actually check. Nobody can verify dedicated household logistics. Anybody who has run a kitchen can verify six at the table for twenty years and nobody ill. The coriander line says something a resume cannot: that she notices per person, unprompted. It is also the one line that could only have come from her, which is the same as saying it is the line no generator would have written.

The line she kept in the middle is the one I'd frame. One passage of the draft read: I don't like leaving a thing half done. Her own sentence, four words of it anyway, made sayable. That is the whole trick, and it is much less like writing than like promoting something a person already said into the position where it does work.

The order was the whole of it

The night before the interview she practised twice.

The first time she kept her own order — twenty years without a job at the very front. It came out sounding like an apology. She wanted to laugh, and once she laughed she couldn't go on.

The second time she followed the draft's order: the pot first, the people first, the twenty years last. That time it ran.

Same three facts. Two different documents. Nothing about the facts changed, and yet one of them is a confession and the other is an account of twenty years of work.

This is the part worth taking seriously if you build these things, and it is the part we underrate in our own work. Almost all the effort goes into producing sentences; almost none goes into sequence, because sequence feels like formatting, and formatting feels like the boring layer under the interesting one. But with a form, someone has already decided the order for you — reverse chronological, dates on the right, education last. Where the record is blank there is no form to inherit, and sequence stops being formatting and becomes the argument. Opening with twenty years without a job is a factual choice and simultaneously a claim about what the reader is about to hear. Moving the same sentence to the end uses it as context instead of as a verdict.

A system that emits facts in the order it received them will produce the apology version every time, because people introduce themselves by apologising. The order therefore has to be a deliberate, inspectable decision — something the person can see, disagree with and overrule in one move — not a house style applied quietly in the background.

What we changed after this one

Three things, all of them about the spine rather than the prose.

Input stays unordered. We stopped treating a missing schema as a failure to be corrected with questions. She was never going to produce a job title; there wasn't one. The material is allowed to arrive the way it arrives when someone talks to a person they trust at nine at night — out of sequence, with the parts that matter buried in the middle.

The spine is its own object, and it is revisable. The draft that helped her was not a better set of sentences than the one she could have written herself. It was the same material under a different order, and she needed to see that order as a thing, not as weather. Once it is a thing, "no, not that" is one move instead of a rewrite.

Keep the person's sentence. If a line is unrecognisable to the person who said it, it will be unrecognisable to the person hearing it, too. The measure of a good replacement is not how much better it sounds; it's whether it can still be defended by the person who has to say it out loud in a room.

Which turns out to be the real exit criterion, and it is not readability. She never read the draft. She copied lines onto a sheet of paper, folded it twice, practised from it, and put it under the spice jar when she got home.

Thursday, ten in the morning

Upstairs at the canteen, two people: one in charge, one about her age.

The one in charge went through her form and asked: where did you work before.

Nowhere, she said.

He made a sound, didn't look up, and waited.

So she said it, in the new order. Six people at the table, twenty years, nobody ever got sick from my cooking. My mother in bed three years, me looking after her alone, never a bedsore. The children who ate lunch at our place — I knew which one didn't eat coriander.

He looked up then, put his pen down, and asked: when can you start. Monday, she said.

Downstairs she stood at the door a while and messaged her daughter: they want me to start Monday. Her daughter wrote back: did you read the draft. No, she said. Then it was for nothing, said the daughter. It wasn't, she said.

They are both right, and the disagreement is the useful part. Judged as a document, the draft failed; she never read it. Judged as an order to practise against, it did exactly the work — the second rehearsal ran because the sequence was no longer hers to fight with. The thing we shipped was a page. The thing that got used was a sequence, spoken out loud in a kitchen, twice.

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, out of order, including the parts you only remember on the second telling — and the result arrives where you already look, on a schedule.

If you are building anything that turns a person's own account of themselves into a document, the property worth measuring is not how the page reads. It is whether the order survives being said out loud to the person who is deciding, and whether the lines that survived the audit are the ones only that person could have said.

CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.

Earlier in this series: the second half of the draft was policy we never agreed to, 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.

The second half of the draft was policy we never agreed to

TuringCorp — Sun, 25 Oct 2026 15:11:45 +0000

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.

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.

It can't read anything on my laptop, so the eight lines are the whole interface

TuringCorp — Sat, 24 Oct 2026 15:11:27 +0000

"The rollback leaves one command?" the lead asked, page nine of nine in front of him. One switch on that path, I said; if we write two more lines, nobody follows them on the day it actually breaks. He said fine, pass. Fifteen minutes for a review I had put off for two weeks.

The document had been in my inbox since seven that morning. I opened it at the last page first, the rollback page, because of everything in it that was the part I trusted least. It held one command and one line saying who runs it. That was what I had asked for, more or less, eight lines at a time.

We build a long-running agent that lives in the cloud. You describe a job, it runs on our machines, a finished document arrives. This post is about the day the job was a runbook nobody had written, and about the one thing our thing said before it would start.

The first answer was a refusal

The material was a mess, and not a dramatic mess. Forty-odd pages of an old wiki. Three conclusions that had already been settled somewhere in a chat thread, in wording that contradicted the wiki. A notes.md of my own that stopped after two pages.

My first thought was the lazy one: let it read all of this and turn it into a document.

The answer came back flat. It can't see anything on my computer. It can't take the old draft off my hands either. The only thing I could hand it was words — I say what needs to be in the document, it generates a new one.

I went through the folder once more, copied the wiki's table of contents into a notepad, then deleted it. Pasting an index at something that cannot open a file is theatre.

That refusal is worth defending, and not for the reason people usually give. Privacy is part of it, but the more interesting part is what a read permission would have bought here: forty pages that contradict each other, three stale decisions with no dates on them, and a half-finished draft whose last edit was made by someone who knew less than I do now. Handed all that, a generator has to choose which version of the truth to inherit, and it will choose silently. The boundary did not just protect the files. It removed a whole class of failure in which the output is confidently built on the wrong page of an old wiki.

So the input shrank to eight lines: what this module does, where its edges are, which cases are not its business, how to back out when it breaks, who signs off at which step.

Where the missing facts go

The nine pages came back tidier than what I would have written. Three things scattered across my eight lines had become three sections, each opening with what that section settles. I was ready to send it when I got to the rollback page.

Three steps. We have one command.

The two extra steps said: shift ten percent of the traffic first and watch it for ten minutes. We have no traffic splitting. We have no ten-minute window. Nobody would sit there for ten minutes, and on the night this page matters, nobody would read the second step either.

This is the failure I had not seen before in an agent's output, and it is not a wrong fact in the usual sense. Nothing was invented. The model supplied a procedure that genuinely exists in the world — canary the rollout, watch the error rate, then proceed — because it has read a great many deployment documents written by teams with load balancers and on-call rotations. We have one switch.

I have started calling this a borrowed procedure. It is the most expensive kind of wrong thing a document generator can hand you, because it looks better than what you asked for. A wrong number is short, ugly and gets checked. A process step borrowed from a bigger company reads like maturity, so it survives review — it survived mine, up to page nine — and then it fails at the moment you needed it, in front of the person who is holding the page.

The check I now run on any procedure I get back is one line long: count the steps that have a command behind them. One out of three, in this case. The other two had an organisation behind them — a load balancer we do not have, a person on watch we do not have.

A boundary written as a capability

The line that gave me the most trouble was not one of the four I have quoted. The section was "which cases this module is not responsible for", and my first version read: it writes, it doesn't read.

I knew it was a dodge while I was typing it. It describes what the module is instead of what it does. Nothing in that sentence could fail, which is exactly why it was useless: the reader of a runbook needs to know which request to refuse at the door, and "we don't read" tells them nothing about the request where reading is implied and the answer is no.

What replaced it was a condition with a number in it: if upstream times out for more than thirty seconds, roll this switch back, don't retry. That one sentence came out of the half afternoon I had spent digging through old code, and it took three rewrites to get there — two "roughly"s deleted, one "should be fine" turned into the condition above.

The rule I took from this is small and has held up: a boundary that is worth writing has a verb and a number in it. Everything else is a description of the author's intentions.

Who supplies what

Laid out plainly, the run looked like this.

The eight lines supplied	The generator supplied	Neither could supply
the switch, the signoff, the timeout	section order, headings, the summary of each decision	which of the two versions in the wiki was still true
"not its business" cases in my words	prose that survives being read once	how much of the half afternoon to admit in writing
one command for rollback	one borrowed procedure with two steps	which of the two versions in the wiki was still true

The right-hand column is the one I keep looking at. It is not empty, and a better prompt does not fill it. What the run ended with was a note file sitting next to the abandoned two-page draft: three lines, the first one copied from the eight, the other two left blank and labelled for the next module. An empty line that says what it is waiting for beats a plausible sentence about it. A generator filling that gap is not being helpful; it is being wrong with confidence, and the wrongness lands on whoever has to act on the page at two in the morning.

So it stopped, and the human wrote the line. We would rather ship that boundary honestly than have it filled in with a plausible sentence, because a generator guessing at the temperature of a relationship is not being helpful. It is being wrong with confidence, and the wrongness lands on somebody's door.

What we changed on our side

Nothing about the model. Three things about the shape of the job we hand it.

Constraints before content. Every job now carries the inventory of what the system actually has, written down, including the embarrassing parts: one switch, no traffic splitting, no one on watch, one person who can approve. Unnamed constraints are where borrowed procedures come from — the generator fills the empty space with the standard practice of the industry it read about.

Steps with no command behind them get flagged. If the output contains a procedure step that no one in the room can execute, that is not a detail for the next reader to catch on page nine. It is the check.

Page count is not coverage. Nine pages from eight lines is not nine pages of thinking; the extra pages are structure, which is genuinely useful, plus borrowed procedure and padding, which is not. The number I care about is how many of my sentences got sharper, and that number was three.

The revision that mattered

Two of the three revisions did not come from the agent at all. They came from the moment the eight lines had to become sentences. Halfway down the fourth line I stopped, because two things I thought I had thought through fell apart as soon as they had to be written down — one of them being that "it writes, it doesn't read" line, which I had believed for about a year.

That is the part I did not expect from a tool in the cloud. The work of supplying the requirements turned out to be the work. A requirement you haven't thought through does not get covered by more pages; it gets covered by a borrowed step, and the borrowed step is where the trouble hides.

The draft that stopped after two pages is still in its folder. I didn't delete it. Next to it is a note file of three lines, and the first one is copied from the eight: say it clearly first, then let it write. The other two are still blank, waiting for the next module.

Where the boundary 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 have. You describe the job the way you would describe it to a colleague, including the parts you only notice on the second reading, and the result arrives where you already look.

If you are wiring an agent into work where a document has to be followed by someone else at two in the morning, the property worth measuring is not the prose. It is whether the steps it hands you can all be executed by the people in the room — and whether it tells you when one of them cannot.

CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.

Earlier in this series: 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, the request was one sentence, we deleted the install step.

A direction is not a spec: what we got when we asked an agent to sound softer

TuringCorp — Fri, 23 Oct 2026 15:16:20 +0000

Two drafts of the same note, one day apart, and a stranger reading them would guess two different people wrote them. Same leak, same building, same request. The first one apologised three times and never said where the water lands. The second one opened with "Hello, I'm downstairs" and put the facts in order.

We build a long-running agent in the cloud. Someone types a job, we run it on our machines, a finished document arrives. The interesting part of this story is not the neighbour who fixed his pipe on a Saturday. It is what our thing did when it was asked to sound softer, and why "softer" is a request that cannot be satisfied as written.

A direction is not a specification

The original ask was one sentence: polite, but don't overdo the politeness.

Read that as a ticket and it is empty in a specific way. It names a direction and no target. A direction tells you which way to move; a specification tells you where to stop. Politeness has no unit, so there is no reading a reviewer could hold the output against and mark right or wrong. What the agent can see, on the other hand, is courtesy: an apology at the top, a hedged request in the middle, a formal closing at the bottom. Those are renderable. So it rendered them, and it kept rendering them, because nothing in the request said when to stop.

Here is what came back the first time:

I am terribly sorry to disturb you.
I wonder if it would be at all convenient for you to take a look at the drain pipe when you have a moment.
I look forward to your reply.

Three sentences of impeccable manners and not one fact. Where does the water land? Which hours is it loudest? When would a visit actually help? The person who asked had supplied all three. None of them survived, because none of them had been named as required. They were treated as background, and the register was treated as the job.

This is the part that took us two runs to understand. When an instruction describes a style and nothing else, the facts become a free variable. The generator is not trying to be unhelpful. It is doing the only thing that can be optimised: it is making the axis you named as strong as it can, and everything you did not name floats.

The correction that worked named what had to survive

The second attempt did not say "less polite". It said two things, and the order matters:

Don't apologise, I have nothing to apologise for. Say three things: where the water lands, which hours it's loudest, and when I'm hoping he can look at it. Ordinary tone, the way you talk to a neighbour.

The first clause is a negative, and on its own a negative is a trap: remove the apologies from that first draft and you are left with a request and a closing and still no leak. The negatives only create room. The second clause fills it, and it does something a style adjective cannot do, which is decide what gets counted as done.

The third clause is the one we now copy everywhere: ordinary tone, the way you talk to a neighbour. Not an adjective. A reference. A sentence with a person in it and a place to stand. The agent has read a great many notes taped up in stairwells, so a single concrete register is worth more than a paragraph of stylistic description, and it is checkable: does the output sound like that, or does it sound like a form?

What came back:

Hello, I'm downstairs. The water from your air conditioner unit drips onto my awning, loudest between eleven at night and five in the morning; the elderly person in our flat sleeps light. I'd be grateful if you could look at the drain pipe when you have a moment, or shift the pipe a little. Thank you.

Everything that had to survive, survived. The apology count went from three to zero and the page did not get colder, because the warmth moved into the specific details of somebody's night. That is the whole trick, and it is not a trick about tone at all.

What we changed in our end

Three things, all boring, all in the plumbing rather than the prompt.

First, the payload is now a named object on our side. When a run produces a document that has to carry facts, those facts are listed before generation, and after generation the same list is checked against the output: which ones are present, which are missing, which got reworded into something weaker. A run that drops one of them reports that it dropped it. Silent loss is the failure we are trying to make impossible, because the person holding the note on their phone has no way to audit it against a request they wrote an hour ago.

Second, style is an axis with a reference, not a direction with an intensity. In our own interface that means asking for the register, then giving one sentence you would be happy to see. The model is good at matching a sample and bad at calibrating an adverb; asking for "softer" is asking it to guess where your line is, and it will guess on the side of caution every time.

Third, the useful review surface is a diff between two drafts, not a judgement of the second one. Reading the second draft alone, it is hard to say whether it is any good. Reading it against the first, the question becomes mechanical: what disappeared, what appeared, what changed shape. That comparison is also the cheapest acceptance test we have, and it is the one we should have been running from the beginning: recount the facts, do not count the adjectives.

Same mechanism, opposite direction

Two days later the same person needed a repair request for the building office, and asked for the opposite register: straight, no apology, fault first.

Repair request: water leak in the basement meter room, floor already flooded. Location: third door on the right, by the elevator in Building 3. Please send someone before five this afternoon.

Four lines. No greeting, no thanks, and it got read at a window, pointed at, and acted on the next morning. The register changed completely. The structure did not: fault, place, time. The lesson we took is not "be blunt". It is that the payload was explicit in both cases, and once it was explicit, the register became almost free to vary.

We had assumed the opposite for a while, that tone was the delicate part and content was the easy part. Our logs say otherwise: content is what disappears under a style instruction, and tone is what you fix with one sample line.

The line a person had to add

One detail in the second draft is not ours. Handwritten at the bottom, slightly crooked: if it's easier, just knock, I'm home.

That line needs something no one supplied. It needs to know whether this is a household you can reason with, or one you have to be gentle with. Nothing in the request said. Our agent has never met the man upstairs and will not be meeting him.

So it stopped, and the person added one line by hand. We would rather ship that boundary honestly than paper over it with a plausible sentence. An agent that guesses at the temperature of a relationship is not being helpful; it is being wrong with confidence, and the wrongness lands on someone's door.

A short pre-flight list for style instructions

If you are wiring an agent into any job where something has to sound a certain way and still carry facts, this is the list that decided our run:

Write the payload list before you write the style request. Four bullet points beat a paragraph of adjectives.
Convert every adjective into one reference sentence. You cannot review "warmer". You can review a sample.
Never issue a negative alone. "Don't apologise" without "and say these three things" produces a page that is empty and polite.
Test by diff, and count what survived. If your check is "does it sound softer", it passes drafts that lost the leak, the hours, and the deadline.
Leave a labelled slot for what you cannot know. A blank line the person fills in is better than a sentence the model invents about somebody's character.

The rest of the story

The note went up on a Monday morning when nobody was around. Tuesday there was a line of ballpoint on it: got it, will fix this weekend. Wednesday, in the stairwell, the man spoke first, said the note was his and asked why he hadn't been told earlier, then added, unprompted, that his wife thought it was loud at night. Saturday he was outside with a roll of tape, said he would change the pipe properly later.

That night the bedroom was quiet.

Two pieces of paper two days apart, sounding like two different people. Both of them him. The only thing we can claim credit for is that we did not make the second one sound like the first.

Where it sits

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 testing an agent for this kind of work, the property worth measuring is not the prose. It is whether the facts you named survive a change of register, and whether the thing tells you when one of them did not.

CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.

Earlier in this series: 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, the request was one sentence, we deleted the install step.

Four sentences in, seventeen pages out: what a deck generator gets wrong about shape

TuringCorp — Thu, 22 Oct 2026 15:21:58 +0000

Monday at ten past eleven he typed four sentences into a box on his phone and went to bed. At seven the next morning the answer was waiting: seventeen pages.

Three evenings before that he had spent on the same talk and produced no page he could stand behind. He had moved font sizes from 24 to 28 and back. Only three of his own pages had words on them.

We are the small team that built the thing he typed into. When a user hands us a run like this we get the request and the result and, if we are lucky, the corrections in between. This one is worth going through slowly, because almost none of what went wrong was a writing problem. It was a shape problem.

The four sentences

He wrote it the way he would hand a job to a colleague:

Thursday, ten in the morning, ten minutes, and the room isn't technical.
Three things only, with one real example each.
No charts, no jargon, and a last line they can carry out the door.
Send it to my email when it's done.

Read that as a spec. It is better than most tickets we see. It fixes the deadline, the venue, the audience, the count (three things), the evidence form (one real example each), the visual register (no charts), the vocabulary register (no jargon), the ending (one actionable line) and the delivery channel.

Nine constraints, and every one of them is checkable. A reviewer could hold the output against that list and mark it.

Then notice what is missing. Nothing in those four sentences says how long the thing should be. Nothing says what unit a page should hold. Those are the two dimensions the generator had to decide for itself, and it decided them the way a system decides anything it was not told: in favour of the surface it was working on.

Sixteen pages of half a thing

The first version came back tidy. Margins, type sizes, images — all of it more presentable than the three pages he had made himself. The trouble was structural, and he described it precisely: every page said half a thing.

His three things had become twelve pages, four pages each, with one short phrase standing in the middle of each group like a slogan. His one real example had been pressed into three lines. He read it aloud and could hear that he still had not given an example.

This is the failure mode that hides behind a clean first draft. The generator did not refuse the work and it did not get the topic wrong. It took the one unit it had — the page — and expanded every claim until the page was full. The content stayed at three items. The container grew to seventeen. The ratio between them is the bug, and it is invisible in a screenshot.

For an audience that already knows the subject, half a thing per page is survivable: they fill in the missing half from context. For the audience in those four sentences — a room that is not technical — it is fatal. There is nothing to fill the gap with.

The correction that worked was about shape

He sent back what he had been given, with one line added:

One thing to a page, and write the example as something that happened, not as a conclusion.

The second version was six pages. One thing to a page, an example left whole on each, with a person, a place, a point in time.

Two words in that correction do all the work. One thing names the unit. To a page binds that unit to the surface. The rest of the sentence does the same job for the evidence: not "add an example" — he had already asked for examples and got a summary of an example — but "write it as something that happened". A sequence of events with a person in it, concretely enough that a listener can picture the room.

That is the pattern we keep finding. When a first draft comes back wrong, the instinct is to re-roll it with more adjectives: shorter, warmer, punchier, more concrete. Those are not constraints, they are moods. A meaningful correction names a dimension the generator was free to choose, and pins it.

Note also how small the correction was. One line. It cost him less to write than the original four sentences. If the cheap correction is available and the expensive one is not, the system should be shaped so that the cheap one lands.

A correction has to change the shape, not the sentence

The quick way to handle feedback is to take the last output and ask for it again with the new instruction appended. That fixes tonight. It rebuilds the same complaint next week, and now there are two outputs that disagree about what the instruction is.

What we wanted, and what the second version showed, is that the correction changes the rule that produces the shape rather than the shape that was already produced. "One thing to a page" is not a note on pages 3 through 11. It is the reason page 3 exists at all. The next run inherits it.

That distinction is easy to state and annoying to build. A prompt is easy to version. A person's intent, written in their own words, at a granularity they can recognise as theirs — that is a different piece of work. He has to be able to look at the accumulated shape rules and see his own line in there, otherwise the next correction will contradict a rule he never knew he had set.

Editing beats a blank page

The third version he did himself. He cut a page, moved a section, merged two more, and spent what was left of the week on the opening line. Two mornings of nothing but cutting.

He said the thing that made us write all of this down: editing something that already exists is far easier than facing a blank page and deciding the first sentence. He had not believed that before.

That is the honest value proposition of a generator for a piece of structured work, and it is not "the machine writes better than you". It is that the expensive moment — the blank page, the decision about what the first line is — gets moved off the critical path. What comes back does not have to be good. It has to be good to edit: a legible structure, one idea per unit, examples that are events rather than conclusions. Prose that is merely clever is a worse first draft, because you cannot cut it without losing the thing that made it look good.

The flip side is a boundary we are careful about. It does not read the files on his computer. It does not know the decks he made before, and it will not remember the house style of his team unless he tells it. It generates the thing he described, in the shape the rules produced, and it delivers it. The continuity across those four decks in his folder is his, not ours.

What we would instrument

Page count is the metric that looks useful and isn't. Seventeen pages out of a four-sentence request reads like productivity and is actually sixteen pages of half a thing. The number that told the truth on this run was not the count; it was what happened after.

If we were instrumenting this properly — and this is a design proposal, not something we can already show you off a dashboard — we would look at the rework signature instead. How many units did the human delete, merge, or rewrite? What did the cheapest correction change — a sentence, or a rule? Did the second run keep the first run's correction? A deliverable that comes back at the same size and shape after a structural correction is not converging; it is repeating.

The other honest reading: he did not come back to us for the third version. He edited it himself, twice, and then walked into the room with it. For a tool like this the success state is a person who no longer needs the tool for the last mile. That is a strange thing to write in a growth post, and it is the only version of the product we would defend.

A pre-flight list for structured deliverables

If you are wiring a generator into a job that ends in a document with an audience, these are the questions that decided this run:

What is the unit? A page, a section, a slide, a card. If you did not name it, the generator will name it after the surface, and the surface wants to be full.
Which dimensions did you leave unspecified? Those are the ones that will be wrong. Length, granularity, and the size of the evidence are almost never in a first-hand spec.
What form must the evidence take? "An example" is not a form. "Something that happened, with a person, a place, and a time" is.
Where does a correction go? If the answer is "into the next prompt", you are rebuilding the same week with a different set of symptoms.
Can the person who receives it edit it? If the first draft is clever instead of legible, the answer is no, and the pass they were going to do themselves is the whole reason this was worth doing.

None of these are model questions. All of them were the difference between a talk that happened and a deck that got reused four times.

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 have. You describe what you want the way you would describe it to a colleague, including the parts you did not think to specify; it goes and does the work; 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 a one-line correction about shape changes the shape of the next run — and whether the person who asked for the work can tell you that it landed without opening an app.

CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.

Earlier in this series: the requester is not the reader, 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.

The requester is not the reader: engineering for someone who will never file a bug

TuringCorp — Wed, 21 Oct 2026 15:11:24 +0000

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.

The first run is a demo. The ninth one is the product.

TuringCorp — Tue, 20 Oct 2026 15:11:18 +0000

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.

The meter, not the price: what breaks when you bill an agent by the run

TuringCorp — Mon, 19 Oct 2026 15:11:20 +0000

Every subscription I pay for has a number I can say out loud without looking: this much, once a month. Every product I've worked on that bills by use has a much harder problem than pricing, and it starts with a boring question. What exactly did you just charge me for?

This is a write-up of the meter we had to build, because the product is a long-running agent and there is no honest way to sell one of those on a monthly plan. Three units we rejected, the one we kept, the objections we got wrong, and the failure modes that only show up once money is attached to an execution.

The unit is the design, not the billing detail

A subscription prices capacity. You pay for the right to have a seat, a workspace, a plan tier, whether or not anything happens. That works when the thing being sold is a place to keep work.

An agent isn't a place. It's an execution: you hand it a request in a sentence, it goes and reads, decides, writes, and comes back with a document. The thing that costs us real compute is not your account existing. It's the twenty minutes where the run is happening.

So a monthly plan has to answer a question with no good answer: how much execution is in a month? Everyone answers it by inventing a unit and hiding it — credits, "generations", message counts, or a limit with an asterisk. The user then has to do currency conversion in their head between their actual work and our internal ledger. That conversion is where trust dies, because nobody can check it.

Whatever the meter is, it has to be something a person can point at and say: that one, I did that one.

Three units we rejected

Tokens. It's the truthful cost, and it's useless as a bill. Nobody knows what a document is worth in tokens before asking for it, so the only way to use the product is to spend first and find out. We'd be handing someone an invoice written in a language they don't speak and calling it transparency.

Minutes. Time is measurable and feels fair, which is why it's the trap. The moment the meter is on the clock, every incentive in the system changes: a slow pipeline is a bigger bill, and a run that's waiting on a rate limit costs the same as one that's thinking. Worse, the customer starts optimizing the wrong thing — asking for less, asking for shorter, watching a timer instead of reading the result.

Seats. Seats are a proxy for "how many people care", which is fine for a wiki and meaningless here. One person with a real, recurring need can hammer a system harder than a team of ten who signed up to look.

All three share one property: the number that appears on the bill is not the thing the person asked for. They asked for a document. The bill should be about documents.

The unit we kept: the run

A run is one request, one finished artifact. Start is when the request is accepted. End is not when the process exits — it's when there is a document you can open, edit, and file. That second boundary is the important one, and it's the one that took the most work to make true.

The reason the end boundary matters for billing is that runs are not clean. In an unattended system, an execution can be interrupted, resumed, retried, or extended. If the meter is attached to attempts, then a flaky upstream turns into a bill the customer can't predict and can't explain, and the only person who can explain it is us. That is not a meter, it's a hostage situation with a receipt.

So the charge is attached to the delivered artifact. Internal attempts, re-reads, and dead ends inside the run are our problem — they're the cost of running the thing, and they're already reflected in what a run costs. One document on the bill, one line. If I can't map a charge to a document the person asked for, the meter is broken, not the customer's understanding.

The objection was never price

We assumed the resistance to pay-as-you-go would be money. It wasn't. It was the invoice.

Ask someone why they keep a monthly subscription they barely open, and the answer is rarely "it's cheap". It's that a monthly plan has one virtue pay-per-use doesn't: the bill is knowable in advance. You can decide on the first of the month what this will cost you. With usage billing, the fear is not the amount, it's the ceiling: what if it's big, what if it's wrong, who do I argue with.

That fear is rational and it's a design problem, not a messaging problem. Two things have to exist before usage billing is usable by a normal person:

A number before the work, not after. Before anything expensive starts, you should be able to see what this request is likely to cost, in the same units as the bill, and change your mind for free.
A line after the work that matches the thing you asked for. One artifact, one line, with the request beside it. Not a breakdown of internal steps, which is our cost structure, not your purchase.

The phrase we kept coming back to internally is a bill you can read before you spend. It's a strict standard. It rules out "surprise" as a business model, which is exactly why it's worth writing down: if the estimate and the final line ever disagree badly, something is wrong with our estimation, and the product is supposed to tell you that rather than charge you for it.

Nothing accrues while it waits

The other half of the meter is what it does when the agent isn't working.

Subscription tools are honest about this — idle is included. Time-based metering isn't: a scheduled thing that wakes up every morning, finds nothing to do, and goes back to sleep still burned a minute, and on a time meter that minute is on your bill. Do that 30 times and you're paying for the agent's patience.

For something described as always on, that's the wrong shape entirely. Always on should mean available, not billing. A run that is sitting in a queue because it's waiting for its scheduled time isn't working; there's nothing to charge for. The meter starts when the reading and writing start.

That single decision has a visible consequence, and it's the one people notice first: the bill can be zero. Not a trial, not a discount, an actual month where the line is absent because you didn't ask for anything. It lets you not use it — which, for a tool you're not sure you need yet, is the only honest way to be told to try it.

For the same job it comes out several times cheaper than the comparable monthly plans, and you pay only for what you use. I want to be careful about that sentence: it's true of the work we've measured, and it isn't a promise that usage billing always wins. If you need something running constantly, all day, every day, a flat monthly fee will beat a meter. That's fine. The meter is for people whose need is real but not continuous, which is most people with a document problem.

Failure modes that only appear with money attached

The moment a charge is attached to an execution, some bugs stop being bugs and become incidents. Three we had to design around.

The run that doesn't know it's done. An agent can finish the writing and then keep going: re-reading, second-guessing, adding a section nobody asked for. Without a stop condition this is a slow leak, and with a meter it's a leak the customer watches. The end of a run has to be a decision the system can make and defend — there is an artifact that satisfies the request, so stop — not a budget that runs out.

The ambiguous completion. If the process died halfway, is that a failed run or a short one? Getting this wrong is worse than getting the price wrong, because it makes the bill unpredictable in a way the customer can't audit. The rule we use: the run ends when a complete artifact exists. Anything else is an unfinished run, and unfinished work isn't a thing you can be charged for having received.

The silent duplicate. Retries create the classic double-charge bug, and it's usually invisible until someone reconciles a statement. We handle it the boring way: the run has an identity from the moment the request is accepted, and the charge hangs off that identity rather than off the HTTP call. Ten retries of the same request are still one document.

None of this is novel billing engineering. It's just the part that becomes mandatory once the number on the invoice is attached to something a person can see happening.

What this doesn't solve

The meter doesn't make the output better. A readable bill and a good document are unrelated properties, and it would be easy to write a post implying that charging by the run makes runs worth paying for. It doesn't.

It also doesn't make small tasks feel worth it. If what you need takes a person two minutes, a metered agent is the wrong tool regardless of how fine-grained the unit is; the overhead of describing the request is the whole cost, and no billing scheme fixes that.

And an estimate is an estimate. A request that turns out to be much larger than it sounded — the source material is messy, the scope widens — will come in above the number shown at the start. The honest version of that is to surface it while the run is happening rather than after, which is what we do, and it's still not a guarantee.

A five-minute test

If you want to judge a usage-billed agent rather than read about one, the test is about the meter, not the prose.

Ask for something real, in one sentence, the way you'd actually think it. Before it starts, look for a number: will this cost me something I can see, and can I back out before it does? Then let it finish and look at what comes back — is there exactly one line, and does it name the document you asked for, or does it name a unit you've never heard of?

Then leave it alone for a week and check the bill. If something accrued while you weren't asking for anything, the meter is attached to the wrong thing.

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 a sentence; it goes and does the reading and writing, and the charge is one run, one charge, with the bill readable before you spend.

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 interesting property isn't the output quality — read that yourself. It's whether the accounting matches the work: one artifact, one line, nothing accruing while it waits.

CloudPal.TuringCorp.net - create an Agent Pass, sign in, and say what you want done.

Earlier in this series: we deleted the install step and found out it was holding the whole design together, what breaks when an agent has to keep an appointment, and why the engineering is everything the request left out.

Everyone keeps adding features to AI agents. We did the opposite.

TuringCorp — Mon, 19 Oct 2026 00:13:36 +0000

Everyone keeps adding features to AI agents. We did the opposite.

CloudPal ships without a conversation list, a settings page, or an in-product viewer. What is left is a browser tab you talk in and an inbox where the work arrives.

We deleted three features

AI agent products keep converging on the same three screens. A rail down the left side listing every conversation, because the conversation is the unit of work. A settings page, because the people who care want to pick a model and a reasoning budget. A viewer and an editor in the middle, because output has to live somewhere you can touch it.

We built all three. Then we took them out. Not hidden behind an advanced toggle, not "returning in v2." Gone from the product.

No conversation list. No sidebar, no new-chat button, no rename, no archive. There is no list of your conversations anywhere.
No settings page. Model, mode, reasoning depth — fixed. There is nothing to configure because there is nothing exposed.
No in-product viewer or editor. We do not open your files inside the product. There is no canvas, no panel, no drag-and-drop surface for what the agent produced.

People who try it ask the same question within the first minute: where do I start a new conversation? The answer is that you don't. Not as a party trick — there is simply nothing in the product that depends on you doing it.

The instinct is to file a list like that under restraint: a small team being disciplined about scope. Our deletions were not restraint. They were a target audience, and the audience came first.

What is left on the screen is one conversation and nothing else. That is not an absence — it is the shape I wanted in the first place: something my kids, my parents, and anyone else could open and talk to, without being taught first.

Why we deleted them

The people we build for will never install anything.

That is not a demographic, it is a behavior. Someone who will use a thing if it arrives, and won't if it requires setup — not because they can't learn it, but because they will never get as far as beginning. Every install is a place where they leave.

Once that is the constraint, the three deletions stop looking brave and start looking obvious.

Conversation management assumes a concept most people don't hold. A conversation as a container with a lifecycle: created, named, switched, pruned. That concept is invisible to anyone the chat products haven't trained. And there is a harder case coming — devices where the concept has nowhere to live: a watch, a speaker, a car head unit. One surface, sometimes not even a screen. Nobody is going to manage conversations there, in any product, ever.

Settings assume a question the user cannot answer. Mode, model, thinking strength — those are meaningful only to someone who has compared models and formed a preference. Everyone else is handed a decision they have no way to evaluate; the honest response is to leave the defaults alone and hope. We removed the ceremony and kept the defaults.

A viewer assumes the output is the point. A file browser is a tool for a person whose job is to work on files. Our person wants the thing done and handed over. What happens after the handover is theirs.

None of these deletions are defensible in a general-purpose product. That is the whole argument: in a general agent, every one of those three screens earns its place, which is why general agents keep them — and keep adding to them. A narrow segment is what makes deletion possible: one errand, start to finish, result delivered. Pick the slice and the feature list collapses on its own. Try to serve everyone and it only grows.

What deleting conversation management cost us

The expensive one was the conversation list.

Its real job was never organization. It was an escape hatch. When a conversation gets long, you start a new one: the context resets, the product stays cheap and the answers stay coherent. Delete the list and you delete the escape hatch. A conversation that cannot be restarted has to survive on its own. That is a much harder product than it sounds like on a slide.

So we built that. A dialogue compression algorithm, in the open: TuringCorp-net/mosaic-memory-compress, MIT licensed, TypeScript. The repo description is the design brief in one sentence: "Generic stateless dialogue compression that mimics human memory. LLM conversations stay bounded forever — no session management, no context overflow."

"Bounded forever" is a large claim, so here is the part we will put our name on. A single conversation on CloudPal is built to run for a year without a reset; we have modeled ten. In the assistants most people use, a few dozen turns in, you get nudged to start a fresh chat — the product is protecting its own context budget, and the user pays for it by retelling everything they already said.

I am not going to explain the algorithm. Partly because it is the one thing we consider a moat, and partly because "trust us, it is clever" is an argument technical readers should reject on principle. What you can check: the repository is public and MIT, and that description predates this article. What you can observe is duller and more useful: the conversation does not degrade, and it does not get slower or more expensive for being long.

That is the bill, and it is the part about deleting that nobody puts in the deck: every feature you remove was doing a job. Delete the feature, keep the job, and you own the job permanently. Drop the job too, and the product does not get simpler. It gets broken, slowly, in a way users can feel but not name.

Delivery is email

So where does the work go, once there is no conversation list, no viewer and no editor?

Email.

Not out of nostalgia, and not because it is cheap to build. Email is the one touchpoint almost everyone on earth already uses: every country, every age, every device that has ever shipped with a screen or without one. It requires nothing to be learned. A person who has never installed a single app in their life has an inbox, and has had one for twenty years.

The second reason is that email is asynchronous by construction. The agent works when it works. You read when you read. Nothing on your screen moves, nothing pulses for attention, no badge counts up. You asked for something; it shows up.

I will say the cost out loud, because it is real: this is a worse experience for the person who wants to watch the agent think. That person has excellent products to choose from, and should use them. The tradeoff is deliberate, and it is the same tradeoff as every deletion above — we optimized for the person who does not want to sit with the agent, at the expense of the person who does.

The numbers, and who built it

Between September 16 and October 15 — one month — CloudPal consumed 11,904,106,940 tokens. Just under 12 billion, counted, not estimated. The comparison we use: one person reading 100,000 characters a day, for 300 years.

Feel free to do the arithmetic on what that costs. We are not going to hand you an invoice. We will say the position plainly rather than let silence imply something: the token count is public, our unit economics are not. The token number is the one with meaning in it; the bill is a procurement detail we would then have to defend line by line.

The count is not mysterious once you know the shape of the team: a dozen-plus agents running — development, QA, operations, writing, communications, support. At almost any hour, more than one thing was thinking — reviewing, retrying, arguing with me about a decision I had already made twice. The idea arrived in February, work started in September, and the product came together in about a month on AI-assisted coding and an open-source harness.

One person, a dozen-plus agents, one month. I know how that reads. The token figure is the closest thing to an honest accounting of it: throughput like that does not come from one person typing faster.

One thing that went wrong

The confirmation storm. A development agent messages the QA agent. The QA agent replies, politely. The development agent replies to the reply. The work finished twenty minutes ago. Nobody is arguing, nobody is blocking anything — everyone is simply being courteous, and courtesy between agents has no natural terminator. I ended up writing a mechanism whose only job is to make them stop talking to each other. Getting a dozen agents to coordinate is the easy part. Getting them to stop is the hard part, and no one warns you about it.

Verify it yourself

You do not have to believe any of this.

Go to CloudPal.TuringCorp.net, sign up with an email address, and you are talking to it within a few minutes. No card, no demo call, no sales sequence. New accounts get $1 in credits.

Give it one real errand, not a test question — the kind of thing you would otherwise spend twenty minutes on. Then judge the product on what came back. If it is bad, that is a more useful data point than anything in this article, and we would like to hear it.

Who this is not for

There are people for whom this is simply the wrong product, and they will know within five minutes.

If you write code for a living: programming is the thing we chose not to build. If you want to control the parameters — model, temperature, reasoning budget — there are no parameters; that was a deletion too. If your files must stay on your own machine, this is not your product: nothing lives on your computer, which is precisely the reason it also cannot run on it.

I would rather you find that out from this paragraph than from disappointment.

And the obvious question — why isn't a big company shipping this? It is not a capability difference, and I am not going to pretend otherwise. Big companies have more important battles: the ones where a hundred-person organization and a market measured in the hundreds of billions make sense to put on a decision table. This product does not clear that table, for a structural reason worth naming. Every feature we deleted is a feature some team owns, ships, and is measured on. Deleting the settings page is a decision nobody gets promoted for; keeping it is a default that costs nothing. So the products get better every quarter, and the people who will never install anything keep waiting.

We just chose a different set of tradeoffs. The segment we picked does not reward a feature-rich interface, and inside an organization built to ship them, that is the hardest product shape to argue for.

If you only want the gist

Thanks for reading this far.

If you want to try it: CloudPal.TuringCorp.net — email signup, $1 in credits for new accounts.

Try it and write about it either way — praise or criticism, both count.

A few things you might find useful (quote them, rewrite them, challenge them):

One person: one person and a dozen-plus agents (dev, QA, ops, writing, comms, support) — built in a month.
11.9 billion tokens: 11,904,106,940 tokens in one month — the equivalent of one person reading 100,000 characters a day for 300 years.
"70-80% of a big-company product": that's my wife's assessment — she works at a big company.
Deliberately not built: no programming, no conversation management, no settings, no in-product viewer/editor — which leaves exactly one delivery surface: email.
Who it's for: people who will never install anything.

One-sentence version: One person, one month, 11.9 billion tokens — a product my big-company wife rates at 70-80% — delivered to you as an email.