// the find
Atmosphere/atmosphere
Real-time transport layer for Java AI agents. Build once with @Agent — deliver over WebSocket, SSE, gRPC, and WebTransport/HTTP3. Talk MCP, A2A and AG-UI.
Atmosphere is a JVM framework that wraps AI agent dispatch behind a single @Agent annotation and auto-registers WebSocket, SSE, MCP, A2A, and AG-UI endpoints based on what modules are on your classpath. It is the original Java push/WebSocket library from 2008 that has pivoted into an AI agent runtime, bringing its battle-tested transport layer with it. Aimed at Java teams that need governed, stateful, multi-channel agents inside an existing Spring Boot or Quarkus stack.
- The classpath-driven endpoint registration is clean: drop atmosphere-mcp on the classpath and your existing @Agent class gets an MCP endpoint at a predictable path with no code changes — the module boundary is the configuration unit.
- Governance is on the critical path, not bolted on: policy admission, @AgentScope scope enforcement, PII redaction, and cost ceilings all run before the LLM call. The plan-and-verify module with an SMT backend (SMTInterpol, Z3 optional) is unusually rigorous for an agent framework.
- The capability matrix is pinned by AbstractAgentRuntimeContractTest.expectedCapabilities() — a runtime adapter cannot silently claim a capability it doesn't implement without breaking CI. Most frameworks ship a README table that no test enforces.
- The durable HITL approval model hibernates without holding a thread, persists workflow state, and resumes via a REST endpoint. That's the right design for long-running human-gated workflows, not a blocking Future.
- The module count is a real tax: 30+ Maven artifacts, two Spring Boot version tracks (-Pspring-boot3 for 3.5, default for 4.0), and a 'bundle' artifact that exists specifically because the modularity makes it hard to assemble a working app. Getting the dependency graph right before you've written any agent code is friction.
- Spring Boot 4.0 as the default target is aggressive — it shipped recently and most production Java shops are still on 3.x. The 3.5 path via atmosphere-spring-boot3-starter is supported but Embabel and Spring AI Alibaba explicitly require it, signaling it's second-class.
- The CrewAI adapter quietly breaks the 'JVM framework' story: it's a Java HTTP+SSE bridge to a Python sidecar, gated by a live /health probe. If you adopt that path you've added a Python process dependency to your JVM deployment.
- The README is dense with feature tables but thin on failure modes. There's no discussion of what happens when the CheckpointStore is unavailable, how the broadcast pipeline degrades under backpressure, or what the actual latency cost of the SMT verifier path is — all questions an adopter needs answered before committing.