Агентный веб

У интерфейса появился второй пользователь

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

Масштаб уже не гипотетический. Матиас Билманн, CEO Netlify, в докладе «Why Agent Experience (AX) Matters» привёл собственную статистику платформы. В мае 2023 они выкатили в GPT store скромный эксперимент — custom GPT «Netlify website deployer». Он довольно быстро вышел на больше тысячи сайтов в день — и это только из экосистемы ChatGPT. Сегодня, после интеграций с Bolt, Windsurf, same.dev, alpha, refine, около 10 000 сайтов в день создаются непосредственно кодагентами. Не людьми, которые пользуются агентом как редактором, а агентами, которые сами инициируют деплой.

Из этого следует вещь, которую продуктовые команды пока плохо переварили. Билманн формулирует её прямо: большинство новых проектов на платформе начинается с агента, действующего от имени человека. Человек в цикле есть, но первое движение — выбор стека, первый вызов API, первый деплой — делает агент. Значит, решение «какой сервис взять» всё чаще принимает не тот, кто платит, а тот, кто исполняет. И конкурировать теперь приходится за него.

Возразить на это легко: агенту и так всё доступно. Любое веб-приложение уже открыто — можно натравить оператора из ChatGPT или computer use из Claude, хочет того сайт или нет. Билманн с этим не спорит и сразу добивает: симуляция человека через виртуальный браузер и скриншоты, скармливаемые мультимодальной модели, логически не может быть оптимальным интерфейсом. Это работает так же, как работает чтение чужой книги через видеозвонок — да, информация проходит, но выбирать этот канал по своей воле никто бы не стал.

Максимилиано Фиртман в докладе «WebMCP: Making Web Apps Faster and Cheaper for Coding Agents» раскладывает происходящее на три вектора, которые полезно держать в голове по отдельности:

Вектор	Что происходит
Агенты хотят строить веб	Что бы ни попросил вайб-кодер, на выходе почти всегда веб-приложение
Веб хочет запускать агентов	Агент прямо в JavaScript страницы; MCP apps — веб-приложение как мини-апп внутри Claude или ChatGPT
Агенты хотят браузить веб	Chrome с Gemini, агент-режимы браузеров, computer use

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

Собственная оценка Фиртмана трезвая: «мы в самом-самом начале агентного веба». Стандарт, вокруг которого построена середина этой статьи, — WebMCP — на момент доклада существовал как Chrome-only эксперимент под флагом, а origin trial открылся в Chrome 149 буквально на следующий день после выступления. Часть решений точно перепишут.

Но направление уже читается, и оно неудобное. Билманн ставит вопрос жёстче всех: если через пару лет ты не лидируешь в агентском опыте, ты не сможешь дать и лучший опыт разработчика — потому что разработчик придёт к тебе через агента. Хороший DX, который ты строил десять лет, обесценивается не потому, что стал плохим, а потому, что до него перестают доходить.

Эта статья — про то, что с этим делать. Дальше по порядку: чем агент отличается от человека как пользователь и почему привычные UX-приёмы против него работают (раздел 1); что технически предлагает WebMCP и почему «больше никаких скриншотов» — не лозунг, а расчёт по секундам и токенам (раздел 2); что конкретно менять в своём продукте, включая аутентификацию и права (раздел 3); и обратная задача — что происходит, когда ты встраиваешь агента внутрь своего продукта, включая цену его галлюцинаций (раздел 4).

Материал целиком — доклады AI Native DevCon 2026 и подкаста AI Native Dev. Восемь выступлений, местами противоречащих друг другу. Противоречия я не сглаживаю.

Чем агент отличается от человека как пользователь

Откуда взялся термин

Agent Experience — не маркетинговая обёртка, а рабочая рамка, и придумана она была в довольно приземлённой ситуации. Матиас Билманн, CEO Netlify, рассказывает в докладе «Why Agent Experience (AX) Matters», что термин родился в разговоре с principal engineer, когда команда разбирала после серии интеграций с кодагентами, что у них работает, а что нет. Определение он даёт короткое: AX — это «холистический опыт, который AI-агент получает как пользователь продукта или платформы».

Ключевое слово тут — «как пользователь». Не как канал, не как интеграция, не как транспорт. Билманн формулирует сдвиг так: продуктом теперь пользуются не только люди, но и агенты — и через агентов.

Чтобы понять, насколько это большая заявка, он выстраивает линию. Норман и Нильсен придумали UX тогда, когда стало ясно, что софт — это не список фич; со временем UX стал рыночным дифференциатором. Следующие десять лет Netlify строила DX: онбординг, документация, бренд, SDK, CLI — одержимость разработчиком как персоной. AX — та же дисциплина с новой персоной. Одержимость агентом как core persona.

	UX	DX	AX
Персона	конечный пользователь	разработчик	агент
Инструменты	интерфейс, копирайтинг, иерархия	доки, SDK, CLI, онбординг	тулы, схемы, контекст-файлы, машиночитаемые ошибки
Метрика	конверсия, удержание	time-to-first-success	доля успешных вызовов, agent NPS
Кто принимает решение о продукте	человек	человек	агент от имени человека

Последняя строка — самая неприятная. Билманн развернул вокруг AX всю продуктовую команду как вокруг North Star и объясняет почему: дифференциация продуктов будет идти по вопросу «какой продукт предпочитает агент вашего пользователя».

Тест пяти пользователей, применённый к агенту

Самая полезная практическая идея доклада — дешёвая. В классике UX-исследований есть приём: посади пять человек перед продуктом и не подсказывай, как им пользоваться.

Билманн предлагает буквально то же самое с агентом: дай ему свой CLI и API, попроси что-нибудь сделать и смотри, не вмешиваясь.

Результат он описывает узнаваемо. Агент галлюцинирует несуществующие фичи и зовёт эндпоинты, которые делают не то, что он думает. Ровно как живой пользователь, который ищет кнопку там, где её нет, — только вслух и в логах.

Это единственное известное мне из материала измерение AX, которое можно провести сегодня вечером и без бюджета.

Что у агента фундаментально не так, как у человека

Здесь полезно послушать не продуктового CEO, а инженера по безопасности. Эндрю Оутс, distinguished engineer в Snyk, в докладе «MCP Mayhem: Fun Ways AI Agents Write Bad Code» разбирает популярную метафору «агент — это джуниор» и отвергает её. Сходства поверхностные: пишет код, ищет, пишет доки и тесты. А нет у него всего фундаментального — понимания, способности разблокировать себя, задать вопрос, попросить обратную связь, учиться со временем и суждения. Оутс формулирует зло: «если бы такой человек пришёл ко мне в команду, с ним пришлось бы проводить performance-разговор».

Из этого следуют три отличия, которые прямо влияют на дизайн продукта.

Первое: у агента нет ground truth. Оутс говорит, что модель не понимает, что такое код, спека или тест, — у неё есть только обучающие данные и контекст. Её экстраполяции почти всегда правдоподобны, часто верны и иногда правдоподобны и неверны. Грубые случаи ловит компилятор и тесты; опасны именно те, что не ловятся. Плюс модели обучены угождать («пользователь всегда прав»), так что критического сопротивления ждать не приходится. Человек, упершись в странность твоего API, напишет в поддержку. Агент — уверенно придумает, как оно должно было работать.

