Каждый профессионал — разработчик своей работы
Бухгалтер раньше не был разработчиком. Теперь он со своим агентом строит себе инструменты и продолжает делать свою работу — уже в них. Рутину он автоматизирует сам.
Стать профессиональным инструментом, который специалист выбирает сам, — как 1С у бухгалтера, Консультант у юриста, Гранд-Смета у сметчика.Их никто не навязывал сверху: специалист не может без них работать, и компания покупает, потому что без них не может работать специалист.
Кто покупает и как продаём
Продаём не «платформу компании», а личный инструмент профессионала. Но сотрудники сами ничего делать не будут — мотор продажи директор.
Директор — покупатель
Видит измеренный кейс: «бухгалтер делает работу в разы быстрее и точнее». Загорается, покупает, требует результат от отделов. Видит его на доске.
Энтузиасты — первые скалолазы
5–10% людей в любой компании. Автоматизируют себя сами, а их путь записывается в рецепты.
Остальные — идут по лестнице
Им не нужно ни хотеть, ни уметь. Директор требует, рецепт есть, агент проводит по шагам.
Самостоятельные профессионалы — тренеры, трейдеры — покупают сами, без директора. Для них личная подписка и результат в первый же день.
Опорная модель — GitHub
Всё то же самое, только для людей, которые кода не видят. Разработчик у них — агент.
| GitHub | У нас |
|---|---|
| аккаунт | личный аккаунт профессионала |
| organization | компания |
| teams | отделы |
| repository | проект |
| Codespaces | среда разработки проекта |
| Copilot | агенты |
| Actions | автоматизации по расписанию: крон + скрипт, крон + LLM |
| Pages / Vercel | деплой и адрес проекта |
| Marketplace, template repo | рецепты |
| Sponsors | донаты авторам рецептов |
| transfer repository | переезд личной работы в отдел и компанию |
Кто есть кто
| Кто | Что это |
|---|---|
| IMJI (мы) | Среда разработки и инфраструктура: оркестратор, агенты, деплой, серверы, адреса, LLM, память |
| Оркестратор | Наша часть: люди, команды, права, агенты, доска. Как организация на GitHub |
| Разработчики | Все сотрудники: владелец, бухгалтер, юрист, тренер. Все разработчики, отличаются только правами |
| Агенты | Инструмент разработчиков, как Claude у программиста. Агент сотрудника универсален: строит, ведёт, поручает |
| Проект | Их приложение: бэк + сайт с меню и ролями + вход + данные + ключи + адрес |
| Каталог | Бывшая «платформа». Просто их первый проект, витрина их проектов и админок. Необязателен: нет его — всё работает |
| Пользователи проекта | Админы клуба, тренеры, игроки, покупатели. Входят только в проект, про IMJI не знают |
Как собирается компания
Компания не настраивается заранее — она собирается из тех, кто пришёл первым. Сначала, например, бухгалтерия, юристы и снабжение, потом остальные отделы в любом порядке.
Что должно работать с первого дня
- Человек первичен, компания — контейнер
- Работа переезжает из личного в отдел и компанию без пересборки
- Память по уровням: личная → отдела → компании
- Иерархия агентов = иерархия людей
Правила
- «Компания» и «отдел» не обязательный первый шаг
- Директор может прийти первым или последним
- Данные между отделами — только по выданному праву, видно кто кому открыл
- Ушёл человек — проекты остаются отделу и компании
Агенты
Агент — одно универсальное окно: разработать, поручить другому агенту, внести или найти информацию. Одно окно на разработку и ведение — это нормально и хорошо. Разница не в том, кто делает, а в том, как.
| Путь кода — разработка | Путь данных — ведение | |
|---|---|---|
| Что | строит проект: страницы, бэк, формы, вход | пользуется проектом: вносит документы, брони, данные |
| Как | меняет код проекта | через сам сайт — форму или API — под своим аккаунтом пользователя. Файлы и базу напрямую не трогает |
| Зачем так | На пути данных действуют правила сайта, роли и журнал «кто что изменил». Сайт переделают — данные не сломаются. Действия агента видны так же, как действия человека | |
Агенты-разработчики
Строят проекты. В каждом проекте у агента свой служебный аккаунт: им он тестирует и ведёт работу. Пароль владельца не просит никогда.
Агенты-рабочие
Работают в проекте как сотрудники: секретарь CTC разбирает почту и заносит письма в сайт через его API с ролью «секретарь». Часто по расписанию. Код не трогают.
CEO управляет всеми агентами: создаёт, пишет правила, ставит расписание, выдаёт роли. Агенты общаются друг с другом и ставят задачи вниз и между отделами.
Ядро системного промпта
Рецепты и донаты
Придут сильные бухгалтеры и всё сделают, остальные переиспользуют. Обмениваемся не копиями кода, а рецептами: код прибит к чужим счетам и чужой 1С, а рецепт агент исполнит под новые данные.
Откуда рецепт
- Сохраняем историю постройки каждого проекта: что просили, что агент решил, ошибки, проверки
- Тупики выкидываются, уточнения вшиваются в промпт шага
- Починенные ошибки становятся ловушками
- Своё (банк, счёт, база) заменяется параметрами
Донаты авторам
- Автор делится настройкой — аналитики, сверки, расписания, — не советом
- Кому помогло — донат автору
- Путь носит имя первого скалолаза
- Нужны платёжный провайдер, выплаты, налоговый статус автора
Рецепт — это цепочка промптов
Знания профессий заранее не пишем. Сначала показываем саму возможность, а знания бухгалтеров складываются из рецептов бухгалтеров — с их согласия и без их данных.
Кейсы по отраслям
Схема одна: рутина, которую руками никто не успевает делать каждый день, а агент делает. Цифры «было — стало» снимаем на реальных данных, не выдумываем.
Бухгалтерия · УПД
- было
- УПД заносят руками: минуты на документ, опечатки, завал к концу месяца. Руками завал не разобрать никогда
- стало
- Агент распознаёт, заносит, сверяет с заказом. Весь завал — за один день. «Вся первичка в учёте сегодня»
- замер
- 50 реальных УПД Miyoumi: минуты на документ, ошибки, часы в месяц
Падел-клуб
- было
- Брони в Playtomic, журнале и чатах, прайм-слоты сгорают, двойные брони
- стало
- Трекинг постоянных игроков, свободный прайм-тайм — им же. Загрузка кортов растёт
- замер
- загрузка, выручка со слотов, часы админа — на PTP
Тренер
- было
- Расписание в голове и WhatsApp, пропуски, оплаты по памяти
- стало
- Свой сайт-расписание, запись, напоминания, учёт оплат и долгов
- кто
- покупает сам, показывает коллегам
Спортзал
- было
- Кто перестал ходить — никто не замечает
- стало
- Агент находит пропавших и возвращает, следит за продлениями, расписанием тренеров
Стройка
- было
- Отчёты прорабов нерегулярные, исполнительная отстаёт
- стало
- Ежедневный отчёт из фото и голосовых, исполнительная, смета против факта
Автомойка
- было
- Загрузка боксов неравномерная, постоянных клиентов не помнят
- стало
- Загрузка, постоянные клиенты, напоминания «пора мыть» — как в паделе
Трейдер · акции и опционы
- было
- Дневник не ведётся, правила риска нарушаются, экспирации пропускаются
- стало
- ИИ-анализ графика и новостей → теория → сделка → самопроверка входа и выхода. Видно, какие теории зарабатывают
- границы
- сделки только с подтверждением человека; делятся настройкой аналитики, не сигналами
Общая схема
Проекты зависят от нас только как сайт от своего хостинга: сервер, деплой, адрес, LLM-API. От нашего кода и логики — никак.
Проект
«Создать проект» — кнопка в оркестраторе, как «New repository» и «New project» в Vercel. Нажимает разработчик с правами или агент по его задаче. Проект — отдельная среда разработки.
Что создаём мы
- Папку проекта с историей изменений из стартового шаблона
- Запускаемый сервис и пустую базу
- Адрес по умолчанию с сертификатом; свой домен потом
- Доступы разработчиков и агентов
- Деплои, логи, копии базы
Что внутри — их
- Сайт с сайдбаром и меню, вкладки по ролям
- Свой вход: регистрация, пароли, сессии, роли
- Служебный аккаунт агента
- Данные в своей базе
- Ключи внешних API: env + шифрование + форма «вставь ключ»; агент значения не видит
- Автоматизации: крон + скрипт, крон + LLM (через наш LLM-API из пула компании)
Не плодить проекты
«Цены для клуба» — вкладка в «Падел-клубе», не отдельный проект. Автоматизация селлера и падел — разные проекты: разные админки, вход, оплаты.
Адрес
Любой поддомен или свой домен. Агент привязывает сам через наш API; для своего домена владелец только вписывает запись у регистратора. Вывести проект в каталог или нет — их выбор.
Что даём мы
Среда разработки
Оркестратор, проекты из шаблона, агенты с системным промптом, скиллы (компания добавляет свои), память по уровням, индексация кода, документов и памяти.
Деплой и серверы
Сборка и запуск проекта, предпросмотр перед включением, база проекта, логи. Копии базы и откат «верни как вчера».
Адреса
API «привяжи адрес к проекту» + сертификат. Поддомен работает сразу.
LLM
Пул подписок компании (например, 5 GPT) живёт у нас, в инфре агентов, обслуживает только её агентов. Проектам — LLM-API из пула своей компании; свой ключ — по желанию.
Сеть
Бэки проектов ходят в интернет напрямую, только порты 80 и 443. Наши внутренние адреса закрыты. Прокси — только у агентов для LLM.
Доверие
Изоляция компаний, журнал «кто что изменил», подтверждение человеком всего необратимого, данные в России.
Чего мы не даём
Вход для проектов, хранилище их данных, сейф их ключей, готовые разделы, раздачу их страниц из нашего бэка, особые правила под одну компанию. И не строим решения под клиентов руками.
Заложить с первого дня
Иначе первые сильные пользователи построят вещи, которые никому нельзя будет отдать, а компания не соберётся без переделки.
Стандарт проекта
- Код отдельно от данных; структура базы описана в коде
- Ключи только через форму
- Своё — в настройках, а не в коде
- Единая структура из шаблона
- Демо-данные: работает до подключения своих
Паспорт проекта
- Какие сервисы подключить
- Какие ключи и параметры спросить
- Роли, расписания, использование LLM
- Установка = агент читает паспорт и присылает формы
История постройки
- Журналы сессий агента привязаны к проекту и хранятся
- Агент собирает рецепт из истории без данных и ключей
- Правила компании отделены от общего знания
Контейнеры людей
- Человек → отдел → компания без переезда
- Права, память и оплата по уровням
- Общие коннекторы как кирпичи: пишутся один раз
Главная ошибка старого SBS
Мы построили платформу компании как свой продукт на своём бэке, а приложения — как её разделы. Продавали компании, а не человеку, и сами допиливали клиентам решения — это агентство, не продукт.
| Старый SBS | Новый продукт |
|---|---|
| Вход — регистрация компании владельцем, обязательный CEO | Вход — человек; компания собирается сама |
Приложение = раздел /platform/<key>/, страницы отдаёт наш сервер из папки агента | Проект со своим бэком и адресом, живёт сам |
| Плоская куча квадратов у разных агентов (у PTP 9 разделов у 3 агентов) | Один проект = один сайт с меню |
| Два бэка — наш и их, агент путается | Один бэк — их |
| Вход в приложение — IMJI-сессия; агент не может войти в своё приложение | Свой вход, тестовый аккаунт агента |
Данные и пользователи у нас: data.json, records, agent-apps/users | В базе проекта |
| Агент строит раздел и сам же заливает в него данные мимо сайта (Miyoumi) | Ведение — через сайт, как пользователь |
| Ключи в нашем сейфе, бэк ходит за ними на каждый запрос | Ключи в проекте: env + шифрование + форма |
| Бэки выходят в интернет через наш прокси, запросы зависают | Напрямую, 80/443 |
| Особые фильтры для поддомена; регрессия в них положила PTP на 3,4 дня | Наш код знает только «проект + адрес» |
| Промпт ~55 000 символов, противоречит сам себе | Короткое ядро самостоятельного разработчика |
| Решения под клиентов делаем мы | Решения строят и раздают сами пользователи |
Два проекта
Старый SBS живёт как есть для текущих клиентов: PTP, Miyoumi, CTC, селлеры. Принудительно не мигрируем. Новый продукт — отдельный проект с нуля: своё ядро, свой репозиторий, свой деплой. Новые клиенты — сразу в новый, старые переходят по желанию; PTP первым, как кейс «Падел-клуб».
Берём из старого — копированием
- Запуск агентов («прозрачная труба»), ходы, стриминг
- Пул LLM: классификация отказов, общий лок, ротация
- Память и индексация (Qdrant)
- Расписания, делегирование, задачи между агентами
- Изоляция компаний: ОС-учётки, namespaces, сетевые правила
- Конвейер деплоя бэков, зеркала образов, база под бэк
- Поддомены, свои домены, сертификаты
- Журналы сессий агентов — основа рецептов
- Коннекторы: WB, Ozon, Точка, 1С, Playtomic, Telegram — как образцы
- Кластер, CI/CD, логи, память об инцидентах
Не берём
- Разделы
/platform/<key>/, хаб с квадратами, встроенные дашборды agent-apps/users,records,data.json- Host policy и host gate для поддомена компании
- Прокси и выдачу ключей бэкам через шлюз
- Исключения под одну компанию (Miyoumi 157)
- Промпт 55 000 символов, PLATFORM.md
- Company-first регистрацию, перепривязку бэка при входе
- Guard, отбивающий жалобы агентов на инфраструктуру
Модули берём копированием в новый репозиторий, а не общей зависимостью: правка в старом не сломает новый.
Этапы
Не всё сразу. Знаний профессий заранее не пишем — сначала показываем саму возможность.
Агент + среда проекта. Проект из шаблона, новое ядро промпта, деплой и адрес из старой инфры. Непрограммист доходит до результата, ни разу не упёршись в технику.
Копии, откат, подтверждение необратимого, журнал изменений.
УПД на Miyoumi и PTP как «Падел-клуб». Честные замеры «было — стало» для директоров.
Личный вход без компании и кнопка «показать боссу».
История постройки → рецепты, публикация и установка. Отсюда растут знания профессий, потом донаты.
Отделы, связи между проектами, доска директора, оплата мест и договор компании.
По нашим правилам новое ядро — программа архитектуры: сначала ТЗ и бэклог с границами и критериями готовности, потом код пакетами.
Открытые вопросы
- Вход разработчиков в свой каталог. Решено: тот же вход, что в оркестратор. Технический механизм выбрать.
- Доступ агента к базе проекта. Чтобы агент не читал ключи из базы и окружения (сейчас агенты PTP читают базу напрямую через
psql). - Каталог при регистрации: ставить из шаблона сразу или по желанию.
- Индексация: что именно — код проектов, документы, память агентов.
- Донаты: платёжный провайдер, выплаты авторам, налоговый статус.
- Цены: личная подписка, места в отделе, договор компании, расход LLM.
Откуда выводы
Разбор инцидента PTP 19–22.09 по логам, базе, журналам сессий агента и коду показал, что каждая поломка — следствие одной ошибки: продукт компании наполовину жил на нашем бэке.
- Агент знал свой бэк: прочитал discovery, README и openapi сервиса 72 и сам прописал привязку.
- Наши фильтры для поддомена закрыли путь к бэку, тест закрепил это как норму — PTP не работал 3,4 дня.
- Агент дважды сообщил о баге, guard отбил: «edit the tenant backend or app draft».
- Платформа отвечает 302 «войди» на любой несуществующий адрес раздела — агент принял его за живой маршрут.
- Агент не мог войти в собственное приложение: своего входа нет, токен агента получает 401.
- Запросы к Playtomic зависали на нашем прокси; напрямую из кластера — 80 из 80 за ~1 с.