TL;DR: I fine-tuned LiquidAI's LFM2.5 (230M and 350M) into a generic front-end agent that runs entirely in the browser - no server, no API key, no cloud costs.
It doesn't just chat; it calls real tools to browse a catalog, answers grounded questions, and manages a cart.
The trick: it's trained on interaction patterns, not domain facts, so the same weights drive a coffee store, an absurdist emporium, or a corner grocer - with zero retraining.
), and let it actually do things in the UI instead of just describing them.
The bet was that a small model can't hold a useful amount of world knowledge, but it can learn a compact set of behaviors well enough to be useful.
Patterns, not knowledge
The model does not know what a "BrewCraft Pico" is, or that it costs $699.
It knows how to:
- pick the right tool for an intent
- bind arguments and item ids correctly
- resolve references ("the second one", "a dozen of those")
- ground an answer in retrieved text, and refuse when the text doesn't contain the answer
- steer back politely when asked something off-topic
Everything domain-specific is injected at runtime.
Each turn, the host app hands the model a compact context: the items currently on screen (with ids and prices), the cart, and any retrieved knowledge.
The model grounds strictly in that. Swap the store, swap the injected context - the same weights work.
That's why the demo ships three storefronts on one model.
And critically, they were held out of training entirely.
If the model can run a store it never saw, the generalization works.
How it actually works
Three design choices carry most of the weight.
A frozen tool roster.
Early on I tried teaching the model to read arbitrary tool schemas - variable tool names and arguments per training example so it wouldn't memorize a fixed set.
For a 230M model, that was too much to ask; it garbled calls.
So the roster is now fixed: eight tools with stable names (list_items, get_item, search_knowledge, add_to_cart, remove_from_cart, clear_cart, checkout, navigate) that the model learns by name.
A small, memorizable action space.
The one place variety survives is the filter set on list_items, which the model reads from the injected schema.
RAG as a tool, not a pipeline.
Retrieval is just list_items (catalog) and search_knowledge (guides, policies).
The model decides when to call them and grounds its reply in the results.
The backend is swappable - BM25, vector, hybrid - because only the result shape is the contract.
The demo uses in-browser BM25; nothing leaves the machine.
Grammar-constrained decoding.
Tool calls are decoded against a GBNF grammar, so every call is syntactically valid and - the important part - every id the model emits is one that actually exists in the injected context.
It literally cannot hallucinate a product id.
That single constraint removes a whole class of failures that would otherwise sink a model this small.
Training it
The pipeline is synthetic-data distillation:
- Defined ~18 interaction recipes (add-to-cart, browse, compare, price lookup, knowledge Q&A, refusal, off-scope steering, small talk, ...).
Each recipe generates short, bounded exchanges with an example runtime context attached. - A teacher model writes the natural-language parts (the customer's phrasing, the grounded reply); the structure is deterministic and generated in code, so the tool calls and ids are always correct.
- Fine-tune the base model on ~30M tokens of this.
Full fine-tune, fits on a single 16GB GPU. - Evaluate on verticals the model never saw - plus a demo-faithful "does it survive the real UI" harness.
One deliberate choice worth flagging for anyone doing the same: train on the pattern, not a blocklist.
For "handle an off-topic request," it's tempting to enumerate a fixed list of off-topics.
Don't - the model just memorizes those strings.
Instead, generate a genuinely different off-topic examples every time (thousands of distinct ones) so it learns the behavior of steering, not fifteen banned phrases.
Some LLM providers might cache requests; this would duplicate training data, where we expect variety. To avoid this, seed each request appropriately.
The quality of the teaching model is of course extremely important; I limited to only Apache 2.0 licensed ones, and the best bang for buck I found at the time of writing was (three storefronts, one model, all in your tab)
Code: ·
Built on LiquidAI LFM2.5.
Model weights inherit the LFM Open License v1.0; code and this post are Apache-2.0 / CC-BY
SOCIAL SHARE CARD GENERATOR