Atmosphere Real-Time JVM Agent Engine
A JVM framework for streaming, governing, and exposing AI agents over real-time transports and agent protocols.
Per-dimension scores and reasoning
Evidence shows governance features (e.g., @AgentScope, approvals, policies), but no specific implementation details for least privilege defaults. User confirmation exists (command confirmations, tool approvals), but default enablement unclear. Data flow transparency limited; no detailed data flow documentation. Sensitive data handling has PII redaction but not deep. Dependency security has supply-chain hardening (GPG verify) but no vulnerability scanning evidence. External effects have sandbox and approvals but not comprehensive. Rollback has checkpoints and replay but no explicit rollback mechanism. Source attribution has Apache license but publisher unverified.
Self-consistency good; README aligns with code structure but not deeply verified. Dependency availability has Maven Central and npm but no dependency lock details. Failure messages have error handling tests but not comprehensive.
Audience clear (JVM teams), scenarios diverse (streaming, governance, multi-channel). Capability boundaries clear (framework not platform). Trigger precision has @Command and @Prompt but no detailed trigger conditions. Environment fit has Spring Boot, Quarkus, etc. but not comprehensive.
Information architecture clear, modules well-defined. Install notes detailed (Maven, npm, CLI). Naming stability not explicit. Examples abundant (multiple samples). Known limitations mentioned (e.g., some adapters lack audio) but not comprehensive. License Apache-2.0. Versioning changelog not provided. Maintenance responsibility has SECURITY.md and CI but publisher unverified.
Output usability has client libraries and examples. Marginal value high (multi-protocol, governance). Cost-benefit no specific data.
Claim traceability has doc links but no specific evidence. Cross-source corroboration has CI badges but not independently verified. Fact-inference separation not explicit.
- Publisher identity unverified; assess supply chain risks carefully.
- Dependency security lacks vulnerability scanning evidence; check dependency versions and known vulnerabilities.
- Data flow transparency and sensitive data handling details insufficient; further review needed.
- Rollback mechanism unclear; verify checkpoints and replay meet rollback needs.
What does this agent do, and when should you use it?
Atmosphere is a real-time, event-driven JVM framework for running AI agents as application services. Developers declare an agent with @Agent and add classpath modules to expose browser endpoints, MCP, A2A, AG-UI, or messaging channels. Its atmosphere-ai module uses the AgentRuntime SPI to connect a built-in OpenAI-compatible runtime and multiple external runtime adapters, while retaining the native framework's model, tool, and memory facilities. Tokens and events move through a broadcaster pipeline over WebSocket, SSE, long-polling, or gRPC; WebTransport over HTTP/3 is optional and has additional classpath and development-certificate requirements. The repository includes durable sessions, checkpoints, human approval, policy controls, auditing, and multi-agent coordination, but does not host model weights, own compute scheduling, or provide payments and commerce primitives. It fits teams with an existing Java, Spring Boot, Quarkus, or Servlet-container stack that need governed, long-lived agent interactions.
An application marks a class containing @Prompt, @Command, and @AiTool methods with @Agent. atmosphere-agent registers /atmosphere/agent/my-agent for browser access, streaming AI dispatch, memory, commands, and /help; adding atmosphere-mcp, atmosphere-a2a, or atmosphere-agui registers their respective protocol endpoints. On a request, AgentRuntime selects an available runtime adapter to call a model; tool calls can pass through ToolExecutionHelper.executeWithApproval, while policy and @AgentScope can reject requests before runtime dispatch. Sessions can persist through SQLite or Redis, and checkpointed workflows can hibernate at a human-approval gate and resume through REST. The broadcaster pipeline delivers text and run events to connected clients.
- A Spring Boot team building a customer-support agent that streams tool-assisted responses to a web client over WebSocket or SSE.
- A Java developer building a startup-team or specialist collaboration flow with @Coordinator, AgentFleet, handoffs, and durable checkpoints.
- An enterprise team that must apply approval, scope restrictions, PII rewriting, or cost ceilings before email, database, or other sensitive tool calls.
- An integration team that needs one Java agent exposed simultaneously to browser clients, MCP clients, A2A callers, and Slack, Telegram, Discord, WhatsApp, or Messenger.
- A workflow developer whose long-running interactions must survive disconnects and later be replayed, approved, or resumed through REST.
What are this agent's strengths and limitations?
- Unifies WebSocket, SSE, long-polling, and gRPC in one broadcaster pipeline, with optional WebTransport/HTTP/3.
- Connects multiple AI frameworks through AgentRuntime and twelve runtime adapters, with capability flags constrained by contract tests.
- Keeps governance on the execution path with policy admission, @AgentScope, tool approval, PII rewriting, cost ceilings, and admin kill switches.
- Durable sessions, checkpoints, and hibernating human-approval workflows support reconnect, resumption, and replay without holding a thread while hibernated.
- The same @Agent can be surfaced through browser endpoints, MCP, A2A, AG-UI, and several messaging channels through modules.
- It is an in-application framework, not a hosted agent platform; the host stack must supply compute, scheduling, model hosting, and wall-clock triggers.
- Runtime features differ, and an adapter may lack audio, token-level streaming, prompt caching, or other capabilities, so the capability matrix matters during selection.
- Spring AI Alibaba has buffered streaming; Embabel supports Spring Boot 3.5 only and requires a particular starter and build profile.
- Optional WebTransport/HTTP/3 requires
jetty-http3-serverorreactor-netty-httpon the classpath plus a development certificate. - The default DockerSandboxProvider introduces a Docker runtime dependency when isolated code execution is needed.
How do you install or deploy this agent?
Install the CLI:
brew install Atmosphere/tap/atmosphereOr:
curl -fsSL https://raw.githubusercontent.com/Atmosphere/atmosphere/main/cli/install.sh | shCreate and run an app:
atmosphere new my-agent --template ai-chat
cd my-agent
LLM_API_KEY=your-key ./mvnw spring-boot:runThe documented baseline is Java 21+, with Spring Boot 4.0.7 or Spring Boot 3.5 using -Pspring-boot3, and Quarkus 3.36.0+.
How do you use this agent?
For a sample, run atmosphere run spring-boot-multi-agent-startup-team. In an application, add atmosphere-spring-boot-starter and atmosphere-agent, then annotate a class with @Agent(name = "my-agent", description = "What this agent does"); use @Prompt for messages, @Command for commands, and @AiTool for tools. The default browser endpoint is /atmosphere/agent/my-agent; adding atmosphere-mcp exposes /atmosphere/agent/my-agent/mcp. Scaffold against Spring AI with --runtime spring-ai, or replace a sample's pinned runtime with --runtime langchain4j --force.
How does this agent compare with similar options?
Atmosphere positions itself as a real-time JVM service layer rather than an agent-hosting platform such as Cloudflare Agents, AWS Bedrock Agents, or Vertex AI Agents: it supplies streaming, governance, and protocol exposure, while the surrounding stack owns model hosting and compute scheduling. Its documentation also compares the default @Agent memory, planning, virtual filesystem, and sub-agent facilities with LangChain deepagents; Atmosphere's focus is hosting those capabilities in a JVM framework.