Второе: агент не откатывается к первым принципам. Оутс называет это doom spiral: упершись в стену — не компилируется, флакающий тест, неудачно выбранная стартовая точка — агент не делает шаг назад и не пересматривает подход, а пробует всё более драматичные средства, пока не удалит весь код. Финал он цитирует почти дословно: «я выполнил задачу, удалив её, теперь программа запускается». По его наблюдению, удаление кода агентом случается каждые пару месяцев.

Третье: агент не помнит вчерашний день и не читает твой сайт. Билманн описывает LLM как «очень странного разработчика»: она прочитала весь интернет, но строит на твоём продукте по случайному устаревшему туториалу, а не по твоей документации. Человек хотя бы гуглит и попадает на твой домен.

Четвёртое: не видя живого состояния, агент его придумывает. Роксана Фишер, CEO anyshift, в докладе «Your Infra is a Graph» показывает это на бытовой просьбе «сделай VPC peering в Terraform». Copilot знает best practice и аккуратно строит динамические зависимости, но не знает, где лежит существующий main VPC, — и досоздаёт новый. Формально валидно, практически бесполезно. Живой человек в этом месте пошёл бы смотреть консоль или спросил коллегу; агент заполняет пробел правдоподобным содержимым, потому что другого поведения у него нет. Подробнее этот сюжет — в разделе 4.

Почему привычные UX-приёмы работают против агента

Тут материал даёт несколько конкретных примеров, и все они контринтуитивны.

Красивый DOM — плохой DOM. Фиртман в подкасте «No More Screenshots» объясняет, почему агенты возвращаются к скриншотам, хотя разметка вроде бы доступна. После эпохи React DOM, отдаваемый пользователю, несемантичен — это «список из сотни div'ов», а div не несёт смысла. На нативном iOS ситуацию спасает accessibility tree, то же дерево, которое читают скринридеры; на вебе тесты дают заметно худший результат. Его формулировка: «DOM оптимизирован под человеческий мозг».

Хороший DX ≠ хороший AX. Пример Билманна почти анекдотический: LLM заметно лучше работают с XML, чем с JSON, по банальной причине — в XML не надо экранировать кавычки. А разработчики исторически предпочитают JSON. Твоё аккуратное решение, принятое ради людей, оказывается налогом для новой персоны.

Абстракции, которые помогали людям, прячут смысл от модели.

СО СЦЕНЫ: BREX ВЫКИНУЛ КАСТОМНЫЕ ХУКИ РАДИ АГЕНТА

• Кто и где: Матиас Билманн, Netlify, AI Native DevCon 2026 — со ссылкой на тред Марсело Терреро из Brex
• Что показали: Из кодовой базы убрали все кастомные хуки — они прятали от модели, что реально происходит. Весь фетчинг данных перевели на Relay (GraphQL), где зависимости данных объявлены прямо в компоненте.
• Цифры: цифр не назвали
• Что это меняет: Relay в своё время «не взлетел» у людей как слишком тяжёлый в освоении. Для агента контекст стал проще — и LLM начала one-shot'ить целые фичи. Технология, проигравшая по DX, выиграла по AX.

Регистрация перед первым действием — теперь трение не для человека, а для агента. Билманн описывает паттерн deploy-then-claim: агент деплоит без регистрации, авторизации и вообще без аккаунта, отдаёт пользователю живой URL плюс claim-ссылку — хочешь сохранить сайт дольше пары часов, забери его в аккаунт. Так работают Bolt и Windsurf (windsurf.build), паттерн уже скопировали Neon DB и Prisma.

Что агенту нужно, а человеку не нужно

Собранное из докладов Фиртмана и Любкена:

• Описания, написанные для модели, а не для человека. У Фиртмана описание тула — отдельная часть контракта, и он подчёркивает: это текст для модели. Его правило дизайна: «ваш потребитель не пользователь, а AI-агент».
• Технические сообщения об ошибках вместо вежливых. Фиртман: в ответ на плохой вызов возвращать не «что-то пошло не так», а точный текст — какие аргументы неверны и почему. Тогда агент итерирует и чинит вызов сам, без человека. Тот же приём у Маттиаса Любкена в «Piece of Pi»: агент сам выясняет контракт, вызывая тул с --help и читая ошибки.
• Отсутствие двусмысленности в наборе возможностей. Любкен: «don't make your agent guess» — определения должны быть точными, раскрывающими намерение и узко заскоупленными.
• Доставка актуальной документации прямо в контекст. Билманн считает это критичным и честно признаёт, что стандартов почти нет: cursor rules, llms.txt, MCP — и всё.
• Слой между API и агентом. Билманн: если дать агенту голый OpenAPI-спек и больше ничего, он справится хуже, чем computer use, проходящий через человеческий интерфейс. Нужно то, что подсказывает, как один вызов направляет следующий, как связать stateful-поток, какой контекст подать. MCP пока единственный кандидат в стандарт — с оговоркой самого Билманна, что «история с авторизацией там всё ещё сырая и мутная».

Что уже применяют

Кроме deploy-then-claim, в материале есть ещё одна практика, которую стоит украсть немедленно. Билманн вайб-кодил MCP-сервер для личного блога: первый промпт со ссылкой на гайд Netlify дал рабочий сервер, второй — два тула. Третьим тулом он добавил «оставь фидбек в опросе agent net promoter score» и подтолкнул агентов пользоваться им после других вызовов. Текущий agent NPS сервера — 50; довольны и Claude, и GPT.

Идея простая до неприличия: если агент — пользователь, у него можно спросить, как ему работалось. И он ответит.

Коротко

• AX — это дисциплина, а не метафора. Та же логика, что UX и DX, но персона другая (Билманн, Netlify).
• Проверить свой продукт можно сегодня: дай агенту CLI и API, не подсказывай, смотри, что он галлюцинирует. Это тест пяти пользователей, применённый к новой персоне.
• Агент — не джуниор, а очень плохой джуниор: нет ground truth, нет способности задать вопрос, нет отката к первым принципам (Оутс, Snyk).
• Решения, принятые ради людей, часто вредят агенту: несемантичный DOM после React, JSON вместо XML, кастомные хуки, регистрация перед первым действием.
• Самая дешёвая победа — сообщения об ошибках. Технический текст вместо «что-то пошло не так» превращает агента в самопочиняющегося клиента.

WebMCP: контракт вместо угадайки

Что сегодня делает агент в браузере

Максимилиано Фиртман в докладе «WebMCP: Making Web Apps Faster and Cheaper for Coding Agents» описывает текущий цикл агента одним словом — угадайка. Наблюдает (скриншот, DOM или accessibility-дерево) → выводит, куда кликнуть → действует → повторяет всё заново после каждого клика. Каждый шаг — новый инференс, потому что после клика состояние страницы неизвестно.

