Чи дійсно AgentPay: є реальні сценарії чи це просто упаковка наративу?

Не всі платежі, що мають у назві Agent, є справжнім AgentPay. Я використовую п’ять рівнів, щоб систематизувати методи зменшення шуму, від наративу, демонстрацій, відтворюваних продуктів, реальних транзакцій до постійного доходу, і обговорюю, які сценарії можуть з’явитися першими.

Автор: Юкі (Лю Юцін)

Сьогодні я знову побачив, як одна платіжна компанія стверджує, що займається AgentPay, і мені стало цікаво, які сценарії вони реалізують. Я зайшов на їхній вебсайт, де є інформація про продукти, платіжні процеси та демонстрація. Але де сценарії? Які реальні сценарії? Чи використовує це агент? Хто платить за це?

Agentic стає новим наративом у галузі.

Незалежно від того, чи це Agentic Payment, Agentic Economy, Agent Commerce чи Agent Trading, усі вони мають в назві Agent. Ті, хто раніше займався гаманцями, починають говорити про Agent Wallet, ті, хто займався платіжними API, починають говорити про AgentPay, а ті, хто займається торгівлею, зберіганням, стабільними монетами та даними, також можуть знайти версію наративу про Agent.

Я сам завжди спостерігаю, чи можуть існувати реальні сценарії Agentic Payment, і спілкувався з багатьма командами. Деякі команди вже почали експерименти: надають агентам гаманці, підключають платіжні протоколи, щоб купувати дані, шукати, моделі або інші інструменти; деякі використовують агентів для торгівлі. Інші команди, переглянувши все, вирішили не слідувати цьому наративу і продовжити поглиблювати свої основні бізнеси.

Протягом останніх кількох місяців, щоб постійно стежити за розвитком цієї сфери та отримувати реальну інформацію, я створив для себе сигнал Agentic Payment. Він щодня шукає нові продукти, нові партнерства, нові інтерфейси та дані про транзакції з джерел, які я налаштував, а потім фільтрує їх за моїми критеріями. Я також регулярно переглядаю ці сповіщення.

Мої критерії фільтрації дуже прості: ця справа повинна дійсно стосуватися Agent Payments, мати продукти, документи, інтерфейси або записи транзакцій, і я повинен бачити, на якому етапі вона зараз. Якщо в заголовку просто додано слово Agent або обговорюється майбутнє в загальному, я зазвичай не звертаю на це уваги.

Agentic Economy по суті є двостороннім ринком, з одного боку мають бути агенти та ті, хто готовий за них платити: хто є клієнтом, як часто вони користуються, за що готові платити; з іншого боку, мають бути товари або послуги, які агенти можуть купувати та обмінювати, і ця угода дійсно повинна вирішувати проблему. Навіть якщо обидві сторони існують, потрібно продовжувати відповідати на запитання: як платформа стягує плату, чи можуть угоди бути постійними, і чи може це стати бізнесом.

Я майже щомісяця бачу нові стартапи та нові дії великих компаній, галузь дійсно просувається вперед. Але голоси агентів на ринку все ще дуже гучні, важко розрізнити, хто просто вдає, а хто дійсно працює, і на якому етапі знаходяться ці так звані агентські стратегії.

Я пишу цю статтю не для того, щоб оцінити, хто займається наративом, а хто робить справжню справу, і не для того, щоб скласти чорний або білий список компаній. Я просто хочу представити деякі явища, які я спостерігав, а також різні виміри, до яких дійшли інші, більш конкретно кажучи, ми можемо розділити те, що можна побачити публічно, на кілька рівнів.

Перший рівень: лише наратив

Компанії, які мають лише наратив, зазвичай публікують дуже повний опис майбутнього. Агенти можуть знаходити послуги, порівнювати ціни, автоматично платити; система підтримує кілька ланцюгів, кілька валют, обмеження, затвердження, повернення коштів та відповідність; і додається схема процесу, а також такі ринкові судження, як "машинна економіка наближається".

Ці матеріали можуть походити з прес-релізів, виступів, річних стратегій або цільових сторінок, але ви не знайдете входу до продукту, документів, коду, інтерфейсів, тестового середовища або шляхів виконання. (Можливо, компанія розробляє це, або це може бути на стадії приватного пілота, просто не опубліковане.)

