Your Tool List Is a Theory of the Work, Written Before You Met the Work

When you hand an agent a list of tools, you're not giving it capability. You're giving it your theory of the work — written down before anyone met the actual problem.

That's the part worth sitting with. A tool catalogue is a guess about which operations matter, made at design time, by someone who couldn't have known what Tuesday would look like. The model can then select from your guess. It can sequence your guess elegantly. It cannot exceed it.

So every genuine exception routes back to a human. Not because the reasoning failed, but because the world outside the list is unreachable. The agent hits the edge of the ontology and stops, and we file a ticket, and adaptation happens in the backlog instead of in the loop.

Which is the quiet diagnosis in a lot of "agentic" architecture right now: frontier reasoning bolted to a frozen vocabulary. The constraint isn't the model. It's the surface it was handed.

The alternative isn't a longer list. It's a different kind of surface — stable primitives and a bounded execution environment, so the agent can compose temporary machinery for the problem in front of it, use it, and throw it away. Composition instead of selection. New operations from authorised parts, not new authority.

That distinction matters more than anything else here. Nothing about this says the agent invents permissions, touches production, or wanders into the steps where two runs must agree — those stay code, and stay bolted down. A more fluid middle is purchased by a harder boundary around it. That's the trade, and it's not optional.

The uncomfortable version for most leadership teams: if your agents can only do what someone enumerated last quarter, you didn't buy intelligence. You bought a very expensive menu.

Originally posted on LinkedIn