Skill Discovery, Selection and Routing¶

Miért kell skill discovery?¶

Egyetlen skillnél nincs routing probléma:

request → one known skill

De ahogy nő a rendszer:

Agent Runtime
├── PR Review Skill
├── Test Failure Analysis Skill
├── Documentation Skill
├── Incident Triage Skill
├── Deployment Health Skill
├── Support Ticket Skill
└── ...

felmerül a kérdés:

Honnan tudja a runtime, hogy egy adott kéréshez melyik capability releváns?

Ez a skill discovery és routing problémája.

A routing nem csak model probléma. Jó rendszerben több deterministic filter és policy dolgozik már azelőtt, hogy a modell skillt választana.

Skill registry / catalog¶

Hasznos mental model:

Skill Registry
├── name
├── version
├── description
├── input contract
├── output contract
├── capabilities / tags
├── risk level
├── required permissions
├── environment constraints
└── status: experimental | stable | deprecated

Például:

name: review_pull_request
version: 2.1
description: Review a pull request for correctness, architecture, regressions and missing tests.
tags: [github, code-review, read-only]
risk: low
requires:
  - repository.read

A registry lehet statikus config, code registry, database vagy runtime discovery service.

A lényeg, hogy a runtime ne csak skill neveket ismerjen, hanem választáshoz szükséges metadata-t.

A skill description valójában interface metadata¶

Ha egy LLM router skill descriptionből választ, a description minősége kritikus.

Gyenge:

Handles code stuff.

Jobb:

Reviews an existing pull request for correctness, architecture risks, regressions and missing tests. Read-only. Does not modify code.

Ez megmondja:

mire való,
mire nem,
milyen scope-ban,
milyen side effecttel.

A skill description így nem marketing szöveg, hanem routing contract része.

Routing pipeline: előbb filter, aztán semantic selection¶

Egy biztonságos flow:

All registered skills
        ↓
status filter
        ↓
environment filter
        ↓
permission filter
        ↓
risk / policy filter
        ↓
relevant candidate skills
        ↓
router
        ↓
selected skill / no skill / ambiguity

Ez nagyon fontos.

Nem jó pattern:

LLM sees every skill
 ↓
chooses dangerous production skill
 ↓
application later discovers user has no permission

Jobb:

user permissions
 ↓
capability filtering
 ↓
LLM never sees unauthorized skill

Ez a least privilege at discovery time.

Routing stratégiák¶

Nincs egyetlen mindig jó megoldás.

1. Deterministic/static routing¶

Példa:

HTTP endpoint /review-pr
       ↓
PR Review Skill

vagy:

request.type == INCIDENT
       ↓
Incident Triage Skill

Előnye:

gyors,
olcsó,
determinisztikus,
könnyű debugolni.

Ha a caller már tudja, melyik skill kell, nincs értelme LLM routert beiktatni.

2. Rule-based routing¶

Például:

source == github && object == pull_request → PR skills
source == pagerduty → incident skills

Ez jó pre-filter.

3. Semantic / embedding routing¶

Skill descriptionök embeddingje és user intent embeddingje alapján shortlist készíthető.

user request
 ↓
embedding similarity
 ↓
top 3 candidate skills

Ez nagy registry esetén olcsó előszűrés lehet.

Viszont similarity nem ugyanaz, mint jogosultság vagy task correctness.

4. Model-assisted routing¶

A modell kap egy shortlistet:

Available:
- review_pull_request
- analyze_test_failure
- update_documentation

és strukturáltan választ:

{
  "skill": "analyze_test_failure",
  "confidence": 0.86,
  "reason": "The request is about a failing integration test."
}

Ez rugalmas, de probabilistic.

5. Hybrid routing¶

Production rendszerben gyakran ez a legjobb:

Deterministic permission/environment filters
                ↓
Semantic shortlist
                ↓
LLM selection among 3-5 candidates
                ↓
validation

Így nem a modellre bízzuk az egész capability universe kezelését.

A router outputja ne csak „skill name” legyen¶

Hasznos structured result:

{
  "decision": "SELECT_SKILL",
  "skill": "review_pull_request",
  "confidence": 0.88,
  "missing_inputs": ["pull_request_number"]
}

Más outcome lehet:

{
  "decision": "NO_MATCH"
}

vagy:

{
  "decision": "AMBIGUOUS",
  "candidates": ["incident_triage", "deployment_health"]
}

Ez sokkal jobb, mint mindig valamit erőltetni.

„No skill” legitim döntés¶

Nagyon fontos:

A routernek tudnia kell azt mondani, hogy egyik skill sem megfelelő.

Ha csak ezt engedjük:

choose exactly one of A, B, C

akkor a modell forced selectiont végez.

Például user:

Írj egy rövid születésnapi verset.

Available skills:

PR Review
Incident Triage
Deployment Health

A helyes routing:

NO_MATCH

