ReachAI Enterprise Agent Platform
An enterprise agent foundation for existing Java business systems, letting AI query data, fill forms, and execute tasks inside OA, ERP, and CRM.
README systematically describes least-privilege and confirmation policy (READ auto, PAGE_ACTION needs page intent, WRITE needs one confirmation, IRREVERSIBLE denied by default; Capability whitelist, Tool ACL, short-lived tokens, backend final authz, Trace audit), with a @ReachCapability annotation example as code corroboration. Deduction: these governance mechanisms exist only as README prose plus one annotation sample; the actual Guard/ACL/confirmation implementation is not in the reviewed files; sensitive-data handling rests on env-template and dev-default-disabling claims unverified in code; rollback appears only as a 'revoke' mention for Skills; publisher is unverified account w8123, attributable only via the MIT copyright line.
The README is largely self-consistent (five services, ports, table ownership, quick-start steps agree) with explicit stack versions; docker compose and an SQL baseline support availability. Deduction: concrete failure messages and degradation behavior are only vaguely referenced at RunOps level with no code evidence; test coverage is unclear (one OpenAPI fixture seen).
Audience (legacy Java enterprise systems: OA/ERP/CRM), three roles, and four scenarios are well described with clear boundaries (JDK8 SDK / Spring Boot 2 Starter, BETA node tiering). Deduction: trigger precision relies on described whitelists/page intent without implementation shown; environment fit is limited to the Java/Spring stack and README admits it describes only the current main path.
Documentation architecture is clear (AGENTS.md, docs navigation, SQL baseline, service-boundary doc); quick start includes prerequisites and stepwise commands; 'current implementation boundary' honestly concedes incompleteness; naming (five services, ports, core objects) is stable, so deductions are minor. Deduction: no CHANGELOG or release/versioning record; maintenance responsibility is only a fast-iteration self-description plus a chat-group image, with no governance path; examples are README illustrations rather than runnable samples.
Output usability is supported by designed Trace/replay/EvalOps/acceptance evidence chains, and differentiation from Dify/OpenClaw (retrofitting existing systems) is clearly stated. Deduction: cost-benefit is asserted via Token/latency statistics without data; the value proposition remains at design-description level since nothing was executed.
The README explicitly separates confirmedFact/technicalInference/openQuestion and provides pointers to code and docs (Page Bridge source, service-table-ownership doc), which is good traceability design. Deduction: only three files were reviewed, so most README claims (screenshots, governance implementation, acceptance flow) cannot be cross-corroborated against other source; the sole test fixture covers only the scanner.
- This is a static review based only on README, LICENSE, and one test fixture; all governance claims (Tool ACL, Guard, confirmation policy, short-lived tokens, backend authz) are unverified in code — audit the actual implementations in reachai-runtime-service and reachai-control-service before production use.
- Local development injects public crypto/signing defaults and pre-fills admin/admin123; ensure REACHAI_LOCAL_AUTH_ENABLED=false and REACHAI_BOOTSTRAP_ADMIN_ENABLED=false in production and inject independent secrets from a Secret manager.
- Publisher is an unverified personal account with no changelog or explicit maintenance commitment; assess long-term maintenance risk before adopting.
- Policies such as IRREVERSIBLE deny-by-default and WRITE confirmation are documentation claims; verify their code paths actually enforce them before connecting real business systems.
What does this agent do, and when should you use it?
ReachAI (repository w8123/EnterpriseAgentFramework) is an MIT-licensed, open-source enterprise agent development and runtime platform designed to quickly and safely bring AI into existing business systems. It consists of five Spring Boot services: model-service (model gateway), knowledge-service (knowledge base and RAG), control-service (public API and identity), runtime-service (agent and workflow execution), and capability-service (capability catalog). Business systems register their capabilities through a JDK 8-compatible Capability SDK / Spring Boot 2 Starter, while ReachAI Embed and Page Bridge embed a chat entry into original pages and explicitly register page actions. At runtime, an AgentScope Supervisor handles intent understanding and task planning, selects whitelisted Workflow-as-Tool entries, and executes version-pinned GraphSpec workflows; reads, writes, and page actions are constrained by Tool ACL, risk levels, and user confirmation, with full Trace capture and replay in RunOps. The Vue 3 + TypeScript admin console covers system scanning, refactoring recommendations, AI Coding tasks, capability release, acceptance, and runtime governance.
The platform works in two phases. Build phase: it registers business systems and scans pages, routes, and APIs to build a capability map; performs read-only analysis on selected pages to output refactoring candidates annotated with confirmedFact, codeReferences, and acceptanceCriteria; packages refactoring needs into standardized tasks handed to Codex, Trae, Cursor, or Claude Code with evidence returned for closure; and captures Java interfaces via the @ReachCapability annotation into a Capability Catalog with field-level diffs and apply/ignore review. Run phase: employees invoke requests through Embed chat on original business pages; the Supervisor plans and selects 0/1/many authorized workflows; the GraphSpec Executor runs the pinned version. READ runs automatically, PAGE_ACTION requires explicit page intent, WRITE requires one confirmation, and IRREVERSIBLE is denied by default; calls to real capabilities carry a short-lived business-user token with final authorization by the original backend. The platform also provides Workflow Studio (visual/AI GraphSpec authoring), Automation, EvalOps (versioned datasets and release gates), and MCP Hub / A2A Hub to expose governed capabilities and workflows as MCP tools or remote agents.
- Enterprises using an OA system: employees summarize today's to-dos and open the most urgent item via natural language without switching apps
- eHR teams: AI queries this month's abnormal attendance and filters unprocessed records
- Procurement departments: AI drafts office-supply purchase requests, requiring user confirmation before submission
- CRM sales: AI generates follow-up plans from this week's customer activity
- Teams with legacy Java systems lacking API documentation: use page scanning and capability snapshots for evidence-based system inventory
- Platform administrators: continuously evaluate agent version performance via EvalOps and triage failures via RunOps
What are this agent's strengths and limitations?
- Differentiated positioning: beyond building AI apps, it covers the full loop of legacy system scanning, refactoring recommendations, AI Coding implementation, capability onboarding, real acceptance, and production governance
- Complete governance evidence chain: capability whitelists, Tool ACL, risk-tiered execution (READ auto / WRITE confirmed / IRREVERSIBLE denied), business-user tokens, and full Trace replay
- Agents handle flexible planning while version-pinned GraphSpec workflows execute mature business reliably, balancing new needs and determinism
- Page automation relies on explicitly registered action contracts rather than screenshot recognition and mouse simulation
- Open protocol ecosystem: MCP Hub and A2A Hub expose governed capabilities and remote agents; model access via an OpenAI-compatible gateway
- The project states it is in rapid iteration; the README acknowledges not all capabilities are production-complete and some workflow nodes remain BETA
- Heavy deployment: requires MySQL 8, Redis 7, Milvus 2.4, and five Java services, making ops cost higher than lightweight agent frameworks
- Primarily targets the Java/Spring ecosystem (JDK 8 SDK + Spring Boot 2 Starter); non-Java legacy systems can only be supplemented via scanning
- The five services currently share one MySQL instance with ownership boundaries enforced by convention and internal APIs, posing migration risk as the architecture evolves
- The screenshot-environment execution engine in Automation is not yet enabled; governance surfaces (ACL, Guard, open protocols) are still being productized
How do you install or deploy this agent?
Requirements: JDK 17, Maven, Node.js with npm, Docker Compose. Steps:
- Copy the credentials template and start infrastructure:
cp deploy/.env.example deploy/.env
docker compose --env-file deploy/.env -f deploy/docker-compose.infra.yml up -d
mysql --default-character-set=utf8mb4 -h localhost -u root -p -e "source sql/initV2.sql"- Build the backend:
mvn clean install -DskipTests - Start the five services: run
.run/00-reachai-five-services.run.xmlin IntelliJ IDEA, or executemvn spring-boot:runper service (model 18601, knowledge 18602, control 18603, runtime 18604, capability 18605). Local development mode auto-injects development-only secrets, so no SECRET env vars are needed for evaluation. - Start the admin console:
cd ai-admin-front
npm ci
npm run devLocal open-source mode ships a pre-filled admin / admin123 account for local development only; production must set REACHAI_LOCAL_AUTH_ENABLED=false, REACHAI_BOOTSTRAP_ADMIN_ENABLED=false, and integrate a real identity system.
How do you use this agent?
Integration path: add the Capability SDK / Spring Boot 2 Starter to modifiable Java systems and annotate business methods with @ReachCapability (name, domain, sideEffect, requiredRoles metadata); the Starter auto-scans annotated methods and Spring MVC interfaces, reporting heartbeats and signed snapshots. In the Capability Catalog, review snapshots with apply/ignore and authorize them. Then use Workflow Studio to author or AI-generate GraphSpec workflows, validate, and publish; configure Agent pinned versions, usage scope, and the Workflow-as-Tool whitelist. On the frontend, integrate ReachAI Embed and eafPageBridge.ts in business pages and explicitly register filter, navigation, and form actions. After launch, use Automation for scheduled runs, EvalOps for version comparisons, and RunOps for failure triage. Detailed references: docs/reference/SDK接入与EmbedChat快速参考.md and docs/reference/Workflow-AI-Coding.md.
How does this agent compare with similar options?
The README directly compares two alternatives: Dify-style AI application orchestration platforms focus on creating and publishing AI apps, agents, and workflows; OpenClaw-style personal agents focus on cross-app task execution from a chat entry for individuals. ReachAI instead targets existing enterprise business systems, covering system scanning, refactoring recommendations, AI Coding implementation, capability onboarding, real business acceptance, and production-grade runtime governance, with confirmation for critical operations and full traceability.