Use case

Decide where a message goes, fast enough to do it on every turn.

The first step of an assistant or an agent: work out what the person wants and send the request to the right tool, flow or model. It runs before everything else, so its latency is added to every reply.

The task.

A message has to be mapped to one of a known set of intents, or to none of them, so that the right tool, workflow or model handles it. Today a large model does this as the first call of every turn, before the real work starts.

Why it is a candidate for a smaller model.

  • It sits in front of every request, so its delay is the floor for every response time.
  • The intents are a closed list that you define, with logged examples of which path each message took.
  • A router that is right can send easy requests to cheaper paths and keep the large model for the hard ones, which is where the saving in the rest of the system comes from.

What would be measured.

These are the acceptance criteria this task usually needs. You would set the figures; the model you run today would be scored against them first, on held-out examples, and the fine-tuned candidate would have to meet them on the same examples.

  • Accuracy for each intent, on held-out messages.
  • Out-of-scope behaviour: how often a message that fits no intent is correctly sent to the fallback instead of being forced into the nearest one.
  • Latency, measured as the user would feel it, since this step is paid on every turn.
  • The estimated cost of a message, against the model you run today.

What you would bring.

Logged messages with the intent that turned out to be right: the path that completed the request, or a person's correction. Include messages that belonged nowhere, labelled as such; a router trained only on in-scope examples has never seen what it should refuse.

Examples will be checked for quality, duplicates and sensitive data and split into training, validation and held-out sets before anything is trained. The first step explains why.

When a fine-tune is the wrong tool for it.

  • New intents are added all the time. A prompt that lists them, or a classifier over embeddings, is easier to keep current.
  • Routing depends on the state of the conversation or the account more than on the message. That logic belongs in code.
  • Volume is low. If the router runs a few hundred times a day, the model behind it is not what you should be optimising.

The decision guide goes through the alternatives. Daidon is being built to point to them when your examples do.

Where this stands.

Daidon is in development. There is nothing to install or run yet. Join the waiting list and we will email you once, when early access opens.

Read next

In development

Join the waiting list.

Daidon is in development. There is nothing to install or run yet. Join the waiting list and we will email you once, when early access opens.

Tell us the task you run today and we will know which early-access teams to start with.