agents IA
Des agents IA qui vident vos files, en production en 14 jours
Quelqu'un chez vous lit un ticket, ouvre trois systèmes, recopie des champs de l'un à l'autre et rédige une note. C'est un travail qu'un agent fait bien, et nous le construisons : des appels d'outils typés vers Salesforce, SAP, Jira, votre AS/400 ou votre propre API, une validation sur tout ce qui écrit, et un journal par décision montrant ce qu'il a lu et pourquoi il a agi. Le premier workflow prend quatorze jours, et le deuxième va plus vite parce que les adaptateurs sont déjà là.
14 jours pour le premier workflow ; le deuxième va plus vite parce que les adaptateurs existent
Le script RPA est barré parce qu'il casse le jour où un éditeur déplace un bouton. Les adaptateurs passent par des API, et là où il n'y en a pas, nous en construisons une.
File manuelle
Des gens trient les tickets, recopient entre systèmes et suivent un runbook qui vit en PDF.
- ticket queuehumans triage
- copy-paste between systemsmanual
- runbook.pdftribal knowledge
- RPA scriptbreaks on redesign
Agent sous validation
Un agent, des adaptateurs typés, une étape de validation explicite, une ligne d'audit par décision.
- agentGo · tool calls
- system adapterstyped
- human approvalexplicit gate
- audit trailper decision
14 jours pour le premier workflow ; le deuxième va plus vite parce que les adaptateurs existent
Comment le travail se déroule
- 01jours 1–2
Choisir le workflow par le calcul
Le volume multiplié par les minutes par dossier, moins les dossiers qui demanderont toujours une personne. Nous faisons cette multiplication avec vous le premier jour et commençons par la file qui se rembourse le plus vite.
- 02jours 2–5
Écrire les adaptateurs
Des appels typés vers vos systèmes, avec les modes de panne traités : limites de débit, enregistrements écrits à moitié, l'endpoint qui renvoie 200 avec une erreur dans le corps.
- 03jours 5–10
Le faire tourner en observation
L'agent propose, une personne décide, et chaque désaccord repart dans le jeu d'évaluation. Le métier de personne ne change encore, et vous obtenez un vrai taux de justesse sur vos propres dossiers.
- 04jours 9–14
Ouvrir la vanne une action à la fois
Les actions au bon historique et au rayon d'action réduit passent en automatique en premier. Les autres restent sous validation aussi longtemps que vous le voulez, y compris définitivement.
Ce que fait la plateforme, ce que fait un humain
| Ce que fait la plateforme, ce que fait un humain | Qui fait quoi | Notes |
|---|---|---|
| Lire le runbook et l'historique des tickets | Plateforme | Y compris les dossiers traités à l'encontre du runbook, qui sont les plus intéressants. |
| Décider ce que l'agent peut faire sans demander | Ingénieur | Nous recommandons par type d'action. Vous signez, par écrit, avant que cela tourne. |
| Construire les adaptateurs | Les deux | Générés depuis le contrat d'API, puis corrigés par un humain contre ce que l'API fait vraiment. |
| Arbitrer les désaccords en mode observation | Les deux | Automatique quand l'historique montre le résultat, humain quand deux de vos experts en discuteraient. |
| La piste d'audit | Plateforme | Entrées, outils appelés, décision, validateur. Une ligne consultable par dossier, gardée que la réponse ait été juste ou fausse. |
| Les chemins d'escalade | Ingénieur | Ce que fait l'agent quand il n'est pas sûr, et qui reprend le dossier à 18 h un vendredi. |
Les gens derrière les agents
Des dizaines de migrations et plus de dix ans passés à relier des systèmes qui n'étaient pas faits pour se parler : SAP, Salesforce, Jira, Dynamics, un AS/400, un endpoint SOAP de 2006, un CSV déposé sur un serveur FTP chaque nuit. Les agents sont la chose la plus récente que nous construisons. L'intégration en dessous est la plus ancienne, et c'est elle qui décide si tout cela marche.
Le mode observation est la preuve, et il vient avant l'engagement. L'agent tourne sur votre vraie file, propose, et une personne décide. À la fin vous tenez un taux de justesse mesuré sur vos propres dossiers.
Questions que nous posent les ingénieurs
- En quoi est-ce différent du RPA que nous avons déjà acheté ?
- Le RPA pilote l'interface, donc il casse à la moindre refonte et ne comprend rien au dossier. Un agent appelle des API et sait traiter le ticket qui ne colle pas au script, celui sur lequel vos gens passent leur journée. La contrepartie, c'est que le RPA est déterministe et un agent ne l'est pas, d'où la validation et le jeu d'évaluation.
- Qu'est-ce qui l'empêche de faire quelque chose de coûteux ?
- Il ne peut pas appeler un outil qu'on ne lui a pas donné, et les outils qui écrivent sont sous validation par défaut. Le rayon d'action est un choix de conception fait par type d'action, avant que quoi que ce soit tourne, et il figure dans le document que vous avez signé.
- Comment savons-nous qu'il a raison ?
- Des jours de mode observation sur votre file, un jeu d'évaluation bâti sur les désaccords, et un journal par décision que vous ouvrez quand quelqu'un se plaint d'un dossier précis.
- Avez-vous besoin de nos données pour l'entraînement ?
- Pas de fine-tuning par défaut. L'agent lit ce dont il a besoin au moment du dossier, et ce qu'il a lu est dans le journal. Si vous voulez ensuite un modèle entraîné sur votre historique, c'est une décision séparée avec sa propre paperasse.
- Que se passe-t-il quand nous changeons un système auquel il parle ?
- L'adaptateur est typé, donc un changement de contrat casse le build au lieu d'échouer en silence en production le jour de la clôture. C'est l'essentiel de la raison pour laquelle nous écrivons des adaptateurs au lieu de laisser un modèle improviser des appels HTTP.
Envoyez-nous une file
Décrivez le travail tel qu'une personne le fait aujourd'hui, y compris l'étape où elle vérifie quelque chose. Combien de dossiers par mois, et combien de temps prend un dossier. Ces deux nombres et une journée nous suffisent pour vous dire ce que cela ferait gagner.
Le formulaire demande le volume de dossiers et le temps de traitement. Ces deux nombres décident de l'essentiel.