Capstone: an AI lead-qualification pipeline

Капстоун собирает все навыки курса в один production-пайплайн: форма на сайте шлёт лида, система валидирует, обогащает, оценивает через LLM и раскладывает по корзинам.

Webhook (POST /lead)
  → валидация payload (IF / Code) ──невалидно──→ Respond 422
  → дедупликация (Remove Duplicates по email)
  → обогащение (HTTP Request: данные о компании по домену)
  → AI-скоринг (AI Agent + Structured Output Parser)
  → страховочный IF (tier из A/B/C, score в 0..100)
  → Switch по tier:
      A → CRM + мгновенный алерт менеджеру
      B → CRM + welcome-цепочка
      C → лог-таблица «позже»
  → Respond to Webhook: 201 { leadId, tier }

Контракт входа фиксируем сразу: { email, name, company, message, source }, обязательны email и message. Всё, что не проходит контракт, получает 422 и не создаёт side effects.

Порядок сборки — скелет раньше мяса: сначала весь путь на заглушках (Edit Fields вместо CRM, фиксированный tier вместо агента), сквозной прогон зелёный — и только потом замена заглушек реальными интеграциями по одной. Так каждая проблема локализуется в последней заменённой ноде, а не «где-то в пайплайне».

Скоринг — сердце пайплайна. System message агента описывает идеальный профиль клиента (ICP) и шкалу:

Ты оцениваешь B2B-лидов для платформы оркестрации AI-агентов.
Идеальный клиент: компания 20+ человек, есть инженерная команда,
в заявке — конкретная задача автоматизации, а не «просто интересно».
Верни score 0-100 и tier: A (>= 70), B (40-69), C (< 40).
В reason назови конкретные сигналы из заявки.

Structured Output Parser получает схему:

{
  "type": "object",
  "properties": {
    "score": { "type": "number" },
    "tier": { "type": "string", "enum": ["A", "B", "C"] },
    "reason": { "type": "string" }
  },
  "required": ["score", "tier", "reason"]
}

Парсер гарантирует форму, но не бизнес-смысл, поэтому после агента стоит страховочный IF: tier действительно из списка, score в диапазоне. Невалидный выход — не падение, а ветка manual review: лид дороже красивой архитектуры.

Temperature держите 0.1-0.3: скоринг должен быть воспроизводимым. Поле reason обязательно сохраняйте в CRM — менеджер должен видеть, ПОЧЕМУ лид получил tier A; непрозрачному скорингу перестают доверять за неделю. Дешёвый тест стабильности: прогоните десять эталонных лидов дважды и сравните разброс score.

Проектируйте с допущением, что внешние сервисы будут падать, — потому что будут.

Обогащение — необязательный шаг: лид без данных о компании ценнее потерянного лида. Поэтому у ноды обогащения On Error = Continue (using error output): ветка ошибки ставит enriched: false и возвращается в основной поток — скоринг работает по тем полям, что есть. Плюс Retry On Fail (3 попытки, 2000 мс) от транзиентных сбоев.

CRM — обязательный шаг: здесь Retry On Fail тоже включён, но при исчерпании попыток лид не исчезает — error-ветка пишет его в резервную таблицу (Google Sheets или Postgres) со статусом crm_failed, а error workflow из урока 5 шлёт алерт с execution.url. После починки CRM лиды доливаются повтором executions — дедупликация по email гарантирует, что доехавшие ранее не задвоятся.

Дедупликация стоит ДО side effects: повторный submit формы и ретрай отправителя не создают второго лида.

И журнал: каждая заявка — строка в лог-таблице (timestamp, email, tier, score, enriched, статус доставки в CRM). Эта таблица — одновременно аудит, дашборд для владельца процесса и датасет для будущего улучшения промпта скоринга.

Пайплайн готов не когда «демо прошло», а когда пройден приёмочный чеклист.

Функциональные сценарии: эталонный лид A-профиля → tier A, запись в CRM, менеджер получил алерт с reason; заявка «студент, пишу диплом» → C, менеджера не беспокоили; payload без email → 422, ни одной записи нигде.

Сценарии отказов: сервис обогащения выключен → лид прошёл со enriched: false и честным скорингом по остальным полям; тот же payload дважды → в CRM одна запись, второй запрос получил корректный ответ; CRM недоступна → алерт в error-канале, лид в резервной таблице, Retry execution после починки доводит его до CRM без дублей.

Метрики первой недели: медианное время от вебхука до ответа (цель — секунды); доля manual review — стабильно выше 10% значит, что схема или промпт слабые; согласованность с человеком — попросите менеджера вслепую оценить 20 лидов и сравните с tier модели. Расхождение больше ~30% лечится уточнением критериев ICP в system message, а не подкруткой temperature.

Это и есть выпускной стандарт курса: workflow, который переживает плохие данные, лежащие сервисы и повторы — и оставляет след, по которому его можно улучшать.