Мой ведущий агент n8n выглядел нормально, пока я не обнаружил три точки отказа: Apollo 200, HubSpot 423 и неверные передачи обслуживания JSON.

Мой ведущий агент n8n выглядел нормально, пока я не обнаружил три точки отказа: Apollo 200, HubSpot 423 и неверные передачи обслуживания JSON. В 2:13 мой поток обогащения потенциальных клиентов n8n дважды отметил одну и ту же перспективу как обогащенную, Apollo вернул HTTP 200 без ничего полезного, HubSpot выдал 423 Locked, а GPT-5 продолжал уверенно повторять попытки плохого JSON. Хуже всего то, что рабочий процесс выглядел нормально. Зеленый проверяет n8n. Никакой драматической трассировки стека. Просто медленная утечка повторяющихся контактов, наполовину заполненные записи и повторные попытки, которые сделали все это более дорогостоящим, но не сделали его более правильным. После отладки мой вывод довольно прост: Обычно это не проблема разведки LLM. Это проблема проектирования контракта. Многие сборщики n8n обвиняют GPT-5 в ошибках, которые на самом деле возникают из-за: Краевые случаи Apollo Поведение записи HubSpot слабая проверка JSON повторить логику без идемпотентности Мое твердое мнение: строгие контракты JSON + ключи идемпотентности каждый раз превосходят фразу «позволить модели исправить это при повторной попытке». Изначально я думал, что модель является слабым звеном. Это был ложный диагноз. Настоящие сбои происходили при передаче обслуживания между n8n, API обогащения Apollo, API записи контактов HubSpot и выходными данными модели в формате JSON. Работа