Как я за месяц перевела команду с SQL-промптов на мультиагентную систему и сэкономила команде 200 часов

Привет! Меня зовут Дарья Воронкина. Я строила и руководила командой DataHub в медтех-компании OneCell (цифровая патология — ИИ ищет опухоли и метастазы на гистологических стеклах), а сейчас консультирую компании по переходу в AI-native режим.

Расскажу, как примерно за месяц я перевела свою команду с ручных промптов на систему агентов, которая ведет операционку сама. Получилось быстро во многом потому, что за плечами годы ML-инженерии и роль лида — я уже привыкла мыслить системами, данными и процессами, оставалось переложить это на агентов. Дальше — что получилось, что сломалось и какие выводы я унесла. Будет полезно тем, кто уже собирает агентов и хочет довести их до прода.

Не ИИ работал на меня, а я на него

Поначалу я отдавала нейросети самое простое — текст и SQL. Рутину, которую делала руками сто раз: «напиши запрос к базе по таким условиям», «разбери этот кусок данных». До медтеха я преподавала математику и сидела в разметке, где огромная часть работы — повторение. Его я и начала делегировать.

В какой-то момент я поймала себя на телесном раздражении. Каждое мое рабочее утро превратилось в копипаст: сюда — контекст, оттуда — ответ, обратно — поправить, потом снова объяснить чату, кто я и какая у нас схема данных. Потолок обнаружился быстро. Один запрос — один ответ. Завтра модель не вспомнит, о чем мы говорили, и каждую сессию ей заново нужно объяснять, кто я, как устроена схема данных, какие у нас конвенции. На ввод контекста уходило больше, чем экономилось на ответе.

Это и есть граница между «пользоваться ИИ» и «построить ИИ-систему». Чтобы ее перейти, чату не хватает трех вещей:

• памяти о том, кто вы и что было раньше;

• доступа к вашим данным без ручного переноса;

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

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

Первый кейс: команда агентов вместо часа ручного SQL

К нам потоком шли запросы вида «выгрузите данные по таким-то случаям». Раньше аналитик садился, писал SQL, валидировал, экспортировал — час-два на каждый запрос. Я выбрала этот процесс первым по трем фильтрам, которыми пользуюсь до сих пор: частота, боль и описуемость. Запросы шли постоянно, отъедали часы, и у них был четкий вход и выход — понятно, что значит «готово». Четвертый критерий добавила со временем: я сама должна уметь делать это руками, иначе не отличу хорошую работу агента от правдоподобной чуши.

Сейчас выгрузку делает не аналитик, а команда агентов. Она генерирует SQL, сама себя проверяет, валидирует результат и отдает сводку со списком ID. Шесть минут вместо часа-двух. Самая важная деталь — агенты перепроверяют друг друга до 100% уверенности перед выдачей. Это медданные, здесь «примерно правильно» не катит: ошибка в выгрузке — это потенциально неверный вывод о данных пациентов.

Team OS: операционка команды, которую держит не человек

Главный кейс родился из другой боли. Операционка съедала команду заживо. Стендапы, разбор задач, планирование, ретро, отчеты — это часы в неделю на каждого и главный источник выгорания. Люди приходят строить ИИ для онкологии, а тонут в координации. Я как лид тратила непропорционально много времени на «кто что делает и почему застряло», а не на сами решения.

И дело было в самой механике трекера. Jira не ведет операционку — ее ведете вы: руками накидать задачи, проставить статусы, собрать стендап, свести отчет. Трекер лишь хранит то, что вы в него занесли. Я хотела наоборот: чтобы рутину держала система, а человек принимал решения.

Так в марте 2026-го появился Team OS — операционная система команды на агентах. Не таск-трекер с ИИ-кнопкой, а среда, где агенты сами ведут операционку: предлагают задачи из бэклога, связывают их с планом развития сотрудника и целями компании, оценивают сложность, проводят стендапы, планирование и ретро. Для команды это не дополнило Jira, а заменило ее целиком.

Началось с DataHub. До этого агенты делали у меня точечные вещи — ту же выгрузку данных за шесть минут вместо часа. Team OS был первой попыткой отдать им не отдельную задачу, а целый командный ритуал — и первой, которая прижилась. Дальше мы раскатали подход на команду ERP/Scanner, и в периметре оказалось до восьми команд. Совпало это с курсом компании на AI-native: Team OS стал у нас первым кейсом, где привычный инструмент заменили не «ИИ-надстройкой», а связкой агентов целиком.

