11 agents IA en production dans un fonds PE de 3 Md$

J'ai passé quatre mois comme le seul ingénieur IA forward-deployed intégré à un fonds de private equity immobilier américain gérant environ 3 Md$ d'actifs. J'y ai livré 11 agents IA en production.

Un ingénieur, onze agents, un fonds

Voici la partie que les études de cas omettent. Le nombre d'agents n'a jamais été le plus dur. Les garde-fous, si.

Je garde le fonds confidentiel, vous ne trouverez donc pas de nom ici. Ce que je peux vous montrer, c'est le problème de donnée sous-jacent, l'architecture que chaque agent partageait, les familles d'agents que j'ai construites, et la seule décision de design qui a permis à du logiciel d'approcher les comptes d'un fonds régulé.

Si vous voulez le journal de build plus court, l'étude de cas couvre la plateforme. Cet article est le pourquoi plus profond : les mêmes 11 agents, racontés à travers les décisions qui les ont maintenus en production.

Ce que forward-deployed voulait vraiment dire ici

Forward-deployed ne veut pas dire que j'étais dans un autre bâtiment à livrer un dépôt par-dessus le mur. Cela veut dire que je me suis intégré au fonds, que j'ai appris leurs vrais workflows, et que j'ai construit contre le désordre qu'ils avaient, pas contre le problème propre qu'un slide décrirait.

Un prestataire vous vend un produit et espère qu'il conviendra. Un ingénieur forward-deployed emménage dans votre problème et construit la seule chose dont votre problème a besoin. Pour un fonds enseveli sous 13 ans de documents, cette distinction était tout le travail.

Le vrai problème, c'était la donnée, pas l'IA

Avant qu'un seul agent soit utile, j'avais un problème de donnée de la taille d'une petite bibliothèque. La vérité de référence du fonds était éparpillée sur 13 sources distinctes, accumulées sur 13 ans, dans des formats qui ne s'accordaient pas entre eux.

Quand je l'ai cartographié, les chiffres étaient toute l'histoire : environ 2 To et 1,4 million de fichiers. Une personne répondant à une seule question pouvait ouvrir cinq systèmes pour trouver l'unique document qui contenait la réponse. L'intelligence n'a jamais été le goulot. La chasse, si.

La première chose que j'ai construite n'était donc pas maligne. C'était un seul magasin queryable qui transformait « où est le document qui explique ceci » d'un après-midi de fouille en une requête qui répond en quelques secondes.

L'architecture sous les 11 agents

La couche de récupération posée sur ce magasin est ce sur quoi reposaient les 11 agents : FastAPI en façade, Postgres avec pgvector qui détient les documents, et un routeur qui choisit un modèle moins cher ou plus fort selon la tâche, sous un plafond de coût strict.

Le squelette ci-dessous en donne la forme. Chaque agent pose la même question de la même manière. Récupérer la preuve d'abord, puis raisonner sur ce qui revient, jamais sur ce que le modèle a par hasard mémorisé.

# One retrieval + routing path, shared by all 11 agents.
async def answer(task: Task) -> Result:
    # 1. Retrieve evidence before reasoning (pgvector over ~2 TB of docs)
    evidence = await store.search(task.query, k=12)
    if not evidence:
        return Result.abstain(reason="no supporting document")

    # 2. Route: cheap model for simple tasks, strong model for hard ones
    model = router.pick(task, budget=caps.for_task(task))

    # 3. Reason only over retrieved evidence, then verify it
    draft = await model.run(task, context=evidence)
    return verify(draft, evidence)  # NLI + numeric checks, else abstain

Les deux lignes qui comptent sont l'appel de récupération et le routage des modèles. La récupération est ce qui garde chaque réponse ancrée dans un vrai document. Le routeur et son plafond de coût sont ce qui empêche 11 agents de faire discrètement grimper une facture que personne n'a approuvée.

Les 11 agents, par famille

Je ne vais pas vous présenter les 11 agents un par un ; le fonds est confidentiel, et de toute façon la manière utile de les voir, c'est par famille. Chaque agent faisait l'un de quelques métiers, et chaque famille portait son propre garde-fou.

La couche qui les a autorisés près des comptes

Chacune de ces familles reposait sur la même couche de sûreté. Dans un fonds régulé, une réponse fausse et confiante coûte plus cher qu'une réponse lente : c'est là qu'est passé l'essentiel de l'ingénierie.

Trois pièces mobiles. Chaque affirmation pointe vers un vrai document source, pas vers la mémoire du modèle. Chaque chiffre est contrôlé avant que quiconque agisse dessus. Et quand la preuve est mince, l'agent le dit et escalade au lieu d'inventer quelque chose de plausible.

Le tout a été évalué et red-teamé avant la mise en production.

Je détaille la conception citations-et-abstention dans son propre épisode sur un RAG autorisé à dire je ne sais pas. La version en une ligne : donner aux agents la permission de s'abstenir est exactement ce qui les a autorisés près des comptes.

Un agent décortiqué : de 8 heures à 23 minutes

Prenez l'agent dont on me parle toujours. Le rapprochement bancaire du fonds engloutissait une journée de travail entière, environ 8 heures d'une personne compétente à recouper des chiffres à la main. Avec la couche de récupération partagée en dessous, cet agent a ramené le même travail à 23 minutes, dont l'essentiel est un humain qui relit la poignée de cas incertains.

J'ai décortiqué ce seul agent du début à la fin dans son propre épisode, y compris la partie la plus importante : ce qu'il a refusé de rapprocher. C'est l'exemple le plus clair de toute la thèse de la plateforme vivant dans un seul workflow.

Ce que cela débloque, et qui devrait l'embaucher

Alors, que vous apportent vraiment 11 agents en production dans un vrai fonds ? Surtout la différence entre une liste d'articles et un vrai bilan.

Le marché est plein de cabinets qui vous enverront un slide avec 11 cas d'usage de l'IA en finance. Ce que presque aucun ne peut vous envoyer, c'est un ingénieur qui s'est intégré à un fonds régulé, a livré les agents, et peut nommer le garde-fou de chacun. Cet écart est tout l'argument.

Si vous voulez le cadre que j'utilise pour distinguer un vrai déploiement d'une démo, c'est l'échelle de preuve FDE.

Et si vous pesez si un ingénieur forward-deployed est la forme d'embauche dont votre problème a besoin, ou si vous voulez voir ce que je fais concrètement, ces pages vont plus loin que celle-ci ne le peut.

FAQ