Not Every AI Problem Needs a Language Model

Executive summary

• MIT’s 6.034, Artificial Intelligence, Spring 2005, taught by Leslie Kaelbling and Tomas Lozano-Perez, was organized in three blocks: search and constraint satisfaction, machine learning, and logic and knowledge representation. Only the last block touches language at all.
• Several core revenue operations problems are constraint satisfaction or rule-based inference problems: territory design, quota allocation, lead routing, discount approval, capacity assignment.
• Those problems have solutions that run in milliseconds, cost a fraction of a cent, return the same answer every time, and can explain themselves.
• A language model applied to them is the most expensive and least predictable instrument available, and it cannot tell you why it decided what it decided.
• The dividing line is simple: if the input or output is language, an LLM is the right tool. If the problem is allocation, assignment, ranking or enforcement, it usually is not.
• There is a second question underneath that one, and it is currently the more expensive of the two: when the task is a language task, does it need an agent or a workflow with model calls in it? If you can draw the flowchart in advance, however many branches it has, you have a workflow.
• This is not an argument against AI in the commercial function. It is an argument for using the correct member of a toolbox that is larger than the current conversation suggests.

What the word used to cover

Look at what an elite university taught as artificial intelligence before the current wave.

MIT’s 6.034, as taught in Spring 2005 and published through MIT OpenCourseWare, covered three areas across a semester:

• Search, three weeks: graph search, constraint satisfaction, games
• Machine learning, five weeks: nearest neighbors, decision trees, naive Bayes, linear separators, neural networks, support vector machines, feature and model selection
• Knowledge representation and inference, five weeks: propositional and first order logic, rule-based systems, natural language

The course description names its subject as “representations, techniques, and architectures used to build applied systems,” and lists “rule chaining, heuristic search, logic, constraint propagation, constrained search, and other problem-solving paradigms.”

Two things stand out from a commercial seat in 2026.

First, only one of those thirteen weeks concerns language. Everything else is about finding, deciding, classifying and proving.

Second, none of it is obsolete. Constraint propagation still solves scheduling. Decision trees still classify with an auditable path. Rule chaining still enforces policy. These techniques did not stop working when transformers arrived. They stopped being marketed.

That is the actual change. Not that the older methods became worse, but that a single method acquired a sales motion and the others did not.

Where this shows up in a revenue organization

Take the problems a revenue operations team actually owns and ask what kind of problem each one is.

The bottom four are genuinely language problems, and a language model is the correct and often the only practical tool. The top eight are not, and each of them has a method that predates the current wave by decades.

Why the distinction is commercial, not academic

Three differences matter to a P&L, and none of them is about model quality.

Cost behavior. A constraint solver assigning three hundred accounts across twelve territories runs in under a second on ordinary hardware for effectively no marginal cost. The same task through an agentic LLM workflow consumes tokens that vary substantially run to run, which is the unit economics problem applied to a task that did not need to have it.

Determinism. Run the optimizer twice on the same inputs and you get the same territories. Run the language model twice and you may not. For a task where the output becomes someone’s compensation plan for a year, reproducibility is not a nice property. It is a requirement, and its absence surfaces the first time a rep asks why their patch changed.

Auditability. A rules engine can answer “why did this lead go to that rep” with the rule that fired. A decision tree can show the path. A language model can produce a fluent explanation that may or may not describe what actually happened inside it. When the question comes from a rep, a customer or a regulator, the difference between a reason and a plausible account of a reason is the whole thing.

There is a fourth difference that matters more than it should: nobody is selling you the optimizer. Constraint solvers and rules engines are unglamorous, they are frequently already inside software you own, and no vendor has a reason to run a campaign about them. That absence of marketing is a poor reason to choose an instrument, and it is currently one of the strongest forces in enterprise technology buying.

Two tests before the tool decision

Test one: is the input or the output language?

If the work consists of reading unstructured text, producing text, or converting between text and structure, a language model is the right tool and the rest of this article does not apply.

If the work consists of assigning, allocating, ranking, scheduling or enforcing, it is probably not, whatever the vendor demo showed.

Test two: what happens when the same input produces a different answer?

If the answer is “nothing, someone reviews it anyway,” variance is acceptable and a language model is workable.

If the answer is “we would have to explain it,” the task needs a deterministic method. Compensation, territory, approval authority, eligibility and pricing all fall on this side, and they are the exact tasks where an unexplainable answer costs the most.

Together those two questions resolve most tool decisions in a commercial organization in about a minute, which is less time than most companies currently spend on them.

The second question: agent or workflow?

Suppose the task passes both tests. It is a language task, and variance is tolerable. You are buying a language model.

There is still a decision underneath, and right now it is the one moving the most money. Does this need an agent, or a workflow with model calls in it?

