About
Why jOpenAgent exists
Agent engineering moved fast, and almost all of it moved in Python.
Meanwhile a very large share of
the systems worth connecting an agent to are written in Java: ERPs, ledgers, schedulers, order
books, industrial back-ends. None of them are going to be rewritten.
The gap
Java had integration libraries. It did not have a harness.
There have been good Java libraries for talking to language models for years: chat clients, embeddings, vector stores, retrieval pipelines, function calling. That is a real and useful category, and it is not the same category as an agent harness.
A harness is the architecture around the model: how state is held, how outputs are typed and repaired, how the model acts, how context is disclosed, how the loop is written, how the whole thing is traced and measured. Published research on agent architecture is consistent on the point. The harness accounts for double-digit swings in benchmark results and large differences in token cost on an unchanged model. Picking a better model is the small lever. The harness is the big one.
So the choice facing a Java team was to stand up a Python service beside their system and accept a network hop, a second runtime and a serialisation boundary between the model and their domain objects, or to do without. jOpenAgent exists so that neither is necessary.
The design commitments
- Agents are plain objects. Debuggable, testable, refactorable with the tools you already have.
- No magic. No dynamic proxy, no bytecode weaving, no annotation processor. Real stack frames.
- No dependencies. Not in the core, not anywhere. The JDK is enough.
- Honest documentation. Including the chapter on what the sandbox does not guarantee.