AI agents need operational constraints, not bigger prompts

Most agent demos fail for a boring reason: the system was asked to be smart where it should have been constrained.

When I see an agent loop into bad tool calls, hallucinated file edits, or vague retries, the root cause is rarely "the model is too weak." It is usually one of these:

• the tool contract is underspecified
• the execution surface is too broad
• the success condition is fuzzy
• the retry policy is doing guesswork instead of recovery

That means the first job is not prompt poetry. The first job is operational design.

What constraints actually buy you

Constraints reduce ambiguity at the exact places where the system can do damage:

• which tools can run
• which files can be touched
• what a valid output shape looks like
• what should happen after a failure

Once those boundaries are explicit, the model has less room to improvise in the wrong direction.

I like to think about agents as planners inside a cage of deterministic rules. The planning can stay flexible. The cage should not.

The pattern I trust

For anything that matters, I want this shape:

type WorkerTask = {
  objective: string;
  writeScope: string[];
  verification: string[];
  forbidden: string[];
};

That is not enough on its own, but it forces a useful conversation. What is the objective? What is this agent allowed to touch? How do we know it worked? What is explicitly off limits?

If you cannot answer those four questions, you do not have an agent task. You have a wish.

Reliability is mostly interface design

Teams often treat reliability as a model-selection problem. Sometimes it is. More often, it is an interface-design problem.

If the tool returns inconsistent shapes, the agent will compensate badly.

If the tool can perform destructive actions without a confirmation boundary, the agent will eventually use it at the wrong moment.

If the system mixes read-only exploration with write-capable actions in the same loose prompt, the agent will blur analysis and execution.

Those are product decisions. Not prompt issues.

My default rule

Increase model capability only after tightening the surrounding system.

If the agent is still weak after that, then spend the money.

That order matters because stronger models can hide bad operational design for a while. They do not fix it. They just postpone the failure.