# solon-ai is a Java framework that splits RAG into three modules and spells two of them wrong

> Solon AI is a Java framework for LLM calls, tools, skills, RAG, MCP and agent orchestration, positioned in its own header as the same kind of project as LangChain, LangGraph and LlamaIndex. The mechanics worth reading are the dialect layer that absorbs provider differences behind one interface, the talent system where admission and instructions are Java predicates over the prompt, and a module tree wide enough to make twenty one Maven coordinates out of one idea.

**opensolon/solon-ai** — Java AI application development framework (supports LLM-tool,skill; RAG; MCP; Agent-ReAct,Team-Agent). Compatible with java8 ~ java26. It can also be embedded in SpringBoot, jFinal, Vert.x, Quarkus, and other frameworks.

- Repository: https://github.com/opensolon/solon-ai
- Website: https://solon.noear.org
- Stars: 459 · Forks: 70
- Language: Java
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/opensolon-solon-ai

## The header names LangChain, LangGraph and LlamaIndex

The positioning is stated before anything else, in three bold lines above the fold. Solon AI is a Java LLM with tool and skill support, RAG, MCP and agent development framework. The second line is a three word motto about restraint, efficiency and openness. The third is the comparison: it is the same type of development framework as LangChain, LangGraph and LlamaIndex.

That framing matters for a Java project, because the reference points are all Python and all application frameworks rather than model clients. The intent is that a Java team reaches for the same shape of abstraction it would find in LangChain and finds it in Maven coordinates under the `org.noear` group, with the parent published as `org.noear:solon-parent` and searchable on Maven Central.

It is described as one of the core subprojects of the larger Solon project, so the framework is not standalone: it is the AI layer of a Java application framework, which is what makes the embedding claim in the next section cheap rather than aspirational. Documentation lives at solon.noear.org with a learn Solon AI page, and the repository is mirrored on Gitee, GitHub and GitCode with stargazer links for all three, which is the distribution pattern of a project whose primary audience is in China.

The README is bilingual, with a Chinese version at a separate file, and the English one is the one this repository defaults to.

## The module tree is the architecture

The top level of the repository is a list of module directories, and reading it tells you more about the design than the feature prose does.

The named pieces are `solon-ai-core`, `solon-ai-llm-dialects`, `solon-ai-mcp`, `solon-ai-agent`, `solon-ai-talents`, `solon-ai-flow`, `solon-ai-loop`, `solon-ai-router`, `solon-ai-harness`, `solon-ai-sandbox`, `solon-ai-anp`, `solon-ai-ui` and `solon-ai-acp`, plus the three RAG modules `solon-ai-rag-loaders`, `solon-ai-rag-repositorys` and `solon-ai-rag-searchs`. Alongside them sit `mcp-core`, a Jackson 2 compatibility module at `mcp-json-jackson2`, and three `acp-` modules for agent client protocol support, along with the aggregator, the parent, `pom.xml`, a release directory, docs, and a TEST.md, an UPDATE_LOG.md and a CONTRIBUTING.md.

Two things jump out. The RAG layer is split three ways rather than one, which is a deliberate choice: you can depend on a loader without a repository, or a repository without a search implementation, and a team that already has vector storage does not inherit it. And two of those three directory names are spelled with an extra syllable, `repositorys` and `searchs`, which means the artifact ids carry the same spelling and any migration story about them has to quote it exactly.

There is also a `NOTICE.template` at the root next to the LICENSE, which is what a project generates per-build attribution files from.

## Dialects absorb the provider differences

The unification point is an interface called ChatModel, described as the general purpose LLM call interface, and the mechanism for absorbing vendor differences is called a dialect.

The sample points at a local Ollama server and names the provider explicitly, with a comment saying the vendor must be specified because it is used to identify the interface style, which is also called the dialect:

```java
ChatModel chatModel = ChatModel.of("http://127.0.0.1:11434/api/chat")
                .provider("ollama") //Need to specify vendor, used to identify interface style (also called dialect)
                .model("qwen2.5:1.5b")
                .defaultTalentAdd(new McpGatewayTalent())
                .build();

AssistantMessage result = ChatchatModel.prompt("The weather in Hangzhou today？")
         .options(op->op.toolAdd(new WeatherTools())) //Adding tools
         .call()
         .getMessage();
System.out.println(result);
```

The named dialects are OpenAI, Gemini, Claude, Ollama, DeepSeek and Dashscope among others. Since the model is a string and the provider is a string, adding a vendor is a matter of adding a dialect rather than branching at every call site, which is the whole value proposition over a per vendor client.

