🕸️ Когда Codex «гуглит», он реально заходит на каждый сайт? Вчера я советовал сделать сайт agent-friendly через Ora. Но сам до конца не понимал, что именно там надо оптимизировать. В моей голове это работало так:

я прошу Codex что-то найти → OpenAI дёргает Google или Bing → какой-то crawler в realtime идёт по сайтам.

1. Как ищет сам Codex

Codex не достаёт свежий интернет из весов модели. Он вызывает отдельный web search tool. В локальном Codex по умолчанию используется cached search по индексу OpenAI. Ещё есть indexed и live: в live-режиме поиск может открыть актуальную страницу прямо во время задачи. Но это не значит, что он синхронно заходит на каждый сайт.

2. Кто тогда заранее ходит по сайтам

У OpenAI есть несколько разных ботов: • OAI-SearchBot собирает страницы для ChatGPT Search • ChatGPT-User может открыть страницу по конкретной просьбе человека • GPTBot отвечает за потенциальное использование контента для обучения Можно разрешить поиск и отдельно запретить обучение.

3. А Google или Bing?

OpenAI публично не пишет, какой именно внешний поисковик стоит под капотом Codex и чем конкретно наполняется cached index. Поэтому рассказы в духе «оно точно всегда ходит через Bing» пока додумывание.

so what? ⚡️ твой будущий клиент может вообще не открыть сайт сам. Он попросит своего агента найти API, сравнить сервисы и выбрать, что купить. Если агент не нашёл страницу, не вытащил цену или не понял, куда нажимать, ты можешь не попасть даже в shortlist. 🧩 @danokhlopkov

Vercel выпустила курс по построению рабочего каркаса ИИ-агента для кодинга Build Your Own AI Coding Agent Harness. Я решил скормить этот курс клоду, и попросить сравнить с тем, что у меня уже реализовано в Lovarus. Был приятно удивлен, что бОльшая часть была закрыта, и где-то даже выше уровня курса. Например, я много внимания уделял детерминированным проверкам кода. Но вот одну вещь я упустил, и она сломала кеширование. Я каждый раз пересобирал системный промпт агента, с учетом некоторых обновлений в структуре приложения. Также подчерпнул из курса классную вещь - санитайзер результатов устаревших вызовов инструментов. Например, агент в самом начале работы прочитал большой файл, потом переписал его, и по сути он больше не нужен в истории, а он там лежит. Буду исправлять.

Как AI-агенты трансформируют компанию? Недавно на воркшопе обсуждали следующий этап работы с AI в компаниях: переход от отдельных чат-ботов к агентам, встроенным в бизнес-процессы компании. Ключевой поинт - Corporate Brain. AI получает доступ к Slack, Jira, созвонам, документам, продуктовой аналитике и репозиториям и связывает разрозненный контекст в единую картину: обсуждение → решение → задача → изменение в продукте → влияние на метрики. На практике такой агент может за несколько минут разобрать backlog и найти связанные задачи и прошлые решения, собрать индивидуальный onboarding-план, сопоставить Jira с ClickHouse, GA, Amplitude и пользовательскими логами, проанализировать PR и коммиты, найти потенциальные проблемы в UX и подготовить гипотезы для команды. Но важный вывод воркшопа: ускорение отдельного сотрудника еще не означает ускорение компании. В одном из примеров AI значительно повысил скорость разработки, но очередь QA выросла с 15 до 55 задач, количество багов увеличилось в 4 раза, а rework - в 6. Поэтому измерять нужно не объем сгенерированного кода или количество AI-запросов, а конечный бизнес-результат. При этом агент нужен не везде. Если задачу надежнее решает обычная автоматизация, API или workflow, усложнять систему агентом нет смысла. Агент особенно полезен там, где нужно работать с большим контекстом, принимать неоднозначные решения, выбирать инструменты и корректировать следующие действия. Главная сложность тоже не в самой LLM. В production быстро появляются вопросы качества данных, доступов, legacy-интеграций, безопасности, стоимости, логирования и контроля действий. Поэтому рабочая схема выглядит примерно так: Goal → Context → Tools → Actions → Verification → Guardrails → Human escalation. И внедрять это лучше постепенно: найти первые реальные кейсы и мотивированных early adopters, измерить эффект и только потом масштабировать. Главная метрика здесь - не токены и не количество пользователей AI, а Cost per Successful Outcome: сколько компании стоит один действительно полезный результат. AI-трансформация - это не "заставить всех дрочить ChatGPT". Это перестроить конкретные бизнес-процессы вокруг новой возможности AI понимать корпоративный контекст, работать с инструментами и выполнять часть работы самостоятельно, но под контролем человека. https://youtu.be/vR_enpahg8M

