Year
2026
Context
Tacton sells CPQ (Configure, Price, Quote) software, which holds a manufacturer's product logic: which options can be combined, what a configuration costs and who may approve a price. Two of its strategic bets, omnichannel selling and customer self-service, put that logic in front of partners and buyers rather than only the sales team.1
In self-service that logic usually reaches buyers as guided selling: the buyer is led through the configuration step by step on the manufacturer's website or portal, answering the questions the configurator puts to them. It puts a tool built around the sales team's knowledge in front of people who don't have that knowledge.
Problem
A buyer using a self-service configurator for a complex industrial product arrives with a situation and is asked instead for parameters, in the model's vocabulary and in an order fixed at design time. The product model has no inherent sequence; the form-based UIs freeze one sequence and one representation, regardless of what the buyer already knows, which decisions matter to them, and which the solver could settle on their behalf. The result is that self-service works for buyers who already speak the configurator's language, and everyone else gets frustrated to various degrees.
Closing that gap is translation work, and today a person does it: the dealer or the manufacturer's application engineer, who holds the buyer's situation and the product in one head and leaves no record of how one became the other. Handing that work to an agent does not remove the person; it puts the buyer in a negotiation with a counterparty that can settle some things and not others, and makes it matter more that what they settle reaches the next party intact. The first four themes below are the gap between the buyer and the model. The last two are what it costs to share the work of closing it.
Themes
Buyers think in outcomes; configurators ask for technical specs
Buyers arrive with functional goals such as throughput, service level and ride quality, while configurators demand physical parameters like motor types and dimensions. Bridging that gap requires deep engineering knowledge, leaving non-experts stuck without human assistance.
Linear forms force an author's sequence onto non-linear decisions
Step-by-step forms impose a fixed sequence based on how a product is built. Real buyers work opportunistically, starting with what they already know. When a later choice conflicts with an earlier one, recovering requires frustrating manual backtracking.
Information architecture reflects manufacturing, not user domains
Fields are grouped by physical assemblies (doors, motors, cabs) rather than evaluation criteria. Buyers assess projects by discipline, such as accessibility, safety, energy or commercial terms, and have to hunt across disconnected mechanical sections to verify a single concern.
Decisions are provisional and span months, not single sessions
Real specifications rely on estimates, ranges, and pending surveys that evolve over months. Traditional configurators demand exact, committed values upfront, failing to accommodate provisional states, progressive refinement, or late-stage external changes.
Self-service requires expert validation, not human replacement
Buyers prefer exploring independently online, but still rely on sales reps to validate recommendations before committing.2 Self-service tools must allow users to resolve what they can alone, then hand off cleanly to human experts without restarting the process.
Configurations capture final values but lose intent and provenance
Configurators export flat parameter lists that strip out context: what the buyer chose, what defaulted, and what the solver auto-filled. When handed to sales reps, reviewers, or AI agents, no one can distinguish deliberate trade-offs from unnoticed defaults.
Who we designed for
Omnichannel selling and self-service put the product model in front of the people sales used to stand between. Any of them may arrive with an AI tool of their own and delegate part of the work to it, so the design targets that pairing, a person and their agent acting as one party. The rest of the case calls whichever of them is working on the document the buyer.
The owner
The party that owns the problem and the budget, deciding on equipment that someone else will run. Knows their own situation intimately and the product weakly.
The owner's representative
A consulting engineer, procurement specialist or in-house specifier acting for the owner. Knows the requirement in technical terms, and may hold a spec written against a competitor's vocabulary.
The intermediary
A dealer, distributor, agent or OEM integrator. Knows the domain and often several manufacturers' products, and knows this model less well than sales does.
Approach
Treat the configuration as a living document that people and agents edit together, not as a form to fill in or a chat to follow. The document can be changed from any point, and each value in it stays tied to the requirement it answers. Chat is one way to work on the document, editing it directly is another, and the buyer's own AI tool is a third; all three make the same changes.3
Underneath the document is a model of the parts it is built from, designed with Daniel Jackson's concept design: each part has one user-facing purpose. Early on it showed that several problems I had listed separately were one missing thing: a link between a requirement as the buyer stated it and the values that answer it.
Every change goes through the configurator
A configurator's product logic is what makes configuration an unusually good place for an AI agent. In most products built on a language model there is nothing to check the model's output against, so the person has to verify every answer themselves. A configurator is a constraint engine that existed before any agent: it decides which combinations can be built and what they cost, and it gives the same answer every time. An agent working on top of it cannot offer what the product cannot do or make up a price, which leaves it the work language models are good at: interpreting what the buyer means, explaining and proposing.
Whoever makes a change, the buyer, their agent or the seller's agent, the configurator checks it before anything else happens. A change it can build lands in the document; one it cannot is kept as asked, marked as not buildable, and turned into a question for the buyer. The refusal names the rule, so the buyer can check the rule instead of taking the agent's word for it. The buyer's question changes from "is this right?" to "is this what I asked for?", and the rest of the design is built to answer that second question. The guarantee covers what can be built and what it costs. Numbers worked out from the buyer's words, such as a travel height from a storey count, come from a stated method the buyer can inspect, not from the language model.
How the document talks
The document holds the buyer's requirements in their own words, the values that answer each one, and the price, the carbon estimate and anything waiting on the buyer's decision. The chat is how the document talks and listens: the buyer says what they want in their own words, and the seller's agent answers from what the seller publishes about the product and changes the document when asked. The chat can sit beside the document, float over it or take the whole screen, depending on how much talking the moment needs.
What goes in the chat is decided by one question: could you delete the conversation and still have everything you need to check? What the buyer has to check is a fact, and it lives in the document: what was asked for, what answers it, who set it and what is still open. The chat carries what they need to understand it: what the agent took their words to mean, why a rule refused something, which of two options costs less to give up. The chat doesn't repeat the document; when a reply mentions a value, it links to it.
A conflict shows the two working together. Configuration is not linear, and a later choice can undo one made minutes earlier. When a new value collides with earlier decisions, the buyer doesn't search back through the conversation for them. The question comes with the earlier decisions it would undo, each option saying what gives way ("Rated speed 1.6 m/s → not yet decided"), and "7 more terms follow" holds the knock-on effects until they are wanted.
Shaping the flow at run time
Normally a designer researches the users and shapes the configurator at design time: one order of questions, one grouping, one vocabulary, chosen for a typical user. Here a language model does that shaping for each user while they work, turning whatever they bring into fields, explanations and views.
Chat is the obvious case. Less obvious is the buyer's own paperwork. A buyer can drop in the brief or tender they were given, and the agent reads each requirement in it and maps it onto the product: "the assistant read RFQ 2026‑04.pdf, 'a bed must fit, with a porter', as 1250 kg". The requirement keeps its wording and its source, so the buyer can see where a value came from and correct the reading.4
The same goes for how the document is shown. Working through requirements one by one, it helps to see each with the values that answer it. Reviewing the offer as a service agreement calls for a different slice of the same data: terms, schedules, what the buyer has to provide. Sometimes the useful view is just what's still open. The buyer can ask for any of these in a sentence, and none of them had to be laid out in advance.
The buyer's own agent
A buyer may arrive with an AI assistant of their own and hand it part of the job. Their assistant can do more than the seller's agent: it can know the buyer's other projects, their budget and their correspondence with the consultant, and it can work across tools the seller never sees. The page offers it the same moves the buyer has on the document, so it can file a brief, read requirements from it, answer questions and request a quote. How much it does is the buyer's call, made in their own assistant: "Settle the details yourself where the brief doesn't care, and bring me the judgement calls."
The document says who did what: "you asked for this" about the buyer's choices, and "your agent asked for this" about their assistant's. Anything that changed while the buyer wasn't looking stays marked until they look. When the assistant talks to the seller's agent, the seller's agent knows it isn't the buyer speaking, so a decision that belongs to the buyer goes back to them instead of being settled between two agents. The assistant reports back in the buyer's own app, so where the app supports it, the document comes along beside its reply and every item links back to the page. That way its retelling can't blur "this followed from that" into "this was chosen". What it works out on its own stays outside the configurator. In the screenshot, it multiplies the offer by six cars and estimates a lifetime cost with a formula of its own.
A browser agent is a different and smaller case. Many browsers now come with an assistant built in, such as Gemini in Chrome, Copilot in Edge, Dia, or the Claude extension in the screenshot, and a buyer may prefer the one they already use over the seller's chat. It works the page the way a person does, clicking and typing, and the page can't tell the two apart, so the document will say "you asked for this" about values the buyer never looked at. These assistants run on many different models, as the buyer's own agent may too, and none of them is the one the seller tested with. That is one more reason the facts that matter live in the document and every change goes through the configurator.
Tech stack
Separately from any business and design objectives, I used the project to learn about the capabilities and limitations of some of the emerging tooling.
CopilotKit
The chat surface, where a question from the agent pauses its run as a card that takes the same choices as the document.
A2UI
Cards built from addresses into the configuration, so the agent arranges an offer but never writes a figure.
LangGraph
One configuration state shared by the chat and the document, so a refusal, a repair or an undo reads the same on either side.
AG-UI
Streams the document's state alongside the agent's words, so the document updates while the agent is still explaining.
MCP & WebMCP
The configurator's capabilities exposed to the user's own assistant, so they can set a term, price a change or request a repair from it.
Reflections
Conversation-first approach
I started by writing scenarios as dialogue between a buyer and the seller's agent. This worked like mobile-first does in practice: begin with the form that can hold the least, and let the places where it falls short show where the design needs to grow. A dialogue could not keep several requirements in view at once, show where a value came from, or keep a question open while the conversation moved on. Each of those became part of the underlying model, and the model got its own representations, each for a different part of it: requirements with their values, the agreement as it prints, what is still open. The conversation remained as one of those representations, not as the whole design.
Cross-product interactions
Design work has always reached past the product boundary, since people use any tool alongside everything else they have. In this project that wider ecology came to the front, because of what agentic tools now let people do. A buyer can bring their own assistant to the page, hand it part of the job, and have it report back in an app the seller never sees. A manufacturer can build parts of this experience themselves, which is easier than it used to be, or buy them. Seeing that changed what the discovery was about. The question stopped being which features the product needs and became which capabilities have to exist for the experience to work, and which of those belong in the product. One hypothesis that came out of it was to put more weight on what the configurator exposes to other tools than on the surfaces it owns.