Skill Routing with Jev

When an agent has dozens of skills, rules, or tools, something has to decide which one applies. Today that decision usually falls to the main model, which burns context on every turn re-reading descriptions and picking.

Skill routing moves the shortlist decision to Jev: classify the task against skill names and descriptions, then add a small suggestion to the main model's prompt. The main model keeps its skill index and can reject the suggestion when it does not fit.

The Pattern

const { answers } = await client.systemOne({
  state: {
    user_request: request,
    available_skills: [
      { name: 'pdf-extract', description: 'Extract tables and text from PDF files' },
      { name: 'spreadsheet-chart', description: 'Build charts from tabular data' },
      { name: 'invoice-reconcile', description: 'Match invoices against purchase orders' },
      // ...
    ],
  },
  questions: {
    skill: choice('Which single skill best fits this request?', {
      'pdf-extract': 'The request needs data read out of a PDF document',
      'spreadsheet-chart': 'The request needs a chart built from tabular data',
      'invoice-reconcile': 'The request needs invoices matched to purchase orders',
      none: 'No available skill fits, or the request is ambiguous',
    }),
  },
})

if (answers.skill.choice !== 'none' && answers.skill.confidence >= 0.85) {
  prompt = `<skill_relevance>Relevant to this request: ${answers.skill.choice}. Ignore this if it does not fit.</skill_relevance>\n\n${request}`
}

A none option and a confidence floor are useful, but they are not sufficient safety mechanisms. A confident wrong suggestion can still steer an agent. For a large or overlapping roster, use a first pass to rank candidates and assess whether a skill is needed, then a second pass that rereads the leading candidates with fuller descriptions and can reject all of them.

Build It as a Hook, Not a Skill

A subtle but important architecture choice: skill routing should be a hook or extension, not itself a skill. If routing is wrapped as a skill, the main model has to decide to invoke it, which reintroduces the extra step you were trying to remove. A hook can add its suggestion before the model starts its turn.

Keep the stable skill index in the cacheable prefix and append only the changing suggestion afterward. Measure cache behavior in the host rather than assuming it.

Debugging a Router That Misroutes

When the router performs poorly, the cause is one of four things, and the way to find it is to freeze everything but one and iterate:

1. The user request is vague.
2. The skill descriptions overlap or under-specify.
3. The question itself is badly formed.
4. There are too many or too few questions.

Hold three constant, change one, and re-test until accuracy cracks it. This is the same margin-and-isolation discipline that threshold tuning needs, applied to routing quality.

The most common result: overlapping descriptions produce low-confidence false negatives. Two skills whose descriptions sound similar make the correct answer genuinely ambiguous to the model. Fix the descriptions, not the model.

The Clarify Loop

When routing is vague, you do not have to fall back to the main model. Ask a clarifying question in the terminal, send the user's answer back to Jev alone, and derive the skill without ever touching the main model. The routing decision stays cheap and the main model only runs once the task is unambiguous.

Route on Every Turn

Two questions come up whenever skill routing is proposed:

• "Doesn't paying Jev every turn get expensive?" At $0.042 per million input tokens with output free, a routing call over a short skill list can cost very little. Deterministic caches can remove repeats where the same request shape recurs.
• "If you only route on the first turn, doesn't the agent break when it needs a new skill later?" It can. Re-evaluate when the task changes, rather than assuming every turn needs the same skill.

When Not to Use It

• When an if or a regex already picks correctly. Do not add a model to a solved problem.
• When the skill set is tiny. With two or three unambiguous skills, the main model handles selection fine.
• When descriptions cannot be made distinct. If two skills genuinely overlap, routing will keep producing low confidence. Either merge them or make the boundary explicit in the criteria.

Related

• Confidence Gating — the bands behind the routing floor
• Model Routing — routing models instead of skills
• Agent Skills — the SKILL.md standard these routers select over