n8n Agents — воркфлоу как инструмент агента, а не наоборот
Саммари
n8n выпускает Agents как объект первого уровня: описываешь задачу агента обычным языком, даёшь модель, инструменты и воркфлоу — агент сам выстраивает шаги, и он один и тот же в Slack, по расписанию и при вызове из любого воркфлоу. Ключевой архитектурный ход — воркфлоу становятся инструментами агента: жёстко описанный процесс («достать контекст аккаунта», «добавить заметку», «пейджинг дежурного») остаётся детерминированным и исполняется с его собственными credentials, а агент решает только когда и в каком порядке его вызывать. Издержки безопасности названы прямо: без воркфлоу-обёртки логирование заметки означало бы выдачу агенту write-доступа к CRM с надеждой, что инструкции удержат его в поле заметки; с воркфлоу у агента нет этого ключа вообще — у него есть процесс, который умеет ровно одно.
Из этого следует, что «процесс против агента» — линия, а не выбор: один и тот же объект может быть воркфлоу с агентом внутри или агентом с воркфлоу-инструментом, и позиция на этой линии меняется задачей (нужна предсказуемость — вынос в воркфлоу, нужна адаптивность — оставляем агенту).
На практике для бизнес-процессов (поддержка, биллинг, документооборот) паттерн «агент держит не ключ, а процесс» закрывает сразу два требования: blast radius ограничивается скоупом воркфлоу, а audit trail получения — нативными execution-логами.
Важный нюанс: skills, knowledge и sub-agents — это та же модель композиции, что в coding-агентах (Claude Skills, AGENTS.md), только привязанная к интеграциям: знание о процессе живёт рядом с процессом, а не в общем промпте.
Ограничение: анонс-материал вендора без независимой эмпирики, статус preview и отсутствие цифр по качеству решений агента; утверждения о безопасности (per-tool credentials, approvals) — описание механизма, а не результат аудита.