Capacités

Au-delà des outils et des déclencheurs, une extension peut exposer des capacités — des interfaces d'exécution standardisées que la plateforme sait orchestrer. Les capacités de modèle se déclarent une FAMILLE à la fois dans provides.models, chacune construite avec defineModels() autour d'un runtime defineCapability*() ; webSearch, webhooks et discovery appartiennent en revanche à un toolkit.

Comment la plateforme résout une capacité

Lorsqu'un workflow demande « un LLM » ou « STT », la plateforme parcourt le registre d'intégrations dans un ordre fixe. C'est ce qui vous permet de substituer OpenAI par un vLLM auto-hébergé sans toucher aux définitions des workflows.

Aucun repli silencieux. Si rien ne correspond, l'appel retourne null et l'appelant remonte une erreur 412 typée — jamais une substitution discrète vers un fournisseur que l'organisation n'a jamais installé.

Les capacités

Comment les capacités apparaissent dans l'interface

La page d'administration Paramètres → Plateforme → Extensions est centrée sur les produits. Cliquer sur un fournisseur ouvre sa fiche ; l'onglet Inclus répond à « qu'est-ce que cette extension m'apporte » en deux sections, dans cet ordre :

1. Modèles — ce sur quoi tournent les appels IA, en premier, parce que c'est la première chose qu'apporte un fournisseur. Une ligne par famille de modèles déclarée par le fournisseur — LLM, Embeddings, Reconnaissance vocale, Synthèse vocale, Image Generation, Vidéo, OCR et Modération — portant le nom de la famille, son nombre de modèles (4 modèles), les noms des modèles en une phrase, et via Microsoft Excel lorsqu'un seul produit la fournit. Ouvrir une ligne affiche les fournisseurs derrière cette famille et son éditeur de liste d'autorisation. Le modèle par défaut de l'organisation ne se choisit pas ici : il vit dans l'onglet Modèles & valeurs par défaut de la page Extensions.
2. Outils d'agents — une ligne par produit apportant des outils, des déclencheurs ou une capacité hors modèle : ce que fait le produit en mots, puis ses décomptes (9 outils, 2 déclencheurs), puis l'interrupteur Activé · à l'échelle de l'organisation, qui indique Non activé lorsqu'il est éteint. Les déclencheurs ne forment pas une section à part — ils sont comptés dans la phrase de la ligne. L'en-tête de section porte les totaux (36 outils, 4 déclencheurs sur 8 produits), et un fournisseur long replie la fin en N produits de plus. La recherche web sélectionne un fournisseur et non un modèle : elle apparaît donc en pastille sur la ligne du produit qui la déclare, et non sous Modèles.

Un fournisseur sans modèles ni produits à outils affiche Rien à lister pour cette extension à la place des deux sections.

Politique de modèle (mode liste d'autorisation)

Pour les capacités d'intelligence, les administrateurs peuvent restreindre les modèles utilisables :

Stocké par fournisseur et par capacité via l'API de politique d'organisation. Périmètre organisation — différentes organisations peuvent choisir différents sous-ensembles du même fournisseur.

Scores de référence

Toutes les capacités d'intelligence supportent des benchmarks optionnels sur les définitions de modèles, affichés dans l'interface des intégrations pour aider les administrateurs à comparer.

interface BenchmarkScore {
  name: string;        // ex. "MTEB Average", "WER", "MOS"
  score: number;
  source?: string;     // ex. "Artificial Analysis"
  updatedAt?: string;  // date ISO
}

Combiner les capacités

Une extension peut fournir un toolkit et autant de familles de modèles que nécessaire. Chaque famille est un élément fourni à part entière, avec son propre identifiant : une organisation peut activer le LLM sans activer l'OCR.

export default defineExtension({
  id: "my-ai-service",
  // ...
  provides: {
    toolkits: [
      defineToolkit({
        id: "my-ai-service",
        name: "My AI Service",
        tools: [chatTool, imageTool],
        webhooks: webhookCapability,
        discovery: discoveryCapability,
        block: myBlock,
        triggers: [],
      }),
    ],
    models: [
      defineModels({ id: "my-ai-service-llm", name: "My AI Service", family: "llm", runtime: llmCapability, models: [/* … */], defaultModel: "…" }),
      defineModels({ id: "my-ai-service-stt", name: "My AI Service", family: "stt", runtime: sttCapability }),
      defineModels({ id: "my-ai-service-tts", name: "My AI Service", family: "tts", runtime: ttsCapability }),
      defineModels({ id: "my-ai-service-embedding", name: "My AI Service", family: "embedding", runtime: embeddingCapability }),
    ],
  },
});

Sessions temps réel

STT et TTS prennent en charge le streaming temps réel via WebSocket ou SSE. Les sessions s'exécutent dans le WorkerThreadBackend propre aux capacités, qui maintient la connexion persistante au fournisseur. Cette durée de vie est distincte de l'exécution des outils et ne prouve pas qu'un outil Agent non-Scrydon a utilisé la frontière microVM vendor_archive à usage unique.

interface RealtimeSession {
  sessionId: string;
  send(chunk: ArrayBuffer | string): void;
  onMessage(handler: (data: RealtimeMessage) => void): void;
  close(): Promise<void>;
}

interface RealtimeMessage {
  type: "interim" | "final" | "audio" | "error" | "metadata";
  data: unknown;
  timestamp: number;
}