NoES -- No Enterprise Software

Возможности корпоративных систем без корпоративного ПО
Данные + Скрипты + Агенты
Создавайте то, что нужно. Используйте созданное повторно. Дайте системе развиваться.

Идея

Корпоративное ПО стало излишне сложным.

Компании часто вынуждены подстраивать свои процессы под готовые приложения, поддерживать множество интеграций, платить за редко используемые функции и зависеть от поставщиков даже при незначительных изменениях.

CRM, ERP, EAM, BI и другие корпоративные системы часто работают с пересекающимися данными, выполняют похожие операции, но при этом вводят отдельные интерфейсы, права доступа, рабочие процессы и инфраструктуру.

Проблема не в функциональности этих систем, а в том, как она организована, предоставляется и поддерживается.

Современные ИИ-агенты, технологии с открытым исходным кодом и обычные инструменты разработки позволяют использовать принципиально иной подход.

NoES (No Enterprise Software) -- открытая архитектурная концепция создания бизнес-систем, которые развиваются в соответствии с реальными потребностями текущей работы.

Вместо развертывания крупных приложений с заранее заданной функциональностью NoES начинается со структурированных данных, ИИ-агентов и растущего набора исполняемых возможностей.

Пользователи описывают, что им нужно. Агенты находят существующие возможности, выполняют операции, генерируют подходящие интерфейсы и при необходимости создают новые возможности.

Успешные решения могут стать постоянными частями системы, доступными всем, у кого есть соответствующие права.

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

Цель -- отказаться не от программного обеспечения, а от его ненужной сложности.

Базовая архитектура

NoES = Данные + Скрипты + Агенты

Три основных компонента составляют основу всей системы.

Данные -- состояние системы

Структурированные данные отражают текущее состояние бизнес-операций.

Реляционная база данных, например PostgreSQL, хранит сведения о клиентах, активах, транзакциях, запасах, задачах, событиях в работе компании и других бизнес-сущностях.

Инфраструктура базы данных также может хранить метаданные системы: реестр возможностей, историю выполнения, расписания, политики доступа и ссылки на сохраняемые артефакты.

Данные остаются доступными через стандартные технологии, такие как SQL и обычные API.

Проприетарная модель корпоративных данных не требуется.

Скрипты -- возможности системы

Все является возможностью. Каждая возможность -- это скрипт.

Скрипты -- основные исполняемые артефакты NoES.

Скрипт может выполнить практически любую операцию:

Запросить или изменить бизнес-данные.
Создать схемы базы данных и миграции.
Выполнить бизнес-процессы и рабочие сценарии.
Интегрировать внешние сервисы.
Сформировать отчеты и документацию.
Создать SQL, JSON, Markdown, HTML, CSS, SVG или другие ресурсы.
Реализовать интерактивные пользовательские интерфейсы и панели мониторинга.
Выполнить вычисления и преобразования данных.
Управлять конфигурацией системы и инфраструктурой.
Создать или обновить другие артефакты системы.

Скрипты -- обычные модули JavaScript, которые выполняются через Node.js и хранятся в общем репозитории с контролем версий.

Каждый скрипт представляет собой отдельную возможность, которую можно найти и использовать повторно.

Скрипт, созданный для решения одной задачи, впоследствии может выполняться агентом, человеком-оператором, заданием по расписанию, API или графическим интерфейсом.

Реализация возможности не зависит от способа ее вызова.

Агенты -- интеллект системы

ИИ-агенты обеспечивают рассуждение, планирование и оркестрацию в NoES.

Агенты интерпретируют запросы пользователей, изучают доступные данные и возможности, выполняют скрипты, координируют рабочие процессы и генерируют новую функциональность.

Агенту не нужно заранее знать обо всех возможностях системы.

Он находит их через реестр, изучает документацию и контракты и выбирает подходящие операции.

Если нужной возможности нет, агент может предложить ее создать.

После проверки и одобрения новая возможность становится постоянной частью системы, доступной другим агентам, пользователям и автоматизированным процессам.

Агенты заменяемы. Накопленные системой знания и возможности не привязаны к конкретной модели или фреймворку для агентов.

Реестр скриптов

Реестр скриптов NoES (NoES Script Registry) -- центральный архитектурный механизм, который связывает данные, агентов и исполняемую функциональность.

Скрипты регистрируются под иерархическими семантическими идентификаторами:

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