WebMCP убирает из этого цикла инференс. Вместо того чтобы модель догадывалась о возможностях страницы по пикселям, страница сама объявляет набор инструментов, который написал веб-разработчик. Формулировка Фиртмана: «мы переходим от инференса к контракту».

Анатомия тула

Тул — объект из четырёх частей:

Часть	Что это
Имя	идентификатор, по которому агент выбирает инструмент
Описание	текст для модели, не для человека — что произойдёт при вызове
Input schema	аргументы со схемой и типами
execute	обычная JavaScript-функция

Императивный API выглядит как document.modelContext.registerTool({...}) — в подкасте Фиртман называет форму navigator.modelContext.registerTool, что само по себе неплохая иллюстрация зрелости спецификации.

Важная деталь: execute возвращает промис. Значит, внутри можно уйти куда угодно асинхронно — на бэкенд, в Bluetooth-устройство, в IndexedDB, к пользователю за подтверждением. Тул на странице — не тонкая обёртка над кликом, а полноценная точка входа.

JavaScript при этом не обязателен. Есть декларативный вариант поверх обычных HTML-форм: на <form> вешаются атрибуты tool-name и tool-description (оба обязательные), булев tool-auto-submit — явное разрешение автора на автосабмит агентом, и tool-parameter-description на инпутах, селектах и textarea, если лейбла модели недостаточно.

Отсюда же и главное ограничение применимости, которое Фиртман проговаривает сам: «нет форм на сайте — считай, нет юзкейса для WebMCP».

Ещё одно правило, которое легко пропустить: регистрировать все тулы на загрузке не нужно и вредно. Набор тулов должен меняться вместе с состоянием приложения — залогинен или разлогинен, какой шаг воронки, какой экран открыт. Тулы снимаются и добавляются на лету.

Чем это отличается от обычного MCP

Фиртман настаивает, что это не конкуренты, а два разных слоя.

	MCP	WebMCP
Что соединяет	агента с бэкендом: серверы, API, данные, воркфлоу	агента с фронтендом: текущей страницей
Где живёт исполнитель	сервер	JavaScript-функция на странице
Транспорт	исторически HTTP с long-polling (веб-сокетов не было) + бинарный сокет для локальных клиентов	никакого — это просто JS в странице
Что доступно	то, что есть на бэкенде	позиция скролла, введённые в форму данные, UI-состояние, сессия, localStorage/IndexedDB, File System API, Web Serial, сенсоры

Последняя строка — суть. WebMCP даёт агенту то, чего на бэкенде физически нет. Пример Фиртмана про сенсоры вполне буквальный: веб-приложение на смарт-очках Meta.

Его же сравнение, объясняющее степень родства: «WebMCP относится к MCP как JavaScript к Java» — вдохновлён идеей, но протокол совсем другой.

Из этого следует практический вывод, который обычно расстраивает команды: экспортировать существующий MCP-сервер в WebMCP нельзя. Общая только концепция «имя + описание на английском + схема». Транспорт разный, среда исполнения разная. Переписывать с нуля. И автоматически WebMCP на сайте не появится — надо идти в свой JavaScript и реализовывать.

Ведущий подкаста AI Native Dev заметил на это любопытную вещь: в AI-мире идёт обратное движение — то, что раньше правильно было разделять, снова слепляют, отсюда и бум монорепо, агенту проще, когда всё в досягаемости. WebMCP делает то же самое с фронтендом: сознательно затаскивает API внутрь страницы, жертвуя чистотой разделения слоёв ради связности для агента. Если тебе от этой идеи неуютно — это нормальная реакция, и она честная.

Ключевой сюжет: почему «больше никаких скриншотов»

СО СЦЕНЫ: ПЯТЬ СЕКУНД, ЗА КОТОРЫЕ КНОПКА УЕЗЖАЕТ

• Кто и где: Максимилиано Фиртман, подкаст AI Native Dev, выпуск «No More Screenshots. Web MCP Lets Agents Talk to Your Website Directly»
• Что показали: Разбор цикла скриншот-агента по шагам. Агент делает снимок экрана, отдаёт его image-модели, получает координаты, кликает. Между снимком и кликом проходит время на анализ — 5–10 секунд. За это время JavaScript на странице вполне мог передвинуть кнопку: догрузился баннер, приехал ответ от API, отработала анимация. Клик уходит в пустоту, нужен новый скриншот, и цикл начинается заново.
• Цифры: окно рассинхрона — 5–10 секунд между снимком и кликом; каждый повтор оплачивается токенами мультимодальной модели
• Что это меняет: «Больше никаких скриншотов» — не про эстетику, а про арифметику. Неэффективно и по времени, и по деньгам: изображения дороги в инференсе, а промах заставляет платить за них дважды и трижды. Прямая цитата Фиртмана: «что если за эти 5–10 секунд JavaScript передвинул кнопку?»

Естественный контраргумент — не надо скриншотов, читай DOM. Фиртман отвечает на него в том же выпуске, и ответ разобран в разделе 1: после эпохи React DOM несемантичен, «список из сотни div'ов», а accessibility-дерево, которое выручает на нативном iOS, на вебе даёт заметно худший результат в тестах. Именно поэтому агенты возвращаются к скриншотам, а не потому, что никто не пробовал иначе.

WebMCP закрывает эту дыру с другой стороны. Вызов тула — это вызов функции: детерминированный, с валидированными аргументами, без координат и без гонки с рендерингом. Одна операция вместо цикла «снимок → инференс → клик → снимок».

Второй ключевой момент: сайт наконец узнаёт, что им управляет агент

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

Сегодня детекта агента не существует в принципе. Фиртман приводит пример: X пытается проверять «настоящий палец на экране» — и это не помогает, потому что Puppeteer и Playwright эмулируют касания. Сайт не может отличить человека от автоматики, если та не хочет представляться.

WebMCP добавляет на window события tool-activated и tool-cancel, плюс CSS-псевдоклассы. То есть страница получает сигнал: сейчас тобой управляет агент, вот какой тул он активировал, вот момент, когда он отменился.

Что с этим можно делать:

• перестроить UI под машинного потребителя — убрать анимации, показать компактное состояние;
• честно показать живому пользователю, что за него сейчас действует агент, — если человек сидит перед тем же экраном;
• вести себя по-разному в одной и той же функции. Фиртман отдельно отмечает: функции можно переиспользовать с обычным UI, есть флаг, позволяющий проверить, кто сейчас вызвал — агент или человек.

К этому же примыкает механика прерывания. Если тул делает что-то платное или необратимое, разработчик может попросить браузер задать вопрос пользователю: агент ждёт, браузер показывает диалог «подтверждаете покупку билета?», ответ возвращается агенту. Принципиально важно, кто у кого спрашивает: не агент сам себя ограничивает, а платформа спрашивает человека. Ограничение честное — работает только там, где человек реально сидит за видимым браузером.

Экономика

Считать тут особо нечего, но направление однозначное.

• Токены. Скриншот-цикл жжёт токены мультимодальной модели, и каждый промах умножает счёт. Вызов тула — текстовый и однократный.
• Время. 5–10 секунд на шаг против одного вызова функции.
• Стоимость промаха. У скриншот-подхода она нелинейная: промахнулся — заплатил ещё раз за весь цикл.