Эволюционировало это в две фазы:

Фаза 1 — все внутри Claude Code, в терминале. Скиллы как действия команды, память как контекст (схема данных, конвенции), интеграция с GitLab и Notion, хуки: на старте сессии система сама подтягивает задачи сотрудника из Notion и то, что в работе, из GitLab. Крутилось 24/7 на ML-машине через tmux. Каждому агенту-роли я дала личность реального человека — например, Торвальдса. Это не игрушка: с заданной личностью агент держит характер и не расползается. Условный Торвальдс не напишет сопли в коде.

Фаза 2 — веб-интерфейс и синхронизация. UI я собрала за десять часов через Claude Design с передачей в Claude Code. Перешла с бэклога на методологию GTD: туду-лист плюс сущность «проект». Главная фишка — синхронизация сессий: одной кнопкой система подключается к машине пользователя, тянет его рабочие сессии по всем задачам через крон-джобы и считает фактически потраченное время. Поверх — оценка часов план/факт, capacity-планирование и автотриаж, который показывает похожие прошлые задачи, чтобы переиспользовать контекст.

Честно про боль этой фазы: веб-интерфейс не может напрямую управлять действиями пользователя, только синхронизироваться с его локальной машиной. Местами сессия и память недосинхронизируются. Это архитектурное ограничение, с которым я вожусь до сих пор.

Как это устроено

Ядро — Claude Code, а не чат. Стек выглядит так:

• CLAUDE.md и папка memory/ — контекст: кто мы, схема данных, конвенции, правила.

• Скиллы (SKILL.md) — конкретные действия: что сделать и как.

• Sub-агенты через оркестратор — он спавнит роли по очереди.

• MCP — доступ к данным и сервисам: GitLab, Notion, базы.

• Хуки — на старте грузят задачи, после действий трекают время.

• Файлы состояния — через них агенты передают друг другу контекст в цепочке.

• Оркестрация моделей по стоимости задачи: Opus на стратегию и архитектуру, Sonnet на код и рутину, Haiku на поиск и логи. Лить Opus на разбор логов — деньги на ветер.

Классический RAG я почти не использую — память у меня файловая. И вот здесь интересное.

Я собрала CoALA руками, не зная, что это CoALA

Когда я чинила память агентов, я делала это по болям, по одной. Агент забывает, кто я, — добавляю факты и правила в CLAUDE.md. Не знает, как делать конкретную операцию, — пишу скилл. Не помнит вчерашнюю сессию — включаю авто-память, где агент сам дописывает себе заметки.

Потом я узнала, что собрала ровно ту структуру, которую academia описала еще в 2023-м. Фреймворк называется CoALA — Cognitive Architectures for Language Agents (arXiv:2309.02427, Sumers, Yao, Narasimhan, Griffiths). Он раскладывает память языкового агента на четыре типа:

• рабочая — контекстное окно, все, что в сессии прямо сейчас;

• семантическая — факты и правила; у меня это CLAUDE.md и memory;

• процедурная — навыки, «как делать»; у меня это скиллы;

• эпизодическая — память о прошлом, что было в прошлых сессиях; у меня это авто-память.

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

Где проходит граница автономии

У меня нет догмы «давайте все сделаем автономным». Само, по триггеру или расписанию, работает сбор и рутина: загрузка задач на старте сессии, агент-ресерчер датасетов (каждые шесть часов проверяет источники и досылает новое в тред), сам Team OS 24/7.

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

И отдельно про зрелость. Я не на одной ступени, а на спектре — это нормально. Флагман (Team OS и ERP-пайплайн) — уже мультиагентная цепочка с оркестрацией и автозапуском. Часть процессов живет на уровне простого скилла. Часть я осознанно оставила руками. Я не верю, что «мультиагент всегда круче»: часто один хороший скилл бьет сложную оркестрацию. Team OS ценен не количеством агентов, а тем, что держит операционку команды без меня.

И к этому вопросу каждый практик относится по-своему — от жесткого скепсиса до мультиагента в проде.

«95% задач решаются одним вызовом модели в детерминированном workflow. Мульти-агент добавляет точки отказа без выгоды для простых кейсов»
— Александр Пантелеев, CTO World Chess, преподаватель курса «ИИ-автоматизация» (ИТМО AI Talent Hub × karpov.courses)