Two other things are visible in the same snippet. Calls come in both synchronous and Reactive forms, and the tool list is attached as an option at call time rather than configured on the model, while `defaultTalentAdd` puts an MCP gateway talent on the model itself. The visible snippet then stops at a comment about the string form of the call, so the Reactive variant and the `ChatchatModel` typo in the line above are as far as this page goes.

## A talent is admitted by a predicate and steered by prompt metadata

Talents are described as Solon AI talents, and the sample shows that they are not static prompt fragments but Java objects with behaviour.

The object is a TalentDesc, given a name and a description, then two functions. The first is admission, described as dynamic admission, and it is a predicate over the prompt: the talent is activated only when the user message content contains a given word, in the sample the word order. The second is instruction, also a function, and it returns different system instructions depending on prompt metadata, in the sample a meta key called user_level whose value VIP selects a different instruction telling the model to call a fast track tool first.

So a talent is a policy object: whether to appear, and what to say when it does. That is a meaningfully different shape from a named snippet in a config file, and it is the piece that would let one application serve a VIP and a non VIP differently without duplicating the tool set.

The example is cut off mid string literal, at the line that returns the instruction for a normal order enquiry, and the visible text ends there. The remaining Talent API surface is therefore not visible on this page, and the documentation site is where the rest of it would be.

## MCP ships a dated protocol revision and a streamable channel

MCP support is described as deep integration with the protocol, and it names the revision it targets: MCP 2025-06-18. The stated scope is cross platform sharing of tools, resources and prompts, which is the three primitive types rather than only tool calls.

A server is an annotated class, with the channel and the endpoint path both declared on the annotation, and a tool method carrying a description on both the mapping and its parameter:

```java
@McpServerEndpoint(channel = McpChannel.STREAMABLE, mcpEndpoint = "/mcp")
public class MyMcpServer {
    @ToolMapping(description = "Checking the weather")
    public String getWeather(@Param(description = "city") String location) {
        return "It's sunny, 25 degrees";
    }
}

McpClientProvider clientProvider = McpClientProvider.builder()
        .channel(McpChannel.STREAMABLE)
        .url("http://localhost:8080/mcp")
        .build();
```

The client side is a builder with the same channel enum and a URL, so both ends of a connection are configured with the same vocabulary, and the streamable channel is chosen rather than being the only option.

The two `mcp-` directories at the repository root explain where the code lives: `mcp-core` and `mcp-json-jackson2`, the second being there for Jackson 2 users, which in practice means a JSON binding choice is isolated into its own artifact instead of forcing a version on everyone. The project is also listed on an MCP directory site from the badge at the top of the README, which is how an MCP server gets discovered at all.

## RAG is four chained pieces and three separate artifacts

The knowledge base section describes full link support from four components, and the order is the pipeline: DocumentLoader, DocumentSplitter, EmbeddingModel and RerankingModel.

The sample wires them into a repository object. An embedding model is built from a URL, key, provider and model name with a batch size of 10, a reranking model from the same four values, and a repository constructed around an embedding model. A PDF is then loaded from a URI and inserted, a query returns a list of documents, and the reranker is applied to that list if you want to reorder it.

Two design details are worth noting. The repository is an abstraction with an insert and a search, and the example implementation shown is `InMemoryRepository`, which is a sensible default for a sample and an obvious limit for production. And the rerank step is positioned after retrieval rather than folded into it, so a team that does not want a reranker can skip it without changing the search layer, which is the benefit of splitting the pieces into separate Maven coordinates in the first place.

That is also why there are three rag modules rather than one. `solon-ai-rag-loaders` is where ingestion lives, `solon-ai-rag-repositorys` is where storage lives, and `solon-ai-rag-searchs` is where retrieval lives, and the spelling of the last two is as it appears in the directory names.

## The ReAct loop is named in a code comment

The agent section is described as an experience with computational flow graphs, and the claim is that Solon AI transforms reasoning logic into graph driven collaboration flows, which is what the introduction calls observable and governable computation flow graphs.

The reflective agent is built from a chat model with a name, a description and default tools, and there are two entry points: ReActAgent and, in the same line, SimpleAgent as the alternative:

```java
ReActAgent agent = ReActAgent.of(chatModel)
    .name("weather_expert")
    .description("Check the weather and provide advice")
    .defaultToolAdd(weatherTool)
    .build();

agent.prompt("What to wear in Beijing today？").call();
```

The comment attached to that call names the loop in four steps: think, call tool, observe, summarize. Having the loop in a comment rather than a class diagram is useful, because it is the thing a reader needs to know and it is also the thing the framework claims to make observable as a graph.

Tools are injected the same way they are on a chat model, and the comment says MCP or local tools, so the tool source is not a separate concept from the MCP client described earlier. The next sample in the README begins to construct a team agent, where member roles are arranged automatically, and the visible text stops there.

