When all you have is a hammer, everything looks like a nail.
Now that we have AI agents, it’s tempting to have them reason through every step of a task. Check a status? Have the agent interpret a record. Calculate a total? Have the agent read the numbers and tell you what they add up to. Decide whether a customer said yes? Have the agent judge the reply.
The agent can handle all three tasks. The question is how you ask it to do each one. It can check a field, use a calculator, or interpret a conversation. Those choices matter when bots start doing work for you and interacting with your customers. Two concepts help explain why: determinism and non-determinism.
A deterministic system produces the same output from the same inputs under the same conditions. A non-deterministic system can produce different results. Language models are generally non-deterministic, so repeating a prompt can produce a different response. Google’s machine learning glossary
That sounds abstract. Let’s make it practical. Suppose you’re building a bot with this instruction: “When the customer says ‘yes’, move to the next step.”
The user responds, “Yes.”, with a capital Y and period. The app checks whether their response matches all lower case “yes”, so the algorithm misses. You decide to account for capitalization and punctuation.
The next person writes “sure.” Then “okay.” Then “sounds good to me.” Damn! Missed again. You add more rules. Those rules are deterministic. You have explicitly defined which responses will match and what happens when it does.
Then someone writes: “I don’t see why we wouldn’t.” Damn Damn. Got me again.
This is where a language model becomes useful. You can ask it to interpret whether the person agreed, using the conversation as context. You no longer have to anticipate every possible phrase yourself. That flexibility is powerful. It also introduces a different kind of decision into your workflow.
There’s a distinction worth making here: interpreting language, inference, and non-determinism are related in these systems, but they describe different things.
Inference is the process of running a trained model on new input to produce an output. It doesn’t specifically mean understanding someone’s intent, and it doesn’t inherently require non-determinism. For our bot, inference is how we run the model. Interpreting the customer’s response is the task we give it. Non-determinism describes the possibility that its answer may vary between runs.
Keeping those ideas separate helps us ask better questions: where does the ability to interpret justify the cost and uncertainty and what did the customer actually approve?
Consider a few more responses:
- “Sure, if you can deliver by Friday.”
- “Okay, but send me the revised price first.”
- “k”
- “Yah, sometimes…”
It would take a lot of guess work and lists of hardcoded matches to catch all the ways a person could say yes. So we decide to use an agent for non-deterministic results. Even then, these deserve different treatment. A positive tone can may contain a condition, or no approval at all. “Sometimes” is especially revealing. It does not clearly lay out what approval requires to get to the next step. Even “k” can mean different things depending on what came before it. The agent can interpret the words and the context, but it cannot decide your standard for approval on its own every time. That standard is partly a matter of judgment and policy, and different people may draw the line in different places. Human or bot.
If your bot’s instruction is “look for anything that sounds like positive movement,” you may have built a system that turns interest into permission. The work is in telling the agent what counts as approval for this task, and what to do when the answer is unclear.
For a bot suggesting another article, a loose interpretation might be acceptable. For a bot placing an order, you may want explicit confirmation of the item, price, and delivery terms.
The model’s ability to interpret language doesn’t decide how much ambiguity your business should accept. You have to decide that.
This amazing ability to allow for a great deal of flexibility and variation has changed our world of work. That doesn’t mean every problem requires it now. Model calls consume massive compute, and asking an agent to interpret more information can add cost and wait time. Sometimes that expense buys something valuable: understanding an unusual request, connecting ideas across documents, or drafting a useful response. Other times, the answer is already available as a field, a formula, or a rule. I wrote more on how you can balance agentic power with deterministic costs here.
Let’s use a common email bot helper that many are using to increase productibity today. Suppose you ask your agent to find the messages that need your attention (archiving or deleting all the slop). It could read your entire inbox every time you ask. That gives it plenty of context, but it also takes time and uses inference on messages a simple filter could handle.
Instead, ask your agent to create a filter for the obvious parts of that task. It can easily screen out information from site you like but only when it doesn’t meat pattern you’ve seen. Those filters will (deterministically) trim the data your agent needs to interpret down – sometimes to zero. Then it can read what’s left. The agent still does the work. You’ve asked it to spend its reasoning on the messages that need reasoning. Then you can even add a routine to have it create filters based on probably patterns it’s deleted without reading. Each run decreases costs.
Using the customer confirmation example from before, I’d redesign the handoff like this: Have the model interpret the reply as approval, rejection, conditional approval, or unclear. You can even include definitive reply patterns to increase speed and save a cent or two each run.
- Ask you dev agent to create a deterministic list of positive exact match cases that ignore periods and captialization.
- Provide explicit non-deterministic rules to understand what each category should permits.
- Ask the user for clarification when a condition or ambiguity affects the next action.
The filter trims the use of the model, model helps interpret the conversation. The rules establish what the system may do with that interpretation. That’s the design decision that deserves more attention as we put agents to work. Thinking, along with the agent, while developing or setting up our personal bots saved the world time, energy, air quality, speed, cost, and more.
Every request for interpretation should earn its place. What ambiguity is the agent resolving? What flexibility are we gaining? What happens when its interpretation is wrong? How can I trim the list of variations with certainty first? An agent can build and run the whole workflow, including creating the filters, lookups, and calculations that let it focus its judgment where it counts.
Knowing when to remove from you agent with your agent, implement with your rules your agent can reason with, and when to have it check back in to be sure, is part of using all the tools on your toolbelt based on what works best.
