Atmosphere : un @Agent Java qui survit au changement de framework LLM

Le problème réel : réécrire l'endpoint à chaque changement de framework

Le README annonce la cible sans détour : des équipes qui veulent qu'un agent se comporte comme un service de production, avec du streaming sur de vrais transports, une vérification avant chaque appel d'outil, et une portabilité entre frameworks IA sans réécrire l'endpoint. C'est le point de douleur concret. Une équipe qui démarre sur Spring AI puis bascule vers LangChain4j, Anthropic ou l'un des neuf autres runtimes cités ne devrait pas avoir à redéfinir sa couche de diffusion ni ses points d'observation. Atmosphere place cette couche dans le framework et non dans l'application.

Le périmètre est explicite dans la section Scope. Atmosphere se décrit comme un framework événementiel temps réel, pas comme une plateforme d'hébergement d'agents. L'hôte (Tomcat, Jetty, Netty, Undertow, Quarkus, Spring Boot, ou n'importe quel conteneur de servlets) reste propriétaire du calcul et de l'ordonnancement. Les rails de paiement et les primitives de commerce sont hors périmètre. Cette délimitation compte : elle signifie que vous n'achetez pas une plateforme, vous achetez une couche de diffusion et de gouvernance.

Une SPI, douze adaptateurs, et des capability flags testés par contrat

Le mécanisme central tient dans atmosphere-ai et son interface AgentRuntime. Le README mentionne douze adaptateurs de runtime, chacun exposant des capability flags vérifiés par contrat. C'est le détail qui décide de l'adoption : une SPI seule ne suffit pas si les runtimes ne se comportent pas pareil. Les flags indiquent ce qu'un adaptateur donné sait faire, et le fait qu'ils soient contract-tested déplace la vérification du côté du projet plutôt que du côté de l'appelant.

Au-dessus, l'orchestration passe par @Coordinator, AgentFleet, des handoffs et du routage conditionnel, avec un journal de coordination événementiel qui porte une lignée causale. Les workflows durables s'appuient sur CheckpointStore, avec une variante Temporal si atmosphere-checkpoint-temporal est ajouté au classpath. La mémoire se répartit en deux objets distincts : AiConversationMemory pour l'historique par conversation, LongTermMemory pour les faits par utilisateur, en mémoire ou persistés via atmosphere-durable-sessions-sqlite ou atmosphere-durable-sessions-redis. SemanticRecallInterceptor permet de brancher son propre magasin vectoriel. Le README précise que la gestion des vector stores est laissée à votre pile : Spring AI VectorStore, embeddings LangChain4j, ou le vôtre.

Le flux : du runtime LLM au client, à travers un broadcaster filtrable

Le trajet décrit par le README est linéaire. Les tokens partent du runtime LLM, traversent un broadcaster que l'on peut filtrer, portillonner et observer, puis sortent vers le client. Les transports toujours actifs par défaut sont WebSocket, SSE et le long-polling, avec gRPC dans le même pipeline. WebTransport sur HTTP/3 est optionnel et exige jetty-http3-server ou reactor-netty-http sur le classpath, plus un certificat de développement. Ce dernier point est une contrainte d'exploitation, pas un détail : sans ces deux éléments, la voie HTTP/3 n'existe pas.

Côté sortie, la même surface couvre MCP, A2A et AG-UI, avec des modules de canaux pour Slack, Telegram, Discord, WhatsApp et Messenger. Le README indique pour MCP une RC sans état sur la spécification 2026-07-28, avec des sessions remontant jusqu'à 2024-11-05. Les clients sont atmosphere.js (React, Vue, Svelte, React Native, TypeScript vanilla) et wasync pour la JVM. La reprise après reconnexion et l'autorisation sont annoncées comme prises en charge par le framework, ce qui est précisément l'endroit où une implémentation maison coûte cher.

Mise en route : CLI, templates et bascule d'adaptateur

L'installation passe par un tap Homebrew ou par un script. Le README donne les deux commandes : brew install Atmosphere/tap/atmosphere, ou curl -fsSL https://raw.githubusercontent.com/Atmosphere/atmosphere/main/cli/install.sh | sh. Ensuite, atmosphere run spring-boot-multi-agent-startup-team lance un exemple complet sans écrire de code.

