«Остерегайтесь мелких расходов. Маленькая течь потопит большой корабль». — Бенджамин Франклин

Существует версия финансового управления стартапом, которую большинство основателей знают не понаслышке. Она не драматична. Она не появляется в презентациях для совета директоров. Она проявляется в счете за облачные услуги, который никто не проверял; в лицензии, которую технически все еще использует тот, кто ушел четыре месяца назад; в продлении подписки, цена на которую автоматически выросла на восемнадцать процентов, потому что ни у кого не было времени дать отпор.

Стартапы невероятно хороши в быстром движении. Но они удивительно плохи в мелкой, скучной и затратной работе по реальному управлению своими расходами. И не потому, что основатели безрассудны, а потому, что их внимание — самый дефицитный ресурс, которым они располагают, и еще никто не придумал, как автоматизировать процесс ведения переговоров.

У потребителей появились инструменты для поиска и отмены забытых подписок. У стартапов не было ничего.

Команда LEGR решила, что это неправильное положение дел.

Проблема, которую они прочувствовали на себе

Вдохновение пришло не из исследований. Оно пришло из опыта управления стартапом.

Неверный вызов модели, когда используется самый дорогой вариант, хотя более дешевый справился бы с той же задачей. «Призрачные» учетные записи для людей, ушедших много месяцев назад. Подписки, о которых никто не помнил. Продления, которые сработали автоматически, потому что ни у кого не было лишних трех дней на переписку с поставщиком.

Озарение заключалось не в том, что стартапам нужна была дашборд-панель получше. Дашборды уже существуют. Их игнорируют, потому что увидеть проблему и решить проблему — это совершенно разные вещи. Команда хотела создать не инструмент, который показывает вам потери, а что-то, что действительно их устраняет — составляет черновик письма, проводит переговоры, работает в выходные и присылает вам одно сообщение, когда всё готово.

Аналогия, к которой они постоянно возвращались: хороший финансовый директор не просто дает вам отчет и ждет. Хороший финансовый директор берет вопрос на себя, держит вас в курсе в важные моменты и закрывает задачу.

LEGR — это финансовый директор, которого никто не мог себе позволить нанять до того, как появилась возможность создать такой продукт.

Что на самом деле делает LEGR

У продукта три основные задачи.

Первая — выявление нецелевых расходов на ИИ: скрытые потери, возникающие при маршрутизации запросов к моделям. Использование дорогих моделей там, где более дешевая модель дала бы тот же результат. Простаивающие кредиты. Забытые пакетные задания. Паттерны, которые никто не замечал, потому что они скрыты в файлах логов, а не в обсуждениях.
Вторая — борьба с «разрастанием» SaaS-сервисов. Каждый стартап накапливает инструменты. Некоторые из них обрастают лицензиями и подписками, которые живут дольше, чем люди или рабочие процессы, для которых они предназначались. LEGR находит их — сверяя счета с реальным использованием — и делает то, чего не делал ни один дашборд: ведет переговоры о продлении автономно, столько дней, сколько потребуется.
Третья — обеспечение комплаенса расходов: проверка каждой транзакции на соответствие политике компании, при этом система молчит, когда всё в порядке, и подает сигнал только тогда, когда требуется вмешательство человека.

Опыт основателя выглядит так: приходит сообщение: «Найдено предстоящее продление. Провести переговоры? Д/Н». Он нажимает «Д». Через три дня приходит отчет: «Закрыто. Сэкономлено $4 140».

Три слова на ввод. Сорок часов переговоров решены. Одно сообщение на выход.

Идеи, лежащие в основе

Архитектурный вопрос, на который команда должна была ответить, звучал так: некоторые задачи занимают секунды. Другие занимают дни. Это не одна и та же проблема, и относиться к ним одинаково нельзя.

