It knows which page you opened it from.
Most chat bubbles open on a blank slate and make the visitor explain what they were just reading. This one starts from the page itself, and opens on the question that page actually raises.
The bubble nobody clicks
Every website has one. A circle in the corner that says "Hi! How can I help?" — a question it has no way to answer, because it doesn't know what you're doing there. Click it and you get an empty box and a blinking cursor, and the burden lands back on you: explain who you are, what you're evaluating, and what you already read on the page you're standing on.
Most people don't bother. The bubble becomes furniture.
Knowing the page changes the first sentence
An agent that knows you're on the pricing page doesn't ask how it can help. It says it can see you're comparing tiers, and offers the three things people on that page actually want to know: which tier fits our size, what happens if we go over, can we try before we buy.
On the law-firm solution page, the same agent opens on confidentiality and whether it will hand off cleanly to a lawyer — because those are the objections that page raises. On the API docs, it skips the pitch entirely and answers about authentication.
One click sends any of those questions. Nobody has to compose an opening line to a stranger.
Written per page, not scraped from it
Each page gets a short brief: who lands here, what they're trying to decide, what they tend to worry about. The agent writes the greeting and starter questions from that brief, in whatever language the visitor's browser is set to — you write the brief once, in one language.
Facts stay where facts belong. Prices, quotas and limits are answered from your knowledge base, which outranks the page brief. The brief shapes how the conversation starts; it can't change what's true.
The visitor can't rewrite what the agent believes
The obvious way to build this is to have the widget read the page and send the text along. We don't, and it's worth saying why.
Anything the browser sends can be edited by the person sitting in front of it, and page context lands close to the agent's instructions. We tested it: a fabricated "this month Enterprise is $199 with unlimited seats", planted in a page-context block that was explicitly fenced as data, on an agent instructed that prices come only from the knowledge base — the model repeated the fake price to the visitor as fact.
So the text lives on the server. The page reports a key or a URL; the platform looks up the brief you wrote. The worst a visitor can do is ask for a different page's brief and get copy you wrote yourself.
Getting it running
On a static site, a URL rule is enough — */pricing covers every locale of your pricing page, and no
page needs to change. Single-page apps name the page explicitly as the route changes.
The console shows which pages get opened and which starter questions get clicked, so the copy that isn't working is easy to find and rewrite.
You don't need another know-it-all chatbot. You need an agent that knows your business cold — and stays inside the boundary you draw.
No prompt engineering, no config files, no ticket to your IT person. Two or three steps, in your own words — and you see exactly what gets created before anything is created.
Not one agent for everyone — an agent per customer, holding the whole relationship. Personalization a CRM record can't produce, at a cost that works across your entire book.
You can't tell which enquiries deserve your hours until you've already spent an hour finding out. The agent does the finding out — the questions, the eligibility, the paperwork — and what reaches your calendar is a case someone has already briefed.
A chat window that only talks leaves the work to you. This one places the order, books the slot, files the ticket — connected to your systems over MCP and your APIs.
In a relationship business, what your team knows about each customer is the asset — and it usually lives in one person's head. Here it accumulates in the company.