Книжный куб

Agent-first IDP: как платформы к агентам готовят бигтехи и облака (Рубрика #PlatformEngineering) Написал продолжение к эссе про внутренние платформы. В прошлый раз в тексте «IDP is Dead? Нет, умирает монополия GUI» я разбирал, почему внутренняя платформа теряет монополию своего GUI и превращается в платформу для агентов — слой возможностей, к которому обращаются не только люди, но и агенты. Это было про «почему». Новый текст — про «как». И в новой статье я специально не ушёл в футурологию. Playbook собран на публичных инженерных материалах компаний, которые уже столкнулись с агентным потреблением платформ: внутренние платформы Block, Uber, LinkedIn, Spotify и доработки публичных облаков — AWS, Azure, Google Cloud. Логика простая: когда внутренние платформы бигтехов и облака независимо сходятся вокруг одних и тех же инженерных решений, это уже не мода, а новый слой платформенной архитектуры. Из чего этот слой складывается: - Уровни зрелости L0 → L4: от GUI-only до управляемой агентной поверхности; - Три слоя, которые легко перепутать: модельный шлюз, инструментальный шлюз и реестр возможностей; - Идентичность агента: агент — субъект доступа от имени пользователя, а не общий сервисный аккаунт «для AI»; - Уровни доверия: read → recommend → act; - Доменные агенты там, где сырой доступ к логам, IAM или SQL опасен; - Evals и телеметрия агентных сценариев вместо MAU портала; - Отдельная модель угроз: prompt injection, tool poisoning, data exfiltration и не только. В конце я привожу примерный квартальный план на 30/60/90 дней и список того, чего делать точно не стоит. Главный вывод такой: бигтехи и облака не дали готовую инструкцию, которую можно скопировать, но уже показали устойчивую архитектурную сходимость. Внутренним платформам не нужно изобретать этот путь заново — нужно признать, что их главный новый пользователь уже не открывает портал. Подробнее можно прочитать в моем блоге #AI #AI4SDLC #PlatformEngineering #Engineering #Architecture #Management