10 Patterns d’Architecture pour des AI Agents en Production

Stripe a récemment publié deux articles décrivant Minions, leurs coding agents autonomes internes.

• Minions: Stripe’s one-shot, end-to-end coding agents
• Minions: Stripe’s one-shot, end-to-end coding agents—Part 2

Au-delà du retour d’expérience, ces articles révèlent surtout une série de patterns d’architecture pour construire des AI agents fiables en production.

Voici les principaux patterns qui émergent du design de Stripe.

1. Considérer l’attention des développeurs comme une ressource rare

L’objectif des coding agents n’est pas de remplacer les ingénieurs, mais de libérer leur attention.

Les agents prennent en charge des tâches redondantes mais simples :

• correction de flaky tests
• petits refactors
• mises à jour de dépendances
• corrections mineures de bugs

Les ingénieurs peuvent ainsi se concentrer sur des problèmes à plus forte valeur.

Idée clé : engineer attention > compute > tokens

Les agents transforment du compute peu coûteux en temps d’attention humaine.

2. Construire les agents à partir de l’infrastructure développeur existante

Stripe n’a pas construit une plateforme AI séparée.

Les Minions réutilisent les outils existants :

• devboxes
• pipelines CI
• linters
• Sourcegraph
• documentation interne
• issue trackers

Principe : si les outils fonctionnent pour les ingénieurs, ils doivent fonctionner pour les agents.

3. Isoler les environnements d’exécution (Agent Sandboxes)

Les agents autonomes doivent s’exécuter dans des environnements totalement isolés.

Stripe utilise des devboxes avec :

• aucun accès à la production
• aucune donnée utilisateur
• accès réseau restreint

Idée clé : autonomy requires sandboxing

L’isolation permet une autonomie élevée sans risque majeur.

4. Préparer les environnements d’exécution

Les agents doivent démarrer rapidement.

Stripe maintient des devboxes pre-warmed où :

• le repository est déjà cloné
• les caches sont prêts
• les outils de build sont chargés

Temps de démarrage : ~10 secondes.

Pattern : pre-warmed environments

Ce modèle est similaire aux infrastructures serverless ou CI.

5. Combiner raisonnement LLM et étapes déterministes

Les LLM sont puissants mais imprévisibles.

Stripe encapsule le raisonnement LLM dans des étapes système déterministes.

Exemple :

LLM reasoning
↓
deterministic step (git commit)
↓
LLM reasoning
↓
deterministic step (run CI)

Avantages :

• meilleure fiabilité
• moins de tokens
• moins d’erreurs agent

Le LLM décide quoi faire, le système contrôle comment l’exécuter.

6. Utiliser des state machines pour les agents (Blueprints)

Stripe orchestre les tâches avec des Blueprints.

Les Blueprints sont des state machines pour agents.

Exemple :

Implement task
↓
Run linters
↓
Push changes
↓
Run CI
↓
Fix failures

Certaines étapes utilisent le raisonnement LLM, d’autres sont déterministes.

Cela limite l’imprévisibilité des agents.

7. “Hydrater” le contexte avant de lancer l’agent

Les agents fonctionnent mieux lorsque le contexte est préparé à l’avance.

Stripe construit ce contexte de manière déterministe.

Exemple :

Slack message
↓
extract links
↓
fetch tickets
↓
load documentation
↓
build structured context
↓
start agent

Cela améliore fortement le taux de succès one-shot.

8. Limiter le contexte localement

Les grandes codebases ne peuvent pas reposer sur un seul prompt massif.

Stripe utilise des file-scoped rules activées selon le dossier concerné.

Exemple :

/payments/*       → rules: payments conventions
/infrastructure/* → rules: infra conventions

Cela maintient des prompts ciblés et pertinents.

9. Centraliser et restreindre les capacités des agents (Toolshed)

Donner trop d’outils aux agents réduit leur fiabilité. La solution de Stripe repose sur deux volets.

D’abord, ils ont construit Toolshed : un serveur MCP unique et centralisé qui sert d’interface unifiée à toutes les capacités internes — documentation, Sourcegraph, statuts de build, tickets Jira, et plus encore — regroupant près de 500 outils en un seul endroit.

Ensuite, plutôt que d’exposer l’intégralité de Toolshed à chaque agent, chaque minion reçoit un sous-ensemble délibérément restreint de ces outils.

Principe : interface unifiée + espace d’action réduit → meilleures décisions

Centraliser les capacités les rend maintenables ; les restreindre par agent assure de meilleures performances.

10. Concevoir des boucles de feedback rapides — shift left

Les agents ont besoin de feedback rapide et automatisé, et ce feedback doit arriver le plus tôt possible dans le processus.

Stripe utilise plusieurs niveaux, ordonnés par vitesse :

1. Lint local pre-push (<5s) : avant tout run CI, un hook local exécute des linters instantanément, retournant les erreurs directement à l’agent et économisant à la fois des tokens et du compute CI
2. Suite de tests CI : des millions de tests s’exécutent après un push, avec des autofixes appliqués automatiquement si disponibles
3. Une seule tentative supplémentaire : si des échecs non corrigeables subsistent, l’agent a exactement une dernière tentative locale avant que la branche soit rendue à un humain

Principe : détecter les erreurs à l’étape la moins coûteuse possible

Les itérations sont volontairement limitées à deux CI runs maximum pour éviter des coûts compute excessifs, des boucles infinies et du gaspillage de tokens.

Conclusion

L’innovation principale réside dans la discipline d’ingénierie autour des AI agents, pas dans le modèle lui-même.