ReachAI (w8123/EnterpriseAgentFramework): Adding AI to OA, ERP and CRM Systems Without Replacing Them

The problem ReachAI solves: AI inside the systems you already run

Most enterprise AI projects fail at the same wall. The model can answer questions, but the answer is useless because the data sits behind a login, a permission check and a form that only submits through the original UI. ReachAI takes the opposite approach to a new AI portal. It embeds an assistant into OA, eHR, procurement and CRM pages, so the employee never leaves the system they already use.

The README frames the target as existing systems with incomplete interface documentation, where pages, routes, components, backend APIs and permission logic are scattered across the codebase. That is a specific and honest description of the audience. It is not aimed at teams starting a new product, and it is not aimed at individual users who want an assistant across their personal apps. The README draws that line explicitly, contrasting itself with Dify-style application orchestration platforms and with personal agents that connect tools from a chat entry point.

The unit of work is a business task, not a conversation. The README gives four examples: summarizing today's to-dos in OA, filtering unhandled attendance exceptions in eHR, creating an office supply purchase request in procurement, and generating a follow-up plan from this week's customer activity in CRM. Each one ends in a real record, which is why the platform treats writes, submissions and approvals differently from reads.

How the agent, workflow and capability layers fit together

The architecture separates understanding from execution. According to the README, an Agent runs against a published configuration version and hands off to an AgentScope Supervisor, which interprets intent, plans the task and selects zero, one or several authorized Workflows-as-Tools. The Runtime then executes a version-pinned GraphSpec and aggregates the result into a Trace.

That split is the most interesting design decision in the project. The README states the reasoning plainly: fixed workflows are stable but cannot cover every new request, while pure AI planning is flexible but hard to control on cost, speed and consistency. ReachAI's answer is that the agent picks the path and the workflow executes verified, authorized steps. A successful new path leaves a Trace, and a frequently repeated pattern can become a workflow draft that a human reviews before publishing.

Two implementation details are worth noting. First, GraphSpec holds the executable semantics while canvas_json only holds canvas layout, so a saved diagram is not the same artifact as a runnable graph. Second, Workflow Studio, AI orchestration and publish validation share one Runtime node capability registry, and publishing checks executor support first. The README describes this as preventing a graph that can be drawn but not run. That is a real failure mode in visual workflow builders, and checking it at publish time rather than at execution time is the right place.

Authorization is enforced at selection: the README states the agent can only choose Workflows-as-Tools from a whitelist, and the Runtime always executes the corresponding published version. Page filtering, navigation and form actions are performed by registered page actions, while actual reads and writes go through backend Capabilities or business APIs.

Installing ReachAI and registering your first Java capability

The README does not give a one-line install command. What it does give is the integration path: a JDK 8 compatible SDK and a Spring Boot 2 Starter that register the project, the instance and the business capabilities with the platform. The repository layout confirms the modules you would build or depend on, including reachai-capability-sdk, reachai-spring-boot2-starter, reachai-control-service, reachai-runtime-service and reachai-model-service, with a deploy directory and a sql directory alongside them. If you are evaluating the project, start by reading deploy/ and sql/ to see what the platform expects to run against, because the README describes the workflow but not the deployment topology.

Once the starter is on the classpath, a business method becomes a capability by annotation. This example is the one the README provides for creating a purchase request:

import com.enterprise.ai.reach.sdk.annotation.ReachCapability;
import com.enterprise.ai.reach.sdk.annotation.ReachParam;
import com.enterprise.ai.reach.sdk.annotation.ReachSideEffectLevel;

import java.util.List;

@ReachCapability(
    name = "purchase.createApplication",
    title = "创建采购申请",
    description = "创建采购申请草稿，提交前需要用户确认",
    domain = "purchase",
    module = "application",
    sideEffect = ReachSideEffectLevel.WRITE,
    requiredRoles = {"PURCHASE_APPLICANT"}
)
public PurchaseApplication create(
        @ReachParam(name = "reason", description = "采购事由", required = true)
        String reason,
        @ReachParam(name = "items", description = "采购明细", required = true)
        List<PurchaseItem> items) {
    // 继续复用原业务系统的领域服务、权限和事务
}

The annotation declares the capability name, the roles allowed to invoke it, and a side effect level of WRITE, which is what triggers the confirmation requirement described elsewhere in the README. The method body is where you keep calling your existing domain service, so permissions and transactions stay where they already are.

