I build support agents for e-commerce, and separating these two has done more for results than any model upgrade. Here is how we think about the split and how it shows up in the code.

Different goal, different cost of being wrong

A pre-sale question is a conversion event in disguise. "Does this fit a 12-month-old?", "Will it ship before Friday?", "Can I return it if the color is off?" The shopper is holding their card. A fast, correct, confident answer removes the last reason not to buy. A slow or hedged answer loses the sale, and you never even see it in a ticket count.

A post-sale question is a retention event. "Where is my order?", "I need to send this back." The money is already collected. Now the only variable is whether this person comes back or tells a few friends not to. The cost of a wrong answer is different on each side: pre-sale a bad answer costs one conversion, post-sale a bad answer costs a customer and their word of mouth.

Same widget, opposite failure modes. That alone justifies routing.

Routing on intent, not on page

The naive split is "widget on a product page means pre-sale, widget in the account area means post-sale". It breaks immediately, because people ask "where is my order" from a product page and "do you restock this" from their account.

So we route on intent, detected from the message, with the page as a weak prior. The first job of the agent is to classify the turn into a small, fixed set of intents, and pre-sale versus post-sale falls out of that classification. It is the same closed intent set I use for everything else: a known list, an explicit "unclear" branch, and no free-form guessing about what the customer "probably" meant.

What each branch is allowed to touch

Once the branch is known, it changes what the agent can do, not only what it says.

The post-sale branch gets tools that read order state: order lookup, tracking, return eligibility. Those tools touch personal data and the real order system, so they require an identified customer and they are scoped to that customer's own orders. The pre-sale branch usually needs none of that. It needs the catalog, stock, shipping and returns policy, and it has no business reaching into the order database at all.

Giving the pre-sale branch fewer tools is a feature. A shopper asking about sizing should not be able to trigger an order lookup, and an agent that does not have the tool will not do it by accident. The permission boundary follows the intent.

Tone and escalation thresholds differ too

Pre-sale, the agent should be willing to be helpful and a little forward within the truth: confirm the fact, then add the relevant detail the shopper did not ask for yet ("yes, it ships before Friday, and returns are free for 30 days"). The escalation threshold is high, because pulling a human into a sizing question is overkill.

Post-sale, the agent should be calmer and quicker to hand off. Someone whose parcel is late does not want a cheerful product pitch, they want a status and a next step. The escalation threshold is lower: a frustrated customer, or a request the tools cannot satisfy, goes to a human fast, with the transcript attached so the customer never has to repeat themselves.

Why this beats one clever prompt

You can try to encode all of this in a single system prompt and hope the model juggles goal, tone, tools and escalation on its own. It mostly works, until the day a pre-sale conversation quietly triggers an order tool, or a late-delivery complaint gets an upbeat upsell. Those are exactly the embarrassing failures.

Splitting the two intents makes them structurally hard to reach instead of prompt-dependent. The pre-sale branch cannot read orders because it does not hold the tool. The post-sale branch escalates early because its threshold is set that way. The behavior lives in the routing and the tool permissions, where you can test it, and not only in a paragraph of instructions you are trusting the model to honor.

For a shop, the payoff is simple: the same chat bubble stops treating a hesitating buyer and an anxious customer as the same person. It answers the first to win the sale and the second to keep it.

I'm Amine, founder of Bynevo Labs. We build sovereign AI support agents for French e-commerce, answering customer questions before the sale and after it, hosted in France on an open-source stack. Happy to talk architecture in the comments.

I run one dedicated instance per merchant, self-hosted in France, on an open-weight French model (Mistral). None of that is exotic anymore. What is less obvious is which engineering decisions get harder and which ones get easier once you commit to it.

The data map comes first, before any prompt

Before writing a single prompt I draw where each piece of data physically goes. For a support turn there are usually four hops: the customer message, the retrieval query against the shop's knowledge base, the model call, and any tool call that touches the order system. With a hosted US model, hops one, two and three leave the EU by default, and hop four often does too if the order data sits in a foreign helpdesk SaaS.

Keeping it in the EU means every hop has a named home. The model runs on a box in a French datacenter. The knowledge base and its embeddings live next to it. The order lookups go straight to the merchant's own store API (Shopify, WooCommerce) over a server-to-server call, not through a third party. The map is boring to draw and it is the single most useful artifact in the whole project, because it is what a merchant shows their DPO and what you check every new feature against.

You give up the frontier model, and it matters less than you think

The honest trade-off is model quality. An open-weight model you can host in France will not top the same leaderboards as the largest hosted models. For open-ended reasoning that gap is real.

Support is not open-ended reasoning. A support turn is a narrow task: understand one customer intent, pull the right fact from a known knowledge base, then answer or hand off. Once the task is scoped that tightly, the model spends its budget on wording and intent detection rather than on world knowledge. That is exactly where a mid-size open model is strong enough. The heavy lifting moves out of the model and into retrieval and tool design, which you control and can test.

Retrieval is where sovereignty is won or lost

If the model does not carry the shop's facts, retrieval has to. Hosting retrieval in the EU is easy. Making it good enough that a smaller model can lean on it is the actual work.

Two things earned their keep here. First, the knowledge base is curated per merchant, not scraped: return policy, shipping zones, sizing, restock rules, each as a short passage with a source. Second, retrieval returns the passage and its source id, and the agent is only allowed to state facts that came back with a source. A smaller model plus tight retrieval beats a bigger model plus loose retrieval for this job, and it keeps every claim traceable to a document the merchant actually wrote.

Logs are personal data, so treat them that way

The part teams forget: your logs are customer data too. A support transcript is full of names, addresses, order numbers. Ship those to a hosted observability tool outside the EU and you just undid the data map.

So logging stays in the EU with the rest, transcripts get a retention window instead of living forever, and anything used to improve the system gets stripped of direct identifiers first. Under the GDPR the transcript is processing like any other, and "we sent it to a US logging SaaS for debugging" is a transfer you now have to justify.

The EU AI Act made one thing non-negotiable

Article 50 of the EU AI Act requires that a person is told when they are interacting with an AI system, unless it is already obvious. For a support agent that is a one-line disclosure at the start of the conversation and a clean path to a human. It costs nothing to implement and it removes a whole category of argument later. We put the disclosure in the first message and make escalation to a human a first-class action the agent can take, not a fallback it stumbles into.

What the constraint actually buys

Working inside "stay in the EU" is more upfront design: the data map, curated retrieval, EU-hosted logging, one instance per merchant instead of one shared model behind an API. What it buys is a system a merchant can explain to their customers and their DPO without hand-waving, running on a model they are not renting by the token from a provider that can change terms next quarter. For an online shop answering real customers, before the sale and after it, that turns out to be worth the extra design.

I'm Amine, founder of Bynevo Labs. We build sovereign AI support agents for French e-commerce, answering customer questions before the sale and after it, hosted in France on an open-source stack. Happy to talk architecture in the comments.