NoES: No? Yes!
Corporate systems built around business needs
Corporate software should help a company get work done. In practice, adopting it often means expensive contracts, lengthy integration projects and complex interfaces to learn. Much of its functionality goes unused, while the changes a company needs depend on the vendor's plans.
Interface complexity is a problem in its own right. When routine tasks require navigating unfamiliar screens and menus, employees can struggle to use the system and resist its adoption, undermining the implementation.
Advances in AI tools and agent-assisted development are making custom software more accessible. Companies have more opportunities to build systems around their own processes and reduce spending on licenses, integration and support.
We are the engineers at RND-PRO.com, and we propose NoES (No Enterprise Software): an approach to building corporate systems from open components, with a reproducible core architecture. It can be adapted to a specific business and expanded as new needs arise.
NoES = NoCRM + NoERP + NoEAM + NoBI + ...
The NoES principle
We propose building a system around a company's data and the workflows of its employees. In this approach, CRM, ERP, EAM and BI functions share a common architecture, where agents work with data and tools under defined access rules.
A conversational UI provides a universal interface in NoES, available out of the box. Employees describe tasks and ask questions in natural language, and agents use the connected data and tools to respond or act within their access permissions. Teams can start working through dialogue without first building a custom interface or learning a separate set of screens for each workflow.
The company chooses the capabilities it needs and decides how they should work. This gives it more freedom to develop the system and keep spending in line with actual business needs.
Core architecture
NoES has three core layers:
- Structured Data Layer - structured data in a relational database, such as PostgreSQL.
- Agentic Layer - agents and an orchestrator, such as OpenClaw, that carry out workflows with access to data and tools.
- Interconnection Layer - connections through MCP, Tools and APIs. This layer defines connection rules, access policies and limits on agent actions.
This separation allows individual parts of the system to be developed as needed. Access control and baseline security requirements are part of the architecture from the start.
Additional components
The choice of additional components depends on the project's needs and scale:
- Docker and orchestration tools: Compose, Swarm or Kubernetes for deployment.
- Semantic search and vector RAG to find and use company knowledge.
- Git for collaboration and version control of agent skills, documentation, contexts, memory and knowledge.
- Web APIs based on REST, RPC or GraphQL for integration with other systems.
- Self-hosted models and auditor agents for additional security and oversight requirements.
What businesses gain
Open core components supported by their communities reduce dependence on a single vendor. The company gains more control over how its system develops and who maintains it.
Ready-made components, plugins and integrations help teams get their first workflows running sooner. Bots, messengers and external services connect through the capabilities of the chosen tools. Custom development can focus on the needs specific to the business.
A modular architecture allows the system to grow gradually and individual workflows to change. Our aim is to make these changes a routine part of the work, without stopping operations or requiring another large implementation project.
Our development: Symbiote Workspace
Symbiote Workspace is a set of ready-made isomorphic modules for workflows involving agents in NoES (Agent-Specific Workflows). We are adapting our libraries to this approach so teams can use existing solutions when building their own systems.
We are developing NoES for companies that want control over their software and the ability to change it as their business evolves. We propose using open components, starting with specific tasks and expanding the system as needed.