Adaptez-le
à votre cas.
Vous avez un besoin précis ? Vous n'avez pas à modifier le cœur de Pumaï. La simple création d'un outil est déjà une extension de l'application — et l'agent s'en sert de lui-même dès lors qu'il est bien défini.
Un outil, c'est une extension
Étendre Pumaï, ce n'est pas forker l'application : c'est lui donner accès à vos systèmes en écrivant de petits outils. Un outil bien décrit — un nom clair, ce qu'il fait, ses paramètres — est choisi automatiquement par l'agent quand la tâche l'exige. Vous refermez la boucle en nommant les outils dans l'instruction, pour que le même schéma se rejoue à l'identique, tous les jours.
Une API dans un outil
Le service que vous utilisez a une API ? On l'enveloppe dans un outil : récupérer, créer, mettre à jour — ce dont vous avez besoin.
Un outil de traitement
Un outil qui transforme les données ou met en forme un contenu — dans exactement le format attendu en sortie.
Un agent vers les outils
À la demande ou via un Pulz autonome : l'instruction nomme les outils, et le schéma tourne seul.
Un support qui rend compte chaque soir
Un client doit traiter les demandes qui lui sont adressées, et recevoir chaque fin de journée un compte rendu dans un format précis. Voici comment on l'assemble.
Accéder aux tickets. Sa plateforme de gestion de tickets a une API : on crée un outil qui récupère les tickets qui lui sont destinés, et un second qui marque un ticket « en cours » ou « résolu ». Les deux se conçoivent et se testent dans le Studio d'outils, sans code répétitif.
Mettre en forme. Le compte rendu doit suivre un gabarit précis — sections, ton, typographie. On crée un outil de formatage qui transforme des notes brutes en exactement cette mise en page. (L'envoi d'e-mail, lui, est déjà intégré au système.)
Mettre en pilote automatique. On crée un Pulz — une mission autonome — et on lui donne l'instruction en clair, en nommant les outils à utiliser. Le même schéma se rejoue chaque soir, sous la même gouvernance (un envoi sensible peut toujours exiger votre validation).
nommer les outils est facultatif — l'agent sait les choisir seul — mais c'est plus net et plus reproductible. la boucle est bouclée : récupérer → raisonner → formater → livrer, tous les jours.
De l'outil à la Compétence
Ce que d'autres plateformes appellent un « skill », Pumaï le distingue en deux briques natives : l'outil — la capacité appelable (atteindre une API, formater, envoyer) — et la Compétence — la procédure réutilisable, le « comment » d'une tâche récurrente (traiter un devis, gérer une réclamation, produire un rapport). Vous créez une Compétence une seule fois, par simple entretien guidé dans un studio dédié ; l'agent la choisit ensuite au sens, exactement comme il choisit un outil, et l'applique à l'identique. Résultat : un comportement fiable et répétable — et un gain mesurable (une comparaison « avec / sans » chiffre le temps et le coût économisés).
Universel par construction. Rien de tout cela n'est propre au support. On peut créer un accès API à n'importe quoi, des outils de traitement de données qui sortent n'importe quel format, et — quand une tâche exige la puissance du système — des outils qui s'appuient sur le système de fichiers et des commandes Linux. On étend le produit en créant des outils, et on oriente l'agent vers eux dans les instructions. C'est tout.
Un cas précis en tête ?
Décrivez-nous votre cas d'usage — réponse individuelle sous 48 h.