Из нижнего интернета принес совсем нишевую историю про процедурное моделирование с помощью ИИ агентов. Есть разрозненное сообщество, чем-то напоминающее демо сцену нулевых, где ребята собираются и пилят модели на новом уровне, и на самом деле некоторые примеры довольно впечатляющие! Прикол такого моделирования в том, что, во-первых, оно собирается исключительно агентами, во-вторых, модели собираются из примитивов, в-третьих, можно программировать поведение или анимации, а точнее интерактивность таких моделей. Они более редактируемы, чем генерации, потому что тут нет лишней геометрии, что и плюс, и минус одновременно, вы не соберете органического монстра с порванной кожей и кишками, например, но можете собрать шкафы, какие-то scifi или hardsurface штуки, которые могут двигаться или сгибаться, например, турели, оружие, автомобили и так далее. Есть даже ребята, которые хотят запилить маркетплейс с такими моделями, чтобы агенты имели доступ к запчастям, типа огромного китбаш склада для агентов, откуда агенты могли бы брать эти запчасти или части интерактивной логики. В общем, направление очень внушительное, но не без своих проблем. Приложу некоторые примеры, но в теории технические штуки, в том числе и через CAD моделирование, могут все же выстрелить на ИИ моделях через 1-2 поколения. @CGIT_Vines

Запись второй части нашего стрима про сбегающих AI-агентов. Посмотреть на YouTube можно здесь. Таймкоды: 0:00:00 — Приветствие и обсуждение планов на стрим 0:02:13 — Архитектура проекта SECS и схема пайплайна 0:06:42 — Интеграция навыков для кодовых AI-агентов 0:10:00 — Локальный запуск модели Qwen и vLLM 0:18:05 — Ускорение инференса через спекулятивное декодирование 0:28:20 — Воспоминания о культовых играх и компьютерах 0:33:45 — Настройка контекстного окна и параметров модели 0:44:00 — Сравнение видеокарт для инференса нейросетей 0:50:40 — Обсуждение генерации музыки в нейросетях 1:08:05 — Тестирование AI-агента на тестовой виртуальной машине 1:23:45 — Автоматизированный анализ и поиск путей эскалации 1:54:30 — Подведение итогов стрима и завершение трансляции Каналы участников стрима, чтобы подписаться: Павел Рыков Константин Доронин

Как структурировать продукт для ИИ: 6 элементов Новая точка ценности возникает в создании интерфейса-протокола-API, который позволяет ИИ понимать ваш продукт и действовать в нём (назовём это AIX вдобавок к привычному UX).

AIX, как и UX, ломается не на сложных, а на неявных действиях

Чтобы продукт стал более удобным для ИИ, его можно разложить на несколько элементов: 1) Структурированный контекст, чтобы ИИ-агент мог видеть то же, что видит пользователь. Но ИИ-агенту нужен не весь контекст продукта, а нужный слой на нужном действии, так как избыточный контекст так же ломает агента, как недостаточный (ибо разнообразие должно соответствовать, а не максимизироваться). 2) Типизированные действия, чтобы ИИ-агент знал, какие действия доступны в процессах а) пользователя; б) продукта и бизнеса.

Типизированное действие = предусловие (срез контекста, при котором действие применимо) + действие + постусловие + альтернативный поток (эскалация на человека).

3) Правила эскалации с версионируемой схемой политик поломок и явным владельцем, чтобы ИИ-агент (и человек) знали, при какой ситуации необходимо предпринять действия коррекции и кому. У каждого типизированного действия должна быть задана стоимость отката. Если откат действия дороже самого действия (необратимые операции: отправка, платёж, удаление), эскалация к человеку должна быть предусловием, а не постусловием. 4) Как только продукт структурирован, его частям нужен ИИ-контракт ИИ-контракт определяет, как фича работает на системном уровне, её связь с каждым компонентом, объектом и правила их взаимодействия внутри продукта, чтобы разные продуктовые области могли подключаться и заставлять своих ИИ-агентов выполнять желаемое поведение. И да, версионируйте контракты ВСЁ, иначе без этого ИИ-агенты молча начинают действовать на устаревшей модели продукта. 5) Цикл. Цикл призван улучшать Систему в времени. Примером ценного цикла может служить захват сигнала коррекции: разницы между тем, что сделал ИИ-агент, и тем, исправил ли это пользователь. Например, когда пользователь редактирует текст, сгенеренный ИИ или отменяет предложенный вариант, это разные по силе сигналы. Первый про качество ответа ИИ, второй про доверие/уместность действия со стороны ИИ в глазах юзера, поэтому разделяйте постусловие на «успех» и «частичный успех». Поэтому каждый цикл коррекции должен иметь владельца (ИИ или человек?), который решает, применять ли исправление системно или считать его исключением.