«Уже мультиагентно — у меня даже есть сплоченная команда из ИИ-сотрудников. Например, поиск трендов: там 19 агентов разбирают новостную повестку».
— Виталий Лукин, директор по ИИ-агентам в X5, преподаватель курса «ИИ-автоматизация» (ИТМО AI Talent Hub × karpov.courses)

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

Ошибки, которые стоили дороже всего

Самый дорогой провал — это доверие к выводу, который выглядел правильным. Классика: агент сделал SQL с ROLLUP по полю, в котором был COALESCE, и тихо удвоил каждую строку. Цифры выглядят нормально, сводка красивая, а она вдвое больше правды. В медданных это не «упс» — а потенциально неверный вывод о пациентах.

Этот баг научил меня главному принципу: доверие к агенту строится на проверке, а не на вере. Теперь агенты валидируют сами себя и перепроверяют друг друга, а на дашборды я повесила алерты на некорректные метрики.

Второе наблюдение — про переход «работает у меня» → «работает в проде». Когда ты сидишь рядом с агентом, ты постоянно его незаметно подправляешь: «нет, не отсюда бери», «тут другой случай». Ты этого даже не замечаешь. В проде агент остается один — и вылезает все, что ты считал «и так понятным»: что данные лежат не там, где логично; что бывают странные случаи, которые ты руками всегда обходил; что половина правил жила только в твоей голове. Лечится скучно: выгрузить свою голову в память агента, написать тесты и оставить ему понятный путь «спросить, если не уверен».

Отдельная категория боли в проде — бесшумные сбои. Агент не падает с ошибкой, а «работает» просто медленно, наполовину или по кругу. Об этом рассказал Александр Пантелеев, который выводил в прод систему автоперевода на n8n:

«Webhook без защиты от зацикливания за полчаса накрутил 700+ лишних запусков и сжег половину дневного бюджета. HTTP-запрос к модели без таймаута однажды висел 31 час. А родительский таймаут в n8n незаметно наследуется дочернему сценарию — у меня агент успевал перевести 2 языка из 14, и контент-команда жаловалась, что переводы выходят только на немецком. Бесшумные сбои опаснее громких: упади оно с ошибкой — заметил бы сразу. „Работает в тесте“ и „работает в проде неделю подряд“ — две разные задачи, и вся разница в обработке ошибок. Закладывайте на нее половину времени, а не на happy path».
— Александр Пантелеев, CTO World Chess

Что это дало в цифрах

• Team OS — главный по эффекту: на пике автоматизации давал возврат вложений до 700% за две недели и снимал с команды около восьми часов рутины в неделю.

• datahub-dump — шесть минут вместо часа-двух, эффект ×12.

• Суммарно по команде — порядка 200 сэкономленных часов.

• Бонусом — прототип UI внутреннего продукта собрала за десять часов через Claude Design и Claude Code вместо недель разработки.

Красивые ROI-числа из презентаций я показываю осторожно — слишком легко натянуть. Мерю в часах и в том, перестал ли процесс меня бесить.

Три вещи, с которых я бы советовала начать

1. Возьмите одну рутину, которая бесит, повторяется и имеет четкое «готово». Не творчество и не стратегию. И такую, что умеете делать руками, — иначе не проверите агента.

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

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

Как создать агента, если вы не ML-инженер?

После такого рассказа закономерно спросить: окей, у тебя получилось за месяц — а что делать тем, кто не имеет опыта в ML? Мой результат — это во многом тот самый бэкграунд: я уже мыслила памятью, состоянием и процессами, оставалось переложить это на агентов. Без него путь длиннее и идет ровно через грабли: контекст, бесшумные сбои, доверие к результату. Собирать это по разрозненным постам, статьям и собственным шишкам кому-то в кайф, но займет много времени.

Если же вам ближе систематизированный маршрут, чем годы набивания контекста, — посмотрите курс «ИИ-автоматизация: проектирование и запуск агентных систем» (karpov.courses × AI Talent Hub, ИТМО). Это та же дорога от первого скилла до агентной цепочки, но собранная в структуру: без воды и на вашей реальной задаче. Также Александр Пантелеев, и Виталий Лукин, чьи комментарии вы видели выше, преподают на курсе. 

С курсом или без — главное, что я хотела передать этим текстом: агент начинает работать, когда вы дадите ему память, роль и проверки. Это доступно без сильного ML-бэкграунда — нужно перестать крутиться вокруг чата и начать выстроить вокруг себя систему.