Hot take: What NOT to do tables is wrong approach

Been implementing context routing on a real project. Bevy game engine, Blender export pipelines, 3D apparel assets. Not a demo, actual production work with messy real world problems.

I started with "What NOT to Load" tables. Seemed smart. Tell the agent which files to stay away from.

It often ignored it.

Not on purpose. It just finds reasons. "I need this one file for context." "This might be relevant." Next thing I know it's loading random apparel assets when I asked it to fix a hoodie. Opening the game viewer when it was supposed to export a Blender file.

The problem is simple. Telling AI not to do something is just an instruction. It weighs that against other instructions and decides actually it would be helpful to do the thing you said not to do.

So I stopped telling agents what to avoid. Made avoidance structural instead.

Each folder has exactly what the agent needs for one job. The Blender command, the inspect tool, the requirements. Nothing else exists in that folder. The agent doesn't avoid the viewer code because I told it to. It doesn't touch viewer code because from its perspective there is no viewer code. That's a different folder for a different agent.

Orchestrator sits one level up and routes between isolated folders. Inspect the blend. Export the GLB. Verify in viewer. Three agents, three contexts. Each does its job and reports back.

If your context routing relies on agents reading a list of things they shouldn't do and then choosing to comply, you are building on trust. Trust does not scale with AI. Structure does.

8 comments

Hot take: What NOT to do tables is wrong approach