NoES -- No Enterprise Software

Enterprise capabilities without enterprise software

Data + Scripts + Agents

Build what you need. Reuse what you build. Let the system evolve.

The Idea

Enterprise software has become unnecessarily complex.

Businesses are often forced to adapt their processes to predefined applications, maintain numerous integrations, pay for functionality they rarely use, and depend on vendors for even minor changes.

CRM, ERP, EAM, BI, and other enterprise systems frequently operate on overlapping data, implement similar operations, and introduce separate interfaces, permissions, workflows, and infrastructure.

The problem is not the functionality these systems provide. The problem is how that functionality is packaged, delivered, and maintained.

Modern AI agents, open-source technologies, and conventional software development tools make a fundamentally different approach possible.

NoES (No Enterprise Software) is an open architectural concept for building business systems that evolve around actual operational needs.

Instead of deploying large applications with predefined functionality, NoES starts with structured data, AI agents, and a growing collection of executable capabilities.

Users describe what they need. Agents discover existing capabilities, execute operations, generate appropriate interfaces, and create new capabilities when necessary.

Successful solutions can become permanent parts of the system, available to everyone with the appropriate permissions.

NoES = NoCRM + NoERP + NoEAM + NoBI + ...

The objective is not to eliminate software, but to eliminate unnecessary software complexity.

The Core Architecture

NoES = Data + Scripts + Agents

Three fundamental components provide the foundation for the entire system.

Data -- The State of the System

Structured data represents the current state of business operations.

A relational database, such as PostgreSQL, stores customers, assets, transactions, inventory, tasks, operational events, and other business entities.

The database infrastructure can also maintain system metadata, including the capability registry, execution history, schedules, access policies, and references to persistent artifacts.

Data remains accessible through standard technologies such as SQL and conventional APIs.

No proprietary enterprise data model is required.

Scripts -- The Capabilities of the System

Everything is a capability. Every capability is a script.

Scripts are the fundamental executable artifacts of NoES.

A script can perform virtually any operation:

• Query or modify business data.
• Create database schemas and migrations.
• Execute business processes and workflows.
• Integrate external services.
• Generate reports and documentation.
• Produce SQL, JSON, Markdown, HTML, CSS, SVG, or other assets.
• Implement interactive user interfaces and dashboards.
• Perform calculations and data transformations.
• Manage system configuration and infrastructure.
• Create or update other system artifacts.

Scripts are ordinary JavaScript modules, executed through Node.js, and organized in a shared, version-controlled repository.

Each script represents an independently discoverable and reusable capability.

A script created to solve one task can subsequently be executed by an agent, a human operator, a scheduled job, an API, or a graphical interface.

The implementation of a capability is independent of how it is invoked.

Agents -- The Intelligence of the System

AI agents provide the reasoning, planning, and orchestration capabilities of NoES.

Agents interpret user requests, inspect available data and capabilities, execute scripts, coordinate workflows, and generate new functionality.

An agent does not need to know every capability in advance.

Instead, it discovers capabilities through the registry, examines their documentation and contracts, and selects the appropriate operations.

When a required capability does not exist, an agent can propose creating it.

After validation and approval, the new capability becomes a permanent part of the system, available to other agents, users, and automated processes.

Agents are replaceable. The knowledge and capabilities accumulated by the system are not tied to any particular model or agent framework.

The Script Registry

The NoES Script Registry is the central architectural mechanism connecting data, agents, and executable functionality.

Scripts are registered under hierarchical semantic identifiers:

db.schema.inspect
db.query
db.migration.create

crm.customers.add
crm.customers.search
crm.customers.dashboard

inventory.stock.update

finance.invoices.generate
finance.reports.monthly

workspace.dashboard.render
workspace.dashboard.create

system.scripts.register
system.scripts.describe

Each registered capability contains:

• A unique semantic identifier.
• An executable entry point.
• A human-readable Markdown description.
• Machine-readable input and output contracts.
• Access requirements and execution policies.
• Version and source-code references.
• Optional dependencies and execution settings.

