ReachAI: An Agent Runtime for Retrofitting Java Business Systems

The problem ReachAI targets: AI that cannot touch the system of record

Most enterprise AI deployments stall at the same boundary. A chat assistant can answer questions, but it cannot open the purchase request form, read the current approval state, or file the request. ReachAI is built for that boundary. Its stated goal is to let AI query data, fill forms and execute business tasks inside existing OA, eHR, procurement, CRM and contract systems, with the employee never switching applications. The intended users are Java teams maintaining systems that already have pages, identities, permissions, interfaces and business rules. ReachAI does not replace any of those. According to the README, the business system keeps its original pages, identity, permissions, interfaces and business rules, while the platform supplies agent scheduling, workflow execution, model access, operation confirmation and run tracing. The examples given are concrete: summarizing today's to-dos in OA and opening the most urgent one, filtering unprocessed attendance anomalies in eHR, creating an office-supply purchase request with confirmation before submission, and generating a follow-up plan from this week's CRM activity. This is a narrower and more operational target than a general agent framework. The value proposition is not that AI can reason; it is that AI can act inside a system whose permission model already exists.

How the pieces fit: page assistant, Capability SDK and Workflow-as-Tool

The architecture visible in the README has three layers. The first is the page assistant embedded in the business system. It reads the current logged-in identity, page state and business context, and it only invokes business capabilities already granted to that user. Page filtering, navigation and form operations are performed by registered page actions. Real data queries and writes still go through backend Capabilities or business APIs. The second layer is the Capability layer. For modifiable Java systems, a JDK 8 compatible SDK and a Spring Boot 2 Starter register projects, instances and business capabilities. The Starter scans @ReachCapability business methods and Spring MVC interfaces, then reports instance heartbeats and signatures. The platform stores a capability snapshot, computes field-level diffs, and lets a developer apply or ignore each change before it becomes part of the Capability Catalog. The third layer is execution. An AgentScope Supervisor handles intent understanding, task planning, workflow selection and limited replanning. It chooses zero, one or several authorized Workflow-as-Tool entries. The Runtime then executes a version-fixed GraphSpec. The README is explicit that GraphSpec holds executable semantics while canvas_json holds only canvas layout, and that Workflow Studio, AI orchestration and publish validation share the same runtime node capability registry, checking executor support before publication. That last detail matters: it is an attempt to prevent the common failure where a canvas draws a node the runtime cannot execute.

The scanning pipeline and its three-part evidence model

ReachAI splits system assessment into two stages rather than one. First, a page map identifies pages, routes, components and API dependencies. The README states that the scanning stage does not infer business value from names. Second, after a developer selects a page, the platform performs read-only analysis and recommends up to three candidate retrofit items. Each candidate records confirmedFact, technicalInference, openQuestion, codeReferences, implementationReference and acceptanceCriteria as separate fields. That separation is the most interesting design decision in the project. Most code-scanning tools blend what they found with what they concluded, and reviewers cannot tell the two apart. ReachAI forces the distinction into the output schema. The README frames this as a response to legacy systems that lack complete interface documentation, where pages, routes, components, backend interfaces and permission logic are scattered across the codebase. The honest limitation is also stated: the platform recommends at most three candidates per selected page. That is a deliberate throttle, and it means a large system will require many selection rounds rather than one sweep.

Getting it running: what the README actually specifies

The repository README does not include a quickstart, Docker Compose file or installation command sequence. What it does specify is the integration surface on the Java side. A business method is exposed as a capability by annotating it with @ReachCapability, declaring name, title, description, domain, module, sideEffect and requiredRoles, and annotating each parameter with @ReachParam including name, description and required. The README example uses sideEffect = ReachSideEffectLevel.WRITE and requiredRoles = {"PURCHASE_APPLICANT"} for a purchase application creation method, with a comment noting that the method continues to reuse the original domain services, permissions and transactions. The imports shown are com.enterprise.ai.reach.sdk.annotation.ReachCapability, ReachParam and ReachSideEffectLevel. The Starter then auto-scans those annotated methods plus Spring MVC interfaces and performs instance heartbeat and signed reporting. The README also describes a second path for systems that cannot be modified: scanning-based inventory. Because no startup commands, port numbers, configuration keys or database requirements appear in the supplied material, a reader cannot determine from the README alone what the platform itself needs to run. The homepage field is empty, so there is no separate documentation site to check. That is a real gap for anyone evaluating adoption.

