Pourquoi Sidekicks parle ACP — explication

De quoi s'agit-il ?

Sidekicks est une application de bureau pour converser avec des agents d'IA, destinée à des personnes qui ne sont pas développeuses. Elle ne contient pas d'agent : c'est un client qui démarre les agents comme des programmes séparés et leur parle avec l'Agent Client Protocol (ACP), du JSON-RPC sur l'entrée et la sortie standard de l'agent. Cette page explique ce choix et ce que le premier contact avec de vrais agents nous a appris. Les décisions détaillées sont dans l'ADR 0001 (en anglais).

Pourquoi un protocole plutôt qu'une intégration

L'objectif est une application agnostique de l'agent. Intégrer la bibliothèque d'un agent lierait Sidekicks à lui ; parler un protocole permet d'ajouter, en trois lignes de YAML, n'importe quel agent qui implémente ACP — mm aujourd'hui, demain ceux que Zed ou JetBrains savent piloter. ACP modélise aussi déjà ce dont une conversation avec un agent a besoin : réponses transmises au fil de l'eau, tool calls, demandes de permission, annulation, commandes slash.

Ce que le spike a appris des vrais agents

Lire une spécification n'est pas observer un agent. Le spike a piloté les agents de test et enregistré le trafic (traces). Quatre constats façonnent le produit :

mm parle la version 1 d'ACP. Le site documente déjà une version 2 ; Sidekicks vise la v1 et isole le protocole dans un package pour ajouter la v2 plus tard.
mm ne sait pas recharger une session. Après un redémarrage, Sidekicks doit redonner à l'agent le contexte de la conversation : la mémoire de la conversation est l'affaire de Sidekicks.
Les skills sont des commandes slash. Les skills de Garfield arrivent comme des commandes, et /idioms Il pleut des cordes. envoyé comme simple texte lance le skill. Dans un channel à plusieurs agents, /garfield:idioms … demande seulement à Sidekicks de retirer le nom de l'agent et d'envoyer le reste à Garfield.
Un petit modèle n'accepte pas un refus. Refusé une fois, Riker a retenté la même action quarante fois sous des formes différentes, jusqu'à ce que mm abandonne sur une erreur. Un dialogue de permission qui ne propose que « autoriser » et « refuser » mettrait un utilisateur non technique face à quarante dialogues ; d'où « jamais dans cette conversation » et « arrêter l'agent » (voir la maquette).

Alternatives écartées

Écrire la couche JSON-RPC à la main : possible, mais le SDK Go de Coder est généré depuis le schéma officiel, couvre tous les messages v1 et n'a aucune dépendance. Maintenir ce code nous-mêmes coûterait sans rien apporter.
Attendre ACP v2 : aucun des agents utilisés ne la parle encore.
Offrir aux agents l'accès aux fichiers et au terminal du client : mm utilise ses propres outils et ne l'a jamais demandé ; cela reste une fonctionnalité optionnelle, pour plus tard.

Lien avec le reste

Seul le package internal/acp connaîtra ACP ; le reste de l'application voit les événements propres à Sidekicks (voir Architecture). Les quatre agents de test et leurs contraintes de mémoire sont traités dans Mémoire et modèles locaux.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# Pourquoi Sidekicks parle ACP — explication

## De quoi s'agit-il ?

Sidekicks est une application de bureau pour converser avec des agents d'IA, destinée à des personnes qui ne sont pas développeuses. Elle ne contient pas d'agent : c'est un **client** qui démarre les agents comme des programmes séparés et leur parle avec l'[Agent Client Protocol](https://agentclientprotocol.com) (ACP), du JSON-RPC sur l'entrée et la sortie standard de l'agent. Cette page explique ce choix et ce que le premier contact avec de vrais agents nous a appris. Les décisions détaillées sont dans l'[ADR 0001](../../adr/0001-acp.md) (en anglais).

## Pourquoi un protocole plutôt qu'une intégration

L'objectif est une application **agnostique de l'agent**. Intégrer la bibliothèque d'un agent lierait Sidekicks à lui ; parler un protocole permet d'ajouter, en trois lignes de YAML, n'importe quel agent qui implémente ACP — mm aujourd'hui, demain ceux que Zed ou JetBrains savent piloter. ACP modélise aussi déjà ce dont une conversation avec un agent a besoin : réponses transmises au fil de l'eau, tool calls, demandes de permission, annulation, commandes slash.

## Ce que le spike a appris des vrais agents

Lire une spécification n'est pas observer un agent. Le spike a piloté les agents de test et enregistré le trafic ([traces](../../spikes/acp/README.md)). Quatre constats façonnent le produit :

- **mm parle la version 1 d'ACP.** Le site documente déjà une version 2 ; Sidekicks vise la v1 et isole le protocole dans un package pour ajouter la v2 plus tard.
- **mm ne sait pas recharger une session.** Après un redémarrage, Sidekicks doit redonner à l'agent le contexte de la conversation : la mémoire de la conversation est l'affaire de Sidekicks.
- **Les skills sont des commandes slash.** Les skills de Garfield arrivent comme des commandes, et `/idioms Il pleut des cordes.` envoyé comme simple texte lance le skill. Dans un channel à plusieurs agents, `/garfield:idioms …` demande seulement à Sidekicks de retirer le nom de l'agent et d'envoyer le reste à Garfield.
- **Un petit modèle n'accepte pas un refus.** Refusé une fois, Riker a retenté la même action quarante fois sous des formes différentes, jusqu'à ce que mm abandonne sur une erreur. Un dialogue de permission qui ne propose que « autoriser » et « refuser » mettrait un utilisateur non technique face à quarante dialogues ; d'où « jamais dans cette conversation » et « arrêter l'agent » (voir la [maquette](../../design/04-permission.png)).

## Alternatives écartées

- **Écrire la couche JSON-RPC à la main** : possible, mais le SDK Go de Coder est généré depuis le schéma officiel, couvre tous les messages v1 et n'a aucune dépendance. Maintenir ce code nous-mêmes coûterait sans rien apporter.
- **Attendre ACP v2** : aucun des agents utilisés ne la parle encore.
- **Offrir aux agents l'accès aux fichiers et au terminal du client** : mm utilise ses propres outils et ne l'a jamais demandé ; cela reste une fonctionnalité optionnelle, pour plus tard.

## Lien avec le reste

Seul le package `internal/acp` connaîtra ACP ; le reste de l'application voit les événements propres à Sidekicks (voir [Architecture](architecture.md)). Les quatre agents de test et leurs contraintes de mémoire sont traités dans [Mémoire et modèles locaux](memoire-et-modeles-locaux.md).