Agent-ready дизайн: как переделать SaaS-интерфейс под автономных AI-пользователей
AI-агенты перестали быть чат-ботами — они заходят в ваш SaaS, нажимают кнопки и заполняют формы. Но большинство продуктов к этому не готовы. Разбираю конкретные ловушки интерфейсов и архитектурные решения.
Новый тип пользователя, которого вы не проектировали
Последний год изменил правила. Claude получил Computer Use, GPT-4 работает через браузер, агенты навигируют по интерфейсам, кликают кнопки, заполняют формы, завершают рабочие процессы. Ваши клиенты уже начали отправлять AI-агентов выполнять задачи в вашем продукте. Не через API — через обычный UI.
И здесь начинается проблема: ваш SaaS почти наверняка сломан для агентов. Не потому что он плохо сделан — просто никто не проектировал интерфейс для нечеловеческих пользователей.
Я столкнулся с этим на практике, когда запустил агента в собственный продукт. Агент останавливался на совершенно нормальных экранах загрузки и спрашивал: «Это сломано?». Skeleton-лоадеры, которые для человека — привычный индикатор загрузки, для агента выглядели как пустой экран с ошибкой.
Это не баг конкретного агента. Это системная проблема дизайна.
Семь ловушек, которые ломают AI-агентов
1. Skeleton-лоадеры = пустое состояние
Человек видит серые прямоугольники и понимает: данные загружаются. Агент видит DOM без контента и решает, что страница пустая или сломана. Он либо уходит, либо начинает повторять действие, создавая каскад ненужных запросов.
Решение: Добавьте ARIA-атрибуты aria-busy="true" на контейнеры с загрузкой. Включите текстовые индикаторы состояния в DOM, а не только визуальные анимации. Агенту нужен машинно-читаемый сигнал, что контент ещё не готов.
2. Автосохранение на каждое нажатие клавиши
Большинство SaaS-продуктов реализуют автосохранение с debounce в 300–500 мс. Агент вводит текст целиком за миллисекунды. Результат: десятки промежуточных сохранений, каждое из которых может триггерить вебхуки, пересчёт зависимостей, отправку уведомлений.
Решение: Реализуйте явный сигнал «ввод завершён» — кнопку сохранения или API-эндпоинт для batch-обновления. Для автосохранения увеличьте debounce для сессий, идентифицированных как агентные, или добавьте HTTP-заголовок X-Agent-Session, чтобы бэкенд переключал стратегию.
3. Переключатели воркспейсов
Одно нажатие на workspace switcher меняет весь контекст: данные, права, проекты. Человек делает это осознанно. Агент может переключить воркспейс случайно, а потом не понять, почему исчезли нужные данные.
Решение: Привяжите воркспейс к URL (поддомен или path). Если агент работает с конкретным проектом, URL должен однозначно определять контекст. Глобальные переключатели без отражения в URL — антипаттерн для agent-ready дизайна.
4. OAuth-попапы в новых окнах
OAuth-флоу стандартно открывает popup. Агент работает в одной вкладке — он физически не может взаимодействовать с popup-окном. Авторизация через сторонний сервис становится тупиком.
Решение: Поддержите OAuth redirect в той же вкладке как альтернативу popup. Для агентных сессий — предоставьте механизм pre-authorized токенов или сервисных аккаунтов.
5. MFA, которую агент не может пройти
TOTP-коды, SMS, push-уведомления — всё это требует человека. Агент не читает SMS с телефона и не нажимает «Подтвердить» в приложении-аутентификаторе.
Решение: Внедрите API-ключи или service tokens как альтернативный метод аутентификации для автоматизированных сессий. Это не ослабляет безопасность, если реализовано с правильными скоупами и ротацией.
6. Асинхронные процессы без статуса
Генерация отчёта занимает 3 минуты. Человек ждёт или переключается на другую вкладку. Агент видит ту же страницу без изменений и решает, что процесс завис. Он может повторить запрос, создавая дубликаты, или бросить задачу.
Решение: Любой асинхронный процесс должен возвращать машинно-читаемый статус: pending, processing, completed, failed. Идеально — через polling-эндпоинт или элемент в DOM с обновляемым атрибутом data-status.
7. Кнопки «Подтвердить», которые стоят денег
«Запустить рекламную кампанию», «Отправить 10 000 писем», «Обновить тарифный план» — одно нажатие запускает платную операцию. Без дополнительного подтверждения. Агент нажимает кнопку, не понимая финансовых последствий.
Решение: Для необратимых и платных операций реализуйте двухшаговое подтверждение с явным отображением последствий в DOM. Добавьте атрибуты data-destructive="true" и data-cost="...", чтобы агент мог прочитать предупреждение до действия.
Operate.txt — robots.txt для эпохи агентов
Все описанные проблемы объединяет одно: агенту негде прочитать, как на самом деле работает ваш продукт. Документация написана для людей. Tooltips — визуальные. Onboarding — интерактивный.
Интересное решение, которое уже появилось в open source, — operate.txt. Это YAML-файл, размещённый по адресу yourdomain.com/operate.txt, который описывает продукт для AI-агентов: где расположены loading-состояния, какие действия необратимы, какие формы зависят друг от друга, какие процессы асинхронные.
По сути, это robots.txt нового поколения. Robots.txt говорил поисковым ботам, куда можно и нельзя ходить. Operate.txt объясняет AI-агентам, как работать с продуктом, не ломая его.
Подход к созданию: откройте свой продукт рядом с AI-агентом, попросите его пройти путь нового пользователя, наблюдайте, где он спотыкается. Эти точки — ваши приоритетные записи в operate.txt.
Архитектурный сдвиг: от UI-first к protocol-first
Глубже отдельных фиксов лежит архитектурный вопрос. Двадцать лет SaaS проектировался по модели «человек смотрит на экран». Каждое дизайн-решение оптимизировало визуальное восприятие: анимации, переходы, skeleton-лоадеры, drag-and-drop.
Agent-ready дизайн требует параллельного слоя: всё, что отображается визуально, должно быть читаемо программно. Не вместо — параллельно. Это не означает полный редизайн. Это означает:
- Семантический HTML вместо div-супа. <button>, <form>, <nav> — не для красоты, а для навигации агентов.
- ARIA-атрибуты как first-class элементы, а не compliance checkbox.
- Стабильные data-атрибуты для ключевых элементов интерфейса (кнопок, форм, статусов).
- Детерминированные URL — каждое состояние приложения должно иметь уникальный адрес.
- API как primary interface — UI становится одним из клиентов API, а не единственным входом.
Конкурентное преимущество сегодня, стандарт завтра
Сейчас agent-ready дизайн — это конкурентное преимущество. Если агент клиента успешно работает в вашем продукте, а в продукте конкурента зависает на skeleton-лоадере — клиент выберет вас.
Через два-три года это станет базовым ожиданием. Так же, как mobile-responsive дизайн сначала был преимуществом, потом стал стандартом, а сейчас его отсутствие — просто баг.
Продукты, в которых агенты работают надёжно, — это продукты, которые будут выбирать клиенты. Потому что следующий миллиард пользователей SaaS — это не люди. Это их агенты.
Пора проектировать для обоих.