Как автоматизировать протоколы встреч с помощью MCP и AI-агентов

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

Несколько часов в неделю экономит не сама транскрибация встреч, а связанный процесс: запись → расшифровка → проверяемые решения → действия в рабочих системах. Транскрипт даёт факты, AI-агент разбирает контекст, MCP подключает трекер, репозиторий и базу знаний, а человек подтверждает важные изменения.

Ниже — архитектура такого процесса, способ посчитать эффект без выдуманных процентов и план пилота для одного типа встреч.

Где теряются часы после встречи

После обычного созвона работа распадается на мелкие действия:

найти запись и дождаться расшифровки;
перечитать заметки и восстановить контекст;
отделить решение от идеи, вопроса или предположения;
сформулировать задачи, назначить ответственных и сроки;
проверить, нет ли таких задач в Jira, ClickUp или другом трекере;
обновить проектный документ;
отправить участникам итог и позже проверить выполнение.

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

Посчитать потенциал автоматизации можно на собственном календаре. Например, восемь встреч в неделю, после каждой из которых уходит 12 минут на протокол, 8 минут на задачи и 5 минут на рассылку итогов, дают 200 минут ручной работы. Это пример расчёта, а не отраслевой норматив. Подставьте фактические значения и добавьте время на поиск потерянных договорённостей — только так получится честная оценка.

Как устроен процесс: от записи до выполненного действия

Рабочая схема состоит из шести этапов.

Запись. Платформа встречи или отдельный сервис сохраняет аудио либо видео. Участники видят, что запись и транскрибация включены.
Транскрибация. Речь превращается в текст с временными метками и, по возможности, разделением по спикерам.
Нормализация. Система добавляет тему, список участников, ссылку на исходную запись и словарь терминов проекта.
Извлечение. AI-агент формирует кандидатов в решения, задачи, риски, открытые вопросы и изменения требований.
Проверка. Человек подтверждает неоднозначные пункты и все чувствительные действия.
Исполнение через MCP. Агент создаёт или обновляет объекты в рабочих системах и сохраняет журнал вызовов.

У Google Meet транскрипт сохраняется в Google Drive организатора и прикрепляется к событию Calendar. В Teams доступ к транскрибации управляется политиками, а материалы хранятся вместе с записью в OneDrive или SharePoint. Поэтому источником процесса может стать корпоративное хранилище, а не ещё один бот в каждом звонке. Подробности зависят от тарифа и настроек платформы: Google Meet Help, Microsoft Teams documentation.

Если расшифровка строится отдельно, выбирайте формат с временными метками и разделением реплик по спикерам. Например, API транскрибации может возвращать diarized_json с сегментами и идентификаторами спикеров. Тогда каждое извлечённое решение можно привязать к фрагменту записи, а не просить пользователя доверять пересказу модели: OpenAI Audio API.

Почему одного AI-саммари недостаточно

Саммари полезно читать, но оно не является системой исполнения. У него обычно нет стабильной схемы данных, проверки дублей, прав на изменение задач и связи с первоисточником.

Для автоматизации лучше требовать от агента структурированный результат:

{
  "decisions": [
    {
      "text": "Запускать пилот только для встреч discovery",
      "evidence": { "start": "00:31:18", "end": "00:31:52" },
      "confidence": "high"
    }
  ],
  "action_items": [
    {
      "title": "Подготовить схему хранения транскриптов",
      "assignee_candidate": "platform-team",
      "due_date_candidate": null,
      "evidence": { "start": "00:37:04", "end": "00:37:41" },
      "requires_confirmation": true
    }
  ],
  "open_questions": []
}

Важны не названия полей, а три свойства.

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

Это защищает от распространённой ошибки: модель услышала «можно попробовать в пятницу» и превратила фразу в обещание релиза к пятнице.

Что дают MCP и AI-агенты после транскрибации встречи

AI-агент отвечает за разбор контекста и последовательность шагов. MCP, или Model Context Protocol, даёт ему стандартный способ обнаруживать и вызывать инструменты внешних систем.

Для процесса после встречи полезен небольшой набор узких MCP tools:

find_issue — найти существующую задачу по проекту и смысловому совпадению;
create_issue_draft — подготовить черновик задачи без публикации;
add_meeting_evidence — добавить ссылку на момент записи и фрагмент транскрипта;
update_project_decision — предложить изменение журнала решений;
post_meeting_summary — отправить подтверждённый итог в нужный канал;
get_open_actions — проверить незакрытые договорённости перед следующей встречей.

