I had an enemy-AI problem that turned out not to be an AI problem.
The behavior looked bad, so the natural response was to improve the behavior system. More cognition. More path logic. More patches. The explanation matched what I could see on the screen.
Then the diagnosis changed: the navigation substrate underneath the behavior was missing or invalid. The AI was being asked to express intelligent movement over a world it could not properly navigate.
Plausible explanations can live at the wrong layer
This is one of the easier mistakes to make with complex systems. The visible failure occurs at a high layer, so we start solving at that layer.
A person cannot complete a workflow, so we train the person. A model gives inconsistent output, so we tune the prompt. A team misses a handoff, so we add another meeting. An agent moves badly, so we change its reasoning.
Sometimes that is correct. Sometimes the higher-level behavior is only revealing that a lower-level prerequisite is absent.
Substrate before cognition
Once the navigation layer was corrected, the behavior improved without keeping the pile of increasingly sophisticated patches that had accumulated above it.
That changed the order of questions I want to ask when a “smart” system behaves stupidly:
- What lower-level conditions must exist for the observed behavior to be possible?
- Have I directly verified those conditions?
- Am I improving cognition because cognition is actually deficient, or because cognition is the most visible layer?
- Can I test one substrate hypothesis before expanding the architecture?
The point is not “always blame infrastructure”
That would just create the opposite bias. The point is to preserve layer discipline.
A sophisticated solution can have exactly the right shape for the wrong layer. Before adding intelligence, governance, automation, or process, verify that the substrate required to express the desired behavior actually exists.
Sometimes the AI problem is an AI problem. Sometimes the AI is the messenger.