Как сделать продукт более agentic за месяц: проверьте, действительно ли ваш API дружелюбен к агентам
Каждый B2B-CEO, с которым сейчас говорят, задает один и тот же вопрос в разных формулировках: «Как нам стать более agentic? С чего начать? Нужен ли Chief AI Officer? Команда forward-deployed engineering? Выезд по стратегии MCP?»
Ответ проще всего этого, и большинство вендоров его пропускают.
Убедитесь, что ваш API действительно, по-настоящему дружелюбен к агентам. Это передний край. Это не так сложно. И, скорее всего, у вас это … не так.
Звучит очевидно. Это не так. «Дружелюбный к агентам» в 2026 году означает очень конкретную вещь, и планка за последние 12 месяцев резко выросла. Большинство B2B-вендоров думают, что если их REST API возвращает JSON, этого достаточно. Это не так. Компании, которые сейчас уходят вперед, поставляют один и тот же набор вещей. Компании, которые тихо теряют клиентов из-за текучки в эпоху агентов, почти ничего из этого не поставляют.
Вот что сегодня на самом деле значит «по-настоящему дружелюбный к агентам», как оценить себя по этой шкале и как выглядит поставка таких возможностей в апреле.
Сдвиг: ваш API больше не интерфейс для разработчика. Это крайне важно принять
Главное, что нужно усвоить, прежде чем чек-лист начнет иметь смысл:
Основной потребитель вашего API — уже не человек-разработчик, пишущий детерминированный код. Это AI-агент, который рассуждает вероятностно, читает документацию во время выполнения, повторяет запросы при сбоях и выбирает, какой endpoint вызвать, на основе вывода модели. Автоматический бот-трафик впервые обогнал человеческий в 2024 году. Трафик агентов на базе RAG вырос на 49% в начале 2025 года. С тех пор рост только ускорился.
Это меняет все ниже по стеку. API, ориентированные на людей, оптимизируются под гибкость и выразительность. Агентов и то и другое наказывает. Перегруженные endpoints, которые обслуживают пять разных сценариев, заставляют агент угадывать. Нечеткие ошибки заставляют его повторять попытки. Скрытые побочные эффекты заставляют его нащупывать путь. Каждая догадка добавляет стоимость, задержку и вероятность сбоя. (techbytes.app)
Проектирование под агента означает устранение неоднозначности из контракта. Делайте возможности явными. Делайте состояние возобновляемым. Делайте мутации идемпотентными. Делайте ошибки исполняемыми.
Настоящий чек-лист: что есть у современного agent-first API
Ниже — то, что сейчас поставляют лидирующие компании. Используйте это как планку.
1. MCP Server, который оборачивает ваш REST API
Это самый большой сдвиг. MCP не заменяет ваш REST API. Это слой протокола поверх него, специально созданный для AI-агентов. Думайте о нем как о USB-C для агентов: один порт, много совместимых инструментов. (workos.com)
Сейчас почти у каждой крупной API-компании он есть. Stripe размещает удаленный MCP server на mcp.stripe.com с OAuth. GitHub, Supabase, Shopify и Twilio сделали то же самое. Агент подключается, находит доступные инструменты во время выполнения через tools/list и вызывает их через tools/call. Никакого кастомного кода интеграции под каждую модель. Никакого скармливания 500 страниц API-документации в контекстное окно. (stripe.com)
Если в 2026 году у вас нет MCP server, для агентного слоя вы фактически невидимы.
2. Agent Toolkit / SDK для основных agent-фреймворков
Одного MCP недостаточно. Серьезные API-компании теперь поставляют agent SDK для тех фреймворков, в которых реально строят агентов. Agent Toolkit от Stripe работает с OpenAI Agents SDK, LangChain, Vercel AI SDK и CrewAI. Python и TypeScript. Предсобранные функции вроде create_payment_link или create_subscription, которые LLM может вызывать напрямую через function calling. (stripe.com)
Если фаундер, строящий агента, может установить ваш SDK, вставить один import и заставить агента сделать осмысленное действие за 10 строк кода — вы выигрываете. Если ему нужно час читать документацию, вы проигрываете.
3. Машиночитаемое обнаружение возможностей в /.well-known/ и /llms.txt
Агенты должны находить ваши возможности без участия человека. Формируется такой паттерн:
- /llms.txt — краткая Markdown-карта вашего сайта и документации
- /llms-full.txt — полная документация в виде одного Markdown-файла, который агент может получить за один запрос
- /.well-known/skills/index.json — каталог «skills» (пакетов Markdown-инструкций) о том, как правильно использовать ваш API
- Актуальная, проверенная OpenAPI-спецификация, которая соответствует реальности
Последний пункт — скрытый убийца. У 75% production-API endpoints не совпадают с их OpenAPI-спекой. (musketeerstech.com) Когда агент читает спецификацию, а API ведет себя не так, как в ней сказано, вы сжигаете его токены и его доверие.
4. Исполняемые ошибки, а не криптографические загадки
Это обманчиво важная вещь. Разница между удобными для человека и удобными для агента ошибками на реальном примере:
Традиционная ошибка:
{"error": {"message": "Model not found"}}
Ошибка, удобная для агента:
{
"error": {
"code": "model_not_found",
"message": "Model 'gpt5' not found",
"did_you_mean": "gpt-4o",
"suggestions": [{"id": "gpt-4o"}, {"id": "gpt-4o-mini"}],
"hint": "Use GET /v1/models to list all available models."
}
}
Один вендор сообщил, что после внедрения этого паттерна потраченные впустую токены у пользователей снизились более чем на 60%. Ошибки, ориентированные на агента, включают структурированные, машиночитаемые подсказки, которые позволяют агенту самокорректироваться без участия человека. did_you_mean, suggestions, hint. Это добавочные поля. Человеческие клиенты их игнорируют. Агенты используют их, чтобы восстановиться на следующем вызове, а не провалить весь workflow. (lemondata.cc)
5. Авторизация, которую агенты реально могут пройти
Аутентификация — самый большой отдельный источник трения для агентов, потребляющих API сегодня. Люди могут проходить OAuth-экраны согласия, решать CAPTCHA и завершать MFA-подтверждения. Агенты не могут делать ничего из этого. (apideck.com)
Что работает для агентов:
- API keys и bearer tokens. Просто, без интерактивного флоу, без browser redirects.
- OAuth 2.0/2.1 client credentials grant. Machine-to-machine. Client ID и secret обмениваются на токен. Без экранов согласия.
- Ограниченные API keys с гранулярными правами по отдельным tool. Ключи rk_* от Stripe позволяют точно указать, какие инструменты может вызывать агент. Если агенту нужно только читать данные, он не сможет писать.
Что не работает:
- Авторизация, требующая browser redirect
- MFA с участием человека в loop
- Тихие сбои авторизации (например, пробелы, ломающие credentials, без полезной ошибки)
- Отсутствие refresh tokens
6. Идемпотентные, возобновляемые мутации, безопасные для повторных попыток
Агенты повторяют запросы. Постоянно. Так они восстанавливаются после потери контекста и частичных сбоев. Если ваш POST /orders при повторном вызове с тем же payload создает дубли заказов, агент со временем начнет стоить вашему клиенту реальных денег.
Что нужно сделать:
- Каждый endpoint с мутацией принимает idempotency key
- Долгие операции экспонируют возобновляемое состояние
- Побочные эффекты точно описаны в схеме ответа
- Операции чтения явно помечены как read-only, чтобы агент понимал: повторять можно без дополнительной проверки
7. Webhook для каждого важного изменения состояния
Это базовый минимум, и все же половина B2B-инструментов в типичном стеке до сих пор работает через polling. Агенты могут компенсировать отсутствие некоторых функций. Они не могут компенсировать слепоту к изменениям состояния. Если единственный способ узнать, что что-то произошло, — опрашивать систему каждые 30 секунд, любой agent workflow поверх вашего API будет медленнее, дороже и менее надежным, чем должен быть.
8. Щедрые и наблюдаемые rate limits
Агенты делают больше запросов, чем люди. Одна задача пользователя может запускать 10–50 API-вызовов, пока агент планирует, повторяет попытки и проверяет результат. Если ваши лимиты были рассчитаны на трафик 2020 года, вы начинаете троттлить каждый agent workflow еще до старта.
Современный паттерн:
- Щедрые лимиты по умолчанию (думайте о порядке величины, а не о 20%)
- Заголовки ответа на каждом вызове, показывающие оставшуюся квоту и время сброса
- Отдельный Bulk / Export API для крупных чтений, не учитывающийся в интерактивных лимитах
- Понятные, пригодные к действию ответы 429, которые говорят агенту, когда повторить попытку
9. Документация, ориентированная на поведение, а не на структуру
Обычная API-документация объясняет, что делает endpoint. Документация, ориентированная на агента, объясняет, когда его использовать, как интерпретировать ответ и что делать, когда что-то идет не так. (musketeerstech.com)
Конкретные элементы:
- На каждой странице документации есть кнопка «Copy for LLM» и Markdown-версия (паттерн Stripe, который уже широко распространен)
- Короткие, единообразные примеры на Python, TypeScript и хотя бы один curl
- Явные подсказки выбора: когда использовать это, а когда то
- Changelog, который реально поддерживается
10. Каталог skills для агентов
Это самый новый элемент и тот, о котором большинство команд еще не слышали. «Skills» — это пакеты Markdown-инструкций, которые учат агента точно, как решать конкретную задачу с вашим API. Stripe поддерживает публичный каталог по адресу docs.stripe.com/.well-known/skills/index.json. (stripe.com)
Когда агент сталкивается с работой, относящейся к skill, он загружает контекст этого skill и действует по вашим предметным best practices вместо общих догадок. Simon Willison называл Skills «возможно, более важной вещью, чем MCP». (apideck.com)
Практический эффект: ваш API перестает быть меню endpoints и становится набором предписанных workflows. Именно такой уровень читаемости нужен агентам.
Один тест, который показывает ваше положение: спросите своего агента
Если собрать все это вместе, для вашего API в 2026 году есть простой и честный тест:
Откройте Claude Code или Cursor. Укажите URL вашей документации. Скажите: «Построй рабочую интеграцию, которая делает X end-to-end, используя только публичную документацию».
Посмотрите, что произойдет.
- Если агент выполняет задачу за одну-две попытки, ваш API готов к агентам.
- Если агент пять раз повторяет попытку, упирается в недокументированные edge cases, не может разобраться с авторизацией или сдается, вам есть над чем работать.
Вот это и есть планка. Не «сможет ли опытный senior engineer в конце концов заставить это работать». А «сможет ли frontier model, имея только вашу документацию, заставить это работать с первой попытки».
Потому что именно так все чаще принимаются решения о покупке. Первый «разработчик», который оценивает ваш продукт, — не человек. Это агент, действующий от имени человека и решающий, стоит ли ваш API интеграции или конкурент в соседней вкладке проще.
Три живых вендора в нашем стеке. Один прошел, один еле-еле, один провалился
Теория — это хорошо. Давайте посмотрим, как этот чек-лист выглядит на трех реальных продуктах, которыми наша команда из трех людей и 20 агентов пользуется каждый день.
Salesforce. Прошел.
Мы используем Salesforce headless. Никто в SaaStr туда не логинится. Это делают агенты. 10K (наш AI VP of Marketing) непрерывно получает данные о pipeline в реальном времени, данные по кампаниям, статус спонсоров, выручку и поток лидов. Qbee (наш AI VP of Customer Success) управляет более чем 100 спонсорами через тот же API. Qualified, Agentforce, Momentum, Artisan, Monaco — каждый агент, которого мы запускаем, читает и пишет записи Salesforce без браузера.
Почему это работает:
- REST API зрелый, хорошо документированный и последовательный. Объекты можно запрашивать так же, как и последние 15 лет.
- Webhooks действительно работают для каждого значимого изменения состояния.
- Rate limits достаточно щедрые, чтобы постоянный polling от полудюжины агентов не приводил к троттлингу.
- Salesforce Headless 360 был запущен на TDX в этом месяце. Более 100 новых agent tools, фонд партнеров на $50M, MCP integration. Самый большой архитектурный сдвиг платформы за 27 лет.
- Agentforce дает вам нативный runtime для агентов внутри платформы.
Marc построил компанию API-first еще до того, как это стало мейнстримом. В эпоху агентов Salesforce не теряет свою силу, а дорастает до нее. По нашему 10-пунктовому чек-листу Salesforce набирает 8 или 9 баллов. Прошел.
Bizzabo. Еле-еле.
Bizzabo ведет логистику для SaaStr Annual, Europa и наших AI-ивентов. Регистрация. Данные участников. Сканирование бейджей. Расписания. 10K вытягивает данные регистрации и участников из Bizzabo через API, чтобы запускать кампании.
Еле-еле.
API работает. Существенно его не обновляли много лет. Rate limits рассчитаны на мир, где платформу, возможно, тронули бы три разработчика. Неполная документация. Устаревшие endpoints. Нет MCP server. Нет llms.txt. Нет agent toolkit. Покрытие webhook выборочное. Ответы об ошибках — общие.
Но данные он отдает. Вызовы не падают молча. Авторизация работает. Достаточно API читаемо, чтобы мы могли скормить его Claude и, если набраться терпения, получить работающую интеграцию на выходе.
Вот как выглядит «еле-еле прошел» в 2026 году. API — реликт, но рабочий реликт. По чек-листу Bizzabo набирает, возможно, 3 из 10. C-minus. Единственная причина, по которой мы еще не ушли, — переключаться между платформами для ивентов посреди года больно, и честно говоря, большинство альтернатив не особенно лучше. Но каждый квартал без модернизации повышает цену пребывания.
Marketo. Провал.
Теперь переходим к тому, что ломает нас уже несколько месяцев.
Adobe берет с нас $60K в год за Marketo. В 2026 году. Вот что этот API реально делает по сравнению с чек-листом:
- MCP server: нет.
- Agent toolkit / SDK: нет.
- llms.txt: нет.
- Webhooks: фактически нет. Все основано на polling.
- Rate limits: враждебные. Однозначное число bulk exports в день. Достигли потолка — и до завтра все.
- Хранение логов: 90 дней. Все, что старше, исчезает.
- Auth: сломан. Нет refresh tokens. Пробелы в credentials молча ломают аутентификацию без полезной ошибки.
- Агрегации: бесполезны. Counts API не может ответить на базовый вопрос «сколько людей сейчас в этом списке».
- История: максимум 6 месяцев. Полная синхронизация наших собственных данных занимает несколько дней из-за ограничений по rate limits.
- Документация: устаревшая, человеко-ориентированная, без LLM-оптимизированного представления.
По чек-листу Marketo набирает 0 из 10. Провал.
История Marketo — это история очень многих устаревших B2B-вендоров прямо сейчас. Возможно, хотя бы частично, это и про вас
Вот момент, когда для нас все стало особенно реальным.
Ссылка для отписки в Marketo в наших рассылках была сломана больше двух недель. Это нарушение CAN-SPAM по самой базовой функции, ради которой вообще существуют email marketing platforms.
Мы хотели, чтобы наш агент диагностировал проблему, завел тикет, дожал поддержку Marketo и внедрил исправление. Обычный workflow агента в 2026 году.
Что произошло на самом деле: мы созвонились с их engineering team, они свалили вину на Salesforce, потом на нас, а затем так и не взяли обязательство что-то исправить. Мы сдались и за полдня собрали замену unsubscribe flow на Replit.
Вывод не в том, что «Marketo плохой». Плохих продуктов достаточно. Вывод в том, что агент не смог нам помочь, потому что API Marketo не позволяет агенту действовать. Нет пригодного API-пути для диагностики. Нет webhook, на который можно было бы опереться. У 10K или Qbee нет даже способа увидеть проблему, не то что разрулить ее. Нет MCP server, к которому агент мог бы обратиться. Нет каталога skills, который подсказал бы агенту, как работать с эскалацией.
Adobe до сих пор продает и оценивает Marketo так, как будто на дворе 2019 год. Продукт построен для мира, где люди с большими ops-командами медленно кликают по dashboards и эскалируют проблемы людям у вендора. Этот мир заканчивается. У SaaStr он уже закончился.
Причина, по которой мы почти полностью перенесли функциональность Marketo в Salesforce, не в том, что у Salesforce лучше набор функций. А в том, что у Salesforce намного более сильный и дружелюбный к агентам API. Когда вы перестраиваете workflows на платформе, с которой ваши агенты действительно могут работать, в какой-то момент вы понимаете, что платите $60K в год за продукт, который вам больше не нужен.
Это и есть новая модель B2B churn. Не сравнение функций. Сравнение agent-operability. И устаревшие вендоры тихо проигрывают — один перенос workflow за другим — еще до того, как это попадет в отчет по churn.
Выполните все 10 пунктов. Сделайте свой API по-настоящему, полностью agent-first. В этом месяце
Нет, вы не можете растянуть это на два квартала. Сейчас Q2 2026.
MCP — публичный стандарт уже 17 месяцев. В декабре Anthropic передала его в Linux Foundation. OpenAI объявила Assistants API устаревшим. Salesforce только что выпустила Headless 360. У Stripe есть каталог skills, MCP server, agent toolkit для четырех разных фреймворков и llms.txt в корне сайта. В production уже более 5,000 MCP servers. Более 844,000 сайтов уже выложили llms.txt.
Каждый ваш клиент, который запускает агентов в production, уже оценивает ваш API по этому чек-листу — говорит он вам об этом или нет. Те, кто оценивает вас плохо, не будут открывать тикет в поддержку. Они перестроят ваши workflows на платформе, которой реально можно управлять агентами, а потом уйдут от вас через шесть месяцев — так же, как мы уходим от Marketo.
> Salesforce только что запустила Headless для AI-агентов. Мы уже живем в этом режиме 6 месяцев.
Материал — перевод статьи с английского.