Технический контекст
Я люблю такие находки больше, чем громкие релизы моделей. Тут не новая LLM, а маленький engineering skill, который логирует решения агента, и именно такие штуки двигают нормальную AI implementation в проде.
История живая: инструмент не анонсировала компания, его человек просто собрал через skill-creator, два месяца погонял в работе и потом выложил на GitHub. Ссылка ведет на decision-auto-tracker в репозитории skills, и по описанию задача у него очень приземленная: фиксировать, что агент решил, почему и к чему это привело.
Я бы именно так и делал. Не писать весь поток мыслей, а ставить лог на точках выбора: какой шаг выбран, какой был контекст, что сломалось, какое решение приняли. Иначе вместо трассировки получится мусорный дамп, который никто не откроет второй раз.
Самое полезное тут не “память” как модное слово, а воспроизводимость. Когда агент в длинной цепочке сначала меняет состояние, потом вызывает тул, потом чинит собственную ошибку, без decision log я часто вижу только последствия. С логом уже можно восстановить причинность, а это совсем другой уровень отладки.
Еще интереснее идея из обсуждения про “сторожа”, который предупреждает текущего агента о конфликте с прошлыми решениями. Вот тут я уже остановился. Если поверх логов повесить простую проверку на противоречия, получится не просто аудит, а зачаток policy layer для AI integration в реальные процессы.
Влияние на бизнес и автоматизацию
На практике выигрывают команды, у которых агент делает не демо, а работу: триаж, саппорт, инженерные рутины, внутренние workflows. Там один повторяющийся сбой стоит дороже, чем сам skill.
Проигрывают те, кто до сих пор считает, что observability для агента можно “добавить потом”. Потом обычно уже есть сломанный пайплайн, странные побочные эффекты и спор в чате, почему агент принял именно это решение.
Я бы вынес отсюда три прямых вывода: сокращается время на разбор багов, проще строить guardrails поверх истории решений, и дешевле поддерживать AI automation в проде. Мы в Nahornyi AI Lab как раз решаем такие вещи для клиентов: не просто запускаем агента, а собираем вокруг него нормальную AI architecture, чтобы система была проверяемой, а не магической черной коробкой.
Если у вас агент уже работает, но команда тратит часы на расследование его странного поведения, давайте посмотрим на цепочку целиком. В Nahornyi AI Lab я могу помочь выстроить AI solution development так, чтобы решения агента были видны, воспроизводимы и не конфликтовали с логикой бизнеса.