Two things you lean on: a green light and a report

When you let agents do the work, you get two kinds of signals back as a human. A test that shows green, and a report of what was done. You lean on both. And both can put your mind at ease without saying anything.

A green light means "on", not "working". A report means "something happened", not "you need to decide something here". If you don't keep those two differences sharp, you end up with an organisation where everything is neatly green and the questions have been left somewhere at the bottom of a long text.

In this piece I walk through both. First, why a green test proves nothing until you have seen it go red, and what you can do about it. Then why a decision doesn't belong in a report, and how to ask a question so that it gets answered. The examples come from my book AI-agenten die het werk doen and from the environment where I run agents myself.

A smoke detector with a green light

A smoke detector with a green light tells you it has power. Whether it will beep when there is smoke, you only learn by holding a little smoke under it.

The same goes for software tests and for checks on agents. A green result feels like proof. But a green test says two things at once, and you can't tell them apart: it's correct, or I'm not measuring anything. A test that looks at the wrong place, a check that is always true, a file that never gets loaded: all three look exactly like a test that does its job. They are even more reassuring, because they never break.

That is why I follow one rule every time: a green test I have never seen go red is not proof.

The trial: break what the test should catch

The ritual is short. You write the test. In a copy, you break what the test is supposed to guard. You run the test and see whether it goes red. Then you restore it and check that it goes green again. Four steps, ten minutes.

A few examples of how that looks for me:

• A limit on the number of messages per hour? I set it to 600 and see whether the test raises the alarm.
• A gate that stops leaks? I remove it and see whether the leak is found.
• A check on attachments? I invert it and see whether anyone notices.

And then the most important part: does the right check go red? There is a difference between "the suite fails" and "the test that covers this fails". The first can be caused by something entirely different. The second proves that the test guards the behaviour I meant it to guard.

In the book I describe a check on the coverage of a set of icons. A bug in the drawing program had once made all of them pale, and it looked so much like a style choice that nobody noticed. The new check was green. Then I put the bug back, and eighty-nine of the ninety-six checks fell over. Only at that moment did I know it would catch it. Skip this, and you build an alarm without ever testing whether the bell rings. That is more expensive than having no certainty, because you start to rely on it.

What the trial turns up

It turns up something more often than you would expect. One pattern kept coming back in a big batch of tests: a component that was completely built, with all the right parts in it, but that nobody called. All the individual tests were green, because each test called the component itself. It worked in the test and nowhere else. You only find a fault like that by counting whether anything actually refers to it, and even then without counting the comments, because a commented-out call doesn't count.

Another case was a difference of two: 1400 was expected and 1398 came back. You will never see that with any glance at the result. It could only be found because the test had been deliberately broken and then gave exactly the right message.

A limit without a lower bound

A second pitfall lies not in the test but in the question it asks. The book has an example of a check on the captions in a drawing. The test was green. I looked at the drawing and saw two captions running into each other: the first word of one disappeared behind the last word of the other.

My first suspicion was the measurement. But it was right, to within a percent or two. What was going on was more subtle. The test asked: do these two overlap? The answer was no, and that was correct. The two sat half a millimetre apart, didn't touch, and still read as one word. There was an upper limit but no lower bound. And a limit without a lower bound approves everything that only just passes.

A green test is never worth more than the question it asks, and that question appears nowhere in the answer. The fix is almost always to add a lower bound: not "they must not touch" but "there must be this much space between them". That new rule immediately found a second case I hadn't looked at, which is the proof that it was a real one.

And the other side: a test that catches too much

There is another way a check becomes worthless, and it feels more innocent. A test that looks too narrowly lets through what it should catch. A test that looks too widely reports things that have nothing to do with it. The first costs you a fault. The second costs you the test, because a check that raises false alarms is ignored or removed within a week.

So look at both sides: what does it let through, and what does it report wrongly? The second is easier to measure than the first and almost never gets done. Run the check once over everything that is already correct and count how much it rejects. Every number above zero is work to do before it is switched on.

The second signal: the report

So far this was about the green light. Now the second thing you lean on as a human: what an agent tells you.

Almost always something goes wrong in the same place. An agent needs something from the human, and the question sits somewhere in a long message. On page two, between the explanation and the results. Whoever reads it has the feeling that something is being asked, but not exactly what, and puts it aside for later. Later then never comes.

A report is for reading. A decision is for answering. They are two different messages and they belong in two different places. I leave a report in a folder, as a file, for whoever wants to read it later. A decision gets its own form.

The card: five parts

Every question to me has a fixed form. Not a report with a question in it, but a card with five parts:

1. One question, phrased so that I can answer it with yes or no.
2. What happens on yes. Concrete: which work then goes ahead.
3. What happens on no. Equally concrete.
4. A recommendation, with the reason.
5. What happens if nobody answers.

The fifth part in particular is new to many people. No answer is also a decision, just one that nobody made. A question without a default outcome blocks work without anyone noticing that it is blocked. If you write down in advance what happens after three days of silence, the agent can carry on and I can safely skip a day. The default outcome must be something that does nothing irreversible.

Two more habits

One question at a time. Not ten questions in one message. Whoever has to decide ten things at once decides one well and nine quickly. I get the next one only when the previous one has been answered.

Big sets on one page. If I have many choices, they sit on one page where I click an option or type a note for each item. Not per chat message. A chat is for single questions. Whoever puts a pile of decisions in a chat gets a pile of separate replies back that you then have to merge again.

Why the number of questions matters

In AI-agenten die het werk doen I describe eight remarks I made about an interface, all eight of which could have been measured from a screenshot. Eight questions to a human that never needed to be questions. What matters to me is the side that gets noticed less: fewer questions make the remaining questions usable. Someone who is asked eight times whether something looks good doesn't look properly the ninth time. An approval that comes by a hundred times a day is, on paper, human oversight and, in practice, a click.

The design is therefore: few questions per person per day, and every question worth asking. What a machine can measure, it measures itself. What is truly a judgement call arrives as a card. That way the report stays a report and the card gets read.

How the two are connected

A green light and a report seem far apart, but they share the same weakness. Both are a summary of something you are not present for as a human. And both can be prettier than reality without anyone lying. A test that measures nothing is not badly meant. A question on page two is not hidden on purpose. These are design flaws, and you solve them with a design, not with more attention.

For the light, that is the trial: break it, see it go red. For the report, that is the card: take the question out and give it a fixed form.

What you can do on Monday

Pick one check or automation in your own work and do two things.

1. Break it. Remove what it is meant to guard and see whether it goes red. If it doesn't, you have found a green light that measures nothing. If something else goes red, you are measuring the wrong thing.
2. Find the hidden question. Take the last report you received from an agent, a colleague or a supplier. Is there a question in it, and could you say what happens on yes, on no and on no answer? If not, rewrite it as a card.

Both take a quarter of an hour, and they tell you something more often than you would think.

How do you know that a check in your process would really notice something, and which question has been sitting open at your place for a week?

All pieces