Якщо ви є професіоналом у галузі або просто цікавитеся AgentPay, і бачите, що компанія говорить "один рядок коду, і ви підключені", спочатку спробуйте знайти цей рядок коду. Якщо не знайдете, зупиніться на рівні наративу. Просто послухайте.

Другий рівень: є демонстрація

Деякі компанії вже створили демонстрацію, ви натискаєте кнопку, і можете побачити, як агент запитує послугу, отримує ціну, підтверджує платіж, а потім отримує результат. У порівнянні з лише схемою процесу, досягнення цього етапу принаймні свідчить про те, що команда дійсно щось написала і з’єднала весь процес, але демонстрація може підтвердити лише це.

Оскільки ви бачите, що платіж успішний, це може бути лише анімацією на екрані; баланс може бути симульованим, а покупець і продавець можуть бути обліковими записами самої компанії. Увесь процес просто потрібно пройти за заздалегідь визначеним маршрутом, що не означає, що зовнішні користувачі дійсно можуть його використовувати.

Отже, дивлячись на демонстрацію, я зазвичай натискаю кілька разів більше, ставлю кілька запитань: чи можна змінити введення, чи лише повторювати один і той же процес? Чи дійсно система отримала запит? Чи дійсно гроші рухалися? Чи можна побачити записи транзакцій? Що станеться, якщо платіж не вдасться, послуга не повернеться, або система повторно виконає один раз?

Якщо ви не можете побачити жодного з цих моментів, це все ще лише прототип продукту, що свідчить про те, що команда дійсно щось зробила, але це ще не означає, що сценарій реалізований, і тим більше, що хтось готовий за це платити.

Третій рівень: є відтворюваний продукт

Третій рівень починає входити в "справжню діяльність". Зовнішні розробники можуть знайти SDK, CLI, MCP, документацію API, репозиторії коду або тестове середовище та самостійно виконати виклик, дотримуючись публічних кроків. Продукт не лише демонструє щасливий шлях, а й пояснює, як обробляються особи, авторизація, обмеження, повторні спроби, скасування та розрахунки.

Найважливіше слово тут - "відтворюваний", не те, що співробітники компанії демонструють успіх на конференції, а те, що зовнішні люди можуть отримати той же результат, дотримуючись публічної документації. На цьому рівні можна сказати, що продукт справжній, але ще не можна стверджувати, що сценарій реалізований.

Платіжна індустрія легко може змінити існуючі можливості на новий вхід для агентів: старий гаманець додає CLI, старий API додає MCP, стара система зберігання додає session key, стара політика двигуна додає авторизацію агента. Це не завжди зміна шкіри, агентам дійсно потрібні виклики, які можна використовувати, і нові межі прав. Але створення продукту лише доводить, що пропозиція існує, не доводить, що попит існує.

Четвертий рівень: є перевіряні платежі та доставки

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

Наприклад, Exa вже підключив свій API для пошуку та веб-читання до x402, агенту не потрібно спочатку реєструвати обліковий запис, запитувати API key, він може безпосередньо надіслати запит; служба повертає ціну, агент платить стабільною монетою та отримує результати пошуку. Згідно з опублікованою ціною, звичайний пошук коштує менше ніж один цент, а читання веб-сторінки ще дешевше.

Apify підключив ряд краулінгів та автоматизованих інструментів до x402, агент може тимчасово купити дані з TikTok, групу комерсантів Google Maps, набір товарів електронної комерції або деякий контент з соціальних медіа. Йому не потрібно спочатку відкривати облікові записи для кожного інструменту та купувати пакети, просто вказавши максимальний бюджет, він може розрахуватися за фактичними результатами. Однак офіційна документація Apify також чітко позначає цю можливість як експериментальну, що свідчить про те, що вона вже працює, але все ще на ранній стадії.

Ці два типи сценаріїв досить легко реалізувати, оскільки агенти купують дуже конкретні речі: один пошук, одна сторінка, набір даних товарів. Скільки коштує, що отримано, чи було доставлено, все це досить легко оцінити.

Агент може автоматично ініціювати сотні тисяч малих викликів за короткий час, у даних x402scan вже були випадки, коли BlockRun за місяць здійснив майже десять мільйонів транзакцій, але адреса покупця була лише близько тисячі; claw402 здійснив десятки тисяч транзакцій, але адреса покупця була менше ста, а загальна сума становила лише трохи більше тисячі доларів.

Отже, кількість транзакцій виглядає великою, але може бути лише невелика кількість програм, що здійснюють високочастотні виклики, і серед них можуть бути тестування, субсидії, внутрішні рахунки та пов’язані гаманці.

