When Not to Use an Agent

The industry is in a phase where every form is suspected of being an agent in waiting. Password reset? Agent. Expense report? Agent. Calendar invite? Surely an agent. I have sat in meetings where the alternative — a well-labeled button — was treated as a lack of ambition.

Ambition is the wrong frame. An agent is a costly way to search a space. If you already know the path, you should not search. You should encode the path and let a person confirm it. That is not a lesser product. That is a finished one.

A short refusal list

• The happy path is known and short. Use a wizard.
• The cost of a wrong action is high and the checks are weak. Use a human.
• The user already knows what they want and can point to it. Use a form.
• You cannot write a stop condition. You are not ready.
• You are using the agent to avoid talking to the user. They will notice.

Where the loop earns rent

Agents shine when the next step is genuinely unknown and the world can talk back. Debugging a flaky test across a large repo. Reconciling a messy inbox of invoices against a ledger. Drafting a migration where the compiler is a harsh, useful critic. In those rooms, a loop that can look, try, and halt is cheaper than a person grinding through the fog.

Even there, the surrounding product should be boring. Show the trace. Show the diff. Make undo obvious. Let a person grab the wheel without filling out a “feedback sentiment.” The agent is the search. The product is the rails.

I would like us to get our pride back about software that does one obvious thing. Not every empty chair needs a ghost in it. Some chairs are empty because the work is done.