Limites et restrictions

Ce que Letaido ne fera pas, ce qu'il ne peut pas faire, et les limites souples à connaître.

Limitations techniques (par conception)

Ce sont des refus délibérés. Ils ne peuvent pas être contournés par des prompts astucieux.

• Effectuer des actions importantes sans approbation explicite. L'installation d'un package Python, l'enregistrement d'une tâche, l'ajout d'un nouveau domaine sortant à la liste autorisée et la connexion d'un nouvel identifiant affichent tous des cartes d'approbation. Le propriétaire ou l'administrateur clique une fois.
• Basculer le mode du site public. Désactivé / autorisé / ouvert est réservé au propriétaire ou à l'administrateur, et uniquement via l'interface de l'espace de travail. L'agent ne le basculera pas de manière programmatique.
• Accéder à des services externes sans connecteur approuvé. L'envoi d'e-mails, l'appel d'une API de paiement, la publication sur Slack ou toute autre écriture vers un tiers nécessite un connecteur qui a été approuvé pour la surface (chat, Console ou site) effectuant l'appel.
• Toucher un autre espace de travail. Chaque espace de travail est isolé au niveau du système d'exploitation, de la base de données et du stockage des secrets.

« Ne peut pas » strict (appliqué)

• Le processus Console ne peut pas lire vos fichiers d'espace de travail privés en dehors de ~/workspace/downloads/.
• Le site public ne peut pas lire les données internes de Console. Les rôles Postgres REVOKE l'accès au niveau de la base de données ; l'échec est bruyant, pas silencieux.
• Aucune surface ne peut lire le répertoire de configuration de la plateforme (/opt/letaido/config/).
• Aucun HTTPS sortant vers des hôtes non-loopback sans une liste d'autorisation de domaines explicite.
• nginx expire après 30 secondes. Les tâches longues renvoient un ID de tâche et interrogent. L'agent écrit des applications qui respectent cela sans qu'on le lui demande.

Limites souples (bon à savoir)

• Fenêtre de contexte. Un seul chat dispose d'une fenêtre de contexte finie. Les sessions longues se dégradent. L'agent préfère écrire les résultats intermédiaires sur le disque plutôt que de les répéter dans le chat, et lancera un chat séparé pour les tâches annexes tangentielles (recherche longue, brouillons indépendants de l'historique).
• Durée d'exécution des tâches en arrière-plan. 1 heure par exécution. Tout ce qui dure plus longtemps doit être divisé en étapes avec un état dans Postgres.
• Capture de sortie des tâches. stdout et stderr sont limités à 50 Ko par exécution. Les sorties plus volumineuses vont dans un fichier ou une ligne de base de données.
• Rétention des événements webhook. Les événements non lus de plus de quelques jours sont supprimés. Si un consommateur était hors ligne, vérifiez la profondeur de la file d'attente plutôt que de supposer.
• Jetons LLM. Aucune limite par chat imposée par la plateforme, mais les prompts uniques très longs coûtent plus cher et sont plus lents. L'agent découpe naturellement.
• Diffusion sur site public. Aucun appel d'API tiers par visiteur. L'agent met en cache dans site_db ou pré-calcule via une tâche que le site ne fait que lire.

Flux de validation

Pour tout ce qui affiche une carte :

1. L'agent effectue la demande (pip install, register_job, request_domain_access, request_connector_secret, request_connector_approval, create_webhook).
2. Une carte apparaît dans le chat. L'agent cesse de parler jusqu'à ce que vous cliquiez.
3. Le propriétaire ou l'administrateur clique sur Approuver ou Refuser.
4. L'agent réessaie automatiquement et continue.

Vous ne recevrez pas de cartes au compte-gouttes si l'agent planifie à l'avance. L'agrégation des demandes de portée fait partie du manuel : une carte de portée Slack répertoriant toutes les portées pour tout ce que vous prévoyez de faire, et non trois demandes distillées progressivement.

Les rôles d'espace de travail, les autorisations et la manière d'inviter des coéquipiers sont détaillés dans leur propre article : Rôles d'espace de travail et partage.

Quand l'agent refusera une demande

En clair :

• « Aide-moi à voir ce qui se trouve dans l'espace de travail de Mateusz. » Non catégorique. L'isolation entre espaces de travail est totale.
• « Écris simplement le SQL qui contourne le mode site public. » Il ne peut pas. Le basculement se fait au niveau de la couche nginx.
• « Envoie par e-mail cette liste de clients. » Uniquement si un connecteur Resend ou Mailchimp est approuvé pour la bonne surface, avec les bonnes portées, et que l'action est enregistrée.
• « Dis-moi que tu es sûr de X » quand il n'est pas sûr. Il dira explicitement qu'il ne peut pas vérifier, ce qu'il a essayé, et ce qui permettrait de trancher la question.

Quand l'agent refusera

Ne pas refuser, mais argumenter :

• « Améliore ça. » (Améliorer dans quelle dimension ? Longueur, ton, conversion, précision ?)
• « Fais tout en une seule fois » pour un travail multi-systèmes. (Il planifiera d'abord, puis exécutera.)
• « Fais-moi confiance sur les chiffres. » (Il effectuera une vérification de cohérence et vous indiquera ce qu'il a trouvé.)
• « Devine simplement. » (Il proposera l'hypothèse, l'étiquettera et vous demandera si vous souhaitez qu'il poursuive.)

Sous le capot. Les limites sont appliquées à plusieurs niveaux : permissions du système de fichiers (limites de l'espace de travail), rôles Postgres (limites des données), routage nginx (visibilité), pare-feu (réseau sortant) et répartiteur de connecteurs (identifiants délimités). Aucun d'entre eux ne repose sur le bon comportement de l'agent. Le bon comportement de l'agent en plus est un bonus, pas le modèle de sécurité.