На цьому рівні, хто платить кому? Що куплено? Чи було це доставлено? Чи є покупець і продавець різними суб’єктами? Чи купить той же покупець наступного разу?

П’ятий рівень: є клієнти та постійний дохід

На п’ятому рівні починає з’являтися щось схоже на бізнес, тут вже не йдеться про "чи платив хтось хоч раз", а про те, чи використовують зовнішні клієнти постійно, і чи може компанія отримувати з цього гроші.

Зараз у публічних прикладах справжніх компаній, які можуть повністю розповісти цю історію, не так вже й багато. AgentCash на своєму вебсайті повідомляє, що агенти вже здійснили понад мільйон платних викликів через їхню платформу. Їхня компанія Merit Systems також розкрила, що команда, яка управляє 44 інтерфейсами, цього року здійснила близько 765 тисяч транзакцій, що принесло близько 40 тисяч доларів доходу.

Ці цифри корисніші, ніж "скільки партнерів підключено" або "скільки гаманців підтримується", оскільки вони принаймні одночасно розповідають про виклики, транзакції та доходи. Але слід зазначити, що це все ще дані, опубліковані самою компанією, а не результати третьої сторони. І вони все ще не відповіли на всі запитання: з цих мільйона викликів, скільки походить з інтерфейсів команди, а скільки з зовнішніх торговців? Скільки різних клієнтів? Як довго клієнти користувалися? Скільки з 40 тисяч доларів походить від одних і тих же людей, які купують повторно? Цього всього ще не видно.

У традиційних фінансових установах Mastercard відкрито заявила, що Itaú та Santander вже здійснили реальні транзакції через її програму Agent Pay. Це, безумовно, є кроком вперед у порівнянні з "обидві сторони спільно досліджують", принаймні гроші та процес покупки дійсно пройшли через систему. Але якщо не повідомляється, скільки транзакцій було здійснено, яка була сума, скільки часу це зайняло, чи повернулися люди для подальшого використання, то наразі це може лише підтвердити, що "реально спробували один раз", але не може довести, що вже є стабільні клієнти.

Отже, на п’ятому рівні не слід зосереджуватися лише на одному великому числі. Набагато важливіше з’ясувати чотири наступні речі:

• Хто користується?
• Чому вони користуються?
• Чи повертаються вони після використання?
• Хто насправді платить, і що отримує компанія?

Якщо компанія лише говорить про велику кількість партнерів, можна запитати: ці компанії просто випустили спільний прес-реліз, чи вже інтегрували системи? Це в рамках обмеженого тестування, чи вже дійсно здійснюють платежі? Якщо вона посилається на десятки мільйонів користувачів, мільярди гаманців або десятки мільярдів API-викликів, можна запитати: скільки з них дійсно походять з нових продуктів Agent?

Сильна база, звичайно, є перевагою. Але загальні дані існуючого бізнесу не можуть довести, що новий продукт знайшов клієнтів і спосіб заробітку.

Ці п’ять рівнів не є рейтингом доброти чи поганості, і не призначені для того, щоб наклеїти на компанію етикетку "справжня" або "фальшива".

Це більше схоже на набір методів зменшення шуму для професіоналів. Коли ви бачите новий проект AgentPay, ви можете спочатку оцінити, на якому етапі він зараз: чи говорить про майбутнє, чи вже створив демонстрацію, відкрив продукт, чи вже здійснив реальні транзакції, чи вже має клієнтів, які постійно платять.

Якщо ви дійсно зацікавлені в цьому напрямку, ви також можете використовувати цей метод, щоб продовжити пошук: яку конкретну проблему він вирішує, що купує агент, чи дійсно відбуваються фінансові операції, хто користується, хто платить, чи є повторні випадки.

Таким чином, ви не будете вважати проект занадто зрілим лише через одну прес-реліз, і не будете ігнорувати вже запущені реальні сценарії та випадки через те, що він ще не має масштабованого доходу.

Наявність демонстрації лише свідчить про те, що продукт починає формуватися; наявність транзакцій свідчить про те, що платежі та доставка пройшли; наявність клієнтів, які постійно платять, свідчить про те, що це починає наближатися до бізнесу.

Які сценарії можуть з’явитися першими?

Щодня переглядаючи Signal, я виявив, що прогрес Agentic Payment відбувається приблизно на трьох рівнях: як агент платить, як люди контролюють агентів, і що саме агент купує.

