What language models do well in sales and configuration, and where they fall short
Language models are good at understanding what people mean. A customer can write "we need a conveyor for 40 cartons a minute in a cold store, and it has to fit under an existing mezzanine", and a language model will pick out the throughput, the environment and the space limit. It can ask follow-up questions, compare two options in plain words and explain why one costs more than the other. That's the work a skilled sales engineer does today, and it's also the work that's hardest to scale.
The weakness is that a language model produces the most likely answer, and the most likely answer hasn't been checked against anything. The model has no built-in sense of which motor fits which frame, which options exclude each other or which variant was phased out last quarter. It will suggest a combination that sounds right with the same confidence as one that is right.
In a chat about holiday plans, that's a small problem. In a quote for a product with thousands of valid variants and millions of invalid ones, I think it's a serious one. Better prompts and more training data reduce the error rate, but they don't bring it to zero, and it only takes one wrong quote for a customer to start doubting the next one.
Guided selling and the part of selling that’s hard to put into rules
A great sales rep does something that's very hard to describe in a rule-based model. In a few minutes of conversation, they put themselves in the customer's shoes, work out what she actually needs and translate that into a solution, often before she has said it in technical terms. That competence is a people skill, built on experience, curiosity and empathy.
In an earlier post on successful product configuration, I described a visit to a car dealer. A good salesperson greets you, asks a few questions about you and your needs, and tailors each following question to the answer you just gave. In the end, he presents a car that fulfills all your wishes, including the budget, and that the dealer can actually deliver when you need it. That last part is easy to miss, but it's the reason you can trust the recommendation.
Configurators have tried to capture this for a long time, mostly through guided selling, where the customer answers questions about her needs and the configurator suggests a product. When I evaluated six online car configurators, none of them used guided selling. All of them asked the customer to pick a base model first and then presented the choices as technical options. A question tree written in advance struggles to do what the salesperson does, because it has to predict every type of customer and every way of describing a need.
I think this is where a language model fits best. It can follow the conversation where the customer takes it, ask the question that makes sense for this particular customer and translate her words into product terms. It won't replace the judgment of an experienced sales rep, but it can bring some of that way of working to every sales channel, including the ones with no person in them. What it can't do on its own is the last part of the car salesperson's job, which is knowing which solutions can actually be built and delivered.
A rule-based product model as the layer of truth
The approach I believe in is to give the language model something to check against: a deterministic product model that describes what the company actually offers. In that product model, the modules, interfaces and variants are defined, and constraint-based rules state which combinations are allowed. Given the same input, it always returns the same answer, and every answer can be traced back to a rule that someone decided on.
This is old technology in a good sense. Rule-based configurators, often as part of a CPQ system, have been used in manufacturing for decades, and the hard part has rarely been the rule engine. The hard part is the product model itself: agreeing on how the product is structured, which variants the market actually needs and who owns the rules when something changes. Companies that have done that work have something a language model can't create by itself, which is a single source of truth about what can be sold and built.
So the language model handles intent and conversation, and the product model handles validity. Each is weak at the other's job.
Agentic configuration in practice
When the two are combined, the AI becomes an agent that works through a configuration step by step instead of a chat window that guesses. An AI product configurator built this way reads the customer's need translates it into choices in the product model and asks the product model whether the result is valid. If a rule blocks the combination, the agent gets the reason back, for example that the cold-store option requires a stainless steel frame, and either adjusts the configuration or asks the customer a better question. Only a configuration that the product model has accepted reaches the quote.
Agentic configuration · the language model proposes, the product model checks
For the sales engineer, this changes the daily work in a practical way. The agent can make the first draft of a configuration in minutes, explain the trade-offs to the customer in plain language and combine several products into one working system, while the rules make sure that nothing is promised that can't be delivered. The person still owns the customer relationship and the final decision, but spends less time in compatibility tables and more time with the customer.
There's a technical side to this too. For an agent to query the product model safely, the product model needs an interface built for AI, such as an API or an MCP server (Model Context Protocol, an open standard for connecting AI agents to tools and data). Access has to be controlled the same way as for any other user, so the agent sees what it's allowed to see and nothing more.
How PALMA supports an AI product configurator
At Modular Management, this is the thinking behind how we build AI support into PALMA, our software for modular product architecture and configuration. PALMA holds the market architecture, the modules, the interfaces and the constraint-based rules, and we give AI agents secure access to it through an API and an MCP server, so that agents, our own or the customer's, can work on top of it. The way we put it internally is that the AI understands what people mean, and PALMA makes sure every answer is a valid product.
My own view is that the companies that get the most out of AI in configuration will be the ones whose product is well structured and well described, more than the ones with the most advanced language model. That's what makes an AI suggestion something you can promise to a customer. If you're exploring AI in sales and configuration and want to compare notes on where a layer of truth is needed, I'd be happy to talk.
Frequently asked questions (FAQ)
What is agentic configuration?
Agentic configuration is when an AI agent works through a product configuration step by step for a sales rep or a customer. The agent turns the customer's need into choices, checks each choice against a rule-based product model and adjusts until the configuration is valid. Only a valid configuration reaches the quote.
Can a language model replace a rule-based configurator?
I don't think so. A language model is good at understanding needs and explaining options, but it gives the most likely answer, and that answer hasn't been checked. A rule-based configurator gives the same answer every time and can show which rule decided it. In industrial sales, you need both.
What's the difference between guided selling and an AI sales assistant?
Traditional guided selling uses a question tree written in advance, so every customer gets the same questions in the same order. An AI sales assistant can adjust the next question to the last answer, like a good salesperson does. It still needs a product model to know which solutions can be built and delivered.
What is an MCP server?
MCP, the Model Context Protocol, is an open standard for connecting AI agents to tools and data. An MCP server on top of a product model lets an agent ask which configurations are valid. Since the product model may hold sensitive data such as costs, margins and variants that aren't released yet, a secure access model is essential. The agent should only see what the user it works for is allowed to see, and every request should be logged.

.gif?width=852&height=574&name=Configurator%20agent%20chat%20(web).gif)