Ведущий подкаста связал это с общей чертой агентной разработки, которую в Tessl сформулировали как «сначала дёшево, потом дорого»: сначала кажется, что один человек делает объём команды, потом приходит счёт и начинается вопрос «а можно ли то же самое дешевле». Большинство команд до этой фазы ещё не дошло — они в discovery. WebMCP — один из ответов на вторую фазу, и продавать его внутрь компании проще именно там.

Есть и второй маршрут удешевления, о котором Фиртман говорит в том же выпуске: client-side AI. Chrome умеет по запросу первого же сайта скачать Gemini Nano (4–8 ГБ, три модели, качается нужная) и отдать его любому сайту через JS-API; отдельно есть библиотеки поверх WebAssembly, WebGPU и WebNN, качающие открытые модели прямо в страницу — специализированные весят 200–500 МБ (модель детекции объектов от Apple — 200 МБ), Qwen 0.5B дообучается на обычной машине. Мотив прагматичный: саппорт-боты первыми упираются в счёт за облачные токены, и часть нагрузки уносят на клиент. В примере спикера счёт составлял $100 000. Оговорок две: по его оценке client-side AI используют меньше 1% компаний, и это «не для терапевта и не для преподавания истории» — а для суммаризации, категоризации, модерации, мини-RAG. Перевод контента, по его словам, проходит тесты качества на 25 языках.

Стоит ли вообще вкладываться во фронтенд под агентов — Фиртман отвечает на это своим прогнозом. Всё, что нагенерировано вайб-кодингом, — веб-приложения, значит, веба становится больше, а не меньше. Его горизонт на три года: меньше нативных приложений на мобильных, больше вещей, к которым приходят по ссылке или QR-коду и которые уже никто не называет «веб-приложением» — просто «AI-приложением». Сам он, к слову, пишет 15-ю книгу за 30 лет в вебе — про vanilla web и принципиально без AI в процессе, — и аргументирует выбор темы ровно в ту же сторону: меньше библиотек и зависимостей не только безопаснее, но и лучше для контекста, агентным инструментам проще писать веб без тяжёлого дерева зависимостей.

Чего WebMCP не делает

Здесь важно не переобещать, иначе внедрение развалится о первую же реальность.

• Не отменяет старые техники. Агенты откатываются на скриншоты и DOM, если тулов нет. WebMCP только добавляет быстрый путь.
• Не заменяет тесты. Фиртман прямо говорит: тулы — это новый публичный контракт, который тоже надо покрывать юнит-тестами. По смыслу WebMCP ближе к юнит-тесту функции, чем к e2e; e2e проверяет, как всё выглядит и ведёт себя для человека, и никуда не денется.
• Не работает в headless. Только видимый Chrome. В Puppeteer доступно под экспериментальным флагом.
• Не поддерживается кодагентами нативно. Рабочая схема на сегодня: агент (Claude Code, Cursor, Codex — любой с MCP) подключается к Chrome DevTools MCP, тот поднимает живой инстанс Chrome, открывает страницу, перечисляет её тулы и вызывает их. Дальше ожидается прямая поддержка — Codex, MCP apps в ChatGPT, браузерный плагин OpenClaw.
• Не всем нужен. Сильнейшая мотивация — e-commerce: «вам всё равно, человек это или агент, вам нужны деньги от покупателя», а Apple Pay и Android Pay вообще работают только на клиенте, поэтому корзина живёт в браузере. Обратная картина у блогов и медиа: авторы агентов отталкивают — IP, пользователь не доходит до сайта, авторство теряется. Контентным сайтам WebMCP по большей части бессмысленен.

И главная оговорка — про статус. Стандарт предложен командой Chrome и целится в их же agent mode. Ни OpenAI (несмотря на спонсорство OpenClaw), ни Anthropic — авторы самого MCP — в обсуждении в W3C пока не участвуют: для них веб-стандарты новая территория. Пока это Chrome-only под флагом; origin trial открылся в Chrome 149 — на следующий день после доклада. Формулировка Фиртмана: «это всё ещё эксперимент, спецификация обсуждается — что-то добавят, что-то выкинут».

Коротко

• WebMCP заменяет инференс контрактом: страница объявляет тулы (имя, описание для модели, схема, execute), агент их вызывает вместо угадывания по пикселям (Фиртман).
• «Больше никаких скриншотов» — арифметика, а не лозунг: 5–10 секунд между снимком и кликом хватает, чтобы JavaScript передвинул кнопку, и цикл начинается заново за твой счёт в токенах.
• Это не экспорт твоего MCP-сервера. Общая только концепция; транспорт и среда исполнения разные — писать заново, в своём JavaScript.
• Впервые появляется детект агента: события tool-activated и tool-cancel плюс CSS-псевдоклассы. Раньше этого не было в принципе — Puppeteer эмулирует даже касания.
• Статус трезвый: Chrome-only, origin trial с Chrome 149, headless не поддержан, ни OpenAI, ни Anthropic в обсуждении стандарта нет.

Что делать со своим продуктом

Начни с того, как агент вообще к тебе попадает

Прежде чем что-то менять, полезно понимать, каким из пяти маршрутов агент доходит до твоего интерфейса. Фиртман в докладе «WebMCP» перечисляет их все:

Техника	Что умеет	Где ломается
Коннектор (MCP-сервер или CLI)	точный, детерминированный	компания должна была его реализовать
Обычный fetch / curl	быстро и дёшево	не исполняет JavaScript — на SPA бесполезен
Браузерное расширение	читает DOM, a11y-дерево, снимает скриншот	несемантичный DOM, дорогие скриншоты
Встроенный браузер агента	у Codex свой webview-браузер	зависит от конкретного агента
Computer use	мышь, клавиатура, скриншоты всего экрана	самый медленный и дорогой; единственный способ загнать агента, скажем, в Safari

Отдельно стоит проверить, что происходит, когда пользователь просит ChatGPT «прочитай эту ссылку». По словам Фиртмана, в большинстве случаев модель до сих пор просто скачивает markdown-версию HTML без исполнения JavaScript — так работал ещё первый браузинг-плагин. Если твой сайт целиком client-side rendered, ответ будет «не могу прочитать эту страницу». Полноценный агент, берущий на себя роль пользователя через Playwright или Puppeteer, — следующий шаг, но он ещё не везде.

Практический вывод номер ноль, до всякого WebMCP: если у тебя чистый CSR, для большой части агентного трафика ты невидим.

Отдавай структуру, а не картинку

Дальше идёт лестница, по которой стоит подниматься в таком порядке.

Ступень 1 — семантика и SSR. Всё, что описано выше, лечится обычной серверной отрисовкой и осмысленной разметкой. Фиртман объясняет провал DOM-подхода тем, что после React разметка несемантична: «список из сотни div'ов», а div не несёт смысла. Ты не обязан ждать нового стандарта, чтобы это исправить.