The distinction is not intricacy. Prashant Mudgal, writing in Towards Data Science in August 2026, works through an aviation maintenance example detailed enough to look unmistakably agentic: read the fault code, pull the fault history, consult the troubleshooting manual, check parts availability, check what is deferrable under the minimum equipment list, weigh the operational cost against the aircraft’s next ten rotations, produce a recommendation.

Then he rejects his own example, and the reason is the useful part. You can draw that flowchart. It has many branches and a competent engineer could specify all of them in advance. As he puts it, a tree with two hundred branches is still a tree.

The line he settles on is narrower and sharper: automation handles known unknowns, agents handle unknown unknowns. You do not know whether the part is in stock, but you know that stock is a thing to check. That is a workflow. You do not know what you need to check, and you will only find out by looking. That is an agent.

His example of the second kind is due diligence on an acquisition, where the instruction is one line and the path cannot be enumerated: a clause leads to a filing, the filing hints at an inquiry that appears in no data room, and the inquiry sends the system into news archives and court records for something nobody had on a checklist.

Why this is worth an hour of a CFO’s attention. Agentic execution is the most expensive way to run a language task by a wide margin. The Stanford Digital Economy Lab work on token consumption in agentic tasks found they consume on the order of a thousand times more tokens than a simple chat exchange, because every step re-reads accumulated context, and that runs on the same task can differ by up to thirty times in total tokens.

So the cost of getting this wrong is not marginal. Buying agentic execution for a problem you could have drawn as a flowchart means paying roughly three orders of magnitude more, with unpredictable variance, for an answer a deterministic workflow would have produced the same way every time.

The test, in one question: can a competent person in this domain draw the decision path in advance? If yes, build the workflow and put model calls at the steps that need language. If genuinely no, you have an agentic use case, and they are rarer than the market implies.

Where the real agentic use cases actually live

Mudgal makes one further observation that is more useful to a revenue leader than the definition itself.

Enterprises spent decades deliberately engineering open-ended state out of their processes. Standard operating procedures for every scenario. Approval thresholds with fixed triggers. Rules in the ERP, the CRM and the compensation system. A purchase order above fifty thousand goes to the CFO, always, not because that is the smartest rule but because it is auditable and it scales.

The goal was to make processes repeatable without requiring thinking, and it worked.

But removing ambiguity from a process also removes its ability to handle anything the designers did not anticipate. So every enterprise built a pressure valve for the leftovers: the exception queue. Whatever does not fit gets escalated to a person, that person applies judgment, and if the same exception recurs often enough someone eventually writes a new rule and it gets absorbed back into the process.

His conclusion is the line worth keeping: the humans at the edges of those processes were the agents all along, absorbing the unknown unknowns while the org chart pretended that was not happening.

That is directly actionable, and it inverts how most companies go looking.

Do not start from a process and ask whether an agent could run it. The processes that are already documented well enough to automate are, by construction, the ones where the path is known, which makes them workflows.

Start from the exception queue. Deal desk escalations. Non-standard pricing requests. Contract redlines that do not match any template. Customer situations that get routed to a named person because nobody wrote a rule for them. That is where the open-ended judgment in your commercial organization actually sits, because it is where you deliberately put it.

Whether an agent should handle any of it is a separate question, and often the answer is still no. But it is the only place worth looking first, and almost nobody looks there.

The hybrid that usually wins

The framing is not language model against classical method. Most real problems use both, and the split is usually clean.

Territory design is the clearest example. The assignment itself is a constraint problem: balance the books, respect the boundaries, limit disruption to existing relationships. That belongs to an optimizer, and the output should be reproducible.

Explaining the result to forty affected sellers is a language problem. Writing forty individualized notes covering what changed, why, and what it means for their pipeline is exactly what a language model is good at, and doing it by hand is why territory changes are communicated badly.

The same pattern holds elsewhere. The scoring model decides, the language model explains. The rules engine routes, the language model drafts the handoff note. The optimizer allocates quota, the language model produces the manager talking points.

Deterministic method for the decision. Language model for the communication. That division gives you a defensible answer and a well-written one, and it costs a fraction of putting the whole workflow through an agent.

Five ways this goes wrong

1. Letting the demo pick the method. A language model demo is compelling for almost any problem, because fluent output looks like competence. The demo shows that a tool can do the task. It says nothing about whether it should.
2. Assuming the older methods are unavailable. Optimization and rules capability is frequently already present in the CRM, the planning tool or the compensation system, unused, because nobody went looking for it after the AI budget was approved.
3. Using an LLM because the data is messy. Messy inputs are a real problem and a language model can genuinely help clean and structure them. That is a preprocessing step, not a reason to also hand it the decision that follows.
4. Treating explainability as a compliance box. In a commercial organization the audience for the explanation is usually a seller whose territory or comp just changed, not a regulator. They will ask, they will not accept “the model decided,” and trust in the system is lost at that moment rather than at an audit.
5. Ignoring the split. Companies tend to choose one instrument for a whole workflow. Almost every commercial workflow has a decision half and a communication half, and they want different tools.