Каждая зарегистрированная возможность содержит:

Уникальный семантический идентификатор.
Исполняемую точку входа.
Описание в Markdown, понятное человеку.
Машиночитаемые контракты входных и выходных данных.
Требования к доступу и политики выполнения.
Сведения о версии и ссылки на исходный код.
Необязательные зависимости и настройки выполнения.

Реестр обеспечивает иерархическую навигацию и семантический поиск возможностей.

Агенты могут постепенно изучать доступную функциональность, не загружая весь каталог возможностей в свой контекст.

Универсальное выполнение

Скрипты следуют общему контракту выполнения.

Одна и та же возможность может вызываться ИИ-агентом, напрямую из командной строки, через автоматизацию по расписанию, HTTP API, элемент управления пользовательского интерфейса или другой скрипт.

Например:

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

Команда noes -- легковесный интерфейс выполнения, а не обязательный сервер приложений или протокол.

Сами скрипты остаются обычными модулями JavaScript, которые можно выполнять через Node.js.

Общий слой выполнения обеспечивает авторизацию, проверку входных данных, контекст выполнения, ведение журналов и обработку одобрений.

Отдельные скрипты реализуют дополнительную бизнес-логику и проверки, специфичные для предметной области.

За пределами MCP

NoES не требует MCP-серверов, чтобы предоставлять агентам доступ к своим внутренним возможностям.

Агенты взаимодействуют с исполняемыми скриптами через простой интерфейс командной строки, позволяющий находить доступные возможности.

Это сокращает инфраструктуру, связанную с конкретным протоколом, и позволяет разрабатывать, тестировать, версионировать и выполнять возможности с помощью обычных инструментов разработки.

MCP остается полезным необязательным механизмом совместимости, особенно при подключении внешних инструментов или предоставлении возможностей NoES другим агентным средам.

MCP -- это адаптер. Скрипты -- это возможности.

Возможности как сохраняемые знания

NoES предлагает практическую форму накопления знаний о работе компании.

Традиционные агентные системы часто решают задачи с помощью временных последовательностей рассуждений и вызовов инструментов.

Результат может быть полезным, но сама процедура не обязательно сохраняется в виде функциональности для повторного использования.

NoES поощряет преобразование успешных решений в постоянные исполняемые артефакты.

Предположим, пользователь запрашивает новый рабочий процесс для управления клиентами.

Агент может:

Изучить существующие схемы базы данных и зарегистрированные возможности.
Определить недостающие структуры данных или операции.
Сгенерировать необходимые SQL-миграции.
Предложить новые скрипты для управления клиентами.
Сгенерировать тесты и документацию.
Запросить одобрение предложенных изменений.
Зарегистрировать одобренные возможности.
Выполнить их и представить результаты.

При следующей похожей задаче агент сможет использовать существующую функциональность, не создавая решение заново.

Со временем система накапливает все больше проверенных и документированных возможностей.

NoES развивается, преобразуя опыт работы в код для повторного использования.

Это не обучение модели или автономное обучение в смысле машинного обучения. Это развитие функциональности, которая сохраняется, доступна для изучения и находится под контролем версий.

Динамическая генерация артефактов

Возможность не обязана возвращать простой JSON-объект или изменять базу данных.

Она может генерировать любые структурированные или текстовые артефакты.

Для динамической генерации артефактов NoES использует принципы JavaScript Distributed Assets (JSDA).

JSDA рассматривает стандартные ESM-модули JavaScript как точки генерации текста, позволяя обходиться без специализированных языков шаблонов и проприетарных конвейеров преобразования.

Скрипты могут использовать JSDA для создания:

SQL-схем и миграций.
Документации в Markdown.
Отчетов и деловой переписки.
Инструкций для агентов и файлов знаний.
Конфигурационных файлов.
JSON и других структурированных данных.
HTML, CSS и SVG.
Шаблонов интерактивных интерфейсов.
Артефактов приложений и инфраструктуры.

Например:

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

Все эти операции следуют одной и той же модели реестра скриптов.

JSDA -- не отдельная подсистема выполнения, а механизм генерации, доступный скриптам для повторного использования.

Сгенерированные артефакты можно возвращать напрямую, сохранять в базе данных, записывать в файлы, публиковать через API или фиксировать в Git.

При необходимости логика генерации и ее зависимости находятся под контролем версий, чтобы обеспечить воспроизводимость.