Исправления пользователя — это размеченные им же несостыковки в реальности продукта

Сигнал коррекции даёт сразу 2 преимущества: – Это данные для оценки, потому что сигнал о том, где ИИ терпит неудачу в продакшене, не даст ни один офлайн-бенчмарк и это же данные для улучшения, так как исправления улучшают самого агента с помощью пар предпочтений или прошлых исправлений, добавленных в его контекст, чтобы агент не повторял ту же ошибку. – Этот сигнал даёт ещё и пользовательские поведенческие инсайты для продакта. Сигналы коррекции нужно тайм-стемпить относительно версии контрактов, иначе уже через квартал правки будут учить агента на артефактах несуществующей схемы действий. Все эти ИИ-улучшения делают продукт и фичи персонализируемыми, предсказуемо масштабируемыми и практически автономными. 6) Поскольку ИИ-агентам нужны определённые предусловия для работы в продукте, и лучше продакт-менеджера их не знает никто, то контрактно-ориентированное мышление становится ещё одним элементом в эпоху ИИ

С начала года я активно пилю свой иишный «второй мозг». Сначала он вырос из моего личного дневника в накопленный контекст жизни, для более качественных ответов с ИИ в чатике. Потом поверх него начал достраиваться контекст по проектам, CRM контактов, доступ к звонкам, телеге, дашбордам и разные агенты, которые помогают принимать решения, трекать меня по целям и задачам. Сейчас я пытаюсь формировать такие контексты для проектов, в том числе, чтобы к ним могли подключаться сотрудники. Для его разработки и обучения сотрудников нанял штатного вайбкодера и сам очень много рисерчу. В основном у западных компаний. Недавно наткнулся Грега Айзенберга, основателя Late Checkout ($100M+ выручка). Он описал, как сегодня выглядит оргчат его бизнесе. В управлении тонкий слой людей, отвечающих за стратегию, креатив и суждения. Под ним широкий слой AI-агентов: саппорт, продажи, исследования, маркетинг, операции. Управление людьми всё больше превращается в управление агентами, а управление агентами в управление и создание контекста. По его мнениею, контекст — это и есть компания, общий мозг, к которому подключены люди и AI. Люди приходят и уходят, агенты меняются и устаревают, а контекст остаётся, накапливается и развивается. Управление его компанией, это способность сохранять и управлять контекстом, который ускоряет и людей, и агентов. Возможно, пока чуть сложно и абстракно звучит, но я все больше в этом убеждаюсь по мере развития собственного «второго мозга». Как-нибудь сделаем эфир и покажу как все это выглядит.

Сегодня ожидают gemini 3.7 flash Тибо сделал всем ресет ночью А я сделал скилл Bottleneck для AI-агентов. Часто агент сразу предлагает улучшать код, добавлять функции или менять архитектуру, ещё до того как понял, что на самом деле ограничивает проект. Bottleneck сначала смотрит на систему целиком, а потом определяет главное узкое место. Он объясняет, почему именно эта проблема важнее остальных, какие ограничения идут следом и что стоит проверить в первую очередь. Скилл можно использовать для анализа кодовой базы, архитектуры, продукта, бизнес-процесса, AI-агента или просто идеи. В Codex вызывается так:

$bottleneck

https://github.com/Antonod1988/what-are-the-bottlenecks пока всё😊