After that, the starter scans @ReachCapability methods and Spring MVC interfaces, performs instance heartbeat and signed reporting, and the platform stores a capability snapshot. The README then describes a field-level diff that a developer resolves with apply or ignore, which is how the Capability Catalog is built up over time rather than in one migration.

Where ReachAI is the wrong tool

The README is candid about one boundary: the SDK path applies to Java systems you can modify. For legacy systems where code changes are not possible, the README states that scanning is the fallback, and scanning produces a page map rather than registered capabilities. That means the write side of the story, where AI fills forms and submits business tasks through backend capabilities, is weaker for unmodifiable systems. If your target system is a packaged ERP with no extension points, plan for the scan-based path and expect less than the annotated example promises.

There is a second constraint worth stating directly. The README describes a six-step process that ends in real business acceptance, and the acceptance criteria include code, service, SDK callback, browser session, trace and business result. That is a heavyweight loop. A team that wants to prototype an agent in an afternoon will find the ceremony disproportionate. The project assumes you are changing a production system that other people depend on, and it prices that in.

The README also does not document rollback for a published capability or workflow version. It describes versioning, publishing and validation before release, but the material is silent on what happens when a published version needs to be reverted in production. Treat that as an open question to resolve during your own evaluation rather than something the documentation answers.

ReachAI compared with Dify and personal agent tools

The README positions ReachAI against two categories. Dify and similar platforms are described as focused on creating and publishing AI applications, agents and workflows. ReachAI's stated difference is that it covers the surrounding work for an existing system: scanning it, recommending changes, implementing them through AI coding tools, registering capabilities, running business acceptance and governing the result.

That difference is real but it cuts both ways. If your goal is to build a new AI application from scratch, Dify's model is a better fit, because ReachAI's value is concentrated in the retrofit path and the governance around it. If your goal is to make an existing OA or ERP system answer questions and submit forms under the current user's permissions, Dify does not address the page-level and identity-level integration at all.

The second comparison is with personal agents such as OpenClaw, which the README describes as connecting tools and services from a chat entry point to help an individual complete tasks across applications. ReachAI targets multi-user, multi-system production business, where the agent calls only capabilities already granted to the current user and key operations require confirmation. The distinction is authorization scope. A personal agent optimizes for reach; ReachAI optimizes for the boundary of what one logged-in employee is allowed to do.

One more reference point the README raises is AI coding tools. ReachAI packages task scope, repository context, modification constraints, structured output and acceptance conditions into standardized engineering tasks and hands them to Codex, Trae, Cursor or Claude Code. The platform then verifies whether the client connected, whether code and services are running, whether the SDK callback closed the loop, and whether the session, Trace, Workflow and published version all correspond to the same acceptance run.

Maintenance, licence and upgrade considerations

The repository is not archived, and the last push was on 2026-08-31. There are no retrieved releases, so versioning currently happens through the repository itself rather than through tagged artifacts, and you should check the deploy and sql directories for the schema and topology assumptions your environment has to satisfy.

The licence is MIT, which places few restrictions on commercial use, modification and redistribution. This is not legal advice, and the practical question for an enterprise deployment is less about the licence text than about the operational surface: you are running several services (control, runtime, model, knowledge, capability) plus a managed executor worker, and the README's governance story depends on those services staying in step with the SDK and starter versions you have deployed in each business system. Because the platform computes field-level capability diffs and requires apply or ignore, an SDK upgrade can surface a backlog of decisions rather than applying silently. Budget for that review step each time you bump the starter.

The README does not describe a support policy, a release cadence or a compatibility matrix between platform versions and SDK versions. That is the main maintenance unknown. If you adopt ReachAI, pin both sides and test the capability diff flow in a staging system before touching production.

Editorial conclusion

Adopt ReachAI if your business logic lives in a Java system you cannot replace and you need AI actions to run under the existing identity, permission and transaction model. Do not adopt it if you only want to build a standalone chatbot or a greenfield agent product, because the whole design assumes a system already in production. Before committing, verify two things in the repository: that the SDK annotations in reachai-capability-sdk match your Spring version, and that the deploy directory contains a topology you can actually run, since the README documents the six-step workflow but not a rollback path for a published capability.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. w8123/EnterpriseAgentFramework on GitHub