Concepts
Convoy décide qui peut faire quoi, avec quels outils, dans quel ordre, quand — et ce qui se passe ensuite.
Une station, toutes les portes, les mêmes règles : notre agent n'est qu'un client parmi les autres.
| dans la phrase | primitive |
|---|---|
| qui | accès : identité, profils, sous-identités |
| peut | politiques |
| faire quoi, avec quels outils | capacités : skills et leurs actions |
| dans quel ordre | parcours : playbooks |
| quand | ce qui ouvre : un événement entrant, une automatisation, l'intention reconnue par le modèle |
| et ce qui se passe ensuite | ce qui suit : événements émis, livraisons, automatisations |
Puis, autour de ces règles :
- la station les porte une seule fois, pour tout agent ;
- ses canaux sont les portes par lesquelles les agents la joignent : MCP, WebMCP, l'API ;
- les agents sont ses clients : Claude, ChatGPT, l'agent d'une entreprise, et le nôtre ;
- les portails sont l'endroit où notre agent rencontre des personnes : widget, PWA, Teams, Slack, WhatsApp.
Un canal relie un agent à la station ; un portail relie une personne à notre agent.
Les mots
| mot | ce que c'est |
|---|---|
| station | un déploiement : APIs + config, joignable par ses canaux. Versionnée : staging, puis production. |
| organisation | le client. Elle possède ses stations, son annuaire, ses clés. |
| user | celui que la station sert : le client (product), l'employé (process). Profils et permissions s'appliquent à lui et à ses agents. |
| admin | celui qui construit et fait tourner la station : le product builder (product), l'admin IT (process). Il agit dans la console, jamais dans une room. |
propriétaire (owner) | le user à qui la room appartient, une fois son identité vérifiée. La personne dont il s'agit, elle, est concernée (concerns). |
| identifiant | une donnée qui identifie la room : phone, email, customer_id… Il est déclaré quand la personne l'a tapé (il reste dans sa room), vérifié quand un fournisseur l'a prouvé (il retrouve ses autres rooms). |
| fournisseur d'identité | un mécanisme que Convoy prépare et que la station configure : otp, oidc (Okta, Auth0, Keycloak, Entra ID), assertion. Il dit quelle donnée il vérifie (verifies:). |
| global | ce qui vaut pour toute la station : langue, devise de tous les champs price, format, fuseau. |
| agent | l'agent que Convoy déploie : sa voix, ses consignes, ses portails. Un client de la station, comme un agent externe. |
| canal | une porte de la station pour les agents : MCP, WebMCP, l'API. Les mêmes règles derrière chacune. |
| portail | là où notre agent parle : web (widget, PWA), teams, slack, whatsapp. Chacun dit comment il prouve qui parle. |
| action | ce qu'une skill propose : « acheter cet article », « rembourser 72 € ». Dans la config, une action s'appelle un item ($item). Une action se lit ou s'écrit. |
| kind | une catégorie d'actions, reconnue par une condition sur leurs champs. Un kind peut être présenté, choisi et exécuté autrement, et déclarer les champs que la personne remplit pour chacune de ses lignes. |
| profil | une catégorie d'acteurs, reconnue par une condition sur l'identité. Un profil peut être servi autrement, sur les mêmes points qu'un kind. |
| skill | une compétence : elle répond à un besoin en proposant des actions. Elle dit comment les obtenir (invoke), les classer (kinds), les présenter (present), les réserver (select) et les exécuter (submit). |
| sélection | l'ordre d'actions de la room : les écritures réservées, et les traces des lectures. |
| garde | une politique évaluée avant qu'une action soit réservée (ou lue). |
| playbook | un ensemble de tâches qui mène à un résultat. Il impose leur ordre, ajoute des gardes, et se termine par son submit. Une commande qui envoie en une requête les lignes de plusieurs tâches se déclare une fois, sur ce submit. |
| sous-playbook | une tâche qui est elle-même un playbook, avec son propre submit. Le parent reçoit son résultat déjà exécuté. |
| submit | l'exécution des écritures réservées, dans l'ordre : un appel qui lit la sortie d'un autre part après lui ; sinon les appels des skills, puis ceux du playbook. Il ferme le playbook. |
| automatisation | un acteur qui démarre, relance ou notifie sur un événement. Elle n'écrit jamais dans un outil et ne soumet jamais. |
| politique | toute restriction, où qu'elle s'applique. Type rule (déterministe, budgets compris) ou smart (un modèle et un seuil : elle peut demander un humain, jamais autoriser). |
| événement | un fait : entrant (d'un outil, d'une autre station), interne à Core, ou émis par la station. Il ne se refuse pas ; il se livre. |
| outbound | la livraison des faits émis à un système externe. Elle ne décide rien. |
| budget | une politique rule qui plafonne plusieurs actions : une somme ou un nombre, par portée et par période. |
| consommation | ce que la station coûte au tenant (parcours, appels au modèle, livraisons). Se lit et se facture ; ce n'est pas une politique. |
| boîte | là où la station demande à une personne de décider, avec un délai et une escalade. Ce n'est pas un portail. |
| room | l'espace d'une personne (ou d'une équipe) avec la station. Le parcours en cours appartient à la room : plusieurs personnes, plusieurs sessions, plusieurs jours. |
| test | un comportement promis par la station, rejoué sans modèle. Vrai ou faux ; un échec bloque la version de la station. |
| eval | ce que notre agent fait d'une demande, joué plusieurs fois avec son modèle. Un taux ; un échec bloque la version de l'agent. |
| journal | ce qui a été décidé, par qui, sur quoi, avec quelles règles. On peut le rejouer. |
Le cycle de vie d'une action
Une action placée dans la sélection a un état. Les événements internes portent les mêmes noms :
action.pending, action.reserved, action.executed…
| action | vie | au submit |
|---|---|---|
| une écriture | proposée → en attente (d'une personne ou d'un service) → réservée → exécutée · refusée · en attente d'un parent | exécutée, dans l'ordre |
| une lecture | lue → remplacée · périmée | jamais rejouée ; portée dans le reçu |
Une lecture laisse une trace parce que la personne qui soumet doit voir sur quoi repose l'action (« Facture INV-2291 vérifiée · 120 € » au-dessus de « Rembourser 120 € »). Une trace ne compte pas dans le total. Elle est remplacée, jamais supprimée.
Un refus ne fait pas reculer le parcours : l'action revient à proposée, et le plan est recalculé.