Pour créer une application, atmosphere new my-agent --template ai-chat génère le squelette, puis LLM_API_KEY=your-key ./mvnw spring-boot:run démarre le projet. La bascule d'adaptateur se fait au moment du scaffolding : le README indique que l'adaptateur intégré est celui par défaut, et que --runtime spring-ai génère l'application contre l'adaptateur Spring AI, un overlay de la CLI injectant la dépendance Maven correspondante. Le README est tronqué à cet endroit précis, donc la liste exhaustive des valeurs acceptées par --runtime n'est pas vérifiable dans le matériel fourni. Il faut se référer à la documentation du projet pour les dix autres adaptateurs.

Gouvernance sur le chemin critique : ce que cela implique vraiment

Le README liste l'admission par politique, @AgentScope, l'approbation humaine, le plan-and-verify, les plafonds de coût, la réécriture PII et les interrupteurs d'administration. Le HITL est décrit comme durable : les approbations hibernent sans retenir un thread, l'état du workflow est persisté, et la reprise passe par des surfaces REST d'approbation. Pour un agent multi-canaux avec validation humaine, c'est le bloc qui justifie l'adoption.

Il faut lire ce bloc comme un coût autant qu'une fonctionnalité. Une vérification avant chaque appel d'outil s'exécute sur le chemin critique : chaque appel d'outil traverse l'admission. Le projet assume ce choix, et c'est cohérent avec sa cible, mais il faut le mesurer contre votre propre latence tolérée avant de généraliser. Le README positionne explicitement la combinaison streaming, JVM et gouvernance comme le différenciateur, et reconnaît en face que pour des agents sans état, intermittents et censés hiberner au repos, une plateforme serverless est généralement plus adaptée.

Session tape et sandbox : les deux briques à examiner séparément

La session tape est optionnelle et enregistre les événements IA aux frontières de session, avec une persistance SQLite. Le README indique qu'elle permet de reconstruire un run ou un arbre de coordination sans appel au modèle, puis d'en distiller un modèle plus petit. C'est une fonctionnalité de débogage et de réduction de coût, pas de production temps réel, et son activation doit être décidée en connaissance de cause puisque le contenu des sessions est alors écrit sur disque.

L'exécution de code passe par atmosphere-sandbox, une SPI SandboxProvider avec DockerSandboxProvider comme implémentation par défaut. L'automatisation navigateur et Chromium headless sont hors périmètre. Une équipe qui attend d'Atmosphere qu'il pilote un navigateur se trompe de brique. De même, le déclenchement horaire n'est pas fourni : le README range le cron et l'ordonnancement wall-clock du côté de votre planificateur de conteneur ou d'un ordonnanceur dédié. Atmosphere exécute des étapes durables, il ne réveille pas un workflow à une heure donnée.

Alternatives et coût de maintenance

L'alternative la plus directement nommée par le README est la plateforme d'agents serverless, illustrée par Cloudflare Agents, AWS Bedrock Agents et Vertex AI Agents. La différence d'approche est structurelle. Ces plateformes hébergent le calcul et le scheduling, ce qui convient aux agents sans état qui hibernent entre deux invocations. Atmosphere laisse l'hôte posséder le calcul et se concentre sur les sessions longues et stateful, la diffusion temps réel et l'admission par politique. Si votre agent doit s'endormir quand personne ne l'appelle, la plateforme serverless est le bon outil, et le README le dit.

Sur la maintenance, le rythme de publication est soutenu : trois versions en septembre 2026, dont 4.0.70 le 1er septembre et 4.0.68 le 23 août. Une cadence de ce type implique de suivre les capability flags et les changements de contrat entre adaptateurs, pas seulement les correctifs. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification ; les implications exactes pour votre organisation relèvent de votre juriste, pas de cet article. Le journal de coordination et la session tape introduisent par ailleurs des artefacts persistés dont la rétention et la localisation restent à trancher au niveau de l'application.

Conclusion éditoriale

Atmosphere convient aux équipes qui ont déjà une application JVM et qui doivent garder un agent en session longue, avec approbation humaine et politiques d'admission branchées sur le flux. Il ne convient pas aux agents sans état et intermittents : le README indique lui-même qu'une plateforme serverless est alors un meilleur choix, et le projet ne fournit ni ordonnancement horaire ni hébergement de modèles. Avant d'adopter, vérifiez deux choses concrètes : que l'adaptateur de runtime visé expose bien les capability flags dont dépend votre code, et que le mode de persistance retenu (SQLite, Redis ou Temporal via atmosphere-checkpoint-temporal) correspond à votre contrainte de reprise après incident.

Sources officielles

1. Atmosphere/atmosphere on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases