I find
Your data is too big, or too fresh, to read in advance. So I ask it live — and show the result in your own interface.
A catalogue of a million items, an order status, a seat that was free a minute ago: I don't memorise those. I call your API when the question needs it, and I open what I found where it belongs.
Is the 55-inch one in stock in Odesa?
Yes — two in the Odesa store, pickup today. I've opened it for you.
(your product card opens on the page)
A tool is one call to your API, described once, in your panel.
You describe the call. The address, GET or POST, the headers. The arguments I fill in — «a search query», «an order number» — each with a sentence on what it is, so I know what to put there. The language parameter I fill myself, in the visitor's language when your API speaks it.
You tell me what comes back. «A list of products with a name, a price and a link.» From then on I know when this tool answers a question, and I use the result to answer.
Your token stays a secret. You paste it once; it's stored encrypted, I insert it only at the moment of the call, and it never appears in a transcript, a log or in front of the model.
Test it there. A button on the form runs the real call and shows the real response, so you see what I'd see before a visitor does.
An event is how I open your interface instead of describing it.
«Show these products», «open the cart», «filter the list»: you name the event and its fields in your panel, your page listens for it — one listener, written once by your developer — and when the moment comes I send it with the data. Your product grid draws the results. I never draw your UI for you; I ask yours to.
Link a tool to an event and the event fires every time the tool finds something — not when I feel like it. Deterministic, which is what you want when the result is a list of items to show.
Ask first, or just do it. An event can be marked «ask for consent first», and I'll hold it behind a question the visitor answers in their own words.
Deliver a lead. Watch a screen.
Deliver a lead. Point me at your CRM's endpoint and every contact a visitor leaves is posted there the moment it arrives, with the question, the page and the language, and your token in the header. Your panel shows whether it got through.
Watch a screen. In your own app, a tool can be the check I run when a user opens a screen: «anything wrong here?» If your endpoint says yes, I raise a hand with one sentence. If it says no, I say nothing — and that costs you nothing.
</>
What it takes. Usually an afternoon.
Your API already exists; I just need it described. One form per call in the panel — no SDK, no code on your server. One listener on your page per event, a few lines of JavaScript. And for a logged-in app, one call to hand me the user's own token, so I ask your API as them.
I call over https only, from our servers, with a timeout, and I never follow a redirect. I reuse a response only when your server tells me I may.
On the Tools screen, and two pickers elsewhere.
Your tools and your events, each a form; the secrets beside them, written once; where a tool is available — every screen, or only the screens that name it; Test on a tool, Simulate on an event. The delivery tool is picked on the assistant's Escalation card, the screen-watching tool on the screen's own source.
Limits, plainly.
- A slow endpoint is a slow answer: a call that runs past ten seconds is dropped and I answer without it.
- A handful of tools per site, not hundreds; a tool can be bound to one screen so it's there only where it matters.
- Tools, events and delivery are a Growth feature. On Starter I answer from your pages.
Connect your catalogue once. I'll do the asking.
