ИИ-агент отправил восемь откликов за неделю, но не добился собеседований

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

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

Подборка готова, а результата пока нет

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

Для отбора используется десятибалльная шкала с порогом 6,5. Учитываются руководящая роль, география, формат работы, тип компании и управленческий опыт. Агентства и заказная разработка исключены по предпочтениям соискателя. Если обязательного навыка нет, оценка снижается или вакансия отбрасывается.

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

Ошибки возникают между отдельными действиями

Самая показательная поломка связана с учётом ответов. Работодатель прислал шаблонное сообщение о рассмотрении резюме, а в списке откликов сохранился статус «Просмотрен». Агент не отразил сообщение в воронке. Автоматизация читала один источник состояния и пропустила другой.

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

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

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

Что стоит забрать в свой продукт

У агента есть полезный результат: автор больше не ищет вакансии вручную, а материалы для подготовки к интервью собраны в одном месте. Но подготовленную базу он, по собственным словам, ни разу не открыл. Создание файла ещё не означает, что следующий шаг процесса состоялся.

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

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