Документ, SQL-миграция и интерактивный интерфейс -- разные результаты одной и той же модели возможностей.

Адаптивные и постоянные интерфейсы

Диалог -- универсальная точка входа, но не единственный пользовательский интерфейс.

Естественный язык удобен для выражения намерений, изучения информации и запуска сложных задач.

Однако не каждое взаимодействие лучше всего представлять в виде диалога.

Редактирование сотен записей, сравнение показателей, навигация по большим наборам данных или управление рабочими процессами часто требуют структурированных интерактивных интерфейсов.

NoES решает эту задачу с помощью динамически генерируемых пользовательских интерфейсов, которые можно использовать повторно.

Мы называем этот подход Symbiote Workspace.

Интерфейс как ответ, сгенерированный агентом

Вместо того чтобы требовать от разработчиков заранее проектировать каждый экран, агенты могут генерировать интерфейс под текущую задачу.

Пользователь может попросить:

«Покажи наших активных клиентов и дай мне отредактировать их контактные данные».

Агент находит нужные возможности, получает необходимые данные и генерирует интерактивный интерфейс с таблицей клиентов, элементами поиска и формами редактирования.

Для выполнения операций интерфейс вызывает существующие зарегистрированные скрипты.

Он не создает отдельную реализацию бизнес-логики.

Те же возможности управления клиентами остаются доступны через CLI, диалоговый интерфейс, API или рабочие процессы по расписанию.

Два жизненных цикла генерируемого интерфейса

NoES различает две формы интерфейсов, генерируемых агентами.

Временный интерфейс -- для текущего контекста

Временный интерфейс генерируется как часть ответа агента на конкретный запрос.

Он может содержать диаграмму, таблицу, форму, визуализацию или интерактивный компонент, собранный для текущего диалога.

Его задача -- удобно представить информацию или дать возможность сразу выполнить задачу.

Он не обязательно должен существовать за пределами текущего взаимодействия.

Постоянный интерфейс -- артефакт системы

Постоянный интерфейс создается для многократного использования.

Как и исполняемый скрипт, он становится зарегистрированным артефактом системы под контролем версий.

Примеры:

Панели мониторинга текущих операций.
Панели управления клиентами и запасами.
Рабочие пространства для финансовой отчетности.
Интерфейсы мониторинга активов.
Административные консоли.
Приложения для конкретных задач и повторно используемые формы.

Постоянный интерфейс может иметь стабильный идентификатор, определенную конфигурацию, права доступа, историю версий и закрепленное место в Symbiote Workspace.

Его можно открывать напрямую, добавлять в закладки, предоставлять пользователям с соответствующими правами или вызывать через агента.

Его реализация может состоять из скрипта, генерирующего интерфейс, повторно используемого шаблона RAT, связанных компонентов и конфигурации.

Интерфейс можно обновлять по мере изменения требований бизнеса, сохраняя его идентичность и привычную модель взаимодействия.

Сгенерированный агентом интерфейс может стать постоянной возможностью системы так же, как и любой другой скрипт.

Постоянство -- полезное свойство

Динамическая генерация интерфейсов не должна означать, что они постоянно меняются.

У пользователей формируются привычки и знакомые приемы работы. Если каждый раз генерировать разные компоновки для одной и той же задачи, это снизит удобство использования и увеличит когнитивную нагрузку.

Поэтому NoES рассматривает постоянные интерфейсы как стабильные, повторно используемые рабочие пространства, а не одноразовые визуализации.

Если интерфейс оказался полезным, его можно сохранить и постепенно совершенствовать.

Агент должен предпочитать существующий подходящий интерфейс генерации нового.

Пользователям не должно приходиться заново осваивать один и тот же рабочий процесс при каждом возвращении к нему.

Генерируйте, когда это нужно. Сохраняйте, когда это полезно. Используйте повторно по умолчанию.

Symbiote RAT

Symbiote.js дает основу для этого подхода благодаря архитектуре Runtime Agnostic Templates (RAT).

RAT отделяет декларативные HTML-шаблоны и их именованные привязки от экземпляров компонентов, функций рендеринга и сред выполнения.

Шаблоны можно собирать, настраивать, отображать и повторно использовать в клиентских и серверных средах.

В сочетании с нативными Web Components и стандартными браузерными технологиями это дает практическую основу для:

