Robinhood a ouvert son API de trading aux agents IA via Model Context Protocol, le spec agent-vers-service qu'Anthropic a sorti fin 2024. Les utilisateurs créent un compte séparé avec un balance pré-chargé que les agents accèdent via MCP — analyse de risque de concentration, scan d'exposition sectorielle, lecture de notes d'analystes, exécution de trades. Le pattern architectural, c'est l'histoire pour les bâtisseurs : wallet sous-compte scoped, previews d'approbation sur certains trades, notifications temps-réel, monitoring d'activité in-app, revue de détection de fraude. La bêta limite les agents aux actions ; les options, crypto, contrats événementiels, futures, pis marchés de prédiction sont listés pour plus tard.
Le signal d'adoption MCP compte plus que la feature de trading. Dix-huit mois après que MCP soit sorti, un courtier coté publiquement dans une industrie lourdement réglementée l'utilise comme couche contrat agent-vers-service. C'est MCP qui graduate de « spec Anthropic » à standard de facto pour la connectivité agent dans les industries réglementées — une catégorie qui a été le slow adopter pour tout, de REST à OAuth. Le pattern que Robinhood implémente — sous-compte séparé, balance scoped, portes d'approbation sur les actions haut risque, logs audit — est aussi la référence architecturale correcte pour n'importe quel bâtisseur qui ship des agents qui touchent à l'argent ou d'autres états irréversibles. C'est pas « laisse l'agent utiliser le compte principal de l'utilisateur avec un flag de permission », ce qui aurait émergé d'un design moins réfléchi.
La lecture honnête côté trading spécifiquement : Robinhood a une longue histoire réglementaire autour de la gamification, l'exposition options pour traders retail, pis la controverse order-flow. Ajouter des agents IA introduit de nouveaux modes d'échec — agents promptés par des inputs adversariaux, agents qui sur-tradent dans une porte d'approbation que les utilisateurs dismiss, agents qui mal lisent le sentiment des analystes. Les mitigations (previews d'approbation, revue de fraude, isolation sous-compte) sont correctes architecturalement, mais la question empirique, c'est si elles tiennent sous le volume. Le premier flash crash piloté par agent ou la première perte d'agent coordonnée est une question « quand pas si », pis le droit de responsabilité du courtier pour ces événements n'est pas écrit. Les bâtisseurs qui shipent des agents ailleurs devraient track comment Robinhood gère le premier échec comme précédent pour la forme réglementaire à venir.
Si tu bâtis de l'infra agent lundi matin : l'implémentation Robinhood est une architecture de référence qui vaut la lecture — isolation sous-compte plus portes d'approbation plus notifications d'audit, c'est le pattern, pas « donne tes credentials principaux à l'agent ». Si tu bâtis des agents qui touchent à l'argent, des contrats, ou d'autres états irréversibles : le même pattern s'applique, MCP ou autrement. Le protocole compte moins que l'architecture de ressource scoped en dessous.