How typing "research it" works

The capability menu — the + next to the message box — lets a visitor pick research this deeper, write me a document, talk to a person. Most people never open it. They type the request instead: "research it", "查查看", "もっと深く調べて". If typing the request does something different from picking it, the menu becomes decoration.

So the platform routes typed messages to the same capabilities. This page is about how, because the obvious two implementations both fail, and the failures are worth knowing before you build something similar.

Why a keyword list loses

A list of trigger phrases has to be right in every language you support, and it has to survive the way people actually type:

• reserach it please — misspelled, and a list matches nothing.
• 研究一下呗 — a phrasing nobody thought to add.
• go deeper on that one — no keyword from the list appears at all.

You can keep adding phrases. What you cannot do is finish. Each new language multiplies the list, and the misses are silent: the visitor typed a request, got an ordinary answer, and has no way to know a feature exists that would have handled it.

Why running a model on every message loses too

The other obvious approach — ask a small model "is this person triggering a capability?" on every message — is accurate enough, but it puts a model call in front of every single message, including the great majority that are plainly ordinary questions. That is latency the visitor feels and cost you pay on messages where the answer was never in doubt.

Two steps: a cheap gate, then a verdict

The router is an embedding gate followed by a model verdict.

Step one — embeddings. Each capability has a handful of anchor phrases; so does a shared set of counter-examples — ordinary replies that sit close to trigger phrases in meaning. The message is compared against both. Embeddings are multilingual, so one set of anchors covers every language: "深挖一下" and "research it" land in the same region of the space. If nothing is close, the router stops here and no model is called.

Step two — the model. If it looks like a button press, a small model picks one capability from the candidates, or says none.

The order matters, and it is the opposite of what we tried first. Embeddings are good at "is this message shaped like a request?" and bad at "is this person asking to use the feature, or asking about the feature?" — How does your deep research feature work? looks identical to a trigger. The model is good at exactly that distinction. So the cheap step gates, and the accurate step decides.

What the counter-examples are for

Anchors alone cannot separate tell me more from dig deeper — they are genuinely close in meaning. What separates them is having tell me more sitting in the counter-example set, so the nearest neighbour is a plain reply rather than a trigger. Two categories had to be added after they misfired in testing:

The third one is the instructive one. The anchors for write me a document have to be long sentences (short anchors score badly against long requests), and any long anchor inevitably carries the agent's subject matter with it. So a long question about the same subject climbs the similarity ladder: one measured at 0.711 — higher than sentences that were genuinely asking for a document.

The numbers

Measured on 110 independently written samples (60 that should trigger, 50 that should not), across seven languages, with phrasings deliberately different from the anchors:

The gate threshold was not chosen by taste. Every value was run against the same samples:

0.55 is the last row where no real request has been lost yet. Above it, every false trigger removed costs a real request — and the sample is not large enough for a one-or-two difference to mean anything, so we do not trade recall for noise.

The same sentence, two meanings

"Add a section about the Brazilian pathway."

With no document open, that is a request to write something. With a document open on the right-hand side, it is a request to change that document. Same words, different answer — and getting it wrong is expensive in a way that is easy to underestimate: a visitor working on a report asked for a section to be added, and a second, separate document was created instead.

The first fix was a rule — while a document is open, never route to write a document. It stopped the bug and broke something else: a visitor who genuinely wanted a second document could no longer ask for one. A second rule (a chart request must literally contain the word "chart") had the same shape, and the same cost: it could not recognise "show those numbers a different way".

Rules stacked on rules is a signal that the wrong component is deciding. The context now goes into the verdict step itself — the model is told a document is open and is given one more option, edit the open document, which routes to nothing at all, because the document-editing tools are already available on that turn and they are what should handle it. Both original bugs stay fixed, and both real requests work again.

One deliberate asymmetry: if the model is unreachable and the router has to fall back to the embedding guess, the bar is raised while a document is open. A misroute there hijacks the whole turn — the visitor discussing a 21-day review window gets "I can't draw a chart of a 21-day review window" — whereas the same mistake in ordinary chat produces, at worst, one unnecessary chart.

What this means for your agent

• Only capabilities on your agent's menu can be triggered by typing. If you have not enabled deep research, a visitor asking for it gets an ordinary answer, not a feature you did not buy.
• You do not write trigger phrases. There is no per-tenant keyword list to maintain, in any language.
• A request that needs a subject and does not carry one comes back as a prefilled box rather than a guess. Someone typing "research it" with no clear topic sees the topic filled into the message box, where they can correct it before sending — the cost of a wrong guess drops from a wasted minute to a two-word edit.