Перші два рівні стосуються гаманців, платіжних протоколів, розрахунків, бюджетів, затверджень і меж відповідальності. Третій рівень вже починає з’являтися конкретна поведінка покупок — від пошуку, даних і викликів моделей до реальних замовлень фізичних товарів.

Отже, після оцінки продукту потрібно повернутися до більш базового питання: що насправді купує агент? Яку проблему вирішує цей платіж? Далі я хотів би конкретніше подивитися, які сценарії покупок можуть з’явитися першими.

Я вважаю, що першим, що буде створено, не є те, щоб агент купував каву, квитки на літак чи готелі, а те, щоб він міг тимчасово купувати цифрові можливості, які можуть бути негайно спожиті під час виконання роботи.

Наприклад:

• Пошук і читання веб-сторінок;
• Збір даних і збагачення;
• Моделі, висновки та обчислення;
• Інформація про торговців, товари та рекламу;
• Сесії браузера, послуги верифікації та RPC;
• Контент та професійні дані за доступом.

Ці товари мають кілька спільних рис: невеликі суми, швидка доставка, результати, які можуть бути прочитані машинами, витрати, які можна виміряти, і невдачі, які відносно легко оцінити.

Наприклад, GTM Agent, щоб провести аналіз виходу на ринок для компанії, можливо, спочатку потрібно провести SEO-діагностику: перевірити індексацію сайту, ранжування ключових слів, зовнішні посилання та проблеми зі сторінками; потім купити трафік конкурентів, основні канали залучення клієнтів та дані ключових слів, щоб визначити, звідки приходять їхні користувачі.

Далі йому, можливо, потрібно буде прочитати цільові сторінки та сторінки цін, зібрати рекламні матеріали та записи розміщення, організувати список торговців на Google Maps або TikTok, а потім викликати API збагачення для заповнення інформації про розмір компанії, контактні особи та електронну пошту. Нарешті, він об’єднує цю інформацію, щоб надати список цільових клієнтів, оцінку каналів та рекомендації щодо наступних кроків.

Для виконання такого завдання може знадобитися безліч послуг, таких як пошук, веб-сканування, дані SEO, аналіз трафіку, рекламна інформація та корпоративна інформація. Але ці можливості не завжди потрібно використовувати щодня; іноді потрібно лише тимчасово перевірити домен, купити звіт або зібрати кілька сотень даних.

Якщо для кожної послуги потрібно, щоб людина спочатку зареєструвала обліковий запис, купила місячний пакет, прив’язала кредитну картку, подала заявку та зберегла API-ключ, а потім заздалегідь повідомила агенту, яку компанію слід викликати, його автономне виконання постійно буде затримуватися на людських попередніх налаштуваннях. Багато завдань не є неможливими для агента, а просто йому не вистачає даних і прав доступу, необхідних для виконання цього кроку.

Agent Payment тут вирішує не лише питання "як витратити гроші". Набагато важливіше, що агент може під час виконання виявити відповідні послуги, побачити ціни та зміст доставки, купувати за раз у межах обмеженого бюджету, а потім повертати результати в первісний робочий процес. Людина відповідає за встановлення цілей, бюджету та меж, агент вирішує, які інструменти потрібно купити для цього завдання і скільки разів.

Але чи може цей сценарій реалізуватися, також залежить від того, чи готова інша сторона відкрити постачання.

Дані, які GTM Agent насправді хоче використовувати, багато в чому контролюються такими зрілими платформами, як Similarweb, Semrush. Вони вже мають API, Semrush також пропонує офіційний MCP, агент технічно може їх викликати. Але користувачам все ще потрібно заздалегідь купити підписку, API-одиниці або зв’язатися з відділом продажу, що є двома абсолютно різними моделями в порівнянні з тим, як агент під час виконання завдання самостійно виявляє послуги, бачить ціни та купує за раз.

Зараз також є кілька стартапів, які переробляють пошук, веб-сканування, трафік та корпоративні дані в послуги, які агент може купувати безпосередньо. Вони можуть зменшити реєстрацію, підписання контрактів та налаштування API-ключів, але також стикаються з реальними проблемами: хто володіє базовими даними? Чи є права на перепродаж? Чи дозволяє платформа даних третім сторонам розбивати свої продукти на разові виклики? Коли ці проміжні шари починають забирати відносини з клієнтами, цінові права та прибуток, чи продовжить оригінальна платформа даних відкриватися?