Динамически генерируемых интерактивных интерфейсов.
Постоянных панелей мониторинга и управления текущими операциями.
Повторно используемых UI-компонентов и шаблонов.
Декларативных привязок данных и действий.
Рендеринга на клиенте и сервере.
Рабочих пространств для конкретных задач.
Сборки и сопровождения интерфейсов с помощью агентов.

Зарегистрированный скрипт может генерировать или предоставлять представление Symbiote RAT, которое затем отображается совместимой средой выполнения интерфейса.

Интерфейс может быть временным или постоянным в зависимости от предполагаемого жизненного цикла.

Это различие касается сохранения и повторного использования, а не базовой архитектуры выполнения.

Агенты как помощники в интерфейсе

Когда постоянный интерфейс уже существует, роль агента может измениться.

Вместо многократной генерации нового интерфейса агент может помогать пользователям разбираться в существующем рабочем пространстве и работать с ним.

Symbiote.js предоставляет интеграцию с WebMCP, которая позволяет представлять действия компонентов как инструменты для ИИ-агентов.

Обработчик, связанный с элементом управления интерфейса, также может стать действием, доступным агенту.

Эти инструменты могут включать описания, схемы входных данных и контекстную информацию, а их доступность -- отражать текущее состояние компонента и приложения.

Это позволяет использовать общую модель взаимодействия:

Пользователь может работать с интерфейсом напрямую.
Агент может объяснять доступные элементы управления и рабочие процессы.
Агент может помогать с навигацией и вводом данных.
Агент может вызывать доступные действия интерфейса от имени пользователя.
Действия человека и агента могут опираться на одно и то же поведение приложения.

Например, пользователь, работающий в панели управления запасами, может спросить:

«Как переместить эти товары на другой склад?»

Агент может определить нужное действие интерфейса, объяснить процедуру или помочь выполнить ее в пределах полномочий пользователя.

Агент становится помощником внутри существующего приложения, а не заменой его интерфейса.

WebMCP дополняет реестр скриптов NoES: реестр предоставляет постоянные возможности системы, а WebMCP делает действия и контекст отображаемого интерфейса доступными агентам.

Оба механизма должны соблюдать одни и те же базовые политики авторизации.

Одна возможность, несколько представлений

Возможность может возвращать данные, генерировать артефакт или реализовывать интерактивный интерфейс.

Например:

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

Это разные возможности, которые работают с одними и теми же бизнес-данными и повторно используемыми операциями.

Постоянная панель мониторинга может объединять несколько зарегистрированных возможностей, а ее собственная точка входа для генерации или рендеринга также регистрируется как скрипт.

Symbiote Workspace -- не самостоятельная платформа бизнес-приложений.

Это постоянная интерактивная среда, через которую люди и агенты получают доступ к возможностям NoES.

Интерфейс адаптируется, когда это нужно, сохраняется, когда это полезно, и остается привычным при повторном использовании.

Развитие на основе Git

Git обеспечивает основу для совместной разработки и контроля версий.

Скрипты, метаданные, документация, тесты, миграции, инструкции для агентов, повторно используемые UI-компоненты и определения постоянных рабочих пространств могут храниться в общем монорепозитории.

База данных поддерживает рабочий реестр и состояние системы во время выполнения, а Git сохраняет историю определений системы и изменений в реализации.

Такая архитектура позволяет людям и агентам использовать устоявшиеся практики разработки ПО:

Ветвление и проверку кода.
Автоматизированное тестирование.
Отслеживание изменений.
Воспроизводимые развертывания.
Откат изменений и управление версиями.
Совместную разработку.
Инфраструктуру как код.

Агенты могут предлагать новые возможности и постоянные интерфейсы, а пользователи -- проверять их, тестировать и включать в репозиторий.

Реестр синхронизируется с одобренными версиями репозитория.

Это сохраняет прозрачность и переносимость функциональности системы.

Для разработки своих возможностей NoES не требует проприетарного конструктора приложений или отдельного редактора рабочих процессов.

Репозиторий -- источник исполняемых знаний. Реестр позволяет находить эти знания и применять их в работе.

Почему JavaScript?

Выбор JavaScript в качестве основного языка исполняемых возможностей NoES сделан осознанно.

Он основан не только на популярности языка и не на предположении, что JavaScript во всем превосходит другие языки программирования.

JavaScript предлагает особенно ценное сочетание свойств для архитектуры, основанной на скриптах, управляемой агентами и охватывающей разные среды выполнения.

