NoES -- No Enterprise Software
Capacidades empresariales sin software empresarial
Datos + Scripts + Agentes
Construya lo que necesita. Reutilice lo que construye. Deje que el sistema evolucione.
La idea
El software empresarial se ha vuelto innecesariamente complejo.
Las empresas suelen verse obligadas a adaptar sus procesos a aplicaciones predefinidas, mantener numerosas integraciones, pagar por funciones que apenas utilizan y depender de los proveedores incluso para cambios menores.
CRM, ERP, EAM, BI y otros sistemas empresariales suelen trabajar con datos que se superponen, implementar operaciones similares e introducir interfaces, permisos, flujos de trabajo e infraestructuras separados.
El problema no es la funcionalidad que ofrecen estos sistemas, sino cómo se agrupa, se entrega y se mantiene.
Los agentes de IA modernos, las tecnologías de código abierto y las herramientas convencionales de desarrollo de software permiten un enfoque fundamentalmente distinto.
NoES (No Enterprise Software) es un concepto arquitectónico abierto para crear sistemas de negocio que evolucionan en torno a las necesidades operativas reales.
En lugar de desplegar grandes aplicaciones con funciones predefinidas, NoES parte de datos estructurados, agentes de IA y un conjunto creciente de capacidades ejecutables.
Los usuarios describen lo que necesitan. Los agentes descubren las capacidades existentes, ejecutan operaciones, generan interfaces adecuadas y crean nuevas capacidades cuando hace falta.
Las soluciones exitosas pueden convertirse en partes permanentes del sistema, disponibles para todas las personas que tengan los permisos correspondientes.
NoES = NoCRM + NoERP + NoEAM + NoBI + ...
El objetivo no es eliminar el software, sino su complejidad innecesaria.
La arquitectura base
NoES = Datos + Scripts + Agentes
Tres componentes fundamentales constituyen la base de todo el sistema.
Datos -- el estado del sistema
Los datos estructurados representan el estado actual de las operaciones del negocio.
Una base de datos relacional, como PostgreSQL, almacena clientes, activos, transacciones, inventario, tareas, eventos operativos y otras entidades del negocio.
La infraestructura de base de datos también puede mantener los metadatos del sistema, incluidos el registro de capacidades, el historial de ejecución, las programaciones, las políticas de acceso y las referencias a artefactos persistentes.
Los datos siguen siendo accesibles mediante tecnologías estándar, como SQL y API convencionales.
No se necesita un modelo de datos empresariales propietario.
Scripts -- las capacidades del sistema
Todo es una capacidad. Cada capacidad es un script.
Los scripts son los artefactos ejecutables fundamentales de NoES.
Un script puede realizar prácticamente cualquier operación:
- Consultar o modificar datos del negocio.
- Crear esquemas de base de datos y migraciones.
- Ejecutar procesos de negocio y flujos de trabajo.
- Integrar servicios externos.
- Generar informes y documentación.
- Producir SQL, JSON, Markdown, HTML, CSS, SVG u otros recursos.
- Implementar interfaces de usuario interactivas y paneles de control.
- Realizar cálculos y transformaciones de datos.
- Gestionar la configuración del sistema y la infraestructura.
- Crear o actualizar otros artefactos del sistema.
Los scripts son módulos JavaScript convencionales, ejecutados mediante Node.js y organizados en un repositorio compartido con control de versiones.
Cada script representa una capacidad que se puede descubrir y reutilizar de forma independiente.
Un script creado para resolver una tarea puede ejecutarse después mediante un agente, un operador humano, una tarea programada, una API o una interfaz gráfica.
La implementación de una capacidad es independiente de la forma en que se invoca.
Agentes -- la inteligencia del sistema
Los agentes de IA aportan las capacidades de razonamiento, planificación y orquestación de NoES.
Los agentes interpretan las solicitudes de los usuarios, examinan los datos y las capacidades disponibles, ejecutan scripts, coordinan flujos de trabajo y generan nuevas funciones.
Un agente no necesita conocer de antemano todas las capacidades.
Las descubre mediante el registro, examina su documentación y sus contratos, y selecciona las operaciones adecuadas.
Cuando una capacidad necesaria no existe, un agente puede proponer su creación.
Tras su validación y aprobación, la nueva capacidad pasa a formar parte permanente del sistema y queda disponible para otros agentes, usuarios y procesos automatizados.
Los agentes son reemplazables. El conocimiento y las capacidades que acumula el sistema no están vinculados a ningún modelo ni framework de agentes en particular.
El registro de scripts
El registro de scripts de NoES (NoES Script Registry) es el mecanismo arquitectónico central que conecta los datos, los agentes y la funcionalidad ejecutable.
Los scripts se registran con identificadores semánticos jerárquicos:
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
Cada capacidad registrada contiene:
- Un identificador semántico único.
- Un punto de entrada ejecutable.
- Una descripción en Markdown comprensible para las personas.
- Contratos de entrada y salida legibles por máquinas.
- Requisitos de acceso y políticas de ejecución.
- Referencias a la versión y al código fuente.
- Dependencias y ajustes de ejecución opcionales.
El registro permite la navegación jerárquica y el descubrimiento semántico de capacidades.
Los agentes pueden explorar progresivamente las funciones disponibles sin cargar todo el catálogo de capacidades en su contexto.
Ejecución universal
Los scripts siguen un contrato de ejecución común.
La misma capacidad se puede invocar mediante un agente de IA, ejecución directa desde la línea de comandos, automatización programada, una API HTTP, un control de la interfaz de usuario u otro script.
Por ejemplo:
noes run crm.customers.add \
--input '{"name":"Alice"}'
El comando noes es una interfaz de ejecución ligera, no un servidor de aplicaciones ni un protocolo obligatorios.
Los scripts subyacentes siguen siendo módulos JavaScript convencionales que se pueden ejecutar mediante Node.js.
Una capa de ejecución común proporciona autorización, validación de entradas, contexto de ejecución, registro de eventos y gestión de aprobaciones.
Cada script implementa la lógica de negocio adicional y las validaciones específicas de su dominio.
Más allá de MCP
NoES no necesita servidores MCP para ofrecer sus capacidades internas a los agentes.
Los agentes interactúan con scripts ejecutables mediante una interfaz de línea de comandos sencilla que permite descubrir las capacidades disponibles.
Esto reduce la infraestructura específica de cada protocolo y permite desarrollar, probar, versionar y ejecutar capacidades con herramientas convencionales de desarrollo de software.
MCP sigue siendo útil como mecanismo opcional de interoperabilidad, especialmente para conectar herramientas externas u ofrecer capacidades de NoES a otros entornos de agentes.
MCP es un adaptador. Los scripts son las capacidades.
Las capacidades como conocimiento persistente
NoES propone una forma práctica de acumular conocimiento operativo.
Los sistemas de agentes tradicionales suelen resolver tareas mediante secuencias temporales de razonamiento y llamadas a herramientas.
Los resultados pueden ser útiles, pero el procedimiento en sí no siempre se conserva como funcionalidad reutilizable.
NoES promueve que los agentes transformen las soluciones exitosas en artefactos ejecutables permanentes.
Pensemos en un usuario que solicita un nuevo flujo de trabajo para gestionar clientes.
Un agente puede:
- Examinar los esquemas de base de datos existentes y las capacidades registradas.
- Identificar las estructuras de datos u operaciones que faltan.
- Generar las migraciones SQL necesarias.
- Proponer nuevos scripts para gestionar clientes.
- Generar pruebas y documentación.
- Solicitar la aprobación de los cambios propuestos.
- Registrar las capacidades aprobadas.
- Ejecutarlas y presentar los resultados.
Cuando surja una tarea similar, el agente podrá reutilizar las funciones existentes en lugar de reconstruir la solución.
Con el tiempo, el sistema acumula un conjunto cada vez mayor de capacidades probadas y documentadas.
NoES evoluciona al convertir la experiencia operativa en código reutilizable.
Esto no es entrenamiento de modelos ni aprendizaje autónomo en el sentido del aprendizaje automático. Es desarrollo funcional persistente, que se puede examinar y está sujeto a control de versiones.
Generación dinámica de artefactos
Una capacidad no tiene por qué devolver un simple objeto JSON ni modificar una base de datos.
Puede generar cualquier tipo de artefacto estructurado o textual.
NoES adopta los principios de JavaScript Distributed Assets (JSDA) para la generación dinámica de artefactos.
JSDA trata los módulos ESM estándar de JavaScript como puntos de generación de texto, sin necesidad de lenguajes de plantillas especializados ni de procesos de transformación propietarios.
Los scripts pueden utilizar JSDA para producir:
- Esquemas SQL y migraciones.
- Documentación en Markdown.
- Informes y correspondencia comercial.
- Instrucciones para agentes y archivos de conocimiento.
- Archivos de configuración.
- JSON y otros datos estructurados.
- HTML, CSS y SVG.
- Plantillas de interfaces interactivas.
- Artefactos de aplicaciones e infraestructura.
Por ejemplo:
db.migration.generate
docs.project.summary
finance.reports.monthly
ui.dashboard.generate
Todas estas operaciones siguen el mismo modelo del registro de scripts.
JSDA no es un subsistema de ejecución independiente. Es un mecanismo de generación reutilizable que está disponible para los scripts.
Los artefactos generados pueden devolverse directamente, almacenarse en la base de datos, escribirse en archivos, publicarse mediante API o incorporarse a Git.
Cuando corresponde, la lógica de generación y sus dependencias se mantienen bajo control de versiones para facilitar la reproducibilidad.
Un documento, una migración SQL y una interfaz interactiva son resultados distintos del mismo modelo de capacidades.
Interfaces adaptativas y persistentes
La conversación es el punto de entrada universal, pero no la única interfaz de usuario.
El lenguaje natural resulta cómodo para expresar intenciones, explorar información e iniciar tareas complejas.
Sin embargo, no todas las interacciones se representan mejor como una conversación.
Editar cientos de registros, comparar métricas, navegar por grandes conjuntos de datos o gestionar flujos de trabajo operativos suele requerir interfaces estructuradas e interactivas.
NoES responde a esta necesidad mediante interfaces de usuario generadas dinámicamente y reutilizables.
Llamamos a este enfoque Symbiote Workspace.
La interfaz como respuesta generada por un agente
En lugar de exigir que los desarrolladores diseñen cada pantalla de antemano, los agentes pueden generar una interfaz adecuada para la tarea actual.
Un usuario podría pedir:
«Muéstrame nuestros clientes activos y permíteme editar sus datos de contacto».
El agente descubre las capacidades pertinentes, obtiene los datos necesarios y genera una interfaz interactiva con una tabla de clientes, controles de búsqueda y formularios de edición.
La interfaz invoca scripts existentes y registrados para realizar las operaciones.
No introduce una implementación independiente de la lógica de negocio.
Las mismas capacidades de gestión de clientes siguen siendo accesibles mediante la CLI, la interfaz conversacional, una API o flujos de trabajo programados.
Dos ciclos de vida de las interfaces generadas
NoES distingue entre dos formas de interfaces generadas por agentes.
Interfaces efímeras -- para el contexto actual
Una interfaz efímera se genera como parte de la respuesta de un agente a una solicitud concreta.
Puede contener un gráfico, una tabla, un formulario, una visualización o un componente interactivo compuesto para la conversación actual.
Su finalidad es ofrecer una representación eficaz de la información o una forma inmediata de completar una tarea.
No tiene por qué seguir existiendo después de la interacción actual.
Interfaces persistentes -- como artefactos del sistema
Una interfaz persistente se crea para utilizarla repetidamente.
Al igual que un script ejecutable, se convierte en un artefacto registrado del sistema, sujeto a control de versiones.
Algunos ejemplos son:
- Paneles de control operativos.
- Paneles de gestión de clientes e inventario.
- Espacios de trabajo para informes financieros.
- Interfaces de monitorización de activos.
- Consolas administrativas.
- Aplicaciones para tareas específicas y formularios reutilizables.
Una interfaz persistente puede tener un identificador estable, una configuración definida, permisos de acceso, un historial de versiones y una ubicación establecida dentro de Symbiote Workspace.
Se puede abrir directamente, guardar como marcador, compartir con usuarios autorizados o invocar mediante un agente.
Su implementación puede consistir en un script que genera la interfaz, una plantilla RAT reutilizable, componentes asociados y configuración.
La interfaz se puede actualizar a medida que evolucionan los requisitos del negocio sin perder su identidad ni su modelo de interacción establecido.
Una interfaz generada por un agente tiene la misma posibilidad de convertirse en una capacidad permanente del sistema que cualquier otro script.
La coherencia es una característica
La generación dinámica de interfaces no debe significar que las interfaces cambien constantemente.
Los usuarios desarrollan hábitos y se familiarizan con la forma de trabajar. Generar repetidamente distribuciones distintas para la misma tarea perjudicaría la usabilidad y aumentaría la carga cognitiva.
Por eso, NoES trata las interfaces persistentes como espacios de trabajo estables y reutilizables, en lugar de visualizaciones desechables.
Una vez que una interfaz demuestra su utilidad, se puede conservar y mejorar de forma gradual.
El agente debe dar preferencia a una interfaz existente y adecuada frente a la generación de una nueva.
Los usuarios no deberían tener que volver a aprender el mismo flujo de trabajo cada vez que lo retoman.
Genere cuando haga falta. Conserve lo que sea útil. Reutilice por defecto.
Symbiote RAT
Symbiote.js proporciona una base para este enfoque mediante su arquitectura Runtime Agnostic Templates (RAT).
RAT separa las plantillas HTML declarativas y sus vinculaciones con nombre de las instancias de componentes, las funciones de renderizado y los entornos de ejecución.
Las plantillas se pueden componer, personalizar, renderizar y reutilizar en entornos de cliente y de servidor.
En combinación con Web Components nativos y tecnologías estándar del navegador, esto ofrece una base práctica para:
- Interfaces interactivas generadas dinámicamente.
- Paneles de control persistentes y paneles operativos.
- Componentes y plantillas de interfaz reutilizables.
- Vinculaciones declarativas de datos y acciones.
- Renderizado en el cliente y en el servidor.
- Espacios de trabajo orientados a tareas.
- Composición y mantenimiento de interfaces asistidos por agentes.
Un script registrado puede generar o servir una representación de Symbiote RAT, que después se renderiza mediante un entorno de ejecución de interfaces compatible.
La interfaz puede ser efímera o persistente, según el ciclo de vida previsto.
La distinción se refiere a la persistencia y la reutilización, no a la arquitectura de ejecución subyacente.
Los agentes como asistentes de interfaz
Una vez que existe una interfaz persistente, la función del agente puede cambiar.
En lugar de generar nuevas interfaces repetidamente, el agente puede ayudar a los usuarios a comprender y utilizar el espacio de trabajo existente.
Symbiote.js proporciona una integración con WebMCP que permite ofrecer las acciones de los componentes como herramientas para los agentes de IA.
Un manejador asociado a un control de la interfaz también puede convertirse en una acción accesible para el agente.
Estas herramientas pueden incluir descripciones, esquemas de entrada e información contextual, y su disponibilidad puede reflejar el estado actual del componente y de la aplicación.
Esto permite un modelo de interacción compartido:
- Un usuario puede utilizar una interfaz directamente.
- Un agente puede explicar los controles y los flujos de trabajo disponibles.
- Un agente puede ayudar con la navegación y la introducción de datos.
- Un agente puede invocar las acciones disponibles de la interfaz en nombre del usuario.
- Las interacciones humanas y las de los agentes pueden utilizar el mismo comportamiento subyacente de la aplicación.
Por ejemplo, un usuario que trabaja en un panel de inventario podría preguntar:
«¿Cómo traslado estos artículos a otro almacén?»
El agente puede identificar la acción pertinente de la interfaz, explicar el procedimiento o ayudar a realizarlo dentro del contexto autorizado del usuario.
El agente se convierte en un asistente dentro de la aplicación existente, en lugar de sustituir su interfaz.
WebMCP complementa el registro de scripts de NoES: el registro ofrece capacidades persistentes del sistema, mientras que WebMCP permite a los agentes acceder a las acciones y al contexto de una interfaz renderizada.
Ambos deben respetar las mismas políticas de autorización subyacentes.
Una capacidad, varias representaciones
Una capacidad puede devolver datos, generar un artefacto o implementar una interfaz interactiva.
Por ejemplo:
crm.customers.list
crm.customers.export
crm.customers.dashboard
Son capacidades distintas que operan sobre los mismos datos del negocio y las mismas operaciones reutilizables.
Un panel de control persistente puede combinar varias capacidades registradas, mientras que su propio punto de entrada de generación o renderizado también se registra como un script.
Symbiote Workspace no es una plataforma independiente de aplicaciones de negocio.
Es el entorno persistente e interactivo mediante el cual las personas y los agentes acceden a las capacidades de NoES.
La interfaz se adapta cuando hace falta, se conserva cuando es útil y sigue siendo familiar al reutilizarla.
Evolución basada en Git
Git proporciona la base para el desarrollo colaborativo y el control de versiones.
Los scripts, los metadatos, la documentación, las pruebas, las migraciones, las instrucciones para agentes, los componentes de interfaz reutilizables y las definiciones de espacios de trabajo persistentes pueden coexistir en un monorrepositorio común.
La base de datos mantiene el registro operativo y el estado de ejecución, mientras que Git conserva el historial de las definiciones del sistema y de los cambios en su implementación.
Esta arquitectura permite que las personas y los agentes utilicen prácticas de desarrollo de software consolidadas:
- Creación de ramas y revisión de código.
- Pruebas automatizadas.
- Seguimiento de cambios.
- Despliegues reproducibles.
- Reversión de cambios y gestión de versiones.
- Desarrollo colaborativo.
- Infraestructura como código.
Los agentes pueden proponer nuevas capacidades e interfaces persistentes, que los usuarios pueden revisar, probar e incorporar al repositorio.
El registro se sincroniza con las revisiones aprobadas del repositorio.
Esto mantiene la funcionalidad del sistema transparente y portable.
NoES no necesita un constructor de aplicaciones propietario ni un editor específico de flujos de trabajo para desarrollar sus capacidades.
El repositorio es la fuente del conocimiento ejecutable. El registro permite descubrir ese conocimiento y utilizarlo en las operaciones.
¿Por qué JavaScript?
La elección de JavaScript como lenguaje principal para las capacidades ejecutables de NoES es deliberada.
No se basa únicamente en su popularidad ni en la suposición de que JavaScript sea superior a todos los demás lenguajes de programación.
JavaScript ofrece una combinación especialmente valiosa de propiedades para una arquitectura basada en scripts, dirigida por agentes y que abarca distintos entornos de ejecución.
Accesibilidad y ecosistema de desarrolladores
JavaScript es uno de los lenguajes de programación más utilizados, con una gran comunidad global de desarrolladores y una barrera de entrada relativamente baja.
Esto facilita la comprensión, el mantenimiento, la ampliación y la auditoría de las capacidades de NoES sin necesidad de especialistas en una plataforma propietaria o un lenguaje poco común.
Su amplio ecosistema ofrece bibliotecas maduras para el acceso a bases de datos, las comunicaciones de red, el procesamiento de datos, la criptografía, la generación de documentos, las pruebas y la integración con sistemas externos.
Muchas capacidades del negocio se pueden implementar con paquetes existentes, sin desarrollar infraestructura especializada.
Código realmente isomórfico
JavaScript se ejecuta de forma nativa en los navegadores web y en entornos de servidor como Node.js.
Esto permite compartir módulos ejecutables entre las interfaces del cliente, las operaciones del servidor, los scripts de automatización y las herramientas de desarrollo.
Las reglas de negocio, las transformaciones de datos, la lógica de validación, los esquemas y las funciones auxiliares se pueden implementar una sola vez y reutilizar en distintos entornos de ejecución.
Sus consecuencias van más allá de la reutilización convencional del código:
- Menos funciones duplicadas y menos inconsistencias.
- Bases de código más pequeñas y menores costes de mantenimiento.
- Menos abstracciones específicas de cada entorno de ejecución.
- Contextos de proyecto más pequeños y coherentes para los agentes de IA.
- Generación, análisis y modificación del código más eficientes mediante LLM.
No todos los módulos se pueden ejecutar en cualquier entorno: siguen aplicándose las API y los permisos específicos de cada plataforma. Sin embargo, el lenguaje y el sistema de módulos compartidos reducen considerablemente las barreras entre ellos.
Para el desarrollo mediante agentes, reducir la cantidad de código y de información contextual necesaria para comprender un sistema es una ventaja arquitectónica.
Ejecución directa sin un proceso de compilación
JavaScript moderno admite ECMAScript Modules (ESM) de forma nativa.
Un archivo .js o .mjs convencional puede servir directamente como punto de entrada ejecutable:
node ./scripts/crm/customers/add.mjs
No se necesita un paso obligatorio de compilación, transpilación, empaquetado ni un proceso de construcción específico de un framework.
Esto resulta especialmente valioso para NoES, donde los agentes crean, examinan, modifican y ejecutan con frecuencia pequeñas capacidades independientes.
Un script generado puede ejecutarse inmediatamente después de su validación y autorización.
La ausencia de un paso obligatorio de construcción simplifica el ciclo de desarrollo, mejora la transparencia del código fuente y reduce la cantidad de artefactos intermedios que debe gestionar un agente.
Análisis estático sin transpilación obligatoria
JavaScript no exige renunciar al análisis estático ni a las herramientas de comprobación de tipos.
TypeScript ofrece un sistema maduro de comprobación de tipos capaz de analizar JavaScript convencional mediante anotaciones JSDoc, archivos de declaraciones (.d.ts) y opciones de configuración como checkJs y strict.
Esto permite que NoES combine:
- Ejecución directa de JavaScript estándar.
- Comprobación estática de tipos durante el desarrollo y en CI.
- Contratos de tipos explícitos mediante JSDoc.
- Definiciones de tipos reutilizables mediante archivos de declaraciones TypeScript.
- Autocompletado, navegación y diagnósticos en el IDE.
- Ausencia de un paso obligatorio de compilación de TypeScript a JavaScript.
TypeScript puede servir así como herramienta de verificación durante el desarrollo sin convertirse en un lenguaje obligatorio para la ejecución.
La comprobación estática no sustituye la validación en tiempo de ejecución, pero aporta una capa adicional de corrección y mantiene la sencillez de los módulos JavaScript ejecutables.
Alto rendimiento donde hace falta
Los motores modernos de JavaScript emplean técnicas avanzadas de compilación justo a tiempo y optimización durante la ejecución.
Para las operaciones que requieren cálculos intensivos, JavaScript puede integrar módulos WebAssembly compilados a partir de lenguajes como Rust, C o C++.
Esto permite una división práctica de responsabilidades:
JavaScript para la orquestación, la integración y la lógica de negocio; WebAssembly o módulos nativos para cálculos especializados de alto rendimiento.
El registro de scripts puede ofrecer estas funciones mediante el mismo contrato de ejecución, sin exigir a los agentes ni a los usuarios que conozcan el lenguaje de implementación subyacente.
Estandarizado, portable y fácil de examinar
JavaScript está estandarizado mediante ECMAScript y cuenta con varios motores y entornos de ejecución independientes.
ESM proporciona un formato de módulos común para los navegadores modernos y los entornos de servidor.
A diferencia de las definiciones de flujos de trabajo propietarias o de los lenguajes de scripting específicos de una plataforma, el código fuente JavaScript convencional sigue siendo legible, editable, comprobable y ejecutable con herramientas ampliamente disponibles.
Esto concuerda con los principios de NoES: portabilidad, transparencia y menor dependencia de los proveedores.
¿Por qué no Python, TypeScript u otro lenguaje?
Python es un excelente lenguaje para la automatización, el procesamiento de datos y el desarrollo de IA. Sin embargo, no se ejecuta de forma nativa en los navegadores web estándar, lo que dificulta compartir realmente los mismos módulos entre cliente y servidor.
TypeScript ofrece herramientas estáticas más potentes, pero los flujos de trabajo convencionales de TypeScript introducen un paso adicional de procesamiento del código fuente o dependen de entornos de ejecución con soporte específico para TypeScript. NoES puede obtener la mayoría de sus ventajas de comprobación de tipos durante el desarrollo mientras ejecuta JavaScript estándar directamente.
Lenguajes como Rust, Go y C++ ofrecen ventajas de rendimiento, garantías estáticas y programación de sistemas, pero generalmente requieren compilación y no pueden ejecutarse de forma nativa como código fuente en los navegadores.
Otros lenguajes y entornos de ejecución pueden satisfacer requisitos individuales, pero pocos ofrecen la misma combinación de soporte nativo en el navegador, ejecución en el servidor, ejecución directa de módulos, madurez del ecosistema y tipado estático opcional.
JavaScript no es el único lenguaje posible para NoES. Es el denominador común más práctico para sus entornos de ejecución previstos.
Una opción predeterminada, no una restricción
NoES no prohíbe las capacidades implementadas en otros lenguajes.
Un script JavaScript puede invocar un ejecutable nativo, cargar un módulo WebAssembly, interactuar con un servicio externo o delegar cálculos en un entorno de ejecución especializado.
El contrato universal pertenece al registro de scripts, no al lenguaje de implementación.
JavaScript es la opción predeterminada porque minimiza la complejidad de los casos habituales y mantiene el acceso a tecnologías especializadas cuando hacen falta.
Un lenguaje para agentes, automatización, operaciones de servidor e interfaces de navegador. Un sistema de módulos. Infraestructura mínima de construcción. Máxima reutilización.
Seguridad y control humano
El desarrollo mediante agentes requiere límites explícitos entre el razonamiento, la generación de código, la autorización y la ejecución.
NoES separa la capacidad de proponer una operación de la autoridad para ejecutarla.
El entorno de ejecución aplica los controles de acceso con independencia de la implementación de cada script.
Los scripts pueden aportar validaciones adicionales y restricciones específicas del negocio, pero no se les puede confiar la definición de sus propios privilegios efectivos.
Las operaciones se pueden clasificar por riesgo, incluido el acceso de solo lectura, la modificación de datos, los cambios destructivos y las acciones administrativas.
Las operaciones sensibles pueden requerir una confirmación humana explícita.
Los scripts y las interfaces generados por agentes deben validarse antes de su activación, con aislamiento adicional para el código no confiable.
Las interfaces generadas no deben poder eludir las políticas de ejecución ni acceder a datos más allá de los permisos del usuario que las invoca.
Los registros de ejecución proporcionan trazabilidad e incluyen quién inició la operación, la versión del script, los parámetros, las aprobaciones y los resultados.
El mismo modelo de seguridad se aplica tanto si el script lo invoca un agente como si lo hace un usuario, un planificador de tareas, una API o una interfaz generada.
Los agentes pueden ampliar el sistema, pero no concederse autoridad por su cuenta.
Minimalismo y arquitectura abierta
NoES prefiere la sencillez a las abstracciones innecesarias.
La implementación inicial no requiere una arquitectura distribuida de microservicios, servidores específicos de automatización, plataformas complejas de integración ni múltiples backends de aplicaciones.
Un entorno funcional de NoES puede comenzar con:
- PostgreSQL.
- Node.js.
- Un repositorio Git.
- Un agente de IA con acceso al registro de scripts.
Las capacidades adicionales surgen mediante scripts y dependencias convencionales.
Tecnologías como Docker, las colas de mensajes, los planificadores de tareas, los servicios HTTP y los entornos de ejecución especializados se pueden incorporar cuando las necesidades operativas lo justifiquen.
La arquitectura está diseñada para mantener su independencia de cualquier modelo de IA, proveedor de nube o framework de orquestación concreto.
Tecnologías de referencia
RND-PRO desarrolla y utiliza varias tecnologías que complementan este enfoque:
JSDA -- JavaScript Distributed Assets, para generar artefactos textuales y estructurados a partir de módulos ESM.
Symbiote.js -- Web Components isomórficos, Runtime Agnostic Templates e integración con WebMCP para interfaces reutilizables y accesibles para los agentes.
Symbiote Workspace -- el entorno propuesto para interfaces efímeras y persistentes generadas por agentes, paneles de control y espacios de trabajo operativos.
Son implementaciones de referencia y componentes básicos, no dependencias obligatorias del concepto NoES.
El contrato arquitectónico que lo define sigue siendo el mismo: capacidades que se pueden descubrir, ejecutar y reutilizar.
Qué cambia NoES
De aplicaciones a capacidades
El software empresarial tradicional agrupa la funcionalidad en grandes aplicaciones.
NoES organiza la funcionalidad en scripts reutilizables de forma independiente.
Una empresa ya no necesita una plataforma CRM completa solo para gestionar registros de clientes ni una suite completa de BI para generar informes operativos.
Necesita las capacidades pertinentes.
De interfaces fijas a espacios de trabajo adaptativos y persistentes
Los sistemas tradicionales ofrecen acceso a la funcionalidad mediante pantallas predefinidas.
NoES permite generar o componer interfaces según las tareas reales.
Las interfaces útiles pueden convertirse después en espacios de trabajo permanentes y familiares, en lugar de volver a generarse desde cero.
La generación dinámica y la coherencia de la interfaz son objetivos complementarios, no contrapuestos.
De integración a ejecución compartida
Las arquitecturas empresariales tradicionales suelen conectar aplicaciones mediante integraciones complejas.
NoES promueve que las capacidades operen sobre datos compartidos con reglas de gestión explícitas y reutilicen un modelo de ejecución común.
Las integraciones externas siguen siendo posibles donde se necesiten.
De personalización a evolución
La personalización del software empresarial tradicional suele introducir dependencias de código, configuración y mantenimiento específicas del proveedor.
NoES amplía la funcionalidad mediante scripts convencionales con control de versiones y artefactos de interfaz reutilizables.
Los agentes pueden participar en este proceso de desarrollo y reducir el esfuerzo necesario para implementar pequeños cambios operativos.
De automatización temporal a capacidades acumuladas
Un flujo de trabajo temporal de un agente resuelve un solo problema.
Una capacidad registrada se convierte en una parte reutilizable del sistema.
Una interfaz efímera ayuda a completar una tarea inmediata.
Un espacio de trabajo persistente se convierte en una herramienta familiar para el trabajo recurrente.
Cuantos más procesos de negocio se formalicen como capacidades reutilizables, más útil será el sistema.
La visión a largo plazo
NoES propone una relación distinta entre las organizaciones y su software.
En lugar de seleccionar un conjunto de aplicaciones empresariales y adaptar los procesos de negocio a sus restricciones, las organizaciones mantienen un entorno compartido de datos y capacidades ejecutables.
Los agentes de IA ayudan a las personas a utilizar y ampliar ese entorno.
Las interfaces pueden surgir de las tareas, pero las que funcionan bien no tienen por qué desaparecer cuando termina la conversación.
Pueden convertirse en aplicaciones estables y persistentes que los usuarios comprenden, en las que confían y a las que vuelven.
Los agentes pueden entonces ayudar a los usuarios dentro de esas aplicaciones, facilitando la navegación, la comprensión y el uso de las funciones existentes.
Los procesos de negocio se convierten en código reutilizable en lugar de configuraciones ocultas de las aplicaciones.
El conocimiento se vuelve ejecutable cuando corresponde.
Las nuevas funciones se desarrollan de forma gradual, según necesidades reales y no a partir de una planificación especulativa de funcionalidades.
El sistema resultante no tiene necesariamente menos funcionalidad total. Tiene menos estructura innecesaria.
Su complejidad crece solo donde el negocio lo requiere.
El objetivo final no es una empresa totalmente autónoma controlada por IA.
Es un entorno donde las personas y los agentes colaboran mediante capacidades de software transparentes, reutilizables y controlables.
El software debe evolucionar con la organización, sin obligarla a evolucionar en torno al software.
Acerca de NoES
NoES es una iniciativa arquitectónica abierta de RND-PRO, un equipo de ingeniería de I+D centrado en la innovación práctica en software, la automatización y los enfoques alternativos para sistemas de información complejos.
El proyecto explora cómo los agentes de IA, los lenguajes de programación convencionales, los datos estructurados y las interfaces generadas dinámicamente pueden sustituir capas innecesarias del software empresarial tradicional.
NoES es un concepto y una arquitectura de referencia en evolución. Sus componentes se pueden implementar de forma independiente y adoptar gradualmente.
Invitamos al diálogo, la experimentación y la colaboración.