Stripe a construit minions, un système d'agents maison qui fusionne plus de 1 300 pull requests chaque semaine sans aucun code écrit par un humain. Le Pinecone de Sierra ouvre 70 % de leurs PRs. Les articles sont excellents. Si vous ne les avez pas lus, vous devriez. Si vous les avez lus, vous vous êtes probablement demandé si vous deviez construire le vôtre.
Pour la plupart des équipes, je pense que la réponse est non. Pas parce que Stripe et Sierra se sont trompés. Ils ont été les premiers sur ces idées et ils ont les équipes pour y parvenir. Mais vous pouvez désormais acheter (presque) tout ce qu'ils ont dû construire. La plupart des organisations devraient optimiser autre chose : la rapidité vers la valeur. Je travaille chez Cursor, donc j'ai mes propres biais, mais voici mes raisons :
1. La partie différenciée est de toute façon portable
La partie d'un système d'agents cloud qui le rend vraiment à vous, c'est la couche de contexte. Des règles qui encodent vos conventions. Des compétences pour codifier des instructions réutilisables. L'accès MCP à vos systèmes internes. Des workflows pour vérifier ce que les agents ont écrit. Quand les minions de Stripe lisent les mêmes fichiers de règles que leurs ingénieurs écrivent pour Cursor et Claude Code, et qu'ils tirent le contexte des mêmes outils MCP internes, c'est le contexte qui fait le travail.
Voici le truc avec cette couche : c'est la partie la plus différenciée du système, et c'est aussi la plus portable. Un fichier de règles, une compétence et une configuration MCP fonctionnent de la même manière partout, et aucun d'eux ne vous lie à un fournisseur. Stripe l'a prouvé en standardisant sur le format de règles de Cursor, de sorte qu'un seul ensemble de règles guide leurs minions, Cursor et Claude Code. Donc la peur habituelle, « si nous achetons la plateforme, nous abandonnons notre différenciation », n'est tout simplement pas un problème. Vous gardez la partie différenciée quoi qu'il arrive. Acheter signifie que vous sautez tout ce qui se trouve en dessous.
2. La construction est bien plus grande qu'il n'y paraît
Faire tourner un agent dans une VM ? C'est un week-end. Atteindre une fiabilité à quatre neuf et des démarrages d'environnement en moins de 10 secondes ? C'est un projet d'infrastructure de plusieurs trimestres. Nous construisons des agents cloud chez Cursor depuis 18 mois et nous croyons que ce sera un domaine d'investissement indéfini.
Il y a aussi un problème de polissage. Même une construction interne fonctionnelle reçoit rarement l'attention aux détails qui fait que les gens l'utilisent réellement. Un outil interne qui est 80 % aussi bon obtient 20 % de l'utilisation. La plupart des équipes livrent un bot Slack et s'arrêtent là, car intégrer le même agent dans l'IDE, la CLI, le web, le mobile, Jira, etc., c'est beaucoup trop de surface. Et puis il y a la gouvernance : gestion des utilisateurs, analyse des tokens, contrôles budgétaires, pistes d'audit. Tout cela est obligatoire, rien n'est différenciant.
La responsabilité est un autre coût qui n'entre jamais dans l'estimation de construction. Les agents font des choses. Finalement, l'un d'eux fait la mauvaise chose. Quand cela arrive, tout le monde regarde l'équipe qui a construit le système, et maintenant cette équipe possède l'incident, le post-mortem et la remédiation. Acheter ne rend pas les incidents impossibles, mais cela met un fournisseur avec une équipe de sécurité en première ligne à vos côtés.
3. L'état de l'art ne reste pas en place
Tous les mois environ, une équipe avant-gardiste invente une meilleure façon d'automatiser le SDLC, et tout ce que vous avez construit il y a trois mois semble dépassé. Les modèles de code finement ajustés ont été dépassés par la prochaine version de pointe. Les piles RAG que tout le monde a construites ont perdu face au long contexte et à la recherche agentique. Les intégrations personnalisées sont devenues des configurations MCP du jour au lendemain. Même Sierra a commencé avec des agents parallèles dans des arbres de travail git et les a dépassés en quelques mois.
À l'échelle de Cursor, nous pouvons tirer parti de ce remue-ménage. Nous sommes heureux de reconstruire parce que le coût est réparti sur des milliers de clients, et le calcul reste valable. La même échelle permet d'obtenir des contrats cloud négociés et un bin packing multi-tenant qu'aucun déploiement interne ne peut égaler. Pour une équipe de devex interne, le même remue-ménage est une taxe. Chaque réinvention atterrit sur une feuille de route déjà pleine de clients internes. Vous ne voulez pas être sur le tapis roulant permanent de la R&D. Vous voulez un partenaire à grande échelle qui le fait pour vous.
4. Acheter ne signifie pas abandonner le contrôle
La dernière objection est le contrôle. La plupart des décisions de construction sont en réalité des peurs de verrouillage déguisées, alors soyez précis sur les endroits où vous avez réellement besoin d'options. Les modèles sont l'évidence : les dépenses en tokens deviennent une véritable ligne budgétaire, et la frontière de Pareto entre capacité et coût évolue toutes les quelques semaines. Avec une plateforme neutre en matière de modèles, vous aurez toujours accès au meilleur, quel que soit le leader de la course cette semaine.
L'autre est la couche d'exécution des agents. Exécutez-la comme vous le souhaitez, de totalement hébergée par Cursor à totalement auto-hébergée dans votre propre réseau, où les agents peuvent atteindre les endpoints internes et l'infrastructure de test comme n'importe quel compte de service. Votre posture de sécurité devient un choix de déploiement, pas une raison de construire.
Quand construire a du sens
Il y a quelques éléments qui font pencher la balance vers la construction. Plus vous vous reconnaissez dans ces éléments, plus le cas est solide.
Votre produit est l'infrastructure d'agents. Sierra vend des agents d'IA pour vivre. Construire des systèmes d'agents est dans leur ADN et dogfoodé par quelques centaines d'employés chaque jour. Ils ont certainement l'expertise pour construire un système d'agents de codage également.
Vous possédez déjà les parties difficiles. Stripe a exécuté minions sur des devboxes qu'ils ont passé une décennie à perfectionner. Pour eux, construire un système d'agents autour de ces devboxes est probablement moins de travail que de les plier pour s'adapter à la forme d'un produit standard. Si votre infrastructure de développement est aussi mature et aussi sur mesure, le calcul peut basculer de la même manière pour vous.
Vous le financerez comme un produit, indéfiniment. Une équipe dédiée avec une feuille de route, une astreinte, et un budget qui survit aux réorganisations. Même alors, ne partez pas de zéro : des blocs de construction comme le SDK Cursor vous offrent un harnais d'agents agnostique en matière de modèle, prêt à l'emploi, de sorte que l'effort de votre équipe va dans les parties qui vous sont uniques.
Crédit là où il est dû
J'ai un immense respect pour Stripe, Sierra et les autres équipes qui repoussent les limites de l'ingénierie agentique. Leurs équipes d'ingénieurs sont sans égales. Mais la plupart des organisations n'ont pas besoin de suivre leurs traces. Elles ont besoin de rapidité vers la valeur et d'un partenaire dont le seul travail est de rester à la pointe pour elles. Pour presque tout le monde, cela vaut plus qu'une personnalisation complète.
Devenez AI-natif dès que possible. Ensuite, décidez quelles pièces ramener en interne, une par une.