What to do with this

Take the list of AI initiatives currently approved in the commercial function and sort them with test one. Language in or language out on one side, everything else on the other.

For anything on the second side, ask what method the problem would have been given by someone trained before 2015. Frequently the answer is a solver or a rules engine, the capability already exists somewhere in the stack, and the initiative can be delivered faster, cheaper and more defensibly than planned.

That is not a downgrade. It is the same outcome at lower cost with a better audit trail, and it frees the AI budget for the problems that genuinely require the expensive instrument.

This is also the practical version of a broader point: an AI program reaches earnings when it changes something structural about the business, not when it applies an expensive tool to a solved problem. That argument is made in full in why AI spending rarely reaches earnings.

Frequently asked questions

When should you not use an LLM?

When the problem is allocation, assignment, ranking, scheduling or policy enforcement rather than language. Territory design, quota allocation, lead routing and approval authority are constraint or rule problems with deterministic solutions that run faster, cost less and can explain themselves. Use a language model when the input or output is text.

What is the alternative to an LLM for these problems?

Constraint satisfaction and optimization for allocation and scheduling, rules engines for policy and routing, and classification methods such as decision trees or gradient boosting for scoring. All were standard curriculum well before the current wave. MIT’s 6.034 taught them to undergraduates in 2005.

Are these older methods still valid?

Yes. They did not stop working when language models arrived, they stopped being marketed. Constraint propagation still solves scheduling, decision trees still classify with an auditable path, and rule chaining still enforces policy. The capability is often already present in software a company owns.

Can we use both?

That is usually the best answer. Use the deterministic method for the decision and a language model for the communication. An optimizer assigns territories reproducibly; a language model writes the forty individualized explanations that follow. You get a defensible answer and a well-written one.

How do we decide quickly?

Two questions. Is the input or output language? And what happens if the same input produces a different answer twice? If the second answer is “we would have to explain it,” the task needs a deterministic method. Compensation, territory, approval, eligibility and pricing all fall on that side.

What is the difference between an agent and automation?

Not intricacy. A flowchart with two hundred branches is still a flowchart. The workable distinction, argued by Prashant Mudgal in Towards Data Science, is that automation handles known unknowns and agents handle unknown unknowns. If a competent person in the domain could draw the decision path in advance, however complicated, it is a workflow. If the path can only be discovered by looking, it is agentic. The second category is much rarer than the market implies.

Why does it matter commercially whether something is an agent or a workflow?

Cost, by roughly three orders of magnitude. Stanford Digital Economy Lab research on agentic tasks found they consume on the order of a thousand times more tokens than a simple chat exchange, because each step re-reads accumulated context, and that the same task can vary up to thirty times in total tokens between runs. Buying agentic execution for a problem you could have drawn as a flowchart is the most expensive available mistake in this category.

Where should we look for genuine agentic use cases?

The exception queue. Enterprises spent decades removing open-ended judgment from documented processes, then escalated whatever did not fit to a person. Deal desk escalations, non-standard pricing, contract redlines with no template, customer situations routed to a named individual. That is where the unmapped judgment in a commercial organization actually sits, because it is where it was deliberately placed. Processes that are documented well enough to automate are, by construction, workflows.

Sources

1. Prashant Mudgal, “Is Agentic AI Just Automation?”, Towards Data Science, August 26, 2026. Cited for the known unknowns and unknown unknowns distinction, the aviation maintenance example and its rejection, and the observation that enterprises engineered open-ended state into exception queues. Practitioner argument, attributed as such.
2. Longju Bai et al., “How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks,” Stanford Digital Economy Lab, 2026. arXiv 2604.22750. Cited for agentic token consumption relative to chat and for run-to-run variance.
3. MIT 6.034, Artificial Intelligence, Spring 2005. Instructors: Prof. Leslie Kaelbling and Prof. Tomas Lozano-Perez, Department of Electrical Engineering and Computer Science. Published by MIT OpenCourseWare under a Creative Commons license. Syllabus, course description and calendar used for the course structure and topic list.

About the author

Andre Magrini is a chief revenue officer and fractional CRO based in the Greater Chicago Area. He led North America for Ag Growth International and, as general manager in Brazil, scaled an operation more than 4x in three years. He served as Vice President of the Marketing and Communications Committee at the American Feed Industry Association, and is the author of seven books, including five on sales, marketing analytics and corporate governance. He has published working papers on predictive analytics in sales forecasting and AI in sales strategy through SSRN.