Les agents d’Antigravity reposent sur une architecture en couches qui combine perception en temps réel, mémoire persistante et appels d’outils pour gérer des tâches complexes sans intervention humaine. Cet article détaille chaque couche, des moteurs de planification à la coordination multi-agents, et montre d’où vient réellement l’intelligence et quelle place occupe la génération d’images dans l’ensemble.
Antigravity a réalisé ce dont la plupart des entreprises d’IA ne font que parler : des agents qui terminent réellement leurs tâches. Pas des chatbots qui répondent à des questions, ni des copilotes qui attendent le prompt suivant, mais un logiciel qui établit un plan, appelle des outils, vérifie son propre résultat et mène le travail à terme. Comprendre le fonctionnement de ces agents suppose de regarder l’architecture sous-jacente, qui est bien moins mystérieuse que ne le laisse croire le marketing.
Antigravity est une entreprise d’infrastructure d’IA centrée sur les systèmes d’agents autonomes. Son produit principal est une plateforme où les développeurs déploient des agents capables de naviguer sur le web, d’écrire et d’exécuter du code, de gérer des fichiers, d’appeler des API externes et de se coordonner avec d’autres agents, le tout dans un même environnement d’exécution.
Ce qui distingue leur approche, c’est la fiabilité au niveau de la tâche, et non seulement au niveau de la réponse. La plupart des grands modèles de langage optimisent la qualité d’une sortie unique. Le système d’Antigravity est optimisé pour la qualité d’une tâche achevée, ce qui est un problème fondamentalement différent.
Passer de « répondre à un message » à « mener une tâche à terme » change tout dans la conception du système. Une interface de chat n’a qu’une boucle : une entrée, une sortie. Un système d’agents comporte de nombreuses boucles, des décisions ramifiées, des états d’erreur, des nouvelles tentatives et une coordination entre plusieurs composants spécialisés.
Antigravity conçoit ses systèmes pour cette complexité dès le départ, ce qui explique pourquoi ses agents se comportent davantage comme des systèmes logiciels que comme des chatbots.
À la base, un agent d’Antigravity est une boucle. Il reçoit un objectif, génère un plan, exécute des étapes, observe les résultats et met à jour son plan jusqu’à ce que la tâche soit terminée ou qu’il atteigne un arrêt strict. C’est le schéma classique ReAct (Reason + Act), enrichi d’une mémoire persistante, de registres d’outils et d’un routage multi-agents.
Voici la répartition des couches :
| Couche | Fonction | Composant principal |
|---|---|---|
| Perception | Reçoit les entrées, analyse le contexte | Fenêtre de contexte + embeddings |
| Planification | Découpe les objectifs en étapes | Raisonnement du LLM + scratchpad |
| Action | Appelle les outils, écrit du code | Registre d’outils + appels de fonctions |
| Mémoire | Stocke et récupère l’état | Stockages court terme + long terme |
| Observation | Évalue les sorties | Auto-critique + validation |
| Coordination | Route vers d’autres agents | Couche d’orchestration |
Chaque couche a un rôle distinct. Une défaillance dans une couche ne rompt pas nécessairement l’ensemble du pipeline, car des mécanismes de repli existent à chaque jonction.
Avant qu’un agent puisse agir, il doit comprendre ce qu’on lui demande. La couche de perception absorbe l’instruction entrante et l’enrichit avec le contexte récupéré depuis les mémoires de l’agent.
Il ne s’agit pas seulement de « lire le prompt ». La couche de perception :
Une couche de perception bien conçue évite le mode de défaillance le plus courant des agents : agir pendant 20 étapes sur une instruction mal comprise avant de remarquer l’erreur.
Une fois la tâche comprise, le moteur de planification la découpe en une séquence structurée de sous-tâches. C’est ici que la capacité de raisonnement du LLM fait le plus gros du travail.
Le planificateur fonctionne selon deux modes, selon la complexité de la tâche :
Planification séquentielle : pour les tâches simples et linéaires, l’agent génère une liste de contrôle étape par étape et exécute chaque élément dans l’ordre. Le classement de fichiers, l’extraction de données et la génération de rapports entrent tous dans ce schéma.
Planification hiérarchique : pour les objectifs complexes en plusieurs étapes, l’agent crée un plan de haut niveau puis génère des sous-plans pour chaque branche. Une tâche du type « rechercher des concurrents, construire un tableau comparatif et rédiger un e-mail de synthèse » devient un arbre de sous-tâches déléguées.
Au sein de la boucle de planification, l’agent tient un scratchpad : un monologue interne continu, distinct de la sortie finale. C’est là que l’agent élabore les étapes intermédiaires, teste sa logique et se corrige avant de s’engager dans une action.
C’est l’un des choix de conception les plus importants d’Antigravity. Sans scratchpad, l’agent est contraint de raisonner en une seule passe avant, ce qui est fragile. Avec un scratchpad, il peut réviser sa réflexion en cours d’exécution sans polluer la sortie ni brouiller les appels d’outils.
💡 Imaginez le scratchpad comme le tableau blanc d’un développeur : il est désordonné, des éléments sont barrés, mais le résultat final est propre et réfléchi.
Planifier ne sert à rien sans action. Les agents d’Antigravity agissent grâce à un registre d’outils, un catalogue structuré de fonctions appelables, avec des schémas définis, des entrées attendues et des formats de sortie.
Les outils se répartissent en plusieurs catégories :
Quand l’agent décide d’utiliser un outil, il ne se contente pas d’« appeler une fonction ». Il construit un objet d’appel d’outil avec des paramètres explicites, le valide par rapport au schéma de l’outil, l’envoie, puis analyse le résultat renvoyé avant de décider de l’étape suivante. L’ensemble du processus est journalisé et auditable.
Ces termes sont souvent confondus. L’appel de fonctions est la capacité brute : le LLM peut produire du JSON structuré qui correspond à la signature d’une fonction. L’utilisation d’outils est le système de plus haut niveau : l’infrastructure qui reçoit ce JSON, exécute réellement la fonction et renvoie le résultat dans le contexte de l’agent. Antigravity gère les deux couches.
La mémoire est ce qui distingue un agent ponctuel d’un agent qui apprend réellement de son propre historique d’exécution.
Le système de mémoire d’Antigravity comporte deux stockages distincts :
La fenêtre de contexte est la mémoire de travail de l’agent pour une exécution donnée. Tout ce que l’agent sait à un instant t, l’instruction initiale, le plan, les sorties d’outils, les notes du scratchpad, y réside pendant l’exécution.
Les fenêtres de contexte ont des limites strictes, mesurées en tokens. Gérer ce qui reste dans la fenêtre et ce qui est résumé ou déporté constitue un véritable défi d’ingénierie. Antigravity utilise une compression dynamique du contexte : le contenu ancien et de faible priorité est résumé à mesure que la fenêtre se remplit, tandis que le contenu récent et très pertinent est conservé dans son intégralité.
Entre deux exécutions, les agents doivent conserver des informations et les récupérer plus tard. Antigravity combine :
Quand une nouvelle tâche commence, la couche de perception interroge les trois stockages et injecte les contenus les plus pertinents dans la fenêtre de contexte initiale. L’agent démarre « à chaud », avec un historique utile, et non à blanc.
Après chaque appel d’outil, l’agent exécute une étape d’observation : il évalue la sortie par rapport à ce qu’il attendait. C’est là que s’effectue l’autocorrection.
La logique d’observation vérifie :
Cette boucle, Planifier, Agir, Observer, Répéter, est le cœur battant de chaque agent d’Antigravity. Le nombre d’itérations n’est pas fixe : la boucle continue jusqu’à achèvement ou jusqu’à ce qu’une limite de sécurité configurée l’arrête.
La boucle est puissante mais fragile face à certains modes de défaillance précis. Les plus courants :
💡 Les meilleurs agents savent échouer proprement. Quand le système d’Antigravity atteint un arrêt strict, il renvoie une erreur structurée avec le dernier état connu, et non un échec silencieux.
Les agents isolés ont des limites. Certaines tâches sont trop larges, trop longues ou exigent trop de capacités spécialisées pour tenir dans un même contexte d’exécution. C’est là qu’interviennent les systèmes multi-agents.
Antigravity utilise un modèle de coordination hiérarchique :
Un agent orchestrateur se situe au niveau le plus haut. Il reçoit l’objectif général, le découpe en sous-tâches et confie chacune d’elles à un sous-agent spécialisé disposant des outils et du contexte adaptés à ce travail précis.
Pour une tâche du type « auditer le SEO de notre site et rédiger une liste de corrections priorisée », l’orchestrateur répartit le travail entre :
Chaque sous-agent fonctionne de manière indépendante. L’orchestrateur recueille leurs sorties, résout les conflits et assemble le résultat final.
La coordination suppose un état partagé. Tous les agents d’une tâche accèdent à un stockage de contexte de tâche : un objet délimité qui contient l’objectif initial, l’avancement en cours, les sorties intermédiaires et les contraintes fixées par l’utilisateur.
Quand un agent termine son sous-travail, il écrit sa sortie dans le contexte partagé et signale l’orchestrateur. Les transmissions sont explicites et non implicites, ce qui signifie qu’aucune donnée ne se perd en chemin entre les agents.
L’architecture est intéressante, mais à quoi ressemble-t-elle en pratique ? Les agents d’Antigravity couvrent des tâches réelles dans plusieurs catégories :
| Type de tâche | Exemple | Agents impliqués |
|---|---|---|
| Recherche | Recueillir les prix des concurrents sur 20 sites | Explorateur + Analyste |
| Contenu | Rédiger un article de blog à partir d’un brief de mots-clés | Planificateur + Rédacteur + Éditeur |
| Travail sur les données | Nettoyer un CSV et générer des graphiques | Exécuteur de code + Mise en forme |
| Automatisation | Surveiller un site et envoyer des alertes en cas de changement | Surveillance + Notificateur |
| Création | Générer des prompts d’images et produire des visuels | Rédacteur + Agent d’image |
Le flux de travail créatif est particulièrement intéressant. Un agent qui génère des images ne rédige pas des prompts au hasard. Il raisonne sur le style, le sujet et la composition à partir d’un brief, puis appelle un outil de génération d’images avec des paramètres structurés. Le résultat est réinjecté dans le contexte, évalué par rapport au brief et affiné si nécessaire.
Quand un agent d’Antigravity prend en charge un travail créatif, il s’intègre généralement à des API de génération d’images externes. Les mêmes modèles disponibles sur PicassoIA sont ceux qui alimentent ces sorties visuelles.
Un pipeline d’agents pour le contenu visuel peut faire appel à :
L’agent choisit le bon modèle en fonction du contexte de la tâche, des contraintes budgétaires et des exigences de qualité. Il n’utilise pas toujours le modèle le plus puissant ; il utilise le bon modèle pour l’étape précise.
Ce que la plupart des gens oublient : quand un agent rédige des prompts d’images, il applique la même boucle de raisonnement que pour tout le reste. Il rédige un prompt, l’envoie au modèle d’image, reçoit l’URL de l’image, évalue le résultat par rapport au brief (parfois avec un modèle de vision pour « voir » le rendu) et affine le prompt si le résultat ne correspond pas aux attentes.
C’est de l’ingénierie de prompts en pilotage automatique, et c’est pourquoi les flux de travail d’agents IA produisent des résultats créatifs systématiquement meilleurs qu’un prompt manuel unique.
💡 L’agent ne se contente pas d’écrire des prompts. Il les teste, observe les résultats et les améliore dans une boucle structurée, exactement comme le ferait un ingénieur de prompts expérimenté, mais sans l’itération manuelle.
Aucune plateforme d’agents sérieuse n’est livrée sans contrôles. Antigravity en met en place plusieurs :
Cela rend le système d’Antigravity adapté aux environnements de production où la responsabilité compte, et pas seulement aux démonstrations de recherche.
Ce que montre l’architecture d’Antigravity, c’est que les systèmes d’IA les plus puissants ne sont pas des modèles isolés. Ce sont des pipelines de capacités spécialisées, chacune faisant une chose bien, coordonnées par une couche de raisonnement qui sait quand appeler quoi.
Les modèles d’images de PicassoIA fonctionnent selon le même principe. PicassoIA Image, Flux Redux Dev et GPT Image 1 sont des outils conçus pour une tâche précise qui, entre les mains de quelqu’un qui les guide avec intention et structure, produisent des résultats rivalisant avec la photographie et l’illustration professionnelles.
Vous n’avez pas besoin d’un système d’agents pour profiter de cette démarche. Commencez par un brief clair, choisissez le modèle adapté à votre type de sortie et itérez sur vos prompts avec l’état d’esprit d’observation qu’Antigravity intègre à son architecture. Les principes qui rendent les agents IA efficaces, une réflexion structurée, les bons outils et une boucle de rétroaction, rendent aussi la génération d’images IA individuelle efficace.
Essayez dès maintenant sur PicassoIA et voyez ce qu’un prompt bien structuré produit dès la première exécution.
Choisissez votre langue