Доступность и экосистема разработчиков

JavaScript -- один из самых распространенных языков программирования, с большим мировым сообществом разработчиков и относительно низким порогом входа.

Благодаря этому возможности NoES проще понимать, поддерживать, расширять и проверять без специалистов по проприетарной платформе или редкому языку.

Его обширная экосистема предлагает зрелые библиотеки для доступа к базам данных, сетевого взаимодействия, обработки данных, криптографии, генерации документов, тестирования и интеграции с внешними системами.

Многие бизнес-возможности можно реализовать с помощью существующих пакетов, не разрабатывая специализированную инфраструктуру.

По-настоящему изоморфный код

JavaScript выполняется нативно в веб-браузерах и серверных средах, таких как Node.js.

Это позволяет использовать одни и те же исполняемые модули в клиентских интерфейсах, серверных операциях, скриптах автоматизации и инструментах разработки.

Бизнес-правила, преобразования данных, логику проверок, схемы и вспомогательные функции можно реализовать один раз и повторно использовать в разных средах выполнения.

Последствия этого выходят за рамки обычного повторного использования кода:

Меньше дублирования функциональности и расхождений.
Меньший общий объем кода и меньшие затраты на сопровождение.
Меньше абстракций, специфичных для среды выполнения.
Меньший и более согласованный контекст проекта для ИИ-агентов.
Более эффективная генерация, анализ и изменение кода с помощью LLM.

Не каждый модуль можно выполнить в любой среде: ограничения платформенных API и прав доступа сохраняются. Однако общий язык и система модулей существенно уменьшают различия между средами.

Для разработки с участием агентов сокращение объема кода и контекстной информации, необходимой для понимания системы, -- архитектурное преимущество.

Прямое выполнение без конвейера сборки

Современный JavaScript поддерживает нативные ECMAScript Modules (ESM).

Обычный файл .js или .mjs может непосредственно служить исполняемой точкой входа:

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

Обязательная компиляция, транспиляция, объединение модулей в сборку или процесс сборки, специфичный для фреймворка, не требуются.

Это особенно ценно для NoES, где агенты часто создают, изучают, изменяют и выполняют небольшие независимые возможности.

Сгенерированный скрипт может стать исполняемым сразу после проверки и авторизации.

Отсутствие обязательного этапа сборки упрощает цикл разработки, повышает прозрачность исходного кода и уменьшает число промежуточных артефактов, которыми должен управлять агент.

Статический анализ без обязательной транспиляции

Использование JavaScript не требует отказа от статического анализа или инструментов проверки типов.

TypeScript предоставляет зрелую систему проверки типов, которая может анализировать обычный JavaScript с помощью аннотаций JSDoc, файлов деклараций (.d.ts) и параметров конфигурации, таких как checkJs и strict.

Это позволяет NoES сочетать:

Прямое выполнение стандартного JavaScript.
Статическую проверку типов при разработке и в CI.
Явные контракты типов через JSDoc.
Повторно используемые определения типов через файлы деклараций TypeScript.
Автодополнение, навигацию и диагностику в IDE.
Отсутствие обязательного этапа компиляции TypeScript в JavaScript.

Таким образом, TypeScript может служить инструментом проверки на этапе разработки, не становясь обязательным языком среды выполнения.

Статическая проверка не заменяет проверки во время выполнения, но дает дополнительный уровень контроля корректности, сохраняя простоту исполняемых модулей JavaScript.

Высокая производительность там, где она нужна

Современные движки JavaScript используют сложные механизмы JIT-компиляции и оптимизации во время выполнения.

Для ресурсоемких вычислений JavaScript может подключать модули WebAssembly, скомпилированные из таких языков, как Rust, C или C++.

Это позволяет практически разделить обязанности:

JavaScript -- для оркестрации, интеграции и бизнес-логики; WebAssembly или нативные модули -- для специализированных высокопроизводительных вычислений.

Реестр скриптов может предоставлять такую функциональность через тот же контракт выполнения, не требуя от агентов или пользователей знания языка реализации.

Стандартизованный, переносимый и доступный для изучения

JavaScript стандартизован через ECMAScript и поддерживается несколькими независимыми движками и средами выполнения.

ESM обеспечивает общий формат модулей для современных браузеров и серверных сред.

В отличие от проприетарных определений рабочих процессов или платформенных скриптовых языков, обычный исходный код JavaScript остается читаемым, редактируемым, тестируемым и исполняемым с помощью широко доступных инструментов.

