AI assistants for support and commerce

Retrieval, answer validation, model routing and tool authorization for assistants that talk to real customers, built to be operated rather than demonstrated.

Who this is for

Teams that run a support inbox or a store and want an assistant that answers from their own knowledge base, catalogue and policies. You may already have a chat widget or a pilot on one provider; what you need is for it to hold up with real customers.

This is the same work I do on Conviro, the support platform I designed, built and operate as its sole engineer: web chat, WhatsApp and Instagram in one inbox, with retrieval, answer validation and handoff to a person.

Typical situations

  • The pilot answers well in demos and wrongly about prices, stock or delivery with real customers.
  • One provider outage takes the whole assistant down, and nobody knows what it said in the meantime.
  • The assistant cannot tell a Dutch customer from a Turkish one, or a retail policy from a wholesale one.
  • Support agents do not trust the suggested answers, so they ignore them.
  • You want the model to act, such as look up an order or issue a return, and you do not want it to do that unchecked.
  • Nobody can say what a month of the assistant costs per tenant or per conversation.

What I deliver

  • Retrieval over your documents, catalogue and past conversations: hybrid search on PostgreSQL (full text plus vectors), with filters per tenant, language and market.
  • Answer validation before delivery: prices, links, product identifiers and policy claims are checked against the retrieved sources; unsupported claims are held back or handed to a person.
  • Model routing across providers behind one contract, with fallback, circuit breakers and budgets per tenant.
  • Tool use with server-side authorization: the model proposes, the application checks permissions, scope and arguments before anything runs, and every action leaves an audit trail.
  • Channel integration: web chat, WhatsApp, Instagram or email into one conversation model, with webhook receivers that tolerate duplicates and late events.
  • Evaluation cases and regression checks that run through the production path, so a change in prompt, model or sources is measured before it ships.

How it goes

Read the conversations. I start with real transcripts, the knowledge base and the catalogue, and write down which questions the assistant must answer, which it must refuse, and what evidence each one needs.

Build the path end to end. Retrieval, routing, validation and handoff, inside your stack or next to it, with evaluation cases from the first week and a staging tenant to test against.

Launch with a measurement. Before go-live we run held-out conversations and a small group of real users, fix what fails and agree on what gets monitored afterwards. On a retainer I keep operating it.

Questions

Which model or provider do you use?

Whichever fits your data region, budget and quality needs, behind an adapter contract so it can change later. I have built routing across several commercial providers and open-weight models. The routing policy and the validation around it matter more than the vendor.

Can it run inside our existing stack?

Usually yes. The retrieval layer is PostgreSQL with pgvector, the rest is ordinary services with HTTP and a queue. If you already have a chat widget or a helpdesk, I integrate with it rather than replace it, unless replacing it is the point of the project.

How do you keep the assistant from making things up?

By separating generation from evidence. Every concrete claim in an answer is checked against what was retrieved, and missing evidence is a defined path (ask, decline or hand over), not a gap the model fills. It is not perfect, so evaluation cases and source management stay part of the work.

What does an engagement look like?

Three forms: a fixed-scope audit of an existing assistant, with a written report on retrieval, validation, authorization and operating gaps; a build project with an agreed scope and acceptance cases; or an ongoing retainer for operating and improving it. Cost depends on the system, so I quote after the first conversation.

Which company do I contract with?

Services are provided by Wizutech OÜ, a company registered in Estonia, to clients in the European Union and other countries, and by Wizutech Teknoloji, a company registered in Türkiye, to clients in Türkiye. The contracting entity is determined by the client's location and the applicable regulations and is named in the proposal; contract, invoicing, VAT and governing law follow that entity. The work is carried out by Hasan Gültekin in both cases.

Related writing

This is the work behind Conviro, the support platform I build and operate as its sole engineer. Notes from it:

Working on something similar?

I take on a small number of platform, AI integration and performance projects. Tell me what you are running and where it hurts.

Request a service