The registry provides hierarchical navigation and semantic discovery.

Agents can progressively explore available functionality without loading the entire capability catalog into their context.

Universal Execution

Scripts follow a common execution contract.

The same capability can be invoked through an AI agent, direct command-line execution, scheduled automation, HTTP API, user interface control, or another script.

For example:

noes run crm.customers.add \
  --input '{"name":"Alice"}'

The noes command is a lightweight execution interface, not a mandatory application server or protocol.

The underlying scripts remain ordinary JavaScript modules that can be executed through Node.js.

A common execution layer provides authorization, input validation, execution context, logging, and approval handling.

Individual scripts implement additional business logic and domain-specific validation.

Beyond MCP

NoES does not require MCP servers to expose its internal capabilities to agents.

Instead, agents interact with executable scripts through a simple, discoverable command-line interface.

This reduces protocol-specific infrastructure and allows capabilities to be developed, tested, versioned, and executed using conventional software development tools.

MCP remains useful as an optional interoperability mechanism, particularly when connecting external tools or exposing NoES capabilities to other agent environments.

MCP is an adapter. Scripts are the capabilities.

Capabilities as Persistent Knowledge

NoES introduces a practical form of accumulated operational knowledge.

Traditional agent systems often solve tasks through temporary sequences of reasoning and tool calls.

The results may be useful, but the procedure itself is not necessarily preserved as reusable functionality.

NoES encourages agents to transform successful solutions into permanent executable artifacts.

Consider a user requesting a new customer management workflow.

An agent can:

1. Inspect existing database schemas and registered capabilities.
2. Identify missing data structures or operations.
3. Generate the required SQL migrations.
4. Propose new scripts for managing customers.
5. Generate tests and documentation.
6. Request approval for the proposed changes.
7. Register the approved capabilities.
8. Execute them and present the results.

The next time a similar task appears, the agent can reuse the existing functionality instead of reconstructing the solution.

Over time, the system accumulates an expanding collection of tested and documented capabilities.

NoES evolves by converting operational experience into reusable code.

This is not model training or autonomous learning in the machine-learning sense. It is persistent, inspectable, version-controlled functional development.

Dynamic Artifact Generation

A capability does not have to return a simple JSON object or modify a database.

It can generate any kind of structured or textual artifact.

NoES adopts the principles of JavaScript Distributed Assets (JSDA) for dynamic artifact generation.

JSDA treats standard JavaScript ESM modules as text-generation endpoints, avoiding the need for specialized template languages and proprietary transformation pipelines.

Scripts can use JSDA to produce:

• SQL schemas and migrations.
• Markdown documentation.
• Reports and business correspondence.
• Agent instructions and knowledge files.
• Configuration files.
• JSON and other structured data.
• HTML, CSS, and SVG.
• Interactive interface templates.
• Application and infrastructure artifacts.

For example:

db.migration.generate
docs.project.summary
finance.reports.monthly
ui.dashboard.generate

All these operations follow the same Script Registry model.

JSDA is not a separate execution subsystem. It is a reusable generation mechanism available to scripts.

Generated artifacts may be returned directly, stored in the database, written to files, published through APIs, or committed to Git.

When appropriate, generation logic and its dependencies are version-controlled to support reproducibility.

A document, an SQL migration, and an interactive interface are different outputs of the same capability model.

Adaptive and Persistent Interfaces

Conversation is the universal entry point, but not the only user interface.

Natural language is convenient for expressing intentions, exploring information, and initiating complex tasks.

However, not every interaction is best represented as a conversation.

Editing hundreds of records, comparing metrics, navigating large datasets, or managing operational workflows often requires structured, interactive interfaces.

NoES addresses this through dynamically generated and reusable user interfaces.

We call this approach Symbiote Workspace.

UI as an Agent-Generated Answer

Instead of requiring developers to design every screen in advance, agents can generate an interface appropriate to the current task.