Такой контракт лучше универсального инструмента call_any_api: сервер может валидировать поля, ограничивать проекты, скрывать секреты и логировать конкретное бизнес-действие. В спецификации MCP tools отдельно рекомендуется сохранять человека в контуре и показывать подтверждение перед чувствительными вызовами.

Агентный сценарий становится циклом, а не одноразовой генерацией текста:

получить транскрипт
→ найти решения и поручения
→ сверить их с проектным контекстом
→ найти дубли в трекере
→ показать изменения человеку
→ выполнить подтверждённые MCP-вызовы
→ сохранить ссылки и аудит
→ проверить открытые действия перед следующей встречей

Именно последние четыре шага превращают расшифровку в экономию времени. Без них команда просто получает ещё один документ, который нужно разбирать вручную.

Как внедрить автоматизацию протоколов встреч за один пилот

Начните не со всех календарей компании, а с одного повторяемого сценария. Например, еженедельной продуктовой встречи, после которой стабильно появляются задачи и решения.

Шаг 1. Зафиксируйте ожидаемый результат. Определите, какие сущности нужны после встречи: решения, задачи, риски, вопросы, изменения требований. Для каждой сущности задайте обязательные поля и критерий подтверждения.

Шаг 2. Выберите источник записи и транскрипта. Проверьте, где хранится файл, кто получает доступ, есть ли спикеры и временные метки, когда материал удаляется. Не стройте весь процесс вокруг копирования текста из письма, если платформа предоставляет управляемое хранилище или API.

Шаг 3. Добавьте контекст встречи. Агенту нужны не все документы компании, а короткий пакет: повестка, участники, проект, открытые задачи, последние решения и словарь названий. Лишний контекст повышает стоимость обработки и количество ложных совпадений.

Шаг 4. Разделите чтение и запись. На первом этапе агент только читает транскрипт и проектные данные, а на выходе создаёт предпросмотр. После проверки подключите отдельные write-tools для создания задач и обновления документов.

Шаг 5. Сделайте операции повторяемыми. Один и тот же транскрипт может попасть в очередь дважды. Используйте стабильный meeting_id, проверку существующих задач и idempotency key для операций записи. Повторный запуск должен обновлять черновик или возвращать уже созданный объект, а не плодить дубли.

Шаг 6. Измеряйте не красоту саммари, а завершение процесса. Сравните время от конца встречи до опубликованного протокола, долю задач с подтверждённым ответственным, число ручных переносов и количество исправлений после агента.

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

Безопасность: запись встречи содержит больше, чем список задач

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

Минимальный набор мер выглядит так:

участники понимают, что встреча записывается и как будет использован материал;
запись, транскрипт, саммари и задачи имеют отдельные правила хранения и доступа;
агент получает только встречи и проекты, доступные инициатору;
секреты трекеров и баз знаний остаются на серверной стороне;
write-tools ограничены конкретными действиями и требуют подтверждения там, где ошибка дорога;
журнал связывает пользователя, встречу, модель, MCP tool, параметры, результат и созданный объект;
чувствительные фрагменты можно исключить до передачи модели;
срок хранения исходной записи не становится бесконечным только потому, что автоматизация умеет её читать.

MCP стандартизирует вызов инструментов, но не гарантирует безопасность реализации. Официальные MCP Security Best Practices разбирают, среди прочего, риски передачи токенов, подмены полномочий и небезопасных прокси. Права, проверка входных данных, аудит и политика хранения всё равно должны быть спроектированы отдельно.

Где в этой схеме Codenik

Codenik не заменяет платформу видеовстреч и сервис распознавания речи. Он работает на следующем участке: между AI-агентом и корпоративными системами, куда должны попасть подтверждённые результаты встречи.

Схема выглядит так:

запись и транскрипт
→ AI-агент
→ Codenik
→ Jira / ClickUp / GitLab / документы / корпоративные сервисы

Через Codenik команда может отдать агенту только нужные MCP-инструменты, оставить секреты на серверной стороне, применить права пользователя и сохранить аудит вызовов. Например, агент читает транскрипт и открытые задачи, готовит три новых поручения, показывает их владельцу встречи и только после подтверждения создаёт записи в трекере.

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

Начните с одного типа встреч и одного действия — например, создание подтверждённых черновиков задач. Замерьте ручное время до пилота, сохраните ссылки на первоисточник и не расширяйте права агента раньше, чем процесс станет предсказуемым. Тогда запись встреч, транскрибация, MCP и AI-агенты складываются не в демонстрацию, а в рабочий конвейер, который может вернуть команде несколько часов в неделю.