How We Built an AI Sales Agent for a Saudi Manufacturing Company

Everyone who watches the demo remembers the chat window. The typing indicator, the answer in seconds, the quotation attached before the customer has put the phone down. What nobody sees is that the chat window is the thinnest part of the build. Underneath it sit four distinct layers, each with one job and each capable of failing on its own. This is the stack we assembled for a steel and rebar manufacturer outside Dammam — the architecture that turned a shared inbox and a nine-person sales desk into a system that answers a real enquiry in 23 seconds.

Four Layers, One Enquiry

Strip the demo away and the agent is a pipeline. An enquiry enters through an intake surface, gets resolved against a structured memory, is turned into language by a drafting loop, and passes a guardrail before anything reaches a customer. Each layer has a single responsibility, and the boundaries are deliberate: language work stays in layer three, while truth about price, stock, and delivery stays in layer two. That separation is what makes the system debuggable. When an answer is wrong, the failure sits in exactly one place.

Layer One: The Intake Surface

A buyer does not choose a channel to suit the vendor, so the intake layer had to accept three: WhatsApp, the website form, and the sales inbox. Each integration normalises into one envelope — sender identity, channel, timestamp, raw text, attachments — and resolves to a single customer record before a model sees a word. A contractor who writes at 10 PM and follows up by email at 7 AM is one thread with one history, not two strangers asking the same question.

Layer Two: The Memory That Is a Database, Not a Prompt

The tempting shortcut is to paste the product catalogue into the system prompt and let the model recall it. We refused. Product names, grades, stock counts, and prices are read from the same Odoo tables the sales desk already uses, through a small set of parameterised queries. The model can describe a 12mm epoxy-coated bar beautifully; it cannot be trusted to remember that 200 meters are on the rack in Dammam. Retrieval owns the numbers and generation owns the sentence, and that division removes the single most common failure in sales automation — a confident, fluent, wrong price.

Layer Three: The Drafting Loop

An enquiry rarely contains everything needed to quote. The loop makes the agent ask itself what is missing — item, grade, quantity, delivery city — then call tools to fill the gaps before composing a reply. It is capped at a small number of tool calls, because an agent that keeps searching for a better answer is an agent that never answers. When the loop ends, the output is structured: a proposed reply plus a draft quotation object, not a paragraph of prose that a downstream system has to re-parse.

Layer Four: The Guardrail at the End of Every Run

Every run ends in code, not in prose. Before a message leaves, deterministic checks read the drafted output: is a price below the floor, is the quote above the figure that requires sign-off, does the reply promise a lead time nobody confirmed, is the Arabic register right for a purchasing manager. Failures route to a human queue with the reasoning attached. Guardrails written as prompt instructions are suggestions; guardrails written as functions are rules, and only the second kind survives a busy Tuesday.

One Enquiry, Traced Through All Four Layers

Here is the path a real message took, in the order it took it.

1. Intake. A contractor sends a voice note on WhatsApp at 10:47 PM asking for 200 meters of 12mm epoxy-coated rebar, needed on site in two weeks.
2. Memory. The transcript is parsed into an item, a quantity, and a delivery window; two queries confirm the grade exists in the catalogue and that 340 meters sit in stock.
3. Drafting. The loop pulls the current rate, applies the delivery date, and produces a reply plus a quotation object in the dialect the message arrived in.
4. Guardrail. The quote sits under the approval threshold, no unconfirmed lead time appears, and the message goes out. Elapsed time: 23 seconds.

What We Left Out of the Stack

Architecture is mostly subtraction. Four things we chose not to build in version one.

• Fine-tuning. The catalogue changed weekly, so a model trained on last quarter would have been wrong by the second month. Structured retrieval plus a firm prompt beat a custom model on accuracy and on maintenance.
• Vector search over prices. Embeddings are excellent at similar meaning and useless at exactly 4,120 SAR per ton. Numbers belong in SQL.
• Autonomous sending. The agent drafts and a human signs above a threshold. A quotation is a commercial commitment, and a commitment needs a name attached to it.
• A customer portal. Buyers already live inside WhatsApp. A login screen would have added friction to the one step that had none.

What the Stack Costs to Run

Running cost is dominated by two things: model tokens per enquiry, which scale with reply length and the number of drafting steps, and the handful of database queries behind each answer. Both are small next to what each layer costs to integrate. The real expense was mapping the catalogue, agreeing approval thresholds with the sales lead, and building an evaluation set of real enquiries to test against. Inference is the cheap part. Agreement about what a correct answer looks like is the expensive part.

Where This Architecture Stops Working

The stack is honest about its edges. Bespoke fabrication requests that are not in the catalogue still route straight to an estimator, because layer two has nothing to retrieve. Credit terms, multi-currency pricing, and staged delivery schedules sit outside version one and stay with people. If the source catalogue is inconsistent — three spellings for the same bar, stock counts updated weekly by hand — layer two collapses first, and no amount of prompt engineering rescues it. Clean master data is the real prerequisite for an agent of this kind.