nem pedig Incident Triage csak azért, mert választania kell.

Ambiguity és clarification¶

User:

Nézd meg, mi a baj a payment-service-szel.

Ez lehet:

production incident diagnosis,
deployment health check,
code analysis,
test failure.

A router kérhet clarificationt:

{
  "decision": "NEEDS_CLARIFICATION",
  "question": "A futó production szolgáltatást, egy deploymentet vagy a source code-ot szeretnéd vizsgálni?"
}

Ez jobb, mint rossz capabilityt automatikusan elindítani.

Confidence nem policy önmagában¶

Ahogy az előző fejezetben:

confidence = 0.84

nem automatikusan kalibrált valószínűség.

Lehet routing signal, de thresholdot evaluationből érdemes kialakítani.

Például:

high-confidence routing → auto select
medium → ask clarification / second-stage router
low → no match

csak mért adatok alapján legyen konkrét határ.

Permission-aware discovery¶

Tegyük fel, hogy van:

read_deployment_health
restart_deployment

Egy read-only usernek a registry projection:

available skills:
- read_deployment_health

A restart skillt nem csak executionkor tiltjuk meg, hanem nem is tesszük választhatóvá.

Global registry
      ↓
user/environment policy
      ↓
Authorized skill view
      ↓
router

Ez csökkenti a hibás és malicious routing lehetőségét.

Environment-aware routing¶

Lehet olyan skill, ami:

environments: [dev, staging]

vagy:

production: approval-required

A runtime ennek megfelelően szűrhet.

Például local coding agentnél elérhető:

run_shell_in_sandbox

production support agentnél viszont nem.

Skill selection vs tool selection¶

Ezek külön szintek.

User request
 ↓
Skill routing
 ↓
Deployment Health Skill
 ↓
Tool selection inside skill
 ↓
query_metrics / get_deployment / read_events

A router task-level capabilityt választ.

A skill execution tool-level capabilityt választ.

Ha ezt összemossuk, óriási flat tool listát kaphat a modell.

Hierarchical capability discovery¶

Nagy rendszernél hasznos lehet:

Domain Router
├── Engineering
├── Support
└── Finance

Engineering Router
├── PR Review
├── Test Analysis
└── Deployment Health

Nem feltétlenül kell minden modellhívásnak 300 skill descriptiont látnia.

Ez hasonló namespace/modularization problémához.

Példa: support agent routing¶

Available skills:

invoice_lookup
refund_recommendation
account_access_diagnosis
subscription_change_explanation

User:

Kétszer vontátok le ugyanazt az összeget.

Flow:

1. permission filter
2. all support skills remain
3. semantic router → invoice/refund candidates
4. LLM router → invoice_lookup first
5. execute read-only lookup
6. based on result, workflow/agent may later invoke refund recommendation

Fontos: nem feltétlenül egyetlen routing döntés oldja meg a teljes problémát.

Routing és skill composition¶

A router ne próbálja előre az egész workflow-t kitalálni, ha csak a következő capabilityt kell kiválasztania.

Például:

request
 ↓
select invoice_lookup
 ↓
new evidence
 ↓
select refund_recommendation

Ez már közelít az agentic loophoz.

A skill routing és a multi-step planning külön fogalom.

Anti-pattern: minden skill mindig elérhető¶

300 skills
+ every tool
+ every permission
→ one prompt

Ez:

zajos,
drága,
nehezebb választást okoz,
security attack surface-t növel,
tool confusiont okozhat.

Jobb: candidate filtering + shortlist.

Anti-pattern: skill name alapján routing¶

skill_42
helper_x
smart_fix

A router nem kap stabil semantic contractot.

A név és description legyen explicit és diszkriminatív.

Anti-pattern: authorizationt a routerre bízni¶

Gyenge:

Prompt:
"Do not select admin skills for normal users."

Jobb:

application removes unauthorized skills
          ↓
router only sees permitted candidates

Anti-pattern: forced selection¶

Ha mindig pontosan egy skillt kell választani, a rendszer hamis kompetenciát gyárt.

Legyen:

NO_MATCH
AMBIGUOUS
NEEDS_CLARIFICATION

Takeaways¶

A skill registry nem csak lista: metadata, contract, risk és permission információ kellhet.
A skill description routing interface része, ezért legyen pontos és diszkriminatív.
Routing előtt determinisztikusan szűrjünk permission, environment, status és policy alapján.
Ha a caller már tudja a skillt, használjunk direkt routingot.
Nagyobb rendszerben jó pattern a hybrid routing: filter → shortlist → model-assisted selection.
A NO_MATCH és AMBIGUOUS legitim outcome.
Confidence thresholdot evaluation alapján használjunk, ne intuitívan.
Skill selection és tool selection külön absztrakciós szint.
Nagy registry esetén hierarchical routing csökkentheti a contextet és a confusiont.
A router soha ne legyen authorization authority.