Ступень 2 — убрать абстракции, прячущие смысл. Кейс Brex из раздела 1 ровно про это: кастомные хуки выкинули, фетчинг перевели на Relay, где зависимости данных объявлены прямо в компоненте, — и LLM начала one-shot'ить целые фичи (Билманн, со ссылкой на тред Марсело Терреро).

Ступень 3 — диагностические тулы. Здесь у Фиртмана самый быстрый профит от WebMCP, и он советует начинать именно с них: тулы, которые отдают агенту фронтовую правду — список всех ошибок текущей сессии, «опиши текущий вид», run diagnostics с полным браузерным контекстом. После этого вопрос «почему эта страница валит QA?» превращается в один вызов вместо серии скриншотов.

Ступень 4 — действующие тулы, дизайн которых обсуждается ниже.

Рецепт внедрения за один вечер

Фиртман даёт последовательность, которую можно пройти без продуктового решения и без релиза:

1. Взять одну высокоценную страницу или состояние.
2. Выставить только диагностические тулы — они ничего не меняют, значит, безопасны.
3. Прогнать вручную из Claude Code, Cursor или Codex, оценивая, какие тулы агент выбирает и с какими аргументами.
4. Затем автоматизировать через Chrome DevTools MCP или Puppeteer.

Третий шаг — самое ценное. Это и есть тест пяти пользователей из раздела 1, только с логами вызовов вместо записи экрана.

Дизайн тулов — это дизайн API, но потребитель другой

Правила Фиртмана, сведённые в список:

• Один тул — одна цель, без пересечений. Если два тула частично перекрываются, агент чаще выбирает не тот.
• Тулы, зависящие от состояния, регистрировать только когда они полезны. Не всё на загрузке.
• Описание — простым языком о том, что произойдёт. Не о том, как устроено внутри.
• Строгая валидация аргументов.
• Маленький выход — ровно запрошенное. Не отдавай агенту весь объект, если он спросил одно поле.

Его формула: «ваш потребитель не пользователь, а AI-агент».

К этому Маттиас Любкен в «Piece of Pi» добавляет требование к самим определениям: точные, раскрывающие намерение (intent-revealing) и узко заскоупленные под задачу.

Его тезис — «don't make your agent guess» — и наблюдение, что главное архитектурное решение в агентной системе не воркфлоу, а набор тулов.

И приём, который стоит отдельного упоминания, потому что он превращает ошибки в интерфейс. Фиртман: возвращать не «что-то пошло не так», а технический текст — какие аргументы неверны и почему. Тогда агент итерирует и чинит вызов сам, без человека. Любкен описывает ту же механику с другой стороны: его агент выясняет контракт, вызывая тул с --help и читая сообщения об ошибках.

Агенты в браузере: что уже работает и где границы

Самая радикальная иллюстрация того, куда это едет, — доклад Ларса Трилофа из Adobe «Building AI agents in the browser, for the browser, of the browser». Slick — агентный цикл, исполняющийся прямо в браузерной вкладке: закрыл вкладку — цикл остановился.

Мотив у него не идеологический, а бытовой: агенту нужна песочница, но ставить Docker Трилоф не хотел — корпоративный MDM заметит и заставит объясняться. Браузер — уже готовый контейнер, и именно в нём происходит вся его работа с тысячами SaaS-приложений. Его тезис: «каждый раз, когда мы сажаем агента в коробку, он становится менее полезным».

Что реально удалось затащить внутрь вкладки: bash и coreutils, SQLite, интерпретатор Python, ImageMagick, инструменты для PDF, git через isomorphic-git (крошечная JS-реализация), а недавно — biome и компилятор TypeScript. Последнее появилось по понятной причине: агент открывал PR к собственному коду, и те падали на линтинге. Чего нельзя: перекодировать видео и лезть в локальную файловую систему.

Протокольный стек тоже показателен: HTTP (агент смотрит на мир через curl), Chrome DevTools Protocol для управления вкладками, WebRTC для связи инстансов между собой, MCP — только HTTP-транспорт, stdio не поддержан. Про CDP у Трилофа есть хорошая ремарка: его собственный мини-Playwright CLI оказался тонкой обёрткой над протоколом — «загадочное вещество, на котором они варят, — вода».

Ограничения он не прячет, и они поучительны:

СО СЦЕНЫ: FIND ПО 50 ГИГАБАЙТАМ КЛАДЁТ РЕНДЕРИНГ

• Кто и где: Ларс Трилоф, Adobe, AI Native DevCon 2026 — доклад про агента, живущего в браузерной вкладке
• Что показали: Изначально агентный цикл крутился в главном потоке — просто и быстро. Пока агент не запустил find по директории с десятками git-worktree и копиями node_modules. Рендеринг встал намертво.
• Цифры: директория, по которой пошёл find, — около 50 ГБ
• Что это меняет: Пришлось строить процесс-менеджмент: ps показывает все команды и промпты, запущенные с момента загрузки страницы, процессы можно прерывать. Если ты пускаешь агентный цикл к себе на страницу, изоляция от главного потока и возможность убить операцию — не оптимизация, а условие работоспособности.

Хорошая новость для тех, кто внедряет WebMCP: со стороны потребителя порог входа низкий. Трилоф говорит, что поддержка WebMCP в Slick — это буквально сказать агенту «найди поддержку WebMCP»: он подтянет подходящий skill и обнаружит, что это просто ещё одно свойство объекта document.

И его же наблюдение про то, чего агенту не хватает на твоём продукте. Модель отлично знает популярные API — скажи «управляй Slack», и она спросит только токен. И совершенно не знает твою самоделку: «что это за странная штука, которую вы состряпали?». Разрыв закрывают skills — они и делают агента практически применимым к конкретному зоопарку SaaS. Если у твоего продукта нет ни MCP-сервера, ни skill, ни llms.txt, агент будет строить по случайному устаревшему туториалу — ровно как описывал Билманн.

Аутентификация и права

Самая недоделанная часть агентного веба, и все три спикера это признают.

Секреты не должны попадать в контекст модели. Решение Трилофа простое и воспроизводимое: в Slick сделан отдельный CLI oauth token, который проводит OAuth-флоу и хранит токен, а от модели значения физически скрыты — они не утекают в контекст. Агент оперирует именем токена, а не самим секретом. Это можно повторить в любом продукте, где агент дёргает твой CLI.

OAuth в его нынешнем виде — трение. Билманн: сегодня «постоянно проходить OAuth десятком тулов, прежде чем агент вообще что-то сделает» — слишком дорого. Он же признаёт, что у MCP история с авторизацией «сырая и мутная», хотя слой стандарта MCP выиграл. Открытые вопросы, которые он выносит на обсуждение (площадка — agentexperience.ax): как выставлять tool use через сам веб, а не через отдельные MCP-серверы; как дать более гранулярные паттерны доступа, чем позволяет текущий OAuth; как отдавать агентам платный контент так, чтобы это монетизировалось; как выставлять собственных агентов наружу для чужих агентов.

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

