Cortex (Chat)
L'application de chat orientée clients. Conversations multi-tours, appels d'outils, @mentions, sous-agents, blocs de contenu et supervision administrateur.
Cortex est l'application de chat orientée clients. Elle fournit une interface conversationnelle multi-tours s'appuyant sur un moteur agentique — non pas une API LLM brute, mais une boucle d'appels d'outils capable de rechercher dans des bases de connaissances, d'exécuter des workflows, d'interroger des données ontologiques, de lancer des automatisations, d'appeler des intégrations et de déléguer à des sous-agents spécialisés, le tout dans un même fil de conversation.
Cortex n'est pas une passerelle LLM. La résolution du fournisseur LLM et la gestion des identifiants se font dans le runtime de capacités hébergé par le service de plateforme. Cortex appelle agentic pour les complétions et achemine les résultats d'outils via le pont d'outils gouverné.
Ce qu'il fait
| Préoccupation | Comment Cortex la gère |
|---|---|
| Conversations | Persiste l'historique des conversations multi-tours dans @scrydon/db-cortex. Les conversations Cortex ordinaires sont délimitées par le workspace et appartiennent à l'utilisateur. Une action de Process Flow peut à la place lier une conversation de ressource partagée à toutes les personnes actuellement autorisées pour cette action. |
| Streaming | Diffuse les réponses LLM vers le navigateur via SSE. Un cache de snapshots permet aux clients qui se reconnectent de rejouer les événements manqués sans redémarrer le tour. |
| Boucle d'appels d'outils | Exécute une boucle itérative d'appels d'outils (jusqu'à 10 itérations par tour). Les outils intégrés couvrent la recherche dans les bases de connaissances, la gestion de fichiers, les workflows, les automatisations, les requêtes ontologiques, les couches cartographiques/géo, les outils d'intégration, l'exécution de code et la recherche web. |
| @mentions | Les utilisateurs peuvent mentionner des workflows, des bases de connaissances, des sources de données ou des tables de chat dans leur message. Le résolveur de mentions injecte la ressource comme contexte structuré avant que le LLM voie le prompt. |
| Sous-agents | L'outil delegate_to_agent achemine une sous-tâche vers un agent spécialisé nommé et réintègre sa réponse dans le tour parent sous forme de bloc de contenu subagent_block. |
| Plan/Todo | Le LLM peut émettre des appels d'outils structurés plan_create / plan_update_item / plan_complete qui affichent un indicateur de progression en direct dans l'interface, sans aller-retour supplémentaire. |
| Blocs de contenu | Les réponses portent des blocs typés (credential, map, subagent, plan_todo, workflow_suggestion, …) que l'interface affiche comme des composants riches au-delà du markdown simple. |
| Supervision administrateur | Un panneau d'administration expose les journaux de conversations, les sujets extraits (via un cron) et les contrôles de purge de rétention. |
| Consentement | Une porte de consentement intercepte les nouvelles conversations pour s'assurer que l'utilisateur a accepté la politique de traitement des données en vigueur avant qu'aucune donnée ne soit envoyée à un fournisseur LLM. |
| Limitation de débit | Des limites de débit par utilisateur et par workspace sont appliquées au niveau de la route /api/chat avant que le tour n'atteigne le LLM. |
Déroulement d'un tour de chat
Navigateur → POST /api/chat (SSE)
→ porte d'authentification (session + limite de débit + consentement)
→ enrichissement du contexte (@mentions, KB du workspace, conversation précédente)
→ agentic ScrydonClient.chat.stream(...)
↕ boucle d'appels d'outils (jusqu'à 10 itérations)
├── Recherche KB, outils fichiers, requête ontologique, couches cartographiques
├── CRUD workflow / automatisation (via l'API agentic)
├── Outils d'intégration (via le pont d'outils gouverné d'agentic)
├── Exécution de code
└── Délégation à un sous-agent (delegate_to_agent → exécuteur → sous-tour)
→ événements SSE diffusés vers le navigateur en temps réel
→ lignes de conversation + message persistées dans db-cortex
→ message de chat vectorisé pour la recherche sémantique dans l'historiqueCortex n'appelle pas directement les fournisseurs LLM. Il appelle le service agentic via ScrydonClient ; agentic résout le modèle, récupère les identifiants auprès du runtime de capacités et dispatche la complétion. Cela signifie que le fournisseur LLM, la politique de basculement et les garde-fous DLP sont tous gouvernés par le registre d'intégrations — Cortex n'a qu'à fournir les messages, les outils et la préférence de modèle.
Conversations privées et conversations d'action partagées
La surface Chat normale et le lanceur Cortex flottant créent des conversations privées appartenant à l'utilisateur. Le volet droit du Wizard d'un Process Flow est différent : il s'agit d'une Conversation d'action partagée liée à l'action en cours. Toute personne qui peut actuellement lire l'action du processus et satisfait son niveau d'habilitation voit le même historique ordonné et l'auteur de chaque question.
Agentic autorise l'action avant que Cortex ouvre le fil, envoie un message, charge l'historique, applique un raffinement ou résolve une source. Le fil partagé n'est ancré que dans le contexte commun à l'action : l'action et sa sortie actuelles, la base de connaissances de l'instance, le dernier brouillon d'enregistrement le cas échéant et le briefing du Contexte de l'entreprise configuré pour l'action. La mémoire personnelle, les fichiers de chat privés et les droits de KB privés n'y sont pas mélangés.
Une question ordinaire ne modifie pas l'action. Sur les sorties IA éligibles, un participant peut choisir explicitement Appliquer comme raffinement sur une réponse ; la plateforme réautorise l'action et réexécute le chemin de raffinement canonique. Les décisions pertinentes et les raffinements acceptés sont résumés dans la KB de l'instance du processus. Le fil brut reste dans Cortex, et rien n'est promu vers le Contexte de l'entreprise.
Les liens de source de la conversation sont hydratés et autorisés au moment de l'affichage. Si une source a été supprimée ou si l'utilisateur n'y a plus accès, Cortex la signale comme indisponible au lieu d'exposer un lien obsolète.
Domaines d'outils
Le registre d'outils de Cortex est partitionné en domaines nommés. Le moteur utilise les capacités du workspace pour sélectionner les domaines actifs pour un tour donné, évitant ainsi les descriptions d'outils inutiles dans la fenêtre de contexte.
| Domaine | Exemples d'outils |
|---|---|
knowledge | search_kb, read_document, create_document |
files | upload_file, attach_to_kb, list_files |
workflows | workflow_list, workflow_create, workflow_run, workflow_suggest |
automations | automation_list, automation_create, automation_enable |
tables | query_table, list_tables |
ontology | ontology_list_types, ontology_query, query_map |
integrations | integration_tool_search, integration_tool_run (via le pont gouverné d'agentic) |
code | execute_code |
utility | search_online, schedule_task, request_oauth_access |
Injection de contexte et @mentions
Avant le premier appel LLM d'un tour, Cortex enrichit le prompt avec :
- Contexte du workspace — IDs des bases de connaissances activées, capacités de workflow et d'outils disponibles pour l'environnement du workspace.
- Contexte des mentions — toute référence
@[Titre](type:id)dans le message de l'utilisateur est résolue en blocs de contexte markdown (définition de workflow, extrait de KB, schéma de source de données, lignes de table). - Historique sémantique — les N derniers tours plus un rappel sémantique sur l'historique de conversation vectorisé maintiennent la fenêtre de contexte pertinente sans toujours inclure la transcription complète.
Panneau d'administration
Cortex embarque un panneau réservé aux administrateurs à /admin :
- Conversations — journal complet des conversations avec le détail des messages et la visionneuse de justifications DLP.
- Sujets — sujets de conversation extraits par un cron en arrière-plan, utilisés pour l'analytique et la recherche.
Où configurer cela
- Quel LLM est utilisé — Paramètres → Plateforme → Intégrations → [vendeur] → Capacités. Cortex respecte le modèle par défaut de l'organisation et tout remplacement de modèle par bloc.
- Quels outils sont disponibles — déterminé par les intégrations activées du workspace et la politique de capacités de l'organisation. Aucun paramètre propre à Cortex.
- Consentement au traitement des données — Paramètres → Plateforme → Politique de consentement.
- Rétention — le cron de purge de rétention est configurable par déploiement via des variables d'environnement.
Voir aussi
- Intégrations — détermine quels outils et modèles sont disponibles dans le chat.
- Architecture → Agentic — le service que Cortex appelle pour les complétions LLM et l'exécution des outils.
- Architecture → Bases de connaissances — connaissance privée de conversation, KB d'espace de travail et Contexte de l'entreprise en lecture seule.
- Intégrations → Capacités — héberge le runtime de capacités qui résout les fournisseurs LLM.
- Sécurité → DLP — appliqué au niveau de la couche agentic/capacités, pas dans Cortex lui-même.
- Sécurité → Gestion des secrets — où vivent les identifiants des fournisseurs.