Atmosphere

The trait that decides it is how little the surrounding application has to change. An annotation on a class and you have an agent your existing service can stream to a browser, which means agent work joins the codebase your team already deploys rather than becoming a second system in a second language with a second on-call rota.

What arrives with it is a lot of surface you did not ask for. Pick it when the JVM is where your product lives. Pick Embabel if you want a smaller thing to reason about.

The abstraction hides real variation. Backends differ in tool-calling semantics, streaming behaviour and structured output support, and an interface that makes them interchangeable does not make them equivalent. A team that develops against one and deploys against another will discover that at runtime, because no compatibility matrix is published.

What it does right is admitting a limit. Browser automation is explicitly declared out of scope rather than half-shipped, which is a discipline most frameworks of this ambition lack.

1. Naming the six operations an agent may perform on files, and putting them over a virtual filesystem scoped to a conversation, converts an unbounded capability into an enumerable one. That is the correct direction: capability as a closed set rather than as a shell.

2. A plan artefact means intent is inspectable before execution rather than reconstructed afterwards. 3. No evaluation is published, so whether these defaults improve task completion over an unstructured agent is unmeasured, and the design argument stands on its own.

Enterprise-shaped features, no enterprise-shaped business. Everything here that a company would pay for is given away, and nothing is sold beside it, so the ongoing cost of maintaining a twelve-adapter surface falls entirely on volunteers. That works until it does not, and the failure is quiet.

Moat: none commercially; the JVM position is defensible and unmonetised. Likely path: a support or hosting offer appears, or the project plateaus and the adapters drift out of date. Position: adopt it, contribute back, and budget for maintaining the adapter you depend on yourself.

This is the first open framework this quarter that anticipated my questions rather than deferring them. Spend limits enforced by the runtime, approval gates as a first-class step and redaction before data leaves are three separate projects my platform team does not have to run, and durable sessions mean a long-running task survives a restart.

The costs are staffing and support: it is a framework we would operate ourselves, with a public issue tracker as the escalation path. Licensing is free across all sixty developers. Approved with conditions: one owning team, and the cost ceiling configured before the first deployment.

Three protocols rather than one is the detail that matters: an agent written here is reachable by clients I have not chosen yet, which is the opposite of the usual arrangement where a framework makes my work legible only to itself. Serving as well as consuming is the half most projects skip.

A local endpoint is a documented provider, the licence keeps a fork viable, and the install is one command from a tap. For a JVM project this is a surprisingly open piece of engineering, and I say that as someone who does not enjoy the JVM.