A user might request:

"Show our active customers and let me edit their contact details."

The agent discovers the relevant capabilities, retrieves the necessary data, and generates an interactive interface containing a customer table, search controls, and editing forms.

The interface invokes existing registered scripts to perform operations.

It does not introduce a separate implementation of business logic.

The same customer-management capabilities remain accessible through the CLI, conversational interface, API, or scheduled workflows.

Two Lifecycles of Generated UI

NoES distinguishes between two forms of agent-generated interfaces.

Ephemeral UI -- Interfaces for the Current Context

An ephemeral interface is generated as part of an agent's response to a specific request.

It may contain a chart, table, form, visualization, or interactive component assembled for the current conversation.

Its purpose is to provide an effective representation of information or an immediate way to complete a task.

It does not necessarily need to exist beyond the current interaction.

Persistent UI -- Interfaces as System Artifacts

A persistent interface is created for repeated use.

Like an executable script, it becomes a registered, version-controlled artifact of the system.

Examples include:

• Operational dashboards.
• Customer and inventory management panels.
• Financial reporting workspaces.
• Asset monitoring interfaces.
• Administrative consoles.
• Task-specific applications and reusable forms.

A persistent interface can have a stable identifier, defined configuration, access permissions, version history, and an established location within Symbiote Workspace.

It can be opened directly, bookmarked, shared with authorized users, or invoked by an agent.

Its implementation may consist of a script that generates the interface, a reusable RAT template, associated components, and configuration.

The interface can be updated as business requirements evolve without losing its identity or established interaction model.

An agent-generated interface has the same opportunity to become a permanent system capability as any other script.

Consistency Is a Feature

Dynamic interface generation must not mean constantly changing interfaces.

Users develop habits and operational familiarity. Repeatedly generating different layouts for the same task would undermine usability and increase cognitive overhead.

NoES therefore treats persistent interfaces as stable, reusable workspaces rather than disposable visualizations.

Once an interface proves useful, it can be preserved and refined incrementally.

The agent should prefer an existing suitable interface over generating a new one.

Users should not have to relearn the same workflow each time they return to it.

Generate when necessary. Preserve when useful. Reuse by default.

Symbiote RAT

Symbiote.js provides a foundation for this approach through its Runtime Agnostic Templates (RAT) architecture.

RAT separates declarative HTML templates and their named bindings from component instances, rendering functions, and execution environments.

Templates can be composed, customized, rendered, and reused across client-side and server-side environments.

Combined with native Web Components and standard browser technologies, this provides a practical foundation for:

• Dynamically generated interactive interfaces.
• Persistent dashboards and operational panels.
• Reusable UI components and templates.
• Declarative data and action bindings.
• Client-side and server-side rendering.
• Task-oriented workspaces.
• Agent-assisted interface composition and maintenance.

A registered script may generate or serve a Symbiote RAT representation, which is then rendered by a compatible interface runtime.

The interface may be ephemeral or persistent, depending on its intended lifecycle.

The distinction concerns persistence and reuse, not the underlying execution architecture.

Agents as Interface Assistants

Once a persistent interface exists, the agent's role can change.

Instead of repeatedly generating new UI, the agent can help users understand and operate the existing workspace.

Symbiote.js provides a WebMCP integration that allows component actions to be exposed as tools for AI agents.

A handler associated with a UI control can also become an agent-accessible action.

These tools can include descriptions, input schemas, and contextual information, with availability reflecting the current component and application state.

This enables a shared interaction model:

• A user can operate an interface directly.
• An agent can explain available controls and workflows.
• An agent can assist with navigation and data entry.
• An agent can invoke exposed interface actions on the user's behalf.
• Human and agent interactions can use the same underlying application behavior.

For example, a user working in an inventory dashboard might ask:

"How do I transfer these items to another warehouse?"

The agent can identify the relevant interface action, explain the procedure, or help perform it within the user's authorized context.

The agent becomes an assistant inside the existing application rather than a replacement for its interface.