Проверка соответствия транзакции политике — это быстрая, без сохранения состояния (stateless) задача. Вы запустили её, получили ответ — готово. Но переговоры о продлении ПО — это процесс с сохранением состояния. Он длится днями. Поставщик отвечает по своему графику. Каждый ответ меняет то, что должно быть сказано в следующем сообщении. Система должна выдерживать перезапуск посреди третьего раунда переговоров.

Команда построила четкое разделение между этими двумя типами работы. Быстрые, ограниченные задачи выполняются как короткие вызовы. Долгосрочные переговоры существуют как персистентные процессы — каждый со своей памятью, историей переписки и пониманием того, какие рычаги воздействия уже были использованы, а какие остались.

Каждая активная переписка ведет файл состояния. Текущий раунд. Полная история переписки. Какие аргументы уже были представлены. Когда поставщик ответил «дайте мне посоветоваться с менеджером», система должна была правильно это классифицировать — не как согласие, не как отказ, а как «затягивание времени» — и ответить терпеливо. Этот классификатор, по словам команды, потребовал больше итераций, чем почти всё остальное в разработке.

Самой сложной проблемой была не техническая. Это была сдержанность.

Первая версия интерфейса отправляла сообщение на каждое событие. В течение часа это превратилось в шум — вы перестаете это читать, потому что системе постоянно есть что сказать. Исправлением стала трехуровневая система оповещений: тишина, когда всё работает штатно; информативность, когда происходит важное событие; и реальный пинг только тогда, когда действительно необходимо решение человека. Умение знать, когда промолчать, оказалось самым важным дизайнерским решением в продукте.

Чем они гордятся больше всего

Момент, который они продемонстрировали на сцене: принудительное завершение процесса переговоров в середине раунда, перезапуск, наблюдение за тем, как система считывает файл состояния и продолжает работу ровно с того места, где остановилась. Персистентность состояния — это не просто функция, которую они описали. Это то, что они доказали в реальном времени.

И сквозной цикл — основатель вводит три слова, система работает днями, в финале — одно сообщение об успехе. Это не демонстрационный поток. Это продукт, работающий так, как задумано.

105 участников. 38 проектов. 36 часов. Мы следили за тем, что получилось за те выходные, потому что качество мышления продолжает заслуживать внимания.

Стоит также сказать: мы знаем проблему разрастания SaaS-сервисов изнутри. Enter был создан специально для того, чтобы разработчикам не нужно было семь инструментов для создания одного продукта — дизайн-редактор, бэкенд, база данных, деплой, уровень совместной работы, всё в одном месте. Одна подписка. Одна платформа. Ирония того, что мы рассказываем о проекте, который выслеживает забытые подписки, не ускользнула от нас.

LEGR заслужил свое место в этой серии, потому что проблема реальна, решение конкретно, а команда поняла нечто важное: сложная часть создания автономного агента — это не автоматизация. Это знание того, когда нужно сделать шаг назад и позволить человеку снова взять управление на себя. Сдержанность как принцип проектирования. Это встречается реже, чем кажется.

Что дальше

В ближайшей перспективе: процесс, который напрямую входит в административные панели поставщиков и выполняет отмену подписок с получением скриншотов в качестве подтверждения. Параллельные переговоры, использующие общий интеллектуальный уровень — успех в одних переговорах становится преимуществом в других. Персистентная модель предпочтений, риск-аппетита и скорости расхода средств для каждого основателя.

Более долгосрочная ставка: финансы — это точка входа. Та же архитектура — быстрые агенты для ограниченных задач, персистентные процессы для работы, требующей дней, — применима к юридическим операциям, управлению поставщиками, HR-комплаенсу. Команда описала это как первый инструмент, который стартап подключает, и последний финансовый инструмент, который им нужен, прежде чем они смогут позволить себе нанять настоящего финансового директора.

Именно для таких амбиций и существуют подобные выходные в Принстоне.

Пропустили предыдущие выпуски? → Вып. 1 — Heritage in Pixels → Вып. 2 — Terra Zone AI *→ Вып. 3: *reAgent *→ Вып. 4: *TaleTailor