concatflowVos agents agissent.
Vous décidez.
Concatflow unifie les définitions de vos données et filtre l’accès de chaque agent via MCP. L’architecture proposée y ajoute des actions métiers réutilisables, gouvernées à chaque appel.
Le contexte MCP appartient au socle actuel. Les tools métiers partagés et leur exécution relèvent de l’architecture proposée.
Un même tool. Des droits différents.
Dans l’architecture proposée, Concatflow partage ce tool métier via MCP ou API. Les droits de l’agent et le montant demandé déterminent la décision.
Rembourser une commande
SimulationDans le plafond autorisé de 500 €.
Un tool.
Deux options.
Les agents partagent un contrat. Le lieu d’exécution reste votre choix.
Tool métier
Une action publiée pour les agents autorisés.
Cloud Concatflow
Le tool s’exécute dans le cloud.
Votre infrastructure
Le tool s’exécute sur votre infrastructure.
Écrit une fois.
Utilisé partout.
Une équipe publie l’action avec son contrat, ses règles et sa version. Les autres agents l’utilisent selon leurs droits, sans recréer la logique dans chaque assistant.
une commande
Un contrat, une version, des règles métier maintenues au même endroit.
MCP APIExemple illustratif. Chaque agent voit la même capacité, avec son propre périmètre.
Le contrôle suit l’appel.
Chaque appel relie l’identité de l’agent, son périmètre, la règle métier et le résultat. Le droit ne dépend pas d’une phrase dans le prompt.
- IdentitéQuel agent demande l’action ?
- PérimètreQuel tool lui est ouvert ?
- RègleLa demande reste-t-elle autorisée ?
- TraceQuelle décision en ressort ?
Le bon contexte.
Par MCP.
Le serveur expose les définitions du workspace appelant via universal_context. Le périmètre s’applique avant la réponse, et la consultation ciblée laisse une trace d’usage.
universal_context({
term: "ca ht net"
})
← terms[0]
term: "CA net"
definitions[0].text: "HT moins remboursements"
definitions[0].status: "unverified"Réponse abrégée d’un scénario de test. Le statut à valider reste visible.
Le contexte retourné appartient à l’espace de l’appelant.
Une définition issue d’une source restreinte à un rôle absent reste cachée.
Une demande de terme est enregistrée comme usage MCP.
Exemple issu des tests, données fictives. Les requêtes SQL en lecture seule vérifient aussi le périmètre avant exécution. Les actions métiers exécutables présentées plus bas appartiennent à l’architecture proposée.
Des sources à l’agent.
Exemple illustratif : des informations dispersées deviennent une définition métier consultable via MCP. Le socle MCP présenté plus haut existe déjà ; le chemin complet montre l’architecture proposée.
- 01 / 03
Trois sources. Une question métier.
Ventes, remboursements et documentation vivent dans des systèmes différents. Leurs origines restent visibles au lieu d’être recopiées dans chaque agent.
Architecture proposée · exemple illustratif01 / 03 01 / SOURCESÀ quoi correspond le CA net ?
Les informations de départ restent dans leurs systèmes.
- Ventes HTBase de ventes
- RemboursementsAPI finance
- Règle de calculDocument interne
QUESTION COMMUNE« Quel est le CA net ? »Trois origines, un terme à définir. - 02 / 03
Une définition relie les pièces.
Dans le Context Layer, « CA net » reçoit un sens explicite, un statut et des liens vers les données concernées.
Architecture proposée · exemple illustratif02 / 03 02 / CONTEXT LAYER« CA net » a un sens partagé.
Une définition et ses repères sont disponibles dans le workspace.
TERME MÉTIERCA netAlias · CA HT netDÉFINITIONHT moins remboursementsStatut · à valider
Mappings vers les sourcesUn sens consultableavec son statut et ses liens aux données - 03 / 03
La définition arrive à l’agent.
Via MCP, il demande « CA net » et reçoit la définition visible dans son workspace. Cette consultation ciblée laisse une trace d’usage.
Architecture proposée · exemple illustratif03 / 03 03 / MCPLe contexte arrive par MCP.
Une demande de terme lui apporte le contexte autorisé, sans lui envoyer les données brutes.
- 01Demande ciblée
Agent → universal_context · « CA net »
- 02Réponse cadrée
Définition et statut visibles dans son workspace
- 03Usage consigné
La consultation ciblée est enregistrée côté MCP
L’exemple n’exécute aucune action métier.
- 01
Questions clés.
Avant de connecter un premier agent, voici les choix qui structurent un déploiement.
Faut-il déplacer toutes nos données ?
Non. Le Context Layer rend leurs définitions, leur provenance et leurs accès partageables. Les sources peuvent rester dans vos systèmes existants.
Comment un agent appelle-t-il une action ?
Dans l’architecture proposée, une action métier publiée est accessible aux agents autorisés via MCP ou API. Son contrat et sa version restent communs, même lorsque plusieurs agents l’utilisent.
Où se trouvent les règles métier ?
Dans l’action métier publiée : l’identité, le périmètre et ses conditions seraient vérifiés à l’appel, plutôt que laissés à l’interprétation d’un prompt.
Où le code peut-il s’exécuter ?
L’architecture proposée prévoit une exécution dans le cloud Concatflow ou sur votre propre infrastructure, selon les besoins de votre intégration.
Que peut-on retrouver après un appel ?
Les consultations du contexte et les requêtes MCP du socle actuel laissent des traces adaptées à leur usage. Pour les actions métiers proposées, la trace associerait l’agent, l’action, sa version, le statut et le résultat.
Une décision.
Son pourquoi.
Changez l’agent ou le montant pour voir comment la règle autorise ou refuse l’action dans cette simulation.
Tester la décision