Agent Runtime Gateway

Idée

Un runtime fermé peut être exposé comme un backend agentique standard sans réécrire ses capacités.

Problème

Certains environnements conversationnels offrent des capacités puissantes (sessions, outils, multimodalité) mais derrière des interfaces propriétaires qui verrouillent l'intégration.

Pourquoi une solution classique ne suffisait pas

Remplacer le runtime obligerait à reconstruire les capacités natives ; les connecter une à une au client multiplie les couplages. Il faut virtualiser l'environnement et standardiser l'interface.

Mécanisme original

Session virtualization : une session logique est maintenue indépendamment du runtime sous-jacent, avec workers dédiés, streaming, tool registry, schema repair et reprise de session.

Difficultés

• Maintenir une session logique malgré le remplacement du runtime sous-jacent
• Réparer les schémas d'outils incompatibles (tool schema repair)
• Rotation des comptes/providers sans casser les sessions

Choix techniques

Résultat actuel

Des clients variés consomment les capacités du runtime via une interface standardisée, avec rotation des comptes et reprise de session.

Ce que ce projet nous a appris

Des clients variés consomment les capacités du runtime via une interface standardisée, avec rotation des comptes et reprise de session.

Clients -> Runtime Gateway -> workers virtualisés (sessions, tools, multimodalité) -> runtime sous-jacent