There is a widget in the corner of this site. It has four buttons and no text input. That was a decision rather than a budget constraint, and it is worth explaining, because the default choice right now is the opposite.
What an open assistant costs you
Put a language model on a twenty-page marketing site and you have created a component that can say anything about your business, to anyone, without review. It will be asked about pricing edge cases, contractual terms, delivery dates, and whether you can do a thing you have never done. It will answer all of them, confidently.
Some of those answers will be wrong in ways that matter: a quoted price that is not your price, a timeline you cannot hit, a capability you do not have, said in your voice, on your domain, to a buyer with no reason to doubt it.
The engineering cost is real too. Doing it properly means a backend, because an API key in the browser is a key you have given away. It means rate limiting, because otherwise you are paying for someone else to send traffic at you. It means logging, retention decisions, and a privacy notice that covers all of it.
What visitors are actually doing
On a site this size, nearly every visitor wants one of four things: to understand a service, to see whether the work is any good, to find out what it costs, or to start a conversation.
That is not a conversation. It is a routing problem, and a router with four buttons solves it in one click, with no latency, no cost per interaction, no privacy surface, and no possibility of saying something untrue.
It also works with JavaScript half-loaded, on a slow connection, and for someone using a screen reader. Those are three conditions where a streaming chat interface is at its worst.
Where a model would genuinely help
This is not an argument that language models have no place on a website. It is an argument about scale and consequence.
The moment there is more content than a person can hold in their head (a documentation set, a catalogue with thousands of entries, a knowledge base built over years), retrieval stops being a navigation problem and becomes a search problem. A model grounded in that corpus earns its cost immediately.
The distinguishing question is whether the assistant is retrieving from something real or generating from a prompt that describes your business. The first is useful. The second is a liability with a typing animation.
The handoff belongs early
Whatever sits in the corner, it should hand over to a person quickly and obviously. The most expensive pattern in support interfaces is the one that makes a frustrated visitor prove they have tried hard enough before it will give them a human.
So the router here has four destinations, and the fourth is the contact form. Not buried behind a fallback, not offered after three failed attempts: just there, as one of the four things anyone might want.
It can be connected to a model later, through a backend, if the site grows enough content to need one. That is a decision to make when the content justifies it, not on day one because everybody else has one.