WebMCP complements the NoES Script Registry: the registry exposes persistent system capabilities, while WebMCP makes the actions and context of a rendered interface accessible to agents.

Both must respect the same underlying authorization policies.

One Capability, Multiple Representations

A capability may return data, generate an artifact, or implement an interactive interface.

For example:

crm.customers.list
crm.customers.export
crm.customers.dashboard

These are different capabilities operating on the same underlying business data and reusable operations.

A persistent dashboard may compose several registered capabilities, while its own generation or rendering entry point is also registered as a script.

Symbiote Workspace is not an independent business application platform.

It is the persistent and interactive environment through which people and agents access NoES capabilities.

The interface adapts when necessary, persists when useful, and remains familiar when reused.

Git-Native Evolution

Git provides the foundation for collaborative development and version control.

Scripts, metadata, documentation, tests, migrations, agent instructions, reusable UI components, and persistent workspace definitions can coexist in a common monorepository.

The database maintains the operational registry and runtime state, while Git preserves the history of system definitions and implementation changes.

This architecture allows humans and agents to use established software development practices:

• Branching and code review.
• Automated testing.
• Change tracking.
• Reproducible deployments.
• Rollback and version management.
• Collaborative development.
• Infrastructure as code.

New capabilities and persistent interfaces can be proposed by agents, reviewed by users, tested, and incorporated into the repository.

The registry is synchronized with approved repository revisions.

This keeps system functionality transparent and portable.

NoES does not require a proprietary application builder or dedicated workflow editor to develop its capabilities.

The repository is the source of executable knowledge. The registry makes that knowledge discoverable and operational.

Why JavaScript?

The choice of JavaScript as the primary language for NoES executable capabilities is deliberate.

It is not based on language popularity alone, nor on the assumption that JavaScript is universally superior to other programming languages.

JavaScript offers a particularly valuable combination of properties for an agent-driven, script-first, cross-runtime architecture.

Accessibility and Developer Ecosystem

JavaScript is one of the most widely used programming languages, with a large global developer community and a relatively low barrier to entry.

This makes NoES capabilities easier to understand, maintain, extend, and audit without requiring specialists in a proprietary platform or uncommon language.

Its extensive ecosystem provides mature libraries for database access, networking, data processing, cryptography, document generation, testing, and integration with external systems.

Many business capabilities can be implemented using existing packages rather than developing specialized infrastructure.

Truly Isomorphic Code

JavaScript runs natively in web browsers and server-side runtimes such as Node.js.

This makes it possible to share actual executable modules between client-side interfaces, server-side operations, automation scripts, and development tools.

Business rules, data transformations, validation logic, schemas, and utility functions can be implemented once and reused across execution environments.

This has implications beyond conventional code reuse:

• Less duplicated functionality and fewer inconsistencies.
• Smaller overall codebases and reduced maintenance overhead.
• Fewer runtime-specific abstractions.
• Smaller and more coherent project contexts for AI agents.
• More efficient code generation, analysis, and modification by LLMs.

Not every module can be executed in every environment: platform-specific APIs and permissions still apply. However, the shared language and module system significantly reduce the boundaries between them.

For agent-driven development, reducing the amount of code and contextual information required to understand a system is an architectural advantage.

Direct Execution Without a Build Pipeline

Modern JavaScript supports native ECMAScript Modules (ESM).

An ordinary .js or .mjs file can serve directly as an executable entry point:

node ./scripts/crm/customers/add.mjs

No mandatory compilation, transpilation, bundling, or framework-specific build process is required.

This is especially valuable for NoES, where agents frequently create, inspect, modify, and execute small, independent capabilities.

A generated script can become executable immediately after validation and authorization.

The absence of a mandatory build step simplifies the development loop, improves source-code transparency, and reduces the number of intermediate artifacts an agent must manage.

Static Analysis Without Mandatory Transpilation

JavaScript does not require abandoning static analysis or type-checking tooling.