• динамическая регистрация тулов — разлогиненному агенту просто не показывать тулы, которых ему нельзя;
• браузерный диалог подтверждения — на платном или необратимом действии вопрос человеку задаёт платформа, агент ждёт ответа.

И самый радикальный вариант — не требовать аккаунта вообще. Deploy-then-claim у Netlify: агент деплоит без регистрации и авторизации, отдаёт живой URL и claim-ссылку. Это не обход безопасности, а перенос момента аутентификации туда, где она нужна человеку, а не агенту.

Обратная сторона: не всем это надо

Честная оговорка, чтобы раздел не читался как призыв всем всё открыть.

Билманн рассказывает, что вторая по частоте просьба клиентов Netlify — блокировка AI-ботов и контроль краулеров: агентные тулы ходят по вебу в паттернах, нежелательных для владельцев сайтов, магазинов и приложений. Его аргумент состоит в том, что это не противоречие: оптимизация под агентов — ещё и способ вернуть контроль над трафиком и ресурсами вместо «тонн скрейпинга и лишних запросов». Дать агенту дешёвый структурированный путь выгоднее, чем терпеть дорогой неструктурированный.

Фиртман проводит границу по типу бизнеса. E-commerce — сильнейшая мотивация: «вам всё равно, человек это или агент, вам нужны деньги от покупателя». Блоги и медиа — противоположный полюс: авторы агентов отталкивают, потому что теряются IP, трафик на сайт и авторство.

Коротко

• Проверь базу до стандартов: чистый CSR невидим для значительной части агентного трафика — модель часто просто качает markdown-версию HTML без JS.
• Порядок работ: семантика и SSR → убрать абстракции, прячущие смысл → диагностические тулы → действующие тулы.
• Первый WebMCP-заход делай безопасным: одна страница, только диагностика, ручной прогон из Claude Code или Cursor, и смотри, что агент выбирает.
• Дизайнь тулы как API для модели: одна цель на тул, строгая валидация, маленький выход, технические ошибки вместо вежливых.
• Секреты — мимо контекста: агент оперирует именем токена, а не значением (приём Трилофа). Гранулярного стандарта доступа пока нет — держи границы через динамическую регистрацию тулов и подтверждение на стороне браузера.

Агент внутри твоего продукта

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

Кейс: кодагент в афтерсейлс

Маттиас Любкен в докладе «Piece of Pi: Embedding the OpenClaw Coding Agent in Your Product» разбирает реальное внедрение. Боль клиента бытовая: квоты на запчасти в афтерсейлс делаются вручную и медленно.

Архитектура скопирована с самого OpenClaw: гейтвей → агент-контейнер на каждого клиента → сессия на каждый кейс. Контекст собирается из переиспользуемых AGENTS.md — общий бизнес, задача, специфика конкретного клиента и его скидки. Тулов всего три: состояние кейса (CRM), поиск запчастей (ERP), черновик письма.

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

Второе решение того же доклада — где живут гарантии.

СО СЦЕНЫ: ГАРДРЕЙЛ В КОДЕ, А НЕ В ПРОМПТЕ

• Кто и где: Маттиас Любкен, доклад «Piece of Pi: Embedding the OpenClaw Coding Agent in Your Product», AI Native DevCon 2026
• Что показали: LLM сама решает, какой тул позвать, — это неотчуждаемо. Но на before-tool-call и after-tool-result вешается своя логика. В кейсе с квотами после генерации черновика письма проверяется, что домен адресата принадлежит клиенту. Те же хуки используют для инъекции динамического контекста в результат тула.
• Цифры: цифр не назвали
• Что это меняет: Проверка перестаёт зависеть от того, послушалась модель инструкции или нет. Формулировка спикера: «мы не полагаемся на инструкции — мы проверяем».

Третье — форма встраивания. Любкен показывает три уровня, которые переиспользуют одни и те же тулы и контекст:

Уровень	Для кого	Что видит пользователь
Стройный автоматический воркфлоу	обычный пользователь	результат, агента не видно
Полноценный чат со встроенным кодагентом	power-юзер	«Cowork внутри вашей системы»
Промежуточный слой в духе MCP UI / MCP apps	между ними	вместо сырого JSON от тула «поиск запчастей» рендерится карточка, где можно поправить количество

Третий уровень — самый интересный для продуктовой команды, потому что он не требует от пользователя ни доверия к автоматике, ни навыка работы с чатом.

Отдельно стоит забрать себе идею сессии как дерева событий. В Pi (агент Марио Зехнера, на котором всё построено) сессия — это JSONL-лог событий с древовидной структурой: можно откатиться из тупиковой ветки и попробовать другой путь, сохранив контекст; есть кастомные сообщения, видимые или невидимые для модели. Раз на каждый кейс есть аудит-лог, на нём можно запускать других агентов, переигрывать шаги и вытаскивать повторяющиеся паттерны в skill, вокруг которого потом строятся evals. То есть лог из отладочного артефакта превращается в источник продуктовых улучшений.

Сам Pi при этом определяется через отсутствие: ни MCP-серверов, ни субагентов, ни permission-попапов, ни plan mode, ни встроенных todo, ни фонового bash. Всё это агент дописывает себе сам — «сделай расширение, которое спрашивает разрешение при пуше в main», и получаешь TypeScript-хук pre-push guard плюс markdown-описание. Реакция Любкена: «внезапно я поменял своего агента так, чтобы он работал ровно как мне нужно». Финальный тезис доклада — malleable software (со ссылкой на эссе Ink & Switch): софт должен быть не набором предопределённых сценариев, а экосистемой мелких инструментов, которые пользователь адаптирует с минимальным трением. Метафора эссе — навороченная овощерезка против ножа.

Кейс: агенты на канвасе

Стив Руис, founder и CEO tldraw, в докладе «Agents on the canvas with tldraw» проходит ту же дорогу с другого конца — от эксперимента к продукту.

Началось всё в ноябре 2023 с Make Real: первый доступ к GPT-4 with vision, нарисованный от руки макет превращается в работающий прототип. Ключевое открытие было не в этом, а в следующем шаге — можно рисовать поверх уже сгенерированного сайта и отправлять новый скриншот обратно, и аннотация становится частью промпта. Идею подхватили клиенты SDK: Google Stitch, Luma, Runway. Условия тогда: API давал около 30 запросов в день и был, по словам Руиза, «до смешного дорогим».

Дальше канвас показал себя как среда для промптов вообще. В tldraw computer каждая нода — маленький промпт со своей структурой, входы — то, что в неё указывает; получается направленный граф. То, что тяжело в одномерном чате — ветвление, повторяемые многошаговые цепочки, динамическая сборка контекста, — на канвасе тривиально, а ремикс сводится к «поменяй вход и перезапусти».

Самая содержательная часть — про форму присутствия агента. Killer feature канваса это коллаборация, отсюда вопрос «почему бы не посадить туда и агента». Сначала скопировали сайдбар Cursor: полный agent-loop с ревью и accept/reject. Не понравилось — агент оказался «заперт в сайдбаре». Тогда сделали fairies: инстансы того же харнесса живут прямо на канвасе как объекты — их видно, их можно таскать, с ними можно разговаривать, видно состояние (думает, ревьюит, работает). И агент создаёт те же примитивы, что и человек: «мы говорим на одном языке». Цифры: до 10 человек в одном документе, у каждого по 3 феи — около 30 агентов одновременно; сами fairies бесплатны, bring your own token.

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

