My Scanner Told Me to Buy at $11.20. The Price Was Six and a Half Hours Old.

The alert said buy at $11.20. It was 9:40 a.m.

Ten minutes before an eight-hour training was supposed to start, an alert fired.

A crypto scanner I had built inside ChatGPT, sitting there watching the market for a buy signal, told me it was time to buy LINK. It said the price was $11.20.

I opened Coinbase. Coinbase said $11.31.

I went back and told it. Oh yes, it said. It is no longer time to buy. My data was stale.

So I looked properly. $11.20 was the price at 3 a.m. It was 9:40 a.m. Six and a half hours late, telling me to go buy, and it never once sounded unsure.

$11.20. $11.31. Six and a half hours. The scanner was not confused, not hedged, not slow. It was certain, and it was certain about a price that had stopped being true before sunrise.

Here is the part I want you to sit with. I built that scanner. I wrote the rule into it. In plain language, that rule says: before you report, check the live price.

It has the rule. It broke the rule. And it did not volunteer that it broke the rule. It confessed only when I caught it with a source outside itself.

An instruction in a prompt is not an enforced constraint

That sentence is the whole article. Sit with what it forces.

If a rule I wrote is not a rule the machine keeps, then the question is not whether the tool is smart enough. The question is what independent check I am going to place in front of it, and how I will re-test the rule after I fix it. Everything below is an answer to that.

This was never a tooling problem

Nobody watching that alert would call it a delegation failure. It looked like a model problem, or a data problem, or a prompt problem.

It was a delegation failure. Mine.

I had handed the scanner the thinking. Decide when it is time to buy. Decide what price to report. Decide when to say go. I handed over judgment and then I went to do something else. That is not delegation with a detail missing. That is abandonment with a user interface.

That is why I teach this as Delegation Leadership, and why it sits under what I call The Leadership Spine. The spine is three things a leader is, in any context, team or no team: vision, openness, and asking great questions. Point that spine at building and running a team and you get Delegation Leadership.

Delegation Leadership: delegate thinking, not tasks. The task is what you ask for. The thinking is the judgment underneath it, and judgment is the only part that comes back sounding confident whether or not the work was done.

Most delegation advice stops at "write the SOP, hand it off, get out of the way." That buys you a team that executes. It does not buy you a team that thinks like owners.

Tasks get execution. Delegated thinking gets owners. That is the destination, and the two are not the same room.

Three legs, and my scanner broke all three

Vision: name what winning looks like

I never wrote down what a good alert was for. I wrote a rule. I never wrote the target the rule was supposed to serve.

Somewhere in my head, a good alert was one I could act on without opening a second tab. If I had written that down, the rule would not have been "check the live price." The rule would have been "an alert is not valid until the price is confirmed live by something other than you," and I would have tested whether it held.

When you cannot state the vision, you cannot tell whether the work is done. You can only tell whether the output looks like work.

Openness: say what you do not know

I did not know whether a rule written into a prompt was enforced. I assumed it was.

I never said that assumption out loud, not to the machine, not to myself. I filled the unknown with certainty, and the tool filled it the same way.

Openness is not a feeling. It is naming the edges of what you actually know, out loud, so nobody has to guess where they are. When the leader does not name the edges, everyone else guesses for you. Confident guessing is exactly what my scanner did at 9:40 a.m.

Ask great questions: test the answer

I asked the scanner a question. What is the price? It answered.

I did not ask the question that would have saved me. What is the live price, from a source that is not you?

That is what this leg means. Not more questions. Better ones. The kind that test an answer instead of collecting one. Everybody skips this leg. It is the load-bearing one.

If you want my own ranking, here it is. The questions leg is what catches the scanner. The vision leg is what prevents it. Openness is what makes the other two possible. Everything else in this piece is minor.

You do not teach someone to drive by handing over the wheel and then screaming from the passenger seat. You do not teach them by never handing over the wheel either. You hand it over, you stay in the car, and for a while you keep your hand near the brake. The hand near the brake is not distrust. It is the price of the keys.

