Allie the Icon's "shopping cart" pattern for multi-intent queries

Allie the Icon posted a pattern for the case where one user query carries more than one intent. She calls it the shopping cart. Instead of asking the model to decompose the whole request in a single shot, you recursively pick the next thing until Jev says you are done, then stop.

Allie the Icon

@allietheicon

X

recursively pick the next thing until Jev says we're done

She says she has used it twice herself. One is a coffee ordering bot in her company Slack, built on DoorDash's CLI. The other is what she describes as a fast multi-intent handler for her smart home system. Both are her own builds, not a published eval, and she gives no accuracy figure for either.

What the post does not say

There are no latency numbers, no token counts and no cost per query in the post. That matters here more than usual, because the shape of the pattern is a loop. Every additional intent in a query is another round trip, so the cost of a two intent request is not the cost of a one intent request. Whether that is cheap enough depends on how many intents your traffic actually carries, which is a thing you can measure on your own logs before you write any of this.

The termination condition is also the model's call. The loop runs until Jev says there is nothing left to pick, which means a false stop drops an intent silently and a false continue adds a phantom one. Allie reports neither failure mode, so neither has been ruled out, and a smart home command and a coffee order are both forgiving domains compared with anything that writes to a ledger.

For people building on it, this is a prompt shape from someone who has shipped it twice, not a benchmark. It belongs in the same bucket as her earlier note on picking the right primitive for a search, which is to say it is a starting structure you still have to instrument. Log the number of loop iterations per query first. That number is the price of the pattern.