Чего это стоило — Руиз рассказывает честно, и это самое полезное:

• Демо оркестрации провалилось прямо на сцене: агенты не распознали выигрыш и «победили все».
• Крупные пространственные перемещения даются агенту хуже всего — передвинуть кота на стол он не может.
• Позиционные правки не работают и в 2026-м: «поменяй кнопки местами» не отработало, а вот цвет — отработал. Это ровно то же ограничение, что было в Make Real.
• Code mode быстрым не бывает. В десктоп-версии с локальным MCP-сервером решили не плодить тулы, а открыть агенту прямой доступ к editor API (editor.selectAll и подобное). Результат Руиз называет «безумным метапрограммированием поверх канваса»: агент делает интерактивными фигуры, которых нет в примитивах — высота круга влияет на рост человечка, кнопки начинают работать, — фактически инжектя скрипты в приложение. Его же оценка кода: «Python шаблонизирует JavaScript внутри bash-вызова — самый странный код, что я видел в жизни. Но он работает». И это медленно.

И рамка, которую стоит применять ко всем агентным демо, включая чужие. Руиз прямо говорит, что все его демо «очень широкие и довольно бессмысленные»; клиенты SDK берут ту же идею, сужают её до конкретного типа пользователя и продукта, поднимают качество — и она начинает работать. Ценность появляется при сужении, а не при расширении.

Сюда же примыкает наблюдение Трилофа из Adobe: раз софт стало очень легко строить, он становится расходником. Интерфейс, который живёт ровно одну презентацию, и его не жалко — слайд с three.js в его докладе был именно таким одноразовым приложением, сгенерированным на лету. Его формулировка: «он не просто становится лёгким в постройке — он становится одноразовым».

Цена галлюцинаций

Всё вышеописанное означает, что твой продукт слушается агента. Дальше — про то, во что это обходится, когда агент ошибается уверенно.

СО СЦЕНЫ: ПАКЕТ, КОТОРОГО НЕ БЫЛО, ПОСТАВИЛИ 30 000 РАЗ

• Кто и где: Эндрю Оутс, distinguished engineer в Snyk, доклад «MCP Mayhem: Fun Ways AI Agents Write Bad Code»
• Что показали: Модель регулярно придумывала несуществующий пакет huggingface-cli. Исследователь зарегистрировал это имя в реестре и стал смотреть, что будет.
• Цифры: больше 30 000 установок за три месяца
• Что это меняет: Агенты у разных людей раз за разом галлюцинировали одно и то же имя и ставили пакет. В нём могла быть кража локальных креденшелов или рабочая функциональность с удалённо эксплуатируемой уязвимостью. Галлюцинация перестала быть индивидуальной ошибкой и стала воспроизводимой точкой входа: чтобы атаковать, достаточно узнать, что придумывает модель, и занять это имя первым.

Оутс раскладывает риски на три класса, и третий — новый:

Класс	Пример	Что под угрозой
Doom spiral	агент удаляет код, чтобы «программа запускалась»	продуктивность
Галлюцинации пакетов	huggingface-cli, 30 000 установок	безопасность сгенерированного кода
Опасное действие без понимания последствий	агент Replit, стёрший продовую базу и красноречиво извинившийся постфактум	безопасность самого процесса разработки

Третий класс, настаивает Оутс, надо защищать отдельно от артефакта — это не то же самое, что проверять код на выходе. Его резюме: «не оставляйте их наедине с детьми или продовыми данными».

Из этого же доклада — тезис, который стоит держать при проектировании: среда агента не должна совпадать со средой разработчика. Сейчас мы даём агенту тот же доступ, что себе: те же CLI, тот же код, ту же документацию, тот же терминал. Оутс считает это неисследованной ошибкой — агенту нужен собственный, отличный и куда более ограниченный вид на мир. Это перекликается и с мотивацией Трилофа (браузер как контейнер), и с подходом Любкена к границам.

Границы Любкен проводит двумя уровнями, и оба в коде, а не в тексте промпта:

1. Дизайн тулов — что вообще возможно. Распространённая ошибка: написать в инструкциях «не используй этот тул», но выдать его. Дали тул — считай, что он будет вызван. Его формулировка: «не удивляйтесь, что агент удалил базу». В его кейсе граница проведена на уровне возможностей — система умеет только черновики писем и физически не умеет их отправлять.
2. Хуки-валидаторы поверх результатов. Отвечая на вопрос из зала о безопасности malleable software («power-юзеры правят расширения — а что с безопасностью, по глупости или со зла?»), он говорит: свобода агента и пользователя всегда остаётся внутри заданных границ. LLM может звать тулы как угодно, но множество последствий очерчено заранее.

Стоит понимать и то, чего эти границы не дают. Трилоф демонстрирует Slick Start, который находит запущенные Electron-приложения, перезапускает их в debug-режиме и инжектит свой бутстрап — так агент дистанционно рулит Slack, Teams, почтовым клиентом. Slack поддался тривиально; тяжелее всех оказался Claude Desktop, где electron fuses убивают бинарь при попытке подключиться к debug-порту (обходится патчем бинаря и снятием fuses). Его реакция — «это же вайб-кодед приложение, как у них такие защиты?» — объяснилась просто: автор Electron работает над десктопным Claude. Вывод для нас прямой: «агент в браузере» не является настоящей песочницей для остальной системы.

И последнее — про слепые пятна. Роксана Фишер, CEO anyshift, в докладе «Your Infra is a Graph» показывает, что агент, не видящий живого состояния, уверенно генерирует фикцию. Просьба «сделай VPC peering в Terraform»: Copilot знает best practice и строит динамические зависимости, но не знает, где лежит существующий main VPC, — и досоздаёт новый. Формально валидно, практически бесполезно. В живом демо Cursor нашёл небезопасных IAM-пользователей, определённых в репозиториях, но пропустил temp-пользователя с administrator access, созданного кликами в консоли и нигде в коде не описанного. Всё, что заведено мимо кода, для кодового агента просто не существует. MCP-серверы (например, AWS) частично закрывают дыру и легко внедряются внутри команды, но дают фрагментированную картину без связей и упираются в rate limits при большом числе вызовов.

Коротко

• Архитектура — это набор тулов, а не воркфлоу (Любкен). Три узких тула плюс контекст в AGENTS.md закрыли реальный бизнес-кейс.
• Гарантии живут в хуках, а не в промпте: before-tool-call и after-tool-result проверяют то, на что нельзя полагаться в инструкции.
• Форма присутствия агента важнее его силы: сайдбар запирает агента (Руиз), объект на канвасе или карточка вместо сырого JSON — работают. И ценность появляется при сужении демо, а не при расширении.
• Галлюцинация — это уже вектор атаки: выдуманный huggingface-cli набрал больше 30 000 установок за три месяца (Оутс, Snyk).
• Дал тул — считай, что он будет вызван. Границы проводи возможностями системы (только черновики, отправлять нечем) и отдельной, более узкой средой для агента.