Моё отношение к компьютерам лучше всего описывается словами «неуверенный пользователь» Когда я учился, персональных компьютеров в России ещё было очень мало. Поэтому вместо программирования на ПК мы учились программировать калькуляторы (был такой Электроника МК-61 🙂) И вот недавно я прошёл курс «Claude Code для предпринимателей» Записался я на него не столько ради новых знаний, сколько из любопытства - а какие задачи предприниматель сегодня действительно может поручить AI-агентам? Из самого курса и чата на 200 участников я понял, что основная работа, с которой AI-агенты действительно хорошо справляются, это работа с контентом. Это было заметно и по участникам курса - самые активные обсуждения шли вокруг «фабрик контента» А вот для руководителя, у которого мало рутины и много нестандартных задач, AI-агенты пока не очень полезны. И вот почему - 1️⃣ Вы действительно получаете AI-помощника. Он полон энтузиазма и знаний, но при этом довольно тупенький. Чтобы сделать его полезнее, существуют разные инструменты для настройки агента под себя и свои задачи. Собственно, этому и учат на подобных курсах. Но для не-айтишника это может оказаться довольно сложно (последние уроки курса я не прошёл, потому что там было уже много незнакомых слов 🙂) 2️⃣ Такой помощник лучше всего работает с рутинными задачами. Но ради этого его сначала нужно довольно кропотливо обучать, делать много итераций и объяснять, что именно вы от него хотите. И даже после этого результат не гарантирован на 100%, потому что всё время что то ломается. 3️⃣ Одни и те же настройки и одинаковые скиллы могут работать у разных пользователей по-разному. Скиллы, это готовые инструкции для агентов, которые уже можно найти в интернете. Но если что-то пойдёт не так, вам придётся самостоятельно разбираться, как это исправить. (А из курса я понял, что что-нибудь обязательно пойдёт не так 🙂) 4️⃣ С цифрами всё очень плохо. А предпринимателю без цифр никак! Даже если несколько раз попросить агента ничего не придумывать, всё перепроверять и искать ошибки, это всё равно не гарантирует, что ошибок не будет. Нужно обязательно перепроверять самому. В общем, я думаю, что инфопредпринимателям AI-агенты действительно могут приносить большую пользу (и судя по количеству курсов на эту тему, неплохую прибыль они им тоже приносят 🙂) А вот в производственном бизнесе широкого применение AI-агентов я пока не вижу. А для себя я понял, что мне гораздо больше нравится работать с Perplexity Computer, чем с Claude Code. Он значительно проще настраивается, понятнее для не-айтишника и, по моему опыту, довольно неплохо делает то, что я ему поручаю. К тому же, в отличие от Клода, он официально работает в России. Если вдруг этот пост прочтут господа айтишники, то расскажите, пожалуйста, в комментариях - прав я или в чем то ошибся насчёт агентов ⤵️ Организаторы курса восторженно рассказывали, что не боятся, и уже смело дают Клоду доступ к своему банковскому аккаунту. Но мне кажется, что это всё-таки некоторое преувеличение (подозреваю, что и банки от такого доверия будут не в восторге🙂) Поэтому следующий пост будет про обслуживание в банках. У меня большой опыт работы с разными банками и премиальные пакеты сразу в нескольких из них, поэтому хочу поделиться с вами своим опытом. Не переключайтесь. Незаметный бизнес

Хочешь разбогатеть - спроси меня как Я несколько раз читал классную бизнес-книгу, понимал, насколько она крута и полезна, что-то даже применял на практике, но 90% советов пропадали зря – сейчас не пригодились, а к тому моменту как понадобится, я все уже забыл. #стартапдня The GTM Co-Founder хочет, чтобы знания приходили вовремя. Это восемнадцать .md-файлов с описанием “бизнес-мудрости” и правильных подходов к развитию стартапа – в основном с фокусом на B2B и ранних стадиях. Инструкции кладутся в папку со скилами Claude Code, Cursor или любого другого агента. Основатель работает как работал, а когда в переписке всплывает «не знаю, сколько брать за подписку», AI использует правила из GTM и отвечает с их учетом. Вы скажете, что знания, которые есть в нейросети изначально, ничем не хуже авторских, Claude и так неплохо отвечает на любой вопрос. Стартап о возражении тоже знает и заявляет несколько преимуществ, существенным из которых мне видится одно. После установки GTM проводит интервью основателя о сути и текущем положении его бизнеса. Результаты хранятся в файле и подтягиваются в следующих сессиях – и тут-то и возникает новое качество ответов. Понятно, что и это можно сделать своими руками “Claude, задай мне серию вопросов…”, но большинство ж так не делает, и им новый скилл реально помогает. Распространяется всё это бесплатно, лицензия MIT, можно использовать как угодно. Автор продвигает так свой платный консалтинг – честно говоря, не думаю, что The GTM Co-founder одобрил бы эту схему. https://gtmcofounder.com/ #ирландия #ai #насвои

