Every fresh answer came from the future.
That was the verdict of the Conductor, the software that assigns work at First AI Movers. It asked its worker servers how full they were. Each server checked its load, stamped the answer with the time, and sent it back.
The answers were fresh. The Conductor rejected them anyway.
How could both worker servers keep sending answers from a time that had not happened yet?
The company runs much of its work through AI agents. Its worker servers are called Development Cells. Think of them as workrooms with space for jobs. The Conductor runs on a separate server and decides which waiting job goes to which room.
It already had stored reports of how full those rooms were. But a job might finish after the last report. A fresh check could reveal the open space and let the next job start right away.
That was what the check was for. Instead, on September 30, both cells’ readings were marked `FROM_FUTURE` each time through the observed run.
An AI investigator found the problem while tracing a job that had been parked instead of placed.
The clocks were the obvious place to look. A server with its clock set ahead could stamp an answer with a time that had not arrived on the Conductor’s clock. Refusing that answer would make sense.
But the clocks agreed. All the machines had their time kept in sync. The measured gap between them fit within the time it took to send a request and get an answer.
The clue was in the Conductor’s own routine.
At the start of a cycle, it saved the current time. Later in that cycle, it asked the cells for their load. Each cell stamped its answer when it took the reading.
The Conductor then compared that new stamp with the time it had saved at the start.
A cycle took roughly three minutes. The load checks happened well after it began. A correct answer would therefore carry a later time than the one used to judge it.
It was like writing down the time before sending a question, then rejecting the reply because it arrived afterward.
The answers had not come from the future. The check was still looking at the past.
This mistake did keep the system safe. It did not count occupied space as free. But it also kept freed space out of sight until a stored report caught up. In the observed cycles, that took 21 to 26 minutes.
The investigator offered a possible reason the tests had missed it: they used a fixed time and built their readings around it. They did not cover a reading taken after the saved time. That was an inference in the record, not a proven cause.
A writer session was launched to make the repair. The change was then merged: finish the load reads first, and only then take the time used to judge them.
The rule stayed strict. An answer stamped later than that decision time still had to be refused. A new test covered that case. The repair changed the order, rather than allowing a bigger clock gap.
The fix was running. Then came the awkward part.
The cycles that followed had no work to place. The Conductor never asked for a load reading. Its repaired check had nothing to check.
The fixer reported that proof from live use was still pending. The next useful evidence would come from a cycle that actually read a load.
Days later, a laptop readiness check hit the same trap. Its time was stamped before its fresh reads, so successful reads looked like future ones. That check was fixed too.
But a later review found no newer proof recorded for the Conductor. The original issue remained open as of October 14. That did not prove the repair had failed, or that no useful cycle had run.
The clocks had been cleared. The repair was running. The record still lacked the answer that would prove it worked.
What any founder can take from this
- Check when a rule takes its measurements. Correct data can fail a check made in the wrong order.
- Ask what a safety rule delays as well as what it prevents. Here, safe rejection hid freed space.
- Define the live event that will prove a repair works. A quiet run may never exercise the changed rule.
Next time: “The Guard That Blocked Its Own Bug Report.”
How this article was made: This draft uses the supplied facts sheet, which cites the investigation, repair, status messages, and later review. Events are reported, not dramatized; the workrooms and reply example are explanatory comparisons. No dialogue, feelings, or live success has been added. Corrections are welcome and will be dated. Draft dated October 14, 2026.