Arcanada проще объяснить не перечнем продуктов, а маршрутом одной задачи.
Допустим, основатель хочет проверить идею нового сервиса. Сначала нужно понять предметную область и отделить факты от предположений. Затем сравнить варианты архитектуры, выбрать один, реализовать его и доказать, что результат соответствует исходному намерению. После паузы другой человек или агент должен продолжить работу без пересказа всей истории.
Обычный чат с моделью помогает на отдельных участках. Для полного маршрута нужна система.
В рабочем виде маршрут выглядит так: замысел → зафиксированное намерение → требования → план → реализация → независимая проверка → compliance → отдельное разрешение на публикацию или другое необратимое действие.
Datarim задаёт жизненный цикл
Datarim появился как способ проводить задачу через явные стадии. В публичном описании их восемь: init → prd → plan → design → do → qa → compliance → archive.
Ценность не в обязательном прохождении всех стадий для любой мелочи. Важно, что на переходе остаётся проверяемый артефакт:
- исходное намерение не растворяется в переписке;
- требования отделены от способа реализации;
- архитектурное решение имеет основания;
- автор реализации не считается единственным проверяющим;
- завершённый цикл сохраняет знания для следующего.
Так задача получает память и контрольные точки.
Arcanada добавляет недостающие способности
Практика быстро показала, что одного процесса недостаточно. Исследованию нужен поиск по источникам. Разным стадиям подходят разные модели и роли. Длинной работе нужна память. Сервисам нужны идентификация, наблюдаемость и управление. Публикации нужен контролируемый канал.
Arcanada связывает эти способности в общую среду. Отдельные компоненты отвечают за работу с моделями, знаниями, публикацией и управлением. Степень их готовности различается, поэтому наличие компонента на карте нельзя считать доказательством полной готовности или заданного уровня автономности.
Arcanada — операционная система для человеческих идей.
Для меня это метафора, а не название готового технического продукта: среда должна связывать замысел, исполнителей, память, доказательства и право человека принять окончательное решение.
Роли важнее персонажей
В агентной системе полезно разделять исследователя, архитектора, разработчика и проверяющего. Это не обязательно четыре разные модели. Главное, что у ролей разные задачи и критерии.
Исследователь собирает варианты и источники. Архитектор выбирает структуру и фиксирует компромиссы. Разработчик меняет систему. Проверяющий пытается опровергнуть утверждение о готовности. Человек утверждает цель, принимает риск и разрешает необратимые действия.
Такое разделение снижает вероятность того, что одна и та же уверенная версия сначала создаст решение, а потом сама же его одобрит.
Доказательство зависит от границы
Файл на диске доказывает только наличие файла. Локальный тест — поведение в локальном окружении. Публичная страница — то, что увидит посетитель. Ни одно из этих доказательств нельзя автоматически подменить другим.
Поэтому система должна отвечать на три вопроса: что изменилось, чем это подтверждено и кто разрешил следующий шаг.
Уровни автономности помогают обсуждать эту границу точнее. Может ли агент только предложить действие? Может ли выполнить обратимый шаг? Требуется ли подтверждение перед публикацией, изменением доступа или работой с деньгами? Целевые уровни Arcanada не означают, что вся экосистема уже достигла их.
Для меня связка Datarim и Arcanada — не виртуальная компания и не витрина AI-инструментов. Это попытка сделать длинную работу наблюдаемой: дать ей роли, память, доказательства и человека, который сохраняет право решения.
Источники и дата проверки
- Datarim: жизненный цикл задачи, проверено 21 июля 2026 года.
- Arcanada: экосистема и компоненты, проверено 21 июля 2026 года.
Перед публикацией продуктовые статусы и формулировки нужно проверить повторно.