The confirmation gate and what it does not cover

ReachAI's stated safety position is that writes, submissions and approvals must be confirmed by the user before execution. Combined with requiredRoles on each capability and the rule that the page assistant only calls capabilities granted to the logged-in user, this produces a model where the AI proposes and the human disposes. The README also says acceptance verification checks code, service, SDK callbacks, browser session, run trace and business result together, and that a task only closes when code, service and real business acceptance all pass. Two things are worth flagging. First, the confirmation requirement is described at the capability level through sideEffect levels, so the granularity of confirmation depends on how integrators classify their methods. A method mislabeled as READ does not appear to pass through the same gate. Second, the README does not describe an approval workflow for capability registration itself beyond the developer apply/ignore step on field-level diffs. If a capability is registered with broad requiredRoles, the platform's protection reduces to the underlying system's own permission checks, which is arguably correct but is not an additional layer.

Where ReachAI is the wrong tool

ReachAI assumes you can modify the business system, or at minimum scan it. If your ERP is a closed SaaS product with no code access and no page-level integration point, the SDK path is unavailable and the scanning path yields an inventory rather than an executable capability. The README acknowledges this split but does not claim the scanning path produces the same result. ReachAI is also a poor fit if you want a general-purpose agent platform for building standalone AI applications. Its center of gravity is the existing system: original pages, original identity, original permissions. Teams that want to build a new AI-first interface rather than retrofit an old one will find the Capability Catalog and confirmation model to be overhead. Finally, the project is Java-centric. The SDK and Starter are Java and Spring Boot artifacts. A Python or .NET business system can presumably be integrated through the platform's API surface, but the README does not document that path, and nothing in the supplied material describes non-Java SDKs.

How it differs from Dify and personal agent tools

The README draws its own comparison, and it is worth taking at face value while noting what it omits. Dify and similar orchestration platforms are described as focused on creating and publishing AI applications, agents and workflows. ReachAI's stated difference is that it covers system scanning, retrofit recommendation, AI Coding implementation, capability onboarding, real business acceptance and production governance for existing systems. Personal agent tools such as OpenClaw are described as connecting tools and services from a chat entry point to help an individual complete tasks across applications. ReachAI's stated difference is multi-user, multi-system production use, with controlled invocation of authorized capabilities and full tracing. The practical distinction is where the identity and permission boundary sits. In an orchestration platform, you typically build the permission model into the application. In ReachAI, the permission model is the one already running in your OA or ERP, and the platform's job is to respect it. That is a meaningful difference in integration cost and in auditability. It is also a constraint: ReachAI inherits whatever weaknesses exist in the underlying system's authorization.

Maintenance, licensing and what to verify before committing

The project is MIT licensed, which permits commercial use, modification and redistribution with the license and copyright notice preserved. Nothing in the README discusses commercial support, hosted offerings or enterprise licensing terms, and the license implications for embedding the SDK in a proprietary business system are the standard MIT ones. No releases were retrieved, so there is no versioning history to assess. The repository was last pushed on 2026-08-31. The README describes a six-stage pipeline from connection through acceptance, and states that after the initial integration, new AI scenarios reuse the same runtime foundation. That is the maintenance argument: the cost is front-loaded into the first integration. The counterargument is that the platform itself is another system to run, upgrade and keep aligned with the SDK version deployed in each business system. The README mentions capability snapshots and field-level diffs, which implies the platform expects the SDK-reported surface to drift over time and provides tooling for that drift. Whether that tooling is sufficient for a fleet of business systems is not something the supplied material answers.

Editorial conclusion

Adopt ReachAI only if you run Java business systems you can modify, you need AI actions to reuse existing permissions and transactions, and you accept that write operations require explicit user confirmation. Do not adopt it if you want a standalone chatbot builder, if your systems cannot be touched at all, or if you need published deployment and scaling documentation before committing. Verify three things first: that your JDK and Spring Boot versions match the SDK and Starter requirements, that the @ReachCapability annotation and Starter auto-scanning behave as documented in your build, and that the confirmation step for WRITE-level capabilities cannot be bypassed by the Agent or Workflow layer.

Official sources

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