Це буде довгострокова гра. Стартапи хочуть об’єднати різні джерела даних в ринок можливостей, які агент може вільно купувати; існуючі платформи можуть самі створити вхід для агентів, залишаючи виклики в рамках підписки та системи облікових записів. Остання модель, яка з’явиться, ймовірно, буде поєднувати відкриті протоколи, самостійні інтерфейси агентів та закриті платформи.

Cloudflare є прикладом, за яким варто продовжувати спостерігати; він не виробляє SEO, трафік або комерційні дані, а стоїть на вході до сайтів і послуг, намагаючись допомогти постачальникам вирішити, який контент можна безкоштовно переглядати, який потрібно заблокувати, а за який можна стягувати плату з агентів.

Pay Per Crawl дозволяє сайтам встановлювати ціну за доступ AI-сканерам до контенту; Monetization Gateway прагне ще більше дозволити сайтам, наборам даних, API та інструментам MCP стягувати плату за раз.

Його цінність полягає не лише в підключенні x402, а й у спробі обробити ціноутворення, ідентифікацію, контроль доступу та платежі в одному місці, дозволяючи постачальникам продовжувати контролювати ціни та правила доступу. Але він також ще на ранній стадії: Pay Per Crawl все ще є закритим бета-тестом, Monetization Gateway все ще в списку очікування, а публічна інформація ще не може підтвердити масштабовані доходи чи прийняття.

Отже, цей напрямок насправді має вирішити не лише питання платежів. Це також включає авторизацію даних, межі перепродажу, виявлення послуг та розподіл вигод. Технічно змусити агента заплатити певну суму не важко, важче пояснити, чому постачальник хоче дозволити йому купувати таким чином.

Реклама є ще одним сценарієм, який я завжди вважав дуже підходящим для реалізації Agentic Payment.

Реклама не є простим зарахуванням грошей на рахунок. Вона також підлягає впливу алгоритмів платформи, стратегій розміщення, якості матеріалів, досвіду оптимізаторів, бюджету та цілей ROI. Оптимізатор щодня приймає безліч дрібних рішень: який матеріал починає втомлювати, якій групі слід збільшити бюджет, яка вартість ключового слова зросла, який канал потрібно зупинити, коли слід знизити ціль, щоб система могла досліджувати новий трафік.

Ця робота має одну особливість: дані швидко змінюються, зворотний зв’язок відносно чіткий, і потрібно постійно приймати рішення. Людині важко стежити за кількома платформами 24 години на добу, але AI може постійно зчитувати покази, кліки, конверсії, CPA та ROAS, коригуючи матеріали, аудиторії, ставки та бюджети відповідно до заздалегідь встановлених цілей.

Фактично Google, Meta та TikTok вже використовують AI для реального часу ставок, розширення аудиторії, комбінації матеріалів та розподілу бюджету на своїх платформах. Отже, можливість може бути не лише створення "інструменту автоматичного коригування цін", а й дозволити агенту стояти над кількома платформами, розуміти бізнес-цілі компанії, порівнювати результати різних каналів і вирішувати, куди слід витратити наступний бюджет.

Тут насправді потрібно дистилювати здатність відмінного оптимізатора: в яких випадках слід продовжувати навчати алгоритм, а в яких випадках слід зупинитися; чи є зниження ROAS нормальною коливанням, чи є проблеми з матеріалом, сторінкою або аудиторією; коли слід змінити матеріал, а коли змінити канал; чи залишаються нові конверсії вигідними після збільшення бюджету.

Але це також не означає, що написавши кілька правил на основі досвіду оптимізатора, агент зможе повністю взяти на себе управління рекламою. Він спочатку потребує надійних даних про конверсії та атрибуцію, а також має розуміти прибуток, запаси, цикли повернення коштів та вартість життя клієнта. Інакше він може добре управляти ROAS на платформі, але не приносити компанії справжній прибуток.

Платежі тут є дуже природним поєднанням, оскільки рекламні рішення в кінцевому підсумку завжди перетворюються на фінансові рішення. Агент не лише пропонує "збільшити бюджет на певну кампанію", він також повинен мати право вирішувати, скільки грошей витратити, на яких платформах, скільки можна втратити за день, в яких випадках потрібно зупинитися і звернутися до людини для затвердження.

