Agents, Workloads & Programs

Agent в SUMMING — это не ИИ-модель и не синоним workflow. Это продуктовая сущность с identity, целью, KPI, политиками и границами. Исполняемая реализация подключается через workload binding: существующий визуальный Process или нативная Program. Одна и та же LLM может обслуживать десять разных агентов, которые друг о друге не знают.

Anatomy агента#

Поле	Что значит
name	Human-readable имя (показывается в списке)
goal	Описание цели одной строкой; используется LLM-нодами если они «понимают контекст»
role	operations / sales / support / analytics / custom — влияет на default'ы template'ов
workload	Primary binding на visual_process или program; пользователь не выбирает версию runtime
templateId	Если агент создан из template'а — ссылка сохраняется для upgrade'ов
workingHours	Cron + timezone + enforcement (hard = блокировать runs вне часов; soft = только warning)
costCap	Опциональный месячный лимит в рублях/токенах
kpiGranularity	none / per_agent / per_channel — уровень детализации KPI'ек
ownerUserId	Кто создал. owner + admin'ы space'а могут править

Два workload'а под одним Agent#

• Visual Process — текущий DAG-редактор, revisions, deployments и Graph Runtime. Он продолжает работать без изменений.
• Program — versioned manifest модулей, подписок, событий и state. Native Program проходит закрытый preview на отдельном Program Runtime.

Для Program-backed Agent не создаётся фиктивный Process. До прохождения compatibility gates визуальные процессы не заявляются как работающие на новом runtime: их миграция потребует parity по trace, outputs и внешним effects.

Visual Process = DAG#

Process — это directed acyclic graph нод:

trigger              (ровно один на процесс)
  ↓
processing nodes     (0..N — можно fan-out'ить)
  ↓
terminal nodes       (output — отдача во внешний мир)

Рёбра могут быть условными (condition на expression-DSL'е SUMMING):

ai.classify
  ├─ output == "hot" → telegram.message.send (to: manager)
  └─ output == "cold" → email.send (template: drip campaign)

Fan-out через control.foreach порождает паралельные run-branches, которые потом join'ятся.

Revisions = git для workflow'ов#

Каждое изменение в editor'е — это revision. Revisions:

• immutable (revision не меняется после сохранения)
• numbered sequentially (1, 2, 3…)
• хранят полный snapshot графа (не diff)
• подписаны createdBy + timestamp'ом

Deployment — это связка revision + environment (sandbox / production). Production-deployment — это то, что runs'ы фактически используют.

Пример lifecycle'а#

1. Revision 1: вы создали workflow webhook → amocrm.lead.create. Published. Production uses revision 1.
2. Вы поправили workflow, добавили ai.classify между ними. Сохранили — revision 2 создалась, но не активна.
3. Потестировали revision 2 в sandbox-environment'е — окей.
4. Publish revision 2 → production deployment переключается. Новые webhook'и идут через revision 2, старые running runs продолжают на revision 1 (как создались).
5. Что-то сломалось? Rollback → revision 1 снова production. Новые runs идут через revision 1. Ничего в rerun'е не нужно.

Template resolver#

Ноды ссылаются на предыдущие через template-syntax:

{{trigger.<field>}}         — payload trigger-ноды
{{<nodeKey>.<path>}}         — output ноды с данным ключом
{{secrets.<secretName>}}     — plain-text значение secret'а (runtime-only)
{{agent.name}}               — metadata агента
{{run.id}}                   — id текущего run'а

Пример:

yookassa.payment.create
  description = "Заказ #{{trigger.order_id}} от {{trigger.customer_name}}"
  metadata    = {order_id: "{{trigger.order_id}}"}

Resolver работает на runtime'е, не на publish'е — если trigger.order_id отсутствует, нода упадёт с понятной ошибкой UNRESOLVED_TEMPLATE, а не тихо пройдёт с пустой строкой.

Полная спецификация resolver'а — в AGENTS.md § 8.11.

Template catalog#

Template — это готовый процесс без конкретных secrets / connection'ов. При instantiate'е:

1. Template выбирается из catalog'а (GET /templates)
2. Wizard просит заполнить configSchema (для lead-qualifier'а — amoCRM-connection, для weekly-digest'а — Telegram-chat_id и cron)
3. SUMMING создаёт agent + process + revision с уже подставленными configSchema-значениями
4. Agent готов к publish'у

Template KPI-цели наследуются с дефолтами; operator уточняет позже.

Blank-agent path#

Если template не подходит — Start from blank:

1. Имя + goal
2. SUMMING создаёт агента с пустым процессом (один webhook.trigger по умолчанию)
3. Переходите в editor и собираете workflow с нуля

Template нельзя «добавить позже» — если нужно переключиться, проще создать второго агента из template'а и удалить первого.

Лимиты#

• 1 agent per user-role-level в free tier; unlimited в pro
• 1 active primary workload per agent (visual_process или program)
• Revisions — unlimited, но storage-quota space'а суммарная
• costCap опционален; при срабатывании агент приостанавливается до следующего billing-cycle'а или увеличения cap'а
• workingHours — hard-enforcement блокирует starts вне часов (running run'ы доезжают до конца даже если вышли за границу)

Связанное#

• Runs & Traces — что происходит когда process исполняется
• KPIs — как агент считает собственные метрики
• AgentsPage в коде — если хотите посмотреть изнутри текущий app UI