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

Первая часть серии объяснила, чем агент отличается от человека как пользователь, вторая — как WebMCP меняет общение страницы с агентом. Здесь — что конкретно делать со своим продуктом.

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

Прежде чем что-то менять, полезно понимать, каким из пяти маршрутов агент доходит до твоего интерфейса. Фиртман в докладе «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 из первой части серии ровно про это: собственные хуки выкинули, загрузку данных перевели на Relay, где зависимости данных объявлены прямо в компоненте, — и LLM начала выдавать целые возможности с одного запроса (Билманн, со ссылкой на тред Марсело Терреро).

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

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

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

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

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

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

Дизайн инструментов — это дизайн 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; как отдавать агентам платный контент так, чтобы это монетизировалось; как выставлять собственных агентов наружу для чужих агентов.

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

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

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

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

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

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

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

Коротко

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