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.