Algorithms that learn.

Textbook algorithms assume nothing about your data, so they pay full price every time. Real data has shape: lists arrive mostly sorted, a few keys stay hot, mazes have corridors. We add heuristics that notice that shape so the algorithm can adapt, and we check every change against the plain version.

Good news, everyone: sometimes the fix is a better rule, not a bigger model.

Fig. 1 Dijkstra, A* and a model-guided search on the same maze. The model gets by with about half as many node expansions, but it spends roughly 100 times longer thinking than A* spends on the whole search, so a plain rule wins this one. Details →
Node expansions vs A*
−52%
Path length vs optimal
+13.8%
Model time vs A* search
15.5 / 0.16 ms
01Spot the structure.

Measure what your data actually does: how sorted it is, how skewed, how repetitive.

02Let the algorithm adapt.

Feed that back in as a heuristic. Use a small model only where a rule can't capture it.

Experiments

Each one raced against a simple rule.

These are screen recordings from our test bench, scoreboard included. We kept the ones the rule won. Click a video to watch it full screen, or see them all on the lab page.

The model in these clips is Laya, an open decision model that runs on the device (about 4 ms a call on the Apple Neural Engine). The benchmarks are small and built by hand, so read them as examples rather than general accuracy numbers.

Protocol

How it goes.

  1. Measure

    Find where your data has structure and where your code makes choices: which branch, which key, which queue.

  2. Baseline

    Write the best simple rule we can and measure it first. That's the boss fight.

  3. Adapt

    Add heuristics that use that structure, within your latency budget.

  4. Decide

    Keep whichever does better on traffic it hasn't seen. Often that's the rule, and that's fine.

Request a pilot

Tell us where your code makes choices.

Tick whatever's relevant and we'll reply within two business days.

Your algorithm
Search, solvers and schedulers. We look for the decisions worth handing to a model.
Your state machine
Routers, workflows and agent loops, with the states kept explicit.
Your invariants
The things that must never happen stay in code, where the model can't overrule them.
Your baseline
We build the best simple rule first and compare everything to it.
Your latency budget
Usually a few milliseconds on the device. Sometimes the answer is no model at all.
Your boundary
It runs in your VPC, on your servers or on the device, so your data stays home.

Want to work on this? Careers →