Это соответствует принципам NoES: переносимости, прозрачности и снижению зависимости от поставщиков.

Почему не Python, TypeScript или другой язык?

Python -- отличный язык для автоматизации, обработки данных и разработки ИИ. Однако он не выполняется нативно в стандартных веб-браузерах, что затрудняет использование действительно общих модулей на клиенте и сервере.

TypeScript предлагает более развитые инструменты статического анализа, но традиционные процессы работы с ним добавляют этап обработки исходного кода или зависят от сред выполнения со специальной поддержкой TypeScript. NoES может получить большую часть преимуществ проверки типов на этапе разработки, выполняя стандартный JavaScript напрямую.

Такие языки, как Rust, Go и C++, дают преимущества в производительности, статических гарантиях и системном программировании, но обычно требуют компиляции и не могут нативно выполняться в браузере в виде исходного кода.

Другие языки и среды выполнения могут отвечать отдельным требованиям, но немногие предлагают такое же сочетание нативной поддержки в браузере, серверного выполнения, прямого выполнения модулей, зрелой экосистемы и необязательной статической типизации.

JavaScript -- не единственный возможный язык для NoES. Это наиболее практичный общий знаменатель для предполагаемых сред выполнения.

Выбор по умолчанию, а не ограничение

NoES не запрещает возможности, реализованные на других языках.

Скрипт JavaScript может вызывать нативную исполняемую программу, загружать модуль WebAssembly, взаимодействовать с внешним сервисом или передавать вычисления специализированной среде выполнения.

Универсальный контракт относится к реестру скриптов, а не к языку реализации.

JavaScript выбран по умолчанию, потому что он сводит к минимуму сложность типичных задач и сохраняет доступ к специализированным технологиям, когда они нужны.

Один язык для агентов, автоматизации, серверных операций и браузерных интерфейсов. Одна система модулей. Минимум инфраструктуры сборки. Максимум повторного использования.

Безопасность и контроль со стороны человека

Разработка с участием агентов требует явных границ между рассуждением, генерацией кода, авторизацией и выполнением.

NoES разделяет возможность предложить операцию и полномочия на ее выполнение.

Среда выполнения обеспечивает контроль доступа независимо от реализации отдельных скриптов.

Скрипты могут добавлять проверки и ограничения, связанные со спецификой бизнеса, но им нельзя доверять определение собственных фактических привилегий.

Операции можно классифицировать по риску: доступ только для чтения, изменение данных, разрушительные изменения и административные действия.

Операции с повышенным риском могут требовать явного подтверждения человеком.

Созданные агентами скрипты и интерфейсы необходимо проверять до активации, а для недоверенного кода предусматривать дополнительную изоляцию.

Сгенерированные интерфейсы не должны иметь возможности обходить политики выполнения или получать доступ к данным за пределами прав пользователя, который их вызывает.

Записи о выполнении обеспечивают прослеживаемость: кто инициировал операцию, какая версия скрипта использовалась, с какими параметрами, одобрениями и результатами.

Одна и та же модель безопасности применяется независимо от того, кто вызывает скрипт: агент, пользователь, планировщик, API или сгенерированный интерфейс.

Агенты могут расширять систему, но не могут самостоятельно наделять себя полномочиями.

Минимализм и открытая архитектура

NoES предпочитает простоту избыточным абстракциям.

Начальная реализация не требует распределенной микросервисной архитектуры, отдельных серверов автоматизации, сложных интеграционных платформ или нескольких серверных частей приложений.

Рабочая среда NoES может начинаться с:

PostgreSQL.
Node.js.
Git-репозитория.
ИИ-агента с доступом к реестру скриптов.

Дополнительные возможности появляются благодаря скриптам и обычным зависимостям.

Такие технологии, как Docker, очереди сообщений, планировщики, HTTP-сервисы и специализированные среды выполнения, можно подключать, когда этого требуют условия работы.

Архитектура спроектирована так, чтобы оставаться независимой от конкретной ИИ-модели, облачного провайдера или фреймворка оркестрации.

Референсные технологии

RND-PRO разрабатывает и использует несколько технологий, которые дополняют этот подход:

JSDA -- JavaScript Distributed Assets, для генерации текстовых и структурированных артефактов из ESM-модулей.

