Solon-AI: a Java LLM, RAG and MCP framework for teams already inside the Solon ecosystem

The gap Solon-AI is aimed at: Java services that need LLM calls without three SDKs

A Java team that wants tool calling today usually ends up importing an OpenAI client, a separate embedding client, and something for MCP, then writing glue so the three agree on message shapes. Solon-AI's pitch is that this glue is the framework. The README describes it as a full-scenario Java AI development framework that integrates LLM large models, RAG knowledge bases, the MCP protocol and Agent collaboration, and it positions itself as the same type of framework as LangChain, LangGraph and LlamaIndex. The intended audience is Java developers building autonomous agents, RAG knowledge bases, multi-agent orchestration, business-driven controlled workflows, document processing and Text-to-SQL dashboards. The list in the README is broad, but the underlying unit is narrower: a service that needs to call a model, give it tools, and optionally ground it in retrieved documents. What separates Solon-AI from a plain HTTP client is the dialect layer. ChatModel.of(url).provider("ollama").model("qwen2.5:1.5b").build() is the README's own example, and the provider value is what selects the interface style. That means swapping Ollama for DeepSeek or Dashscope is a configuration change rather than a rewrite of every call site. For a team that expects to change model vendors at least once, that is the concrete value.

ChatModel, provider dialects and the options object

The core object is ChatModel, built from a URL, a provider name, a model name and optional defaults. The README states that ChatModel supports both synchronous and reactive calls and carries built-in dialect adaptation, Tool, Skill and ChatSession support. The call shape is fluent: chatModel.prompt("hello").stream() returns a Flux<ChatEvent>, which the README describes as full semantic events rather than raw text chunks. The synchronous path goes through .call().getMessage(). Per-call behaviour is attached through an options lambda, so toolAdd(new WeatherTools()) adds tools for that prompt only, while defaultTalentAdd(new McpGatewayTalent()) sets a default at construction time. That split matters in practice: defaults live on the model, per-request concerns live on the prompt. The dialect list named in the README is OpenAI, Gemini, Claude, Ollama, DeepSeek and Dashscope. The README does not document how a dialect maps onto each vendor's tool-calling format, so if you depend on a provider-specific feature such as a particular structured-output mode, verify it against the source rather than assuming parity across providers.

Talents: dynamic activation and per-request instructions

The most distinctive piece is the Talent abstraction, which the README introduces as a way to bundle a description, an activation rule, an instruction and tools. The example defines a talent named order_expert with a description of Order Assistant, then attaches isSupported(prompt -> prompt.getUserMessageContent().contains("order")). The talent is only considered when the user message mentions the word order. Instructions are also computed per request: the example checks prompt.getMeta("user_level") and returns a different instruction string for VIP customers, telling the model to call fast_track_tool first, versus the normal process otherwise. Tools are attached with toolAdd(new OrderTools()). This is a different design from the usual approach of registering every tool globally and letting the model choose. Here the framework can narrow the candidate set before the model sees it, using plain Java predicates, and the instruction text can vary with request metadata. The trade-off is that activation logic is code you write and maintain. A predicate that checks for the substring "order" is brittle; it will fire on "order of magnitude" as readily as on a purchase query. The README presents the mechanism, not a policy for writing good predicates.

RAG as a pipeline of four replaceable pieces

The RAG support is described as full-link, spanning DocumentLoader, DocumentSplitter, EmbeddingModel and RerankingModel. The README's example builds an EmbeddingModel with a provider, model, apiKey and batchSize(10), builds a RerankingModel the same way, then constructs an InMemoryRepository over the embedding model. Documents go in with repository.insert(new PdfLoader(pdfUri).load()), retrieval is repository.search(query), and reranking is a separate call: rerankingModel.rerank(query, docs). Two things are worth noting. First, reranking is explicit, not automatic, so you decide whether the extra model call is worth it per query. Second, the only repository shown is InMemoryRepository. The README does not describe a persistent vector store adapter, which means a production deployment either keeps the index in process memory and rebuilds it, or you write your own repository implementation against whatever interface the code exposes. That is the single biggest gap between the README's examples and a running system, and it is not addressed in the material provided.