Важность исследования контекста Тема заезженная, но я сейчас кодю с Opus 5 и, конечно, провожу новую фичу через research стадию и интервью. Собственно, хоть фича и совсем небольшая, даже после того, когда кажется, что все готово, я все равно прошу опуса доисследовать контекст и проработать корнер кейсы и он действительно находит что-то новое и мы учитываем дополнительные инварианты, т. е. не зря просили доисследовать. Вообще, может показаться, что с появлением новых сильных моделей и харнессов проблема исследования контекста (research фазы) решена. Тем более, я даже явно попросил агента о дополнительном исследовании. Но что в действительности? Вы помните, что у меня Grok Heavy подписка с практически бесконечными лимитами, поэтому я смело попросил опуса запустить 5 сфокусированных грок агентов поисследовать глубже все ли мы с ним учли в спеке. Результат: гроки нашли 9 релевантных пробелов, которые мы не учли в спеке. Ну, всё, куда уж дальше-то копать? Ан нет, грок-то бесконечный у нас, давайте еще один проход 5-ти субагентов запустим. Результат: еще +4 находки. Ну, теперь-то уж точно всё, сколько можно? в 2025-й что ли вернулись? Почти. Мы тут недавно CodeAlive агента перевели на GPT 5.6 Luna (кстати, невероятно цепкая и крутая в исследовании и в code review модель), хороший повод проверить новый режим глубокого анализа нашего агента (он специально запромптчен, чтобы предельно глубоко копать)... Отправил. 2 минуты поисков и вуаля, еще +6 находок и пробелов в спеке, которые Опус потом подтвердила и исправила. Ну, и финально фейблом тоже прошлись, которая дала еще 3 полезных замечания по спеке и несколько мелочей. И только теперь спека готова к реализации. Почему так сложно? Две главные причины: 1. Да, фича хоть и небольшая, но нетривиальная и идет в некоторый конфликт с существующей механикой. 2. Кодовая база уже довольная большая и непростая - за 2+ года набралось более полу миллиона строк кода в сумме, это тоже усложняет задачу агенту. Количество ручной работы при этом можно сократить, завернув всю церемонию в скилл (вы тогда на вопросы будете отвечать где-то ближе к началу и в конце, т. к. каждый новый ваш ответ может поменять траекторию и потребовать доп. проверку контекста). В целом, чем более легаси проект, тем актуальнее будут все эти долгие и упорные перепроверки и тем сложнее будет стадия планирования. Особенно если вы, как и я, хотите за one-shot получить около prod-ready результат. Теперь когда вы услышите, что агенты не работают в enterprise, вы знаете каким постом ответить. Кстати, почему не Haiku 4.5? Хайку очень слабая модель на фоне Грока и Luna, она просто видит сильно меньше и уже подводила меня, поэтому теперь не советую ее (в крайнем случае Sonnet 4.6 хотя бы если у вас только клод подписка). Расскажите как у вас теперь выглядит стадия планирования? Вот теперь думаю раз CodeAlive так здорово спеки умеет ревьюить и граундить, может, есть смысл упаковать это в отдельный MCP/skill метод и отдать агентам в пользование? Актуально это? @ai_driven

Cloudflare представили Kitesurf — браузер для AI-агентов, работающий целиком на изолятах V8 в Cloudflare Workers, без Chromium. Он доступен бесплатно в бете через Browser Run: достаточно добавить параметр browser=kitesurf, и существующие клиенты Puppeteer, Playwright и MCP-агенты работают без изменений. По замерам CF, Kitesurf потребляет в 3-7 раз меньше памяти и процессорного времени, чем Chromium, при типичных задачах вроде скриншотов и извлечения HTML, хотя по времени выполнения пока проигрывает в 1,7 раза из-за отсутствия JIT в V8. Это не чистая замена Chrome-dev-tools и аналогам — в анонсе подчеркивается, что агентам не критичны pixel-perfect рендеринг стилей или частота кадров, и важнее обезопасить агента от prompt injection. Но в качестве замены локальному браузеру или облачной версии для доступа, например, к JS-rendered контенту выглядит очень хорошим вариантом. https://blog.cloudflare.com/kitesurf/

