De l'Alpha à l'Action : Comment AISDK5 nous a aidés à construire un CRM natif de l'IA

Jack et Nikita se présentent en tant que créateurs de Lightfield, un CRM natif IA, et expliquent les limites fondamentales des systèmes CRM traditionnels. Ils décrivent le problème récurrent : à mesure qu'une équipe grandit et que le nombre de clients augmente, l'information se disperse entre Slack, email, Google Docs et enregistrements Zoom non transcrits. Les CRM conventionnels, construits il y a des décennies sur l'hypothèse d'une saisie manuelle par les humains, imposent des schémas rigides et ne capturent pas la véritable nuance des conversations. Finalement, le CRM devient simplement un outil de rapport pour les VP ventes plutôt qu'un système qui aide réellement à vendre. Ce problème fondamental a motivé la création d'une meilleure approche.

Lightfield repense complètement ce qu'un CRM devrait être en tant que système de mémoire et d'action pour les startups. Le produit offre trois capacités clés : la capture automatique de toutes les conversations, réunions et emails sans saisie manuelle, une mémoire sans perte avec support des listes de schémas personnalisables, et la transformation de cette mémoire en actions via des agents IA. Contrairement aux CRM traditionnels destinés uniquement aux équipes commerciales, Lightfield bénéficie à toute personne ayant besoin de mémoriser et d'agir sur le contexte client, y compris les équipes de succès client qui identifient des modèles dans les conversations de support. Un exemple concret montre un agent capable de trouver cinq affaires stagnantes et de rédiger des emails personnalisés pour chacune, que l'utilisateur peut ensuite envoyer ou modifier.

L'architecture de Lightfield repose sur trois interfaces différentes (interface utilisateur, agents en langage naturel, et tâches de workflow) qui interagissent toutes via la même couche unifiée d'objets de domaine. Le principe fondamental est la parité agent-UI : si un utilisateur peut y accéder, un agent peut y accéder avec les mêmes permissions, visibilité et opérations complètes de lecture, création et mise à jour. Cette approche est un choix de produit et architectural dès le premier jour, car elle distingue la construction native IA depuis le départ de l'ajout d'agents aux systèmes hérités. Les agents ne fonctionnent pas via une API séparé avec des règles différentes, mais agissent en représentation de l'utilisateur via la même couche de données qui alimente l'interface utilisateur, créant des interfaces différentes pour les mêmes données.

Jack explique que lors de la construction de produits IA en 2025, il n'existe pas de manuel complet, d'où la nécessité d'optimiser la vitesse d'apprentissage plutôt que la perfection. Lightfield lui-même teste ce concept : quand l'équipe d'ingénierie doit comprendre un problème client, elle peut simplement le demander en langage naturel plutôt que de naviguer dans le CRM. L'équipe cite la sagesse de Sandy Metz : 'La duplication est beaucoup moins chère que la mauvaise abstraction', ce qui s'applique particulièrement à la construction de produits IA aujourd'hui où le développement est extrêmement rapide. L'approche se concentre sur la construction de fonctionnalités et la résolution de vrais problèmes au lieu de lutter contre les frameworks ou de sur-ingéniérer des abstractions prématurées. L'AI SDK a fourni la flexibilité nécessaire pour itérer sans tout réécrire à chaque étape.

L'équipe Lightfield a commencé à développer avec l'AI SDK en janvier, l'utilisant d'abord pour la commutation de modèles et les primitives stream text, ce qui leur a permis d'expédier rapidement des tâches aux agents spécifiques en quelques semaines. Ils ont progressivement construit plus d'agents et de fonctionnalités de chat, puis en juin 2025 ont adopté l'API useChat spécifiquement pour les options de transport personnalisé. La transition de V4 à V5 alpha s'est déroulée relativement facilement avec une avance rapide, le framework croissant avec leur produit au lieu de les forcer à réécrire ou à ralentir. Une anecdote amusante révèle qu'ils identifient souvent une fonction dont ils ont besoin le lendemain d'avoir vu un tweet de l'équipe AI SDK annonçant exactement cette fonctionnalité, montrant une alignement remarquable. Cet exemple illustre comment un bon framework doit croître avec les besoins des utilisateurs plutôt que de les contraindre.

