Stipendex: продукт и позиционирование

Проблема, ландшафт, стратегия дистрибуции и монетизация. Технические детали — в spec/.

Проблема

Агенты научились действовать (MCP), но не научились платить. Сегодня оплата чего-либо агентом — это либо API-ключи и карты, заведённые человеком заранее на каждый сервис по отдельности, либо полная остановка работы «спроси хозяина». Следствия:

• Для разработчиков инструментов: 19 000+ MCP-серверов, почти все бесплатны — не потому что авторы альтруисты, а потому что взять деньги за вызов нечем.
• Для владельцев агентов: делегировать агенту деньги страшно — LLM подвержена prompt injection, а границ («не больше $20 в день, только этим сервисам») никто не enforce'ит.
• Для коммерции: покупка товара агентом упирается в вопросы, на которые нет стандартных ответов: кто подтвердил сумму? чем доказать полномочия агента при чарджбэке? как холдировать оценку, если финальная цена известна только продавцу?

Чем платежи агентов отличаются от человеческих

1. Плательщик — не человек: нельзя показать 3DS-форму; нужна делегация с границами.
2. LLM нельзя доверять деньги: решение о платеже обязан принимать детерминированный код.
3. Частота и размер: от долей цента (инструменты) до сотен долларов (товары).
4. Автономность: платежи без человека в моменте, но с проверяемыми лимитами и эскалацией по порогу.
5. Аудит: доказуемая цепочка «кто разрешил → за что заплатили → что получили».
6. Сумма часто неизвестна заранее (токены, доставка, налог) — нужны котировки по факту и допуски, а не прайс-листы.

Ландшафт (июль 2026) и наша щель

Щель: открытый нейтральный слой «полномочия + конверт + доверие» поверх этих рельсов, простой как MCP. Мы сознательно не строим: новые рельсы, торговые сценарии (поиск/корзина/checkout-UI), KYC. Мы строим то, чего нет ни у кого: стандартный кошелёк с мандатом + единый платёжный цикл + федерируемый реестр доверия.

Два квадранта — один протокол

Общее у квадрантов — 80% механики: мандат, кошелёк, Quote/Proof/Receipt, реестр, идемпотентность, аудит. Разница — режим списания и обязательность HITL. Поэтому один протокол с двумя профилями, а не два протокола.

Стратегия дистрибуции (ответ на «кто это внедрит»)

Классическая смерть платёжного протокола — chicken-and-egg: продавцы ждут агентов, агенты ждут продавцов. Наш план разрывает круг тремя ходами:

1. 4agents как первый живой сценарий. Не абстрактный «showcase», а работающий продукт с реальными магазинами: checkout-профиль Stipendex — это платёжная часть его order-flow v2.1, кошелёк — стандартная реализация его HITL-шага. Stipendex запускается не в вакууме, а внутри готового спроса.
2. Кошелёк как агентский крючок. Владельцу агента мы продаём не «протокол», а безопасность: «поставь @stipendex/wallet — агент сможет тратить деньги, не пугая тебя: бюджеты, лимиты, подтверждения, только проверенные получатели». Кошелёк приносит агентов → агенты приносят трафик получателям → получатели приносят новых пользователей кошелька. Дефолтный allowlist кошелька — реестр доверия: сетевой эффект замыкается.
3. SEP в спецификацию MCP. Ошибка payment_required + капабилити payments — кандидат на стандартизацию тем же путём, каким в MCP вошли elicitation и structured output. До принятия SEP всё работает через _meta без изменений спеки.

Монетизация (кто на чём зарабатывает)

Протокол и SDK — бесплатные и открытые (это условие адопции). Деньги в экосистеме:

• Фасилитатор — комиссия с оборота/подписка за hosted-счета, верификацию, HITL-очередь, антифрод. Референс-API открыт, операторов может быть много; первый — оператор 4agents.
• Провайдер реестра доверия — подписка получателей за верификацию (модель verified из 4agents, расширенная с магазинов на платные MCP-серверы).
• Платформы-оркестраторы (4agents и подобные) — take rate своих сценариев.

Разделение ролей принципиально: открытый протокол не «подсаживает» на одного оператора, а операторы конкурируют сервисом — как почтовые серверы поверх SMTP.

Риски