Что делать сейчас

Если свести восемь докладов к одному утверждению, оно будет таким: у твоего продукта появился второй пользователь, и он уже приносит решения о выборе стека. Билманн из Netlify измеряет это в сайтах — около 10 000 в день создаются непосредственно кодагентами против чуть больше тысячи в день в 2023-м, когда единственным каналом был custom GPT в GPT store. Фиртман измеряет в секундах и токенах — 5–10 секунд между скриншотом и кликом, за которые JavaScript успевает передвинуть кнопку, и весь цикл оплачивается заново.

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

Порядок действий

Чек-лист ниже отсортирован по принципу «сначала то, что окупается независимо от судьбы WebMCP». Первые два блока имеет смысл пройти всем; третий — если у тебя формы и транзакции; четвёртый — если ты сажаешь агента внутрь продукта.

БЛОК 1. БАЗА — окупается независимо от стандартов

• Проверь, что видит агент без JS: чистый CSR = «не могу прочитать эту страницу» для значительной части агентного трафика (Фиртман)
• Разметка семантична? DOM после React — «сотня div'ов», смысла не несёт
• Актуальная документация доставляется в контекст модели: llms.txt / cursor rules / MCP. Иначе агент строит по случайному устаревшему туториалу (Билманн)
• Сообщения об ошибках API технические, а не «что-то пошло не так»: какие аргументы неверны и почему — агент чинит вызов сам
• Регистрация перед первым действием убрана или отложена (паттерн deploy-then-claim: живой URL + claim-ссылка)

БЛОК 2. ИЗМЕРЬ, ПРЕЖДЕ ЧЕМ ЧИНИТЬ — один вечер

• Тест пяти пользователей на агенте: дай ему свой CLI и API, попроси сделать задачу, не подсказывай. Запиши, какие несуществующие фичи он придумал и какие эндпоинты понял неправильно (Билманн)
• Добавь тул «оставь фидбек» и собери agent NPS — у Билманна на его MCP-сервере он равен 50
• Посмотри в логи: сколько запросов к тебе уже идёт от агентов и в каких паттернах

БЛОК 3. WEBMCP — если у тебя есть формы и транзакции

• Убедись, что юзкейс есть: «нет форм на сайте — нет юзкейса» (контентным сайтам это по большей части бессмысленно)
• Выбери ОДНУ высокоценную страницу или состояние
• Выставь ТОЛЬКО диагностические тулы: список ошибок сессии, «опиши текущий вид», run diagnostics — они ничего не меняют
• Прогони вручную из Claude Code / Cursor / Codex через Chrome DevTools MCP; смотри, какие тулы агент выбирает и с какими аргументами
• Только после этого — действующие тулы. Правила: одна цель на тул, без пересечений; описание для модели; строгая валидация; маленький выход; регистрация по состоянию, не всё на загрузке
• Покрой тулы юнит-тестами — это новый публичный контракт
• На платных и необратимых действиях — подтверждение через браузер, а не через доверие к агенту
• Подпишись на события tool-activated / tool-cancel: впервые можно узнать, что тобой управляет агент, и перестроить UI

БЛОК 4. АГЕНТ ВНУТРИ ПРОДУКТА

• Проектируй набор тулов, а не воркфлоу; определения узкие и раскрывающие намерение (Любкен)
• Границу проводи возможностями: если отправлять письма нельзя — пусть система физически умеет только черновики
• Дал тул — считай, что он будет вызван. «Не используй его» в инструкции не работает
• Гардрейлы — в хуках before-tool-call / after-tool-result, не в промпте
• Секреты мимо контекста: агент оперирует ИМЕНЕМ токена, а не значением (приём Трилофа)
• Среда агента ≠ твоя среда: более узкий доступ, отдельный вид на мир (Оутс)
• Пин зависимостей и проверка существования пакетов — галлюцинация имени пакета это вектор атаки, а не опечатка
• Сессии логируй деревом событий: на аудит-логе потом строятся skills и evals

Что здесь молодое и переделают

Оговорка обязательная, и лучше её проговорить самому, чем услышать на ревью.

WebMCP — эксперимент, а не стандарт. Фиртман говорит об этом прямым текстом: спецификация обсуждается, что-то добавят, что-то выкинут. Предложен он командой Chrome и целится в их же agent mode; ни OpenAI, несмотря на спонсорство OpenClaw, ни Anthropic — авторы самого MCP — в обсуждении в W3C пока не участвуют, для них веб-стандарты новая территория. Сегодня это Chrome-only под флагом, origin trial открылся в Chrome 149 — буквально на следующий день после доклада. В headless-браузерах не работает вовсе, в Puppeteer доступно под экспериментальным флагом. Имя API в двух выступлениях одного и того же спикера разное — document.modelContext и navigator.modelContext, — и это неплохой индикатор стадии.

Слой авторизации не готов ни у кого. MCP, по оценке Билманна, выиграл слой стандарта, но «история с авторизацией там всё ещё сырая и мутная». Он же перечисляет открытые вопросы, на которые ни у кого нет ответа: как выставлять tool use через сам веб, а не через отдельные MCP-серверы; как дать более гранулярные паттерны доступа, чем позволяет текущий OAuth; как отдавать агентам платный контент так, чтобы это монетизировалось. Пока трение остаётся большим — «постоянно проходить OAuth десятком тулов, прежде чем агент вообще что-то сделает».

Индустрия одновременно открывается и закрывается. У Netlify AX-инструменты и блокировка AI-ботов едут параллельно, и блокировка — вторая по частоте просьба клиентов. Это не лицемерие, а признание того, что дешёвый структурированный доступ и неконтролируемый скрейпинг — разные вещи. Но означает это и то, что единой отраслевой позиции «пускать или не пускать» сейчас нет, и твоё решение будет твоим.

Демо врут в предсказуемую сторону. Руиз из tldraw сам называет свои демо «очень широкими и довольно бессмысленными» — работать начинает то, что клиенты SDK сузили до конкретного пользователя и продукта. У него же на сцене провалилась оркестрация фей, а позиционные правки не работают с 2023 года. Читая любое агентное демо, включая эту статью, держи поправку на широту.

Одна мысль на вынос

Если из всего списка выбирать одно действие, я бы выбрал не WebMCP, а тест пяти пользователей на агенте. Он бесплатный, занимает вечер и даёт то, чего не даст ни один чек-лист: список конкретных мест, где твой продукт непонятен новой персоне. После него станет очевидно, нужен ли тебе стандарт вообще — или сначала надо починить сообщения об ошибках и написать llms.txt.

А аргумент, ради которого стоит начинать раньше конкурентов, у Билманна сформулирован жёстче всего: через пару лет плохой AX обнулит хороший DX, потому что разработчик придёт к тебе через агента. Дифференциация пойдёт по вопросу «какой продукт предпочитает агент вашего пользователя», и отвечать на него будет не человек.