PaiAgent: a Java DAG workbench for wiring LLM nodes visually

What PaiAgent is and what it is not

The project describes itself in a single line as an enterprise grade AI workflow visual orchestration platform, built so that combining and scheduling AI capabilities becomes simple and efficient. The description in the repository says it is a lightweight AI workflow orchestration system comparable to dify and n8n, developed with vibe coding using Qoder and the CLI, with a stack that includes SpringAI, LangGraph4J, SSE, MinIO and a custom DAG engine. The README adds the practical detail: through an intuitive drag and drop interface, developers and business people can both build complex AI processing flows, and multiple large models can be coordinated without writing code. The primary language is Java, the default branch is main, and the licence is listed as unknown with a LICENSE file in the tree while the README badge reads MIT, so that discrepancy is the first thing to check.

The layered architecture, and why the layering matters

The architecture diagram in the README is drawn as five horizontal layers, and the separation is the design rather than decoration. The front end layer is React 18 with TypeScript, ReactFlow and Ant Design, holding the visual editor, the node panel and the debugging tools, and it talks to the back end over REST API and SSE. The application layer is Spring Boot 3.4.1 on Java 21, with Controller, Service and Interceptor. Below that sits the core engine layer, which is where the interesting parts live: EngineSelector for routing between the DAG and LangGraph engines, DAGParser for topological sort and cycle detection, LangGraph4j for state graph orchestration with conditional routing, SkillRegistry as the skill registry with progressive loading, and NodeExecutor as a node execution factory. The AI model layer is Spring AI and Spring AI Alibaba with a ChatClientFactory for dynamic creation of clients, and the data layer is MySQL for workflow configuration and execution records, with MinIO as optional file storage.

The DAG engine: Kahn for order, DFS for loops

The homegrown engine is small and the README describes its two algorithmic choices precisely. Node scheduling uses topological sort based on the Kahn algorithm, and loop detection uses depth first search to prevent infinite loops, which is the standard pairing since a graph that cannot be topologically sorted contains a cycle. Data flow between nodes is described as an intelligent passing mechanism, and execution monitoring as complete execution logs and result records. The readme lists the topics for the repository as dag, dfs, fastjson2, kahn and ski, which lines up with that description. The practical difference from a generic workflow tool is where the graph semantics live: the engine is not a generic expression language with an agent in the middle, it is a graph of typed nodes whose outputs feed the next node's inputs.

Two engines behind one engineType field

The LangGraph4j state graph engine is marked as newly added in the README, and it exists to cover the cases the DAG engine handles badly, namely conditional branching and dynamic routing. The state graph orchestration is built on LangGraph4j's StateGraph, and the switching between the two is automatic: EngineSelector routes by the engineType field to the DAG or the LangGraph engine, and the README says this is backward compatible. The point of that design is that existing workflows do not have to be rewritten. NodeAdapter adapts the existing NodeExecutor into an AsyncNodeAction so the business logic inside a node does not need to be rewritten for the new engine, and StateManager centralises the workflow context, holding inputData, nodeOutputs and globalContext. During execution, ExecutionEvent callbacks fire for each node's start, success and exception, which is what makes the debug panel usable.

The skills system and its three step loading

The Skills system is the most distinctive part of the design and is also marked as newly added. A skill is declared with a SKILL.md file and YAML Frontmatter giving the name, the description and the execution rules, and loading is progressive in three levels: the summary with name and description, then the full SKILL.md, then the reference documents in a reference subdirectory, loaded on demand to save tokens. The SkillRegistry scans the classpath and the file system at application startup and caches what it finds in a ConcurrentHashMap, so there is no manual registration step. The skills are exposed to the model as Spring AI FunctionCallback through LoadSkillDetailFunction and LoadSkillReferenceFunction, which means the model itself decides to pull a skill in, and there are REST endpoints for listing skills, fetching details and loading reference documents, plus a SkillSelector component in the front end for picking a skill inside a workflow.

Model nodes, tool nodes and streaming feedback

The node catalogue is what a user actually touches. On the model side, the README says Spring AI and Spring AI Alibaba give unified access to several providers: an OpenAI node for models such as GPT-5, a DeepSeek node over an OpenAI compatible interface, a Tongyi Qianwen node with native DashScope support through Spring AI Alibaba, a Zhipu AI node for the GLM series, and an AIPing node described as a third party model proxy. The tool side has a TTS node covering Qwen3 TTS and StepAudio for speech generation, input and output nodes for flexible data, and custom extension nodes built on a unified interface. The debugging story is the other half of the experience: a built in debug panel, SSE streaming output, and a visual view of the execution process, with the ExecutionEvent callbacks supplying the per node status.

What the README does not tell you

There are gaps, and they matter for an adoption decision. The README has no installation or run command, no configuration example, no database schema and no list of environment variables, so the practical path to a running system is the linked USER_GUIDE.md and the tutorial series on paicoding, where the first run of the series covers building the PaiAgent scaffold, then node configuration, developing an LLM node, a hyper realistic audio node and real time workflow push. The tutorial series also covers resume writing, interview questions and LangGraph4J. There is a separate PROGRESS.md linked as development progress, which is the document to read for what is finished and what is not, and the README marks several features as newly added, which in a project of this size usually means the edges are still moving. The repository tree also carries a .qoder/ directory, a .feisuan/ directory, an AGENTS.md, a .java-version file, a test_llm_config.py at the root, a docs/ directory and a BOOT-INF/ directory, and the project is also mirrored on AtomGit at atomgit.com/javabetter/PaiAgent. There are no GitHub releases at all, so there is no version to pin.

Editorial conclusion

Adopt PaiAgent if your team builds AI workflows on Java and wants business users to assemble them in a canvas while engineers extend the node set, since the plugin model, the REST and SSE surface and the MySQL backed execution records are all there. Do not adopt it if you need a battle tested hosted product with published releases and a support contract, because the project publishes no GitHub releases and the README points to a tutorial series and a mirror instead. Before you plan an evaluation, read USER_GUIDE.md and PROGRESS.md, confirm your model provider works through Spring AI or Spring AI Alibaba, and check whether the LangGraph4j dependency at the 1.8.0 beta3 stage is something you want in a production build.

Frequently asked questions

Official sources

1. Issues
2. itwanger/PaiAgent on GitHub
3. README