The other agent related directories at the top level, `solon-ai-loop`, `solon-ai-flow`, `solon-ai-harness`, `solon-ai-router` and `solon-ai-sandbox`, are where that graph machinery would live, though which module holds which piece is not stated on this page.

## Java 8 through Java 26, and embedded in other frameworks

The compatibility claim is in the repository description rather than in a table, and it is a range: Java 8 through Java 26. The badges above the fold point at the Oracle download pages for JDK 8, 11, 17 and 21, plus a current downloads page, so the endpoints of that range are not all pinned to a specific archive.

The embedding claim is the more interesting one. Solon AI is said to integrate into SpringBoot, jFinal, Vert.x and Quarkus as well as fitting the Solon ecosystem, and the project publishes example embedding repositories under the name solon-ai-mcp-embedded-examples, hosted on Gitee, GitCode and GitHub, described as including third party frameworks. Embedding an MCP capable AI layer into an existing Java application without adopting the application framework is the differentiator, and it is why the example repositories are named the way they are.

The list of application types the README claims to cover runs from general purpose autonomous agents, with Manus and OpenOperator as the reference points, through intelligent assistants and RAG knowledge bases like Dify and Coze, multi agent orchestration like AutoGPT and MetaGPT, business workflows, document processing and ETL, data insights and text to SQL, automated testing, and low code visual workflow platforms like LangFlow and Flowise. Naming competitors in a positioning list is one thing; the claim to be usable in all of those is another, and the visible page does not say which of the nine are demonstrated.

Two synthesis projects are offered as production or customisation starting points: SolonCode, described as the Java implementation of Claude Code, and SolonClaw, the Java implementation of OpenClaw. Releases went v4.0.6 on 17 August 2026, v4.1.0 on 7 September, and v4.1.1 on 1 October, which is the same day as the last push to main.

## Conclusion

solon-ai fits a Java shop that wants LLM, RAG, MCP and agent code in the same dependency family as its web framework, and that needs the provider dialect layer rather than a wrapper per vendor. It does not fit a team that wants one artifact, since the module tree is wide and the RAG pieces are three separate coordinates, and it does not fit a project that must stay on a single Maven parent it already controls. Before adopting it, check which Solon version line your parent resolves, read the truncated usage samples in the README against the docs site, since several code blocks stop mid statement, and decide whether an in-memory repository is the only repository implementation you were shown, because that is the one the visible example uses.

## FAQ

### What is solon-ai and what is it comparable to?

It is a Java AI application development framework covering LLM calls with tools and skills, RAG, the MCP protocol and agent orchestration, and the README describes it as the same type of development framework as LangChain, LangGraph and LlamaIndex. It is one of the core subprojects of the Solon project.

### How does solon-ai handle different LLM providers?

Through a ChatModel interface and something called a dialect, where the provider is named when the model is built so the framework can adapt the interface style. The dialects named include OpenAI, Gemini, Claude, Ollama, DeepSeek and Dashscope, and calls come in synchronous and Reactive forms.

### What is a Talent in solon-ai?

A Talent is a policy object rather than a fixed prompt fragment. The sample builds one with a name and description, an admission predicate that activates it only when the user message contains a given word, and an instruction function that returns different text depending on prompt metadata such as a user level.

### Does solon-ai speak MCP, and as a server or a client?

Both. The framework targets the MCP 2025-06-18 revision and shares tools, resources and prompts across platforms. A server is a class annotated with McpServerEndpoint on the streamable channel with tool methods annotated by ToolMapping, and a client is built with McpClientProvider using the same channel and a URL.

### What are the building blocks of the RAG support in solon-ai?

DocumentLoader, DocumentSplitter, EmbeddingModel and RerankingModel, chained into a repository abstraction that supports insert and search. They live in three separate modules, solon-ai-rag-loaders, solon-ai-rag-repositorys and solon-ai-rag-searchs, and the visible example uses an in-memory repository implementation.

### Which Java versions and host frameworks does solon-ai support?

The repository description gives a range from Java 8 to Java 26, and the framework is described as embeddable in SpringBoot, jFinal, Vert.x and Quarkus as well as within the Solon ecosystem, with example embedding repositories published for third party frameworks.

## Sources

- [License: Apache-2.0](https://github.com/opensolon/solon-ai/blob/main/LICENSE)
- [opensolon/solon-ai on GitHub](https://github.com/opensolon/solon-ai)
- [Project website](https://solon.noear.org)
- [README](https://github.com/opensolon/solon-ai/blob/main/README.md)
- [Releases](https://github.com/opensolon/solon-ai/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opensolon-solon-ai