Ad-hoc вопрос — с запросом в приложении
Кто-то спрашивает, что случилось с конверсией на 27-й неделе. Пишет запрос, гоняет его, сверяет результат со вторым срезом и отвечает и числом, и SQL. Следующему спрашивающему вы тоже не нужны.
Решения·Data Science
Сессия — это реальная Linux-машина. Агент ставит то, что нужно, гоняет запрос, пишет скрипт, который можно прочитать, и коммитит. На выходе — анализ и код, который его произвёл: воспроизводимый по определению, потому что это файл в repo.
Передача работы
Большая часть очереди — не моделирование. Это четвёртая вариация уже заданного вопроса, pipeline, который сломался ночью, или определение «active», о котором не согласны три команды. Эта очередь — передача работы.
Кто-то спрашивает, что случилось с конверсией на 27-й неделе. Пишет запрос, гоняет его, сверяет результат со вторым срезом и отвечает и числом, и SQL. Следующему спрашивающему вы тоже не нужны.
Читает ошибку, воспроизводит трансформацию на своей машине на sample, находит форму строки, которая всё сломала, и открывает change request с фиксом и тестом, который бы это поймал.
Null там, где не должно быть, сдвинувшиеся распределения, join'ы, которые начали размножаться, dimension, который вырос на 40% за ночь. Сообщает, что сдвинулось и что, по его мнению, сдвинуло — и говорит, когда не знает.
Находит каждое место, где считается метрика, diff'ит определения друг с другом и сообщает, где они расходятся. Неприглядно, реально сложно запланировать — и причина, почему два дашборда показывают разную выручку.
Профилирует датасет, строит распределения, проверяет leakage и imbalance и пишет первый честный абзац о том, что в данных. Вы начинаете с брифа, а не с пустой ячейки.
Еженедельный cohort cut, месячная кривая retention, квартальное обновление сегментов. Тот же код, новый период, запуск по триггеру, попадает как change request с перегенерированным графиком.
Результат
Ответ в чате нельзя опровергнуть и повторить. Поэтому сессия анализа коммитит работу: запрос, скрипт, notebook, график и заметку о том, что проверила. Это и приходит на ревью.
У агента есть shell и файловая система. Может поставить пакет, стянуть sample, запустить, посмотреть вывод и попробовать снова — цикл, в котором реально работает аналитик, а не один выстрел фиксированным набором tools.
Ответ и то, что его произвело, приходят вместе в одном change request. Перезапуск через месяц — re-run, а не реконструкция.
Фильтры, границы дат, строки, которые отбросило, и почему. Анализ без задокументированных исключений — не анализ, а комментарий в запросе — самое дешёвое место их хранить.
Куда дотягивается
Мы не будем выстраивать ряд логотипов warehouse, которые не проверяли. Вот что правда про то, как сессия анализа достучится до данных — включая часть, где работа идёт локально.
Сильнейший data-коннектор на этой странице — sandbox. Стянуть extract, работать локально тем, чем вы обычно пользуетесь, и не переносить анализ в tool, который не умеет арифметику.
Доступ через коннектор, который вы определяете: OpenAPI, Postman, GraphQL, raw HTTP или удалённый MCP-сервер. Neuro OS превращает каждую операцию в tool со своим Allow, Ask или Block.
Клонируется при старте сессии на свежей ветке. Код трансформаций, определения метрик и прошлые анализы уже там — агент может сверить новое определение с существующим.
Потому что половина реальных входов в анализ — spreadsheet, который кто-то ведёт руками. Читает как source и пишет результат туда, где его будет искать заказчик.
Живой канал. Задайте вопрос в треде, где он возник; ответ, график и запрос вернутся в тот же тред.
Easy connect покрывает SaaS-источники по краям. Для самого warehouse прямые типы коннекторов — обычно честный ответ: большинство warehouse достигаются через driver или API, а не OAuth-каталог.
Как это крутится
Та же механика сессии запускается тремя способами. Изоляция и путь ревью не меняются от триггера.
Кто-то спрашивает в канале. Mention запускает сессию, сессия делает работу на своей машине, ответ возвращается в тот же тред с приложенным запросом.
Чтение — Allow, всё, что пишет в warehouse или перезаписывает таблицу — Ask. Прогон останавливается на вызове с statement перед вами и продолжается с того же места после согласования.
Cron-триггер перезапускает повторяющийся анализ на новый период и открывает change request с перегенерированным результатом. Второй гоняет quality sweep и говорит только когда проверка падает.
Контроль
Агент анализа — в основном задача чтения. Пока не перестанет. Будьте точны в обеих половинах.
Дефолт при поставке — permissive: действие выполняется, пока вы не сказали иначе. Чтение обычно так нормально. Запись в warehouse — нет; поставить их в Ask — ваша настройка.
Агент получает только перечисленные коннекторы и не может обнаружить остальные. Аналитический агент до warehouse и support-агент до helpdesk — разные grants.
Notebook, запрос и фикс попадают через change request в main. Агент не может merge, пока admin не выдал право в versioned config — расширение grant само проходит ревью.
Credential коннектора брокерится на сервере и не попадает в машину. Runtime secret, который вы сознательно даёте сессии, — реальное env-значение внутри неё. Стоит знать, прежде чем выдать пароль warehouse вместо коннектора.
Сессии не делят working tree или файловую систему. Extract, стянутый в одну сессию, не виден другой — машина одноразовая.
Та же платформа
Один проект, один набор коннекторов, одна память, которая накапливается. Каждая команда пишет skills под свою работу; никто не поднимает вторую систему.
«Анализ, который можно перезапустить — не число в окне чата.»
Любая модель, ваши ключи. Neuro OS в вашем облаке, VPC или on-prem.