Nikita présente la fonctionnalité d'Adaptive Context Building, une innovation clé qui démontre comment utiliser l'AI SDK pour construire des systèmes intelligents. Lorsqu'un utilisateur pose une question comme 'Qu'a mentionné Jordan Lee lors de notre dernier appel ?', le système détermine intelligemment le contexte pertinent sans que l'utilisateur ne doive spécifier le compte exact ou la réunion spécifique. L'API Data Parts du SDK permet de fournir des signaux du client au serveur qui construit le contexte, les entités et signaux variables côté client étant complètement hydratés côté serveur. Concernant l'injection de fichiers dans le fil de chat, plutôt que d'envoyer directement des fichiers encodés ou des URLs S3 publiques, le client envoie un ID interne référençant le fichier, le backend remplaçant ces identifiants par des URLs S3 signées avec délai d'expiration. Cette approche sécurise les données en empêchant l'accès non autorisé et la divulgation accidentelle de données privées au public.

Lightfield construit dynamiquement un ensemble d'outils spécifique à chaque utilisateur, injectant les dépendances et ID utilisateur directement dans les outils eux-mêmes. Cela signifie que le LLM n'émet jamais directement des requêtes à la base de données ; tout transite par la même couche de données unifiée que l'utilisateur accèderait via l'interface CRM. Pour les workflows high-stakes comme la création d'entités CRM, l'équipe a implémenté des workflows human-in-the-loop en utilisant les abstractions du SDK. Quand le LLM émet un appel d'outil requérant confirmation, cet appel est transféré au client qui affiche une interface. L'utilisateur peut modifier les valeurs suggérées et approuver ou rejeter chaque élément, puis les valeurs modifiées et l'approbation/rejection sont envoyées au backend pour exécution. Avant que le résultat soit renvoyé au LLM, le système ajoute les résultats d'exécution (succès ou erreurs), donnant au LLM une visibilité complète de l'historique d'interaction pour suggérer les prochaines étapes appropriées.

Un principe de conception clé de Lightfield est de permettre aux utilisateurs et agents de mouler le CRM selon leurs besoins spécifiques, reconnaissant que chaque entreprise a des aspects et processus de vente uniques. À l'intérieur de Lightfield, les utilisateurs peuvent construire des modèles de données personnalisés pour chaque entité CRM ; par exemple, une startup de productivité B2B pourrait suivre la pile technologique du client, la taille de l'équipe d'ingénierie et les investisseurs mutuels. Les utilisateurs spécifient ces champs typés et comment les agents doivent les utiliser dans leurs processus, fournissant des instructions supplémentaires sur les significations et les applications. Au niveau backend, le système crée les outils au runtime avec des schémas basés sur la configuration de l'entreprise, le schéma de l'outil réel étant dérivé de la base de données, et les valeurs suggérées par le LLM étant validées pour correspondre aux types. Cette approche permet aux agents de remplir rétroactivement les champs en recherchant sur le web ou en fouillant les enregistrements CRM existants incluant transcriptions et emails.

Lightfield offre une section de connaissance configurable où les utilisateurs fournissent au LLM un contexte supplémentaire sur leur entreprise, y compris les informations sur les produits et les instructions pour l'exécution des workflows en arrière-plan. Un exemple clé est la préparation automatique de réunions : avant chaque réunion, Lightfield génère un document de préparation listant les participants clés avec des informations à leur sujet, les détails du compte avec lequel l'utilisateur se réunit, et les points de discussion clés importants. Après la réunion, le système suggère des éléments d'action de suivi et des mises à jour de champ basées sur les discussions. Ces capacités fondamentales se combinent pour débloquer la génération d'emails haute qualité : après une réunion, Lightfield accède au Google Calendar pour suggérer des créneaux de suivi appropriés basés sur les discussions précédentes. Ces emails préliminaires restent soumis à l'approbation explicite de l'utilisateur, garantissant que l'agent ne prendra jamais d'action sans consentement, et les notifications aident les utilisateurs à rester à jour sur chaque affaire.

Jack conclut en résumant les quatre principes fondamentaux découverts en construisant Lightfield : (1) Parité sécurisée agent-UI dès le premier jour, où les agents ont accès complet en lecture-écriture par la même couche de données que les humains sans API séparé qui deviendrait un fardeau de maintenance ; (2) Itération rapide plutôt qu'abstraction parfaite, optimisant la vitesse d'apprentissage au début plutôt que la perfection à l'avance, reconnaissant que la duplication est moins chère que la mauvaise abstraction ; (3) Workflows human-in-the-loop où les gens restent en contrôle, spécialement pour les interactions à enjeux élevés, avec transparence complète et historique complet pour gagner la confiance ; (4) Systèmes programmables par utilisateurs et agents où les vrais clients ont besoin de modèles de données personnalisés, et le produit se façonne sur la structure des données des clients plutôt que l'inverse. L'équipe invite les auditeurs à partager leurs propres découvertes et visitent lightfield.app pour voir ces principes en action.