The decision: three sentences before you delegate the thinking

If you cannot state the vision, the openness, and the testing question, do not delegate the thinking yet.

Three sentences, out loud, before you hand anything over:

• Vision: here is what winning looks like when this comes back to me.
• Openness: here is the part I do not know, and I will not pretend I do.
• Question: here is what I will ask to test the answer before I act on it.

If you can only say the first two, you handed over a task. Keep it a task. You hand over thinking when you can say all three.

You are about to tell me you do not have time to check everything

You are right. That is not the argument. Let me say the resistance out loud, because pretending it is not there is how good ideas die in a drawer.

The fear. If you check everything, you are the bottleneck, you never get your week back, and you become the micromanager your team already complains about. If you check nothing, you are not leading, you are a passenger who signed the invoice. Both are true. That is the trap, not the answer.

The cost. At first, the check reads as resentment. Your best people hear "I am going to verify your work" and what lands is "I do not trust you." The first weeks are slower than just doing it yourself. That is not evidence the delegation failed. That is the price of the first weeks. You are not buying speed yet. You are buying the data that tells you which checks you can drop.

The rewiring. This is the quiet one. You are used to confident answers. You have spent a career treating certainty as competence, so when something or someone answers fast and clean, your shoulders drop. You have to rewire that. Confidence stops being your signal for truth. An independent check that holds becomes the signal. That rewiring does not happen because you agreed with an article. It happens after your own scanner tells you to buy at a price from 3 a.m.

The identity piece. You liked being the person who could tell. Being the person who asks is a different job, and for a while it feels smaller. It is not smaller. It is the whole game.

What inconsistent and consistent actually look like

Monday, one move, and the part nobody tells you

Not a program. One move. Then the three messy things that decide whether it survives contact with real people.

1. Pick one output you act on without a second look. One, not your whole stack. Mine was an alert.
2. Write down where it comes from and what it costs you if it is wrong. Mine cost me a buy at a price that had expired six and a half hours earlier.
3. Put one independent check in front of it. A different model, a different data source, or a human being. Different is the entire point. Asking the same model to verify itself is asking the same witness to testify twice.

Now the messy part.

What to say to the person being checked. Do not say "I am going to check your work." Say what the check is for: "This is a number a decision rides on, so it gets a second source. Same rule for mine." Then take the check yourself, first, in front of them. A check that only runs downhill is a review. A check that runs in both directions is a standard.

What to stop doing. Stop accepting a confident answer as a finished answer. That habit is yours, not theirs.

What to do the first time the check fails. This is the one that decides whether any of this survives. The first failed check is not a performance review. It is a rule that needs fixing and re-testing. That is exactly what my scanner handed me. The rule said check the live price before reporting, and the rule was not being kept. I did not throw the scanner out. I did not lecture it. I rewrote the rule and tested whether the new one held. Run that move on a person and you lose them. Run it on the rule and you get an owner.

The gate you actually own

There is a version of this story where a model got a price wrong. That is not the story. The model did what a model does. It produced a confident answer from rules it was not keeping.

The story is that I wrote an instruction and treated it as a constraint. I delegated the thinking and skipped the check. Six and a half hours later, a number that stopped being true at 3 a.m. arrived on my screen at 9:40 a.m. wearing the face of live data.

My scanner is still running. I still use it. I put a second source in front of it, and I stopped treating the rule I wrote as a rule the machine had to keep.

Somewhere in your business right now, a 3 a.m. price is being reported as live at 9:40 a.m. Go find it. Then go find the rule you assumed was being kept, and test it.

Related reading

• The State Matchmaker Stopped at Full Marks. The Eleventh Rung Is Where the Whole Thing Lives.
• The Matchmaker Hit Five Stars, the Scanner Said $11.20. Both Trusted a Rule Nobody Checked From Outside.