Содержание
  1. От первых ботов к своему проекту
  2. Компания внутри компьютера
  3. Самая сложная часть — связать исполнителей
  4. Как появились контроль и восстановление
  5. От личной разработки к предложению для бизнеса
Кейсы

Как Александр Морозов создал Mag_OS — систему с ИИ-директорами

11 ноября 2026 · 5 минут чтения

Александр Морозов, 44 года · Москва

Александр Морозов работал в банковской верификации: проверял сделки с точки зрения экономической безопасности. В Зерокодере он начал с чат-ботов на Salebot, затем освоил Python и перешёл к программе «Промпт-инжиниринг». Из учебных ботов и небольших собственных автоматизаций выросла Mag_OS — система, в которой человек ставит задачи, а ИИ-директора организуют работу по направлениям.

От первых ботов к своему проекту

Александр называет себя «гуманитарием в квадрате». В молодости он уже пробовал учиться IT, но практические задачи давались тяжело. Когда на новом обучении дошло до чат-ботов, знакомая трудность вернулась: временами казалось, что разобраться с ними не получится.

Помогло подключение языковых моделей. С их помощью стало проще разбирать задачи, а с переходом к Python, по словам Александра, работать оказалось ещё легче. Постепенно расширялся и набор инструментов: к Salebot добавились нейросети, средства разработки с ИИ и n8n для связывания сервисов в автоматические сценарии.

Перед покупкой курса Александр около года смотрел вебинары. Ему было важно следить за развитием ИИ и сохранять доступ к новым знаниям. Каждый следующий курс добавлял к предыдущему ещё один способ решить задачу. Сначала он собирал простые учебные модели и пробовал автоматизировать собственные мелкие дела.

К Mag_OS Александр, по его словам, приступил через три-четыре месяца после окончания курса. Отправной точкой стал собственный опыт: ему хотелось сделать помощника для человека, которому сложно общаться с компьютером на техническом языке.

Компания внутри компьютера

В основу Mag_OS Александр положил привычную модель организации. Владелец выступает в роли CEO: задаёт цель, определяет приоритеты и принимает решения. ИИ-директора отвечают за направления, а специализированные ИИ-сотрудники пользуются инструментами и возвращают результаты.

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

Для медийного направления нашлась личная задача. Александр пишет посты и книги, выкладывает главы на YouTube. Раньше ему приходилось отдельно загружать ролики на площадки и готовить описания. По его словам, он настроил сценарии, в которых система помогает готовить описание и публиковать материалы в Telegram, MAX и YouTube. Возможности каждого подключения зависят от доступных операций и разрешений площадки.

Управление собрано в главном окне CEO: здесь видны дирекции, проблемы, предложения и ожидающие согласования. Внутри направления есть «Диалог», «Показатели» и «Планёрка». Через них можно обсудить поручение, посмотреть состояние работы и собрать цели и результаты недели.

Главное окно Mag_OS с инженерной, инфраструктурной и медийной дирекциями
Главное окно Mag_OS с инженерной, инфраструктурной и медийной дирекциями

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

Самая сложная часть — связать исполнителей

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

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

Сама разработка тоже строилась как совместная работа с ИИ. Александр формулировал идею, требования и цели, просматривал и исправлял промпты, принимал решения. Модели помогали с проектированием, кодом и проверками. Codex он использовал как главного инженера: тот разбирал задачу, делегировал часть работы ZCode и объединял результаты.

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

Как появились контроль и восстановление

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

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

Чтобы узнавать состояние направлений без постоянных вопросов директорам, он разработал Director Operations Loop — цикл наблюдения за сервисами и процессами. По его описанию, обычные проверки выполняются программно, а языковая модель подключается для интерпретации результатов и подготовки отчёта. Это позволяет разделить регулярный сбор состояния и работу, которой нужен ИИ.

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

От личной разработки к предложению для бизнеса

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

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

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

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

Читайте также

3 материала