Engineer splits agent decisions into four timed loops

Sean Goedecke built a real-time agent on a decision model and hit two walls anyone building a router, ranker, or retry-escalate layer will recognize.

The first: a single update loop can't serve both fast reactions and slow planning. The second is worse. Ask the model to score more than 100 candidates in one pass and it doesn't just get sloppier, it fails outright.

His fix for the first problem is nested timing instead of one loop deciding everything. He ran four loops on separate clocks: strategic goals recalculated every 10 seconds, tactical subgoals every 5, specific targets every 1, raw input control every 100 milliseconds. Each layer feeds its output to the one below it. A call made at the 10-second layer keeps shaping behavior through several cycles of the 1-second layer below it, so the system isn't re-deciding everything from scratch on every tick, per his post on system-one models.

The second fix is tournament-style batching. Score a hundred candidates at a time, take the winners, run a second pass over just those. It works, Goedecke found, because the model is far better at picking a winner between two options than assigning either one an absolute number.

Neither trick is specific to his project. Anything asking a model to rank a large set, or to run the same function at both a 100ms and a 10-second scale, hits the same wall. Goedecke doesn't say what candidate count his system needed before scoring broke down, only that it happened past 100, so where the cliff sits in other setups is untested. The relative-judgment failure is the cheaper one to hit by accident, which is why it's worth checking first.