Getting it running: Maven coordinates and the embedding examples

The README points to Maven Central under the org.noear group, with the badge linking to a search for org.noear:solon-parent, and the licence is Apache-2.0. The README does not print a dependency snippet, so the exact artifact for a given module has to be read off Maven Central rather than copied from the documentation. What the README does supply is a set of embedding examples for third-party frameworks, hosted at gitee.com/solonlab/solon-ai-mcp-embedded-examples, gitcode.com/solonlab/solon-ai-mcp-embedded-examples and github.com/solonlab/solon-ai-mcp-embedded-examples. Those repositories are the practical starting point if you intend to run Solon-AI inside Spring Boot, jFinal, Vert.x or Quarkus rather than inside Solon itself. The README's own quickstart is the ChatModel builder shown earlier; the smallest working program is a URL, a provider string, a model string and a prompt. Note the README's code sample contains a typo, ChatchatModel.prompt where ChatModel is meant, so copy the builder pattern rather than the snippet verbatim.

Where Solon-AI is the wrong choice

Two limits are visible in the material. The first is the repository question already raised: InMemoryRepository is the only store the README demonstrates, so a team that needs durable vectors, filtered search or index updates without a full rebuild is looking at work the documentation does not cover. The second is ecosystem gravity. Solon-AI is a subproject of Solon and the README states it fits into the Solon ecosystem while also being embeddable elsewhere. Embeddable is not the same as idiomatic. If your application is already built on Spring AI or LangChain4j, adding Solon-AI means two abstraction layers over the same model endpoints, two sets of message types, and two upgrade schedules to track. That cost is only justified if the talent model or the dialect coverage solves a problem the existing layer does not. A third consideration is version churn. The releases listed are v4.1.0, v4.0.6 and v4.0.5, dated within roughly a month of each other. A fast minor-release cadence is normal for an actively developed framework, but it means pinning a version and reading release notes before upgrading.

Spring AI and LangChain4j: the difference is where the abstraction sits

The obvious alternatives in Java are Spring AI and LangChain4j, and the README itself names LangChain, LangGraph and LlamaIndex as the same category of tool. The distinction is not feature count. Spring AI anchors its abstractions in Spring's dependency injection and configuration model, so a Spring Boot application gets auto-configuration and property-driven setup and pays for it by taking a Spring dependency. LangChain4j builds a chain-and-memory vocabulary that is closer to the Python LangChain lineage. Solon-AI instead puts the vendor difference in a provider string on ChatModel and puts the routing logic in Java predicates on a Talent. That makes the framework smaller to reason about if you are not in Spring, and it makes the extension point for conditional behaviour a plain lambda rather than a chain DSL. The cost is that you get fewer batteries: no demonstrated persistent vector store, and no documented auto-configuration story beyond the embedding example repositories. Choose on where you want the abstraction to live, not on which one has more listed capabilities.

Maintenance, licence and what to verify first

The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant; it also means redistributed modifications carry notice obligations. That is a statement about the licence text, not legal advice, and any organisation with a review process should run it through that process. On maintenance, the material shows a repository that is not archived, a last push in September 2026, and three releases within about four weeks, which suggests active development rather than a dormant project. The README also points to two synthesis projects, SolonCode and SolonClaw, described as Java implementations of Claude Code and OpenClaw respectively, which are the closest thing to a reference application in the material. If you are evaluating Solon-AI, read those two repositories before writing your own agent loop, and confirm on Maven Central which org.noear artifacts correspond to the modules you need, since the README does not list them.

Editorial conclusion

Adopt Solon-AI if you are building Java services that need tool calling, MCP endpoints and a small RAG loop, and you want them behind one ChatModel interface rather than several vendor SDKs. Do not adopt it if your team is standardized on Spring AI or LangChain4j and has no appetite for a second abstraction layer, or if you need a managed vector store on day one, since the README only demonstrates InMemoryRepository. Before committing, verify the release cadence against your upgrade tolerance and read the Maven Central artifacts for org.noear to confirm which modules you actually need.

Official sources

1. License: Apache-2.0
2. opensolon/solon-ai on GitHub
3. Project website
4. README
5. Releases