Самый дешевый AI-агент может оказаться самым дорогим Короче, мы нашли еще один прекрасный способ неправильно измерять эффективность AI: смотреть на стоимость токенов😉 Токены дешевеют? Отлично, значит и AI становится дешевле! Ну да. Ну да. Пошли мы нафиг со своей простой математикой. McKinsey выпустили материал об экономике AI-агентов, и там, как обычно это бывает, супер очевидная мысль, когда ее кто-то озвучил, но нифига не очевидная до этого: Токены - это не ценность. Токены - это счет, который вам выставляют. Он (счет) показывает, сколько вы потратили, но вообще не отвечает на вопрос: А зачем вы это потратили? И самое важно, сделали ли вы это эффективно Проблема в том, что агент - это уже не один запрос к LLM, потому что агент: — читает контекст; — вызывает инструменты; — пробует разные варианты; — проверяет результат; — исправляет результат; — еще раз проверяет результат; — иногда решает начать все сначала. В итоге агентская задача может потреблять примерно в 1000 раз больше токенов, чем обычный чат или единичная задача на рассуждение. Причем около 60% стоимости может уходить не на создание первого ответа, а на его проверку, исправление и повторную проверку. Ииии вот тут начинается самое интересное. Один и тот же агент на одной и той же задаче может пройти совершенно разный путь. Сегодня сделал пять вызовов инструментов. Завтра — двадцать. Поэтому стоимость агента - это не фиксированная цена, а распределение веротяностей. Потому что все в LLM - это распределение вероятностей. А оценивать его нужно не по стоимости миллиона токенов, а по: стоимости успешно выполненной задачи. Агент приносит пользу, когда вероятность его успеха выше, чем: время проверки результата / время самостоятельного выполнения задачи. Например: Человеку нужно два часа, чтобы сделать задачу. Проверить результат агента можно за шесть минут. Тогда агенту достаточно успешно выполнять всего 5% задач, чтобы его использование уже имело экономический смысл. Но только если ошибка ничего не ломает. Если агент отправил неправильный документ, то вы его удалили. Если агент пообещал клиенту вернуть деньги за невозвратный билет, теперь у вас есть не только ошибка, но и стоимость ее исправления. McKinsey называет это agency tax: стоимость проверки + стоимость переделки + последствия ошибки. Как итог, недостаточно считать: — токены; — запросы; — стоимость модели; — количество запущенных агентов. Нужно считать: — какой бизнес-результат получил агент; — сколько стоило успешное выполнение задачи; — сколько времени человек потратил на проверку; — сколько стоило исправление ошибок; — насколько агент улучшил реальную бизнес-метрику. Иначе через год у вас будет 1000 AI-агентов, огромный счет от провайдера и очень сложный ответ на простой вопрос финансового директора: «А кто из них вообще приносит пользу?» И вот новая ценность платформ для инженеров в том, чтобы оптимизировать экономику результата.

n8n VS code Во 2 полугодии 2026 до сих пор обсуждают насколько нужен n8n , если уже есть готовые и продвинутые AI агенты, которые могут собирать готовые решения. Кто-то говорит что n8n не нужен. В этом 🎞 интервью подробно разобрана практическая сторона этого вопроса, потому что обсуждать можно бесконечно, а есть реальные задачи, под которые на практике подбираются свои инструменты. Ведь код тоже бывает разный. Шпаргалка когда что выбирать: Выбирай Код если: - у вас есть сервер чтобы его развернуть - вам базово неплохо бы понимать код - вам надо где-то хранить ключи (в gitHub не вариант) - не безопасно (нужны доп. библиотеки) - авторизацию и ролевую модель нужно отдельно делать - вероятность багов выше → нужно отлаживать (80% вашего времени и токенов) - возня с БД (и понимать какая для чего нужна) между кодом и n8n есть PaaS платформы типа Railway (у меня там 2 проекта крутится), в целом хорошее решение для чего-то более гибкого Выбирай n8n если: - нужно чтобы все было наглядно - все детерминировано - процесс последовательный (если есть откат — тебе нужен LangGraph / CrewAI) - решение можно воспроизвести 1:1 - можно быстро перенести/поделиться рабочим процессом - есть версионирование - встроенные простые evals в корпоративном секторе важна наблюдаемость (observability), безопасность, воспредводимость, масштабиримость.