Отже, цей сценарій потребує не того, щоб кожен раз при торгах відбувалася мікроплатеж, а більш розумної форми, коли людина спочатку надає агенту контрольований бюджет і встановлює білу смугу для платформи, денний ліміт, цільовий CPA або ROAS, правила зупинки та затвердження. Агент продовжує оптимізувати в межах цих меж; як тільки він виходить за межі, він зупиняється або повертається до людини.

Реклама сама по собі є безперервним процесом ухвалення рішень та розподілу коштів. Коли ухвалення рішень починає автоматизуватися, автоматизації підлягають також повноваження на витрати, механізми зупинки втрат та межі відповідальності.

Платежі завжди служать сценарію, у рекламі сам сценарій вже має часті ухвалення рішень, чіткий бюджет та результати, які можна постійно оцінювати. З розвитком штучного інтелекту в часткових ухваленнях рішень, він потребує не лише набору аналітичних інструментів, а й системи платежів та повноважень, яка може безпечно залучати кошти.

Отже, різні сценарії потребують різних агентських платежів. Невеликі, часті, машинні послуги вимагають розрахунків за кожну операцію та миттєвих розрахунків; реклама, закупівлі та корпоративні витрати вимагають більше повноважень та контролю.

Як визначити, чи варто продовжувати спостереження за AgentPay?

Коли я знову побачу компанію, яка оголошує про стратегію AgentPay, Agent Wallet або Agentic Economy, я перевірю за цим порядком:

Спочатку дивлюсь на продукт

Що саме купує агент? Це чіткий API, дані, модель чи послуга, чи лише уявлення про "майбутні машини, які будуть самостійно торгувати"?

Потім дивлюсь на вхід

Чи є публічні продукти, документація, SDK, CLI, MCP, пісочниця або кінцева точка? Чи можуть зовнішні розробники самостійно викликати?

Далі дивлюсь на гроші

Чи дійсно відбувається платіж? Чи можу я побачити квитанцію, хеш транзакції або надійні виробничі записи? Анімація на сторінці та тестові монети не вважаються комерційним використанням.

Потім дивлюсь на клієнтів

Чи підтверджують зовнішні клієнти використання через свої канали? Це підтримка, спільна розробка, пілотний проект чи платний клієнт?

І нарешті дивлюсь на повторні покупки

Чому клієнт знову захоче використовувати? Якщо кожного разу потрібно покладатися на субсидії компанії, стимулювання акцій або внутрішній трафік, навіть велика кількість транзакцій навряд чи стане бізнесом.

Ще одне питання, яке я вважаю дуже важливим: що саме нове додала ця агенція? Якщо це просто зміна назви існуючого гаманця або платіжного API, цінність обмежена. Якщо вона дійсно зменшила тертя при реєстрації облікових записів, налаштуванні API ключів та розрахунках між постачальниками, або додала бюджет, авторизацію, скасування, аудит та звірку, тоді навіть якщо вона повторно використовує стару базу, це може бути значним новим продуктом.

Врешті-решт

Я вірю, що економіка агентів прийде, але вона не відбудеться просто тому, що у машин з'являться гаманці.

Агенти переходять від надання відповідей до виклику інструментів, налаштування ресурсів та виконання завдань. Коли програмне забезпечення починає діяти замість людей, оцінка, авторизація, платежі та звірка більше не будуть периферійними функціями, а стануть частиною їхньої здатності до дій.

Справжній бар'єр агентських платежів ніколи не полягав у тому, щоб змусити машину здійснити один платіж, а в тому, щоб вона могла постійно ухвалювати рішення, вартість яких виправдовує витрати в межах обмеженого бюджету, чітких цілей та відповідальності.

Ця конкуренція врешті-решт не буде лише про те, яка ланцюг швидший, який протокол відкритіший. Глибше питання полягає в тому: хто визначає, що машина може купувати, хто надає їй бюджет, хто оцінює, чи завершена угода, і коли машина помиляється, хто може зупинити та взяти на себе відповідальність.

Гаманець лише вхід, сценарій визначає, чи є попит, контроль визначає, чи може він увійти в компанію, повторні покупки визначають, чи стане це врешті-решт бізнесом.

Отже, я більше схильний розглядати сьогоднішні агентські платежі як переписування меж повноважень.

Коли агенти більше не просто відповідають на запитання, а починають залучати зовнішні ресурси, платежі стануть частиною їхньої здатності до дій. Але лише тоді, коли вартість, створена цими діями, перевищить витрати, економіка агентів справді перейде від наративу до реальності.