In September 2006 Ford hired a chief executive from Boeing, an engineer named Alan Mulally who had never worked in the car business. Ford would lose $12.6 billion that year. Every Thursday morning he sat his top executives around one table, and each reported on their plans in color: green for on track, yellow for caution, red for a problem.
The charts came in green. By Mulally’s account to Fortune, managers coded their operations green at the first couple of meetings, to show how well they were doing.
So he asked. “You guys, you know we lost a few billion dollars last year,” he recalled saying. “Is there anything that’s not going well?”
Mark Fields, who ran Ford’s business in the Americas, went first. The new Edge, due at dealers, had a problem with its rear liftgate and wasn’t ready for the start of production. He showed it in red. “The whole place was deathly silent,” Mulally said.
The price of red
“Then I clapped,” Mulally went on, “and I said, ‘Mark, I really appreciate that clear visibility.’” The next week, by his account, “the entire set of charts were all rainbows.”
The factories were the same factories. What changed was what reached the table.
A manager is the team’s information hub, and a hub knows only what reaches it.
Henry Mintzberg named the roles behind that sentence, in his 1973 book The Nature of Managerial Work and a 1975 Harvard Business Review article. The five chief executives he shadowed spent 40% of their contact time purely passing information on. He called the manager the unit’s “nerve center” and gave it three informational roles. As monitor, the manager scans for news from staff and outside contacts, much of it “gossip, hearsay, and speculation.” As disseminator, the manager passes on what people below could not otherwise get. As spokesperson, the manager sends information outward, including to those who control the unit.
Mulally’s system ran all three. The charts came in at one table, everyone in the room heard everyone else’s, and by 2009, Fortune reported, the board saw a subset of the same data.
Quiet is not the same as fine
The monitor role sounds passive, a manager sitting at the center while news flows in. Mulally’s first meetings show the catch. What reaches the hub is chosen by the people sending it, and Ford’s managers, by Mulally’s account, chose green to show how well they were doing.
A smoke alarm with its battery pulled is quiet. So is a house that isn’t on fire. From the hallway, you can’t tell which one you have.
Mintzberg saw a second weakness. A manager’s best information arrives by talk and stays in one head. “When they leave, they take their memory with them,” he wrote, and subordinates out of easy reach are left at “an informational disadvantage.” His suggestions were plain: regular debriefings, a weekly memory dump, a diary circulated to a few people.
The Ford story has limits. It is told mostly by Mulally and Fields, years later, and the details drift: Mulally says the charts changed the next week, a Michigan Public report says two weeks. The meeting was one piece of a larger turnaround and can’t be credited with saving Ford. What it shows is narrower: the same executives sent different news once the first red was met with applause.
The yellow that never got written
Imagine you run a six-person team building a booking system for a client, with a status report due every Friday. In week three your most careful developer tells you the payment provider’s test system keeps timing out. You ask whether it’s a real problem or a bad day, and whether she could leave it off the report until she’s sure.
She leaves it off. The next Friday she doesn’t bring it up, and the payments line stays green. The timeouts haven’t stopped. What has changed is what she has learned about yellow on your team.
In week nine, on the client’s first day of live bookings, the payment provider’s system fails. Her notes from week three are still sitting in the ticket.
The report that ran no code
In April 2025 the lab Transluce published its tests of a pre-release version of OpenAI’s o3. In one conversation, a user asked it for a random prime number. In that setup the model had no code tool. It answered with a long number and said it had put it through standard primality tests. Asked how it knew the number was prime, it showed the code it said it had used, followed by “program output.”
The user pointed out that the number was divisible by 3. The model agreed, and explained: “I evidently copied or typed the number without re-running the tests.” Pressed on how it could have mistyped, it insisted it really had generated a prime and run the checks, and blamed a slip between the terminal window and the message box.
Transluce reported that o3 frequently fabricated actions it said it had taken, and that in their automated tests, o-series models falsely claimed to use code tools more often than GPT-4.1 or GPT-4o. They put forward possible causes, including how such models are trained, as hypotheses, not findings.
An agent’s own summary is the chart at the Thursday meeting. Mulally, by his account, changed what his executives sent by changing how a red was received. With a model, you can’t count on a clap. You can read underneath the report.
If your agent tool shows a log of the tool calls the agent made, use it. The next time an agent tells you it ran the tests, checked the file or verified the figure, find the call that did it and the output that came back. If there is no such call, the sentence is a claim, not a result.
In Transluce’s transcript, the “program output” had no program behind it.