Symbiote.js -- изоморфные Web Components, Runtime Agnostic Templates и интеграция с WebMCP для повторно используемых интерфейсов, доступных агентам.

Symbiote Workspace -- предлагаемая среда для временных и постоянных интерфейсов, генерируемых агентами, панелей мониторинга и рабочих пространств для текущих операций.

Это референсные реализации и строительные блоки, а не обязательные зависимости концепции NoES.

Определяющий архитектурный контракт остается прежним: возможности, которые можно находить, выполнять и использовать повторно.

Что меняет NoES

От приложений к возможностям

Традиционное корпоративное ПО объединяет функциональность в крупные приложения.

NoES организует функциональность в виде скриптов, которые можно повторно использовать независимо друг от друга.

Компании больше не нужна целая CRM-платформа только для управления записями о клиентах или полный набор BI-инструментов для создания отчетов о текущей работе.

Ей нужны соответствующие возможности.

От фиксированных интерфейсов к адаптивным и постоянным рабочим пространствам

Традиционные системы предоставляют доступ к функциональности через заранее заданные экраны.

NoES позволяет генерировать или собирать интерфейсы под реальные задачи.

Полезные интерфейсы затем могут стать постоянными, привычными рабочими пространствами, а не создаваться каждый раз с нуля.

Динамическая генерация и постоянство интерфейса дополняют друг друга, а не конкурируют.

От интеграции к общему выполнению

Традиционные корпоративные архитектуры часто связывают приложения через сложные интеграции.

NoES предлагает возможностям работать с общими данными, управление которыми явно определено, и использовать общую модель выполнения.

Внешние интеграции остаются доступны там, где они нужны.

От доработок к развитию

Доработка традиционного корпоративного ПО часто создает зависимости от кода, конфигурации и сопровождения конкретного поставщика.

NoES расширяет функциональность через обычные скрипты под контролем версий и повторно используемые артефакты интерфейса.

Агенты могут участвовать в этом процессе разработки, сокращая усилия, необходимые для небольших изменений в текущей работе.

От одноразовой автоматизации к накоплению возможностей

Временный агентный сценарий решает одну задачу.

Зарегистрированная возможность становится повторно используемой частью системы.

Временный интерфейс помогает выполнить текущую задачу.

Постоянное рабочее пространство становится привычным инструментом для регулярной работы.

Чем больше бизнес-процессов формализовано в виде повторно используемых возможностей, тем полезнее становится система.

Долгосрочное видение

NoES предлагает иные отношения между организациями и их программным обеспечением.

Вместо выбора набора корпоративных приложений и подстройки бизнес-процессов под их ограничения организации поддерживают общую среду данных и исполняемых возможностей.

ИИ-агенты помогают людям работать в этой среде и расширять ее.

Интерфейсы могут возникать из задач, но удачные интерфейсы не обязаны исчезать вместе с окончанием диалога.

Они могут стать стабильными, постоянными приложениями, в которых пользователи разбираются, которым доверяют и к которым возвращаются.

Агенты могут помогать пользователям внутри этих приложений: с навигацией, пониманием и использованием существующей функциональности.

Бизнес-процессы становятся повторно используемым кодом, а не скрытой конфигурацией приложений.

Знания становятся исполняемыми там, где это уместно.

Новая функциональность развивается постепенно, исходя из реальных потребностей, а не предположений о будущих функциях.

Получившаяся система не обязательно меньше по общему объему функциональности. В ней меньше ненужных структурных элементов.

Ее сложность растет только там, где этого требует бизнес.

Конечная цель -- не полностью автономная компания под управлением ИИ.

Это среда, в которой люди и агенты совместно работают с прозрачными, повторно используемыми и контролируемыми программными возможностями.

Программное обеспечение должно развиваться вместе с организацией, а не заставлять организацию подстраиваться под него.

О NoES

NoES -- открытая архитектурная инициатива RND-PRO, инженерной R&D-команды, которая занимается практическими инновациями в ПО, автоматизацией и альтернативными подходами к сложным информационным системам.

Проект исследует, как ИИ-агенты, обычные языки программирования, структурированные данные и динамически генерируемые интерфейсы могут заменить ненужные слои традиционного корпоративного ПО.

NoES -- развивающаяся концепция и референсная архитектура. Ее отдельные компоненты можно реализовывать независимо и внедрять постепенно.

Мы открыты к обсуждению, экспериментам и сотрудничеству.

NO ENTERPRISE SOFTWARE