Providers et workers

Elora peut utiliser plusieurs modèles et agents, mais aucun d'eux ne devient Elora. Le control plane choisit, borne, audite et conserve la continuité.

Ollama local

Runtime local pour chat, raisonnement secondaire et embeddings. Il permet une exécution local-first, inspectable et utilisable même sans API distante.

Providers distants

OpenAI ou d'autres APIs peuvent être ajoutés comme spécialistes, mais seulement via le registre provider, avec coûts, latence, confidentialité et readiness explicites.

Workers bornés

Codex, Hermes, local_code, CLI workers et domain agents exécutent des tâches. Ils produisent des artefacts, pas l'identité du système.

Pourquoi Ollama compte

Ollama donne à Elora un socle local de génération et d'embeddings. Concrètement, Elora peut pointer un provider OpenAI-compatible local vers l'instance Ollama, choisir un modèle principal, un modèle de raisonnement ou un modèle de code, puis vérifier l'état par des commandes locales.

Ce n'est pas une obligation idéologique: c'est une condition pratique d'indépendance. Si un provider cloud disparaît, change ses prix, limite une API ou devient inadapté, Elora doit continuer à répondre, classer, router, récupérer du contexte et exécuter des workflows locaux.

Sélection d'un moteur

Elora classe la demande par type de tâche.
Elle applique confidentialité, coût, latence, profondeur attendue et readiness.
Elle privilégie le local quand c'est suffisant ou requis.
Elle escalade vers un spécialiste connecté seulement si la route l'autorise.
Elle journalise le choix réel: provider déclaré, candidat sélectionné, fallback éventuel et résultat.

Types de workers

Déterministes

Scripts, CLIs et workers locaux comme `local_code` ou les capacités directes web/fetch/browser/vision/audio. Ils sont préférés quand le résultat doit être reproductible.

Model-only

Un modèle peut produire un texte, un plan, une proposition ou une analyse. Il ne doit pas prétendre avoir écrit un fichier ou lancé un test sans preuve outil.

Overlay Hermes

Hermes accélère certaines délégations et profils domaines, mais reste optionnel. Il consomme les contrats Elora; il ne remplace ni mémoire, ni policy, ni routing.

Codex specialist

Codex reste le worker privilégié pour la chirurgie repo complexe, les refactors et les corrections avec tests, mais il n'est pas l'identité d'Elora.

Règle opérationnelle: un provider profile ne suffit pas à créer un agent effectif. Un agent utilisable doit avoir route, task class, worker ou provider prêt, inputs, outputs, policy boundaries, competence contract et quality gate.