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