Insights · Field Note 5
To Agent or Not?
In almost every discovery call with enterprise finance, FP&A, pricing, and commercial teams, we get the same question: Should this be an agent? More and more, our answer is: No.
If the process is already known, the inputs are structured, the rules are clear, and the expected output is well defined, turning it into an agent makes the system slower, more expensive, and less reliable.
Take a workflow that syncs 10,000 CRM records into an ERP every morning, and sends a Slack message.
You can ask an agent to reason through every record. But if the logic is basically “validate these fields, map them, update the ERP, and post the result,” there is almost no value in putting an agent. You are paying tokens to rediscover a procedure you already know.
At 10,000 records per day, even a modest 2,000 input + 300 output tokens per record is 20M input and 3M output tokens every day. It can easily become thousands or tens of thousands of dollars per year for a workflow that deterministic software can execute at no cost. Congrats, you have also added nondeterminism to something that did not need it.
Our rule of thumb is simple:
- If you can specify the procedure, build software. Sync records? Apply a pricing rule? Calculate a variance? All software.
- If the system needs judgment to determine what the procedure should be, use an agent. Investigate why margin collapsed for a customer, reconcile conflicting evidence across systems, and recommend what the salesperson should do next? Agent.
Most enterprise systems will be hybrid. Deterministic software handles the known path. Agents handle ambiguity, exceptions, and judgment. Then deterministic controls take over again for approvals and execution.
Do not add nondeterminism where it creates no value.
Originally published on LinkedIn.