TypeScript provides a mature type-checking system that can analyze ordinary JavaScript through JSDoc annotations, declaration files (.d.ts), and configuration options such as checkJs and strict.

This allows NoES to combine:

• Direct execution of standard JavaScript.
• Static type checking during development and CI.
• Explicit type contracts through JSDoc.
• Reusable type definitions through TypeScript declaration files.
• IDE autocompletion, navigation, and diagnostics.
• No mandatory TypeScript-to-JavaScript compilation step.

TypeScript can therefore serve as a development-time verification tool without becoming a required runtime language.

Static checking does not replace runtime validation, but it provides an additional layer of correctness while preserving the simplicity of executable JavaScript modules.

High Performance Where Necessary

Modern JavaScript engines employ sophisticated just-in-time compilation and runtime optimization.

For computationally intensive operations, JavaScript can integrate WebAssembly modules compiled from languages such as Rust, C, or C++.

This enables a practical division of responsibilities:

JavaScript for orchestration, integration, and business logic; WebAssembly or native modules for specialized high-performance computation.

The Script Registry can expose such functionality through the same execution contract, without requiring agents or users to understand the underlying implementation language.

Standardized, Portable, and Inspectable

JavaScript is standardized through ECMAScript and supported by multiple independent engines and runtimes.

ESM provides a common module format across modern browsers and server-side environments.

Unlike proprietary workflow definitions or platform-specific scripting languages, ordinary JavaScript source code remains readable, editable, testable, and executable using widely available tools.

This aligns with the NoES principles of portability, transparency, and reduced vendor dependence.

Why Not Python, TypeScript, or Another Language?

Python is an excellent language for automation, data processing, and AI development. However, it lacks native execution in standard web browsers, making truly shared client-server modules more difficult.

TypeScript provides stronger static tooling, but conventional TypeScript workflows introduce an additional source-processing step or depend on runtimes with TypeScript-specific support. NoES can obtain most of its development-time type-checking benefits while executing standard JavaScript directly.

Languages such as Rust, Go, and C++ offer advantages in performance, static guarantees, and systems programming, but generally require compilation and cannot execute natively as source code in browsers.

Other languages and runtimes may satisfy individual requirements, but few provide the same combination of native browser support, server-side execution, direct module execution, ecosystem maturity, and optional static typing.

JavaScript is not the only possible language for NoES. It is the most practical common denominator across its intended execution environments.

A Default, Not a Restriction

NoES does not prohibit capabilities implemented in other languages.

A JavaScript script may invoke a native executable, load a WebAssembly module, interact with an external service, or delegate computation to a specialized runtime.

The universal contract belongs to the Script Registry, not to the implementation language.

JavaScript is the default because it minimizes the complexity of the common case while preserving access to specialized technologies when necessary.

One language across agents, automation, server-side operations, and browser interfaces. One module system. Minimal build infrastructure. Maximum reuse.

Security and Human Control

Agent-driven development requires explicit boundaries between reasoning, code generation, authorization, and execution.

NoES separates the ability to propose an operation from the authority to execute it.

The execution environment enforces access controls independently of individual script implementations.

Scripts may provide additional validation and business-specific restrictions, but they cannot be trusted to define their own effective privileges.

Operations can be classified by risk, including read-only access, data modification, destructive changes, and administrative actions.

Sensitive operations may require explicit human confirmation.

Agent-generated scripts and interfaces must be validated before activation, with additional isolation for untrusted code.

Generated interfaces must not be able to bypass execution policies or access data beyond the permissions of the invoking user.

Execution records provide traceability, including the initiating actor, script version, parameters, approvals, and results.

The same security model applies regardless of whether a script is invoked by an agent, user, scheduler, API, or generated interface.

Agents may extend the system, but they do not independently grant themselves authority.

Minimalism and Open Architecture

NoES favors simplicity over unnecessary abstraction.

The initial implementation does not require a distributed microservice architecture, dedicated automation servers, complex integration platforms, or multiple application backends.

A functional NoES environment can begin with:

• PostgreSQL.
• Node.js.
• A Git repository.
• An AI agent with access to the Script Registry.

Additional capabilities emerge through scripts and conventional dependencies.

Technologies such as Docker, message queues, schedulers, HTTP services, and specialized execution environments can be introduced when operational requirements justify them.

The architecture is designed to remain independent of any particular AI model, cloud provider, or orchestration framework.

Reference Technologies

RND-PRO develops and uses several technologies that complement this approach:

JSDA -- JavaScript Distributed Assets, for generating textual and structured artifacts from ESM modules.

Symbiote.js -- Isomorphic Web Components, Runtime Agnostic Templates, and WebMCP integration for reusable and agent-accessible interfaces.

Symbiote Workspace -- the proposed environment for ephemeral and persistent agent-generated interfaces, dashboards, and operational workspaces.

These are reference implementations and building blocks, not mandatory dependencies of the NoES concept.

The defining architectural contract remains the same: discoverable, executable, reusable capabilities.

What NoES Changes

From Applications to Capabilities

Traditional enterprise software groups functionality into large applications.

NoES organizes functionality into independently reusable scripts.

A business no longer needs an entire CRM platform just to manage customer records, or a complete BI suite to generate operational reports.

It needs the relevant capabilities.

From Fixed Interfaces to Adaptive and Persistent Workspaces

Traditional systems expose functionality through predefined screens.

NoES allows interfaces to be generated or assembled according to actual tasks.

Useful interfaces can then become permanent, familiar workspaces rather than being regenerated from scratch.

Dynamic generation and interface consistency are complementary, not competing goals.

From Integration to Shared Execution

Traditional enterprise architectures frequently connect applications through complex integrations.

NoES encourages capabilities to operate on shared, explicitly governed data and reuse a common execution model.

External integrations remain possible where needed.

From Customization to Evolution

Traditional enterprise customization often introduces vendor-specific code, configuration, and maintenance dependencies.

NoES extends functionality through ordinary, version-controlled scripts and reusable UI artifacts.

Agents can participate in this development process, reducing the effort required to implement small operational changes.

From Disposable Automation to Accumulated Capabilities

A temporary agent workflow solves a single problem.

A registered capability becomes a reusable part of the system.

An ephemeral interface helps complete an immediate task.

A persistent workspace becomes a familiar tool for repeated work.

The more business processes are formalized as reusable capabilities, the more useful the system becomes.

The Long-Term Vision

NoES proposes a different relationship between organizations and their software.

Instead of selecting a collection of enterprise applications and adapting business processes to their constraints, organizations maintain a shared environment of data and executable capabilities.

AI agents help people operate and extend that environment.

Interfaces can emerge from tasks, but successful interfaces do not have to disappear when the conversation ends.

They can become stable, persistent applications that users understand, trust, and return to.

Agents can then assist users within those applications, helping them navigate, understand, and operate existing functionality.

Business processes become reusable code rather than hidden application configuration.

Knowledge becomes executable where appropriate.

New functionality is developed incrementally, based on actual needs rather than speculative feature planning.

The resulting system is not necessarily smaller in total functionality. It is smaller in unnecessary structure.

Its complexity grows only where the business requires it.

The ultimate objective is not a fully autonomous enterprise controlled by AI.

It is an environment where humans and agents collaborate through transparent, reusable, and controllable software capabilities.

Software should evolve with the organization, not force the organization to evolve around software.

About NoES

NoES is an open architectural initiative by RND-PRO, an R&D engineering team focused on practical software innovation, automation, and alternative approaches to complex information systems.

The project explores how AI agents, conventional programming languages, structured data, and dynamically generated interfaces can replace unnecessary layers of traditional enterprise software.

NoES is an evolving concept and reference architecture. Its individual components may be implemented independently and adopted incrementally.

We welcome discussion, experimentation, and collaboration.

NO ENTERPRISE SOFTWARE