Глава 14. Платформенная команда и продуктовые команды¶

1. Почему агентная платформа почти всегда ломается не на коде, а на модели владения¶

В нашем сквозном кейсе поддержки это выглядит очень конкретно: агент уже существует, шлюз инструментов уже есть, трассы уже собираются, подтверждения уже встроены. Но как только начинается первый платформенный инцидент эксплуатационного уровня, оказывается, что главный вопрос звучит не “что сломалось”, а “кто именно обязан это чинить и менять общий слой”.

На раннем этапе все обычно выглядит просто: есть несколько энтузиастов, один-два агента, пара интеграций, быстрые эксперименты. Это нормально.

Проблемы начинаются позже:

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

То есть технически система может даже работать, но организационно она уже начинает расползаться.

2. Платформенная команда не должна забирать у продуктов все решения¶

Есть плохая крайность: платформенная команда пытается стать единственной точкой принятия любых решений об агентах.

Тогда получается:

• платформа становится узким местом;
• продуктовые команды теряют скорость;
• все изменения упираются в одну очередь;
• платформенный слой разрастается до неповоротливого комбайна.

Это нерабочая модель. Платформенная команда нужна не для того, чтобы писать все агентные функции самой, а для того, чтобы давать устойчивые общие слои и безопасные пути по умолчанию.

3. И обратная крайность тоже плохая: полный федерализм¶

Иногда компании идут в другую сторону: “пусть каждая команда сама решает, как ей строить агентов”.

Это быстро дает:

• несовместимые контракты;
• разную позицию безопасности;
• разное качество оценок;
• разную наблюдаемость;
• локальные платформы внутри каждой команды.

На короткой дистанции это выглядит как свобода. На длинной это почти всегда зоопарк.

4. Зрелая модель обычно выглядит как platform + product split¶

Хорошая операционная модель обычно делит ответственность примерно так:

platform team отвечает за:

• примитивы оркестрации;
• policy framework;
• контракты инструментов и capabilities;
• основу наблюдаемости и оценок;
• общие шлюзы;
• базовую модель безопасности.

product teams отвечают за:

• пользовательские workflows;
• продуктовые prompts и политики;
• доменную логику;
• критерии приемки успешной задачи;
• интеграцию платформенных примитивов в конкретный продукт.

flowchart LR
    A["Платформенная команда"] --> B["Рантайм, политики, наблюдаемость, шлюзы"]
    C["Продуктовые команды"] --> D["Пользовательские workflows, доменная логика, UX-исходы"]
    B --> E["Золотые пути и общие примитивы"]
    D --> E

5. Платформа должна давать golden paths, а не просто набор низкоуровневых деталей¶

Если platform team поставляет только “конструктор из запчастей”, продуктовые команды все равно начнут собирать системы по-разному.

Golden path обычно включает:

• базовый шаблон рантайма;
• готовые policy hooks;
• стандартный tracing/eval wiring;
• approved-паттерн шлюза инструментов;
• рекомендации по использованию памяти;
• дефолты раскатки и регрессии.

То есть хороший платформенный продукт помогает не только “мочь”, но и “делать правильно по умолчанию”.

6. Ownership должен быть явным на каждом слое¶

Очень полезно заранее разложить, кто владеет чем:

• кто меняет контракты платформы;
• кто утверждает новые write-capabilities;
• кто владеет схемами политик;
• кто отвечает за схему телеметрии;
• кто on-call за платформенные инциденты;
• кто решает, когда продукту можно отойти от golden path.

Если ownership размыт, почти любой инцидент превращается в длинный организационный пинг-понг.

6.1. Platform inventory тоже должен иметь владельца¶

Полезная мысль из Google здесь в том, что governance не заканчивается на policy framework. У платформы должен быть еще и явный inventory того, чем организация вообще пользуется.¹²

Минимально полезно видеть хотя бы:

• какие агентные рантаймы существуют;
• какие capabilities разрешены;
• какие шлюзы считаются approved;
• какие connectors и secrets используются;
• какие deviations активны;
• кто owner у каждого из этих объектов.

Если такого inventory нет, платформа почти неизбежно начинает жить в режиме слухов: кажется, что “все под контролем”, пока не случается инцидент и не выясняется, что никто не знает, какие именно агенты и инструменты вообще работают в production.

7. Не все отклонения от платформы нужно запрещать, но их нужно делать осознанными¶

Иногда продуктовой команде правда нужен special case:

• нестандартный workflow;
• отдельная capability;
• другой trade-off задержки и стоимости;
• экспериментальная раскатка.

Это нормально. Но разница между зрелой платформой и хаосом в том, что deviation:

• виден;
• обсужден;
• ограничен по blast radius;
• имеет owner;
• не становится тихим новым стандартом.

8. Пример governance policy для агентной платформы¶

Ниже очень практичный шаблон:

governance:
  platform_owned:
    - runtime_contracts
    - policy_framework
    - telemetry_schema
    - shared_tool_gateway
  product_owned:
    - workflow_logic
    - domain_prompts
    - task_success_criteria
  requires_platform_review:
    - new_write_capability
    - custom_policy_engine
    - telemetry_schema_change
    - direct_external_tool_access

Такой YAML не решает все организационные проблемы, но он очень хорошо снимает вечный вопрос “а кто вообще это должен решать?”.

8.1. Approved registry полезен не меньше, чем policy schema¶

Очень часто команды хорошо обсуждают policy, но почти не обсуждают registry. А именно registry отвечает на вопрос:

• что вообще считается platform-approved;
• что можно запускать без дополнительного review;
• что находится в exception zone;
• что уже должно быть выведено из эксплуатации.

Простой пример:

registry:
  approved_runtimes:
    - agent_runtime_v3
    - workflow_runtime_v2
  approved_gateways:
    - shared_tool_gateway
    - approval_gateway
  deprecated_patterns:
    - direct_prod_tool_access
    - local_policy_engine_without_audit

Такой registry не заменяет governance. Он делает governance исполнимым.

9. Платформа должна измеряться не числом фич, а снижением хаоса¶

Очень важно не попадать в ловушку vanity metrics вроде:

• сколько инструментов добавили;
• сколько MCP-серверов подняли;
• сколько продуктовых команд “подключились”.

Сильная платформа должна уменьшать:

• дублирование;
• число кастомных обходов;
• стоимость добавления нового workflow;
• время расследования инцидентов;
• число unsafe deviations.

Иначе ты можешь много строить, но не становиться системно лучше.

9.1. Continuous controls лучше разовых ревью¶

Еще одно практическое улучшение: рискованные изменения лучше ловить не только через ручные согласования, но и через continuous controls.

Например, система может автоматически проверять:

• не появился ли прямой доступ к инструменту в обход gateway;
• не подключен ли новый connector без owner;
• не ушел ли рантайм с approved template;
• не возник ли новый secret scope без review;
• не живет ли deprecated pattern дольше установленного срока.

Это важно, потому что platform governance почти всегда ломается не в момент красивой презентации архитектуры, а через месяцы тихих исключений и обходных путей.

10. Частые ошибки¶

Обычно проблемы повторяются:

• платформа становится узким местом для всех решений;
• продукты полностью обходят платформу;
• владение неясно;
• общие примитивы слишком низкоуровневые;
• нет процесса для deviations;
• дорожная карта платформы не связана с болевыми точками продуктовых команд.

Это приводит к классической развилке: либо платформа никому не помогает, либо продукты считают ее препятствием.

11. Быстрый тест зрелости для операционной модели платформы¶

Команде не стоит думать, что она уже решила проблему владения платформой, только потому, что создала platform team и задокументировала несколько правил ревью.

Более сильная планка такая:

• владение платформы и продуктов явны именно на том слое, где реально происходят инциденты;
• golden paths убирают хаос, а не просто публикуют общие детали;
• deviations видимы, имеют owner и ограничены по blast radius, а не терпятся по умолчанию;
• platform inventory и approved registry делают governance исполнимым;
• платформа измеряется снижением дублирования и обходов, а не театром вокруг adoption.

Если большинство этих условий не выполняется, у организации уже может быть платформенный ярлык, но реальной операционной модели платформы у нее пока нет.

12. Что сделать сразу¶

Сначала пройди по короткому списку и отдельно отметь все ответы «нет»:

• Ясно ли, что именно во владении platform team?
• Ясно ли, что остается за product teams?
• Есть ли golden path, а не только “набор возможностей”?
• Понятно ли, кто утверждает новые risky capabilities?
• Есть ли процесс для отклонений от стандартного пути?
• Уменьшает ли платформа реально число локальных реализаций рантайма?

Если на несколько вопросов подряд ответ “нет”, у тебя, скорее всего, уже не техническая проблема, а проблема организационного дизайна.

13. Что делать дальше¶

Сначала сделай ownership явным, а потом посмотри, как он превращается в golden paths, shared gateways и anti-zoo patterns.

Следующий естественный шаг в этой части: разобрать, как именно строить shared gateways, reusable templates и anti-zoo patterns, чтобы орг-модель не оставалась только на словах.

• Глава 13. Офлайн-оценки, онлайн-оценки и регрессионные шлюзы
• Глава 15. Золотые пути, общие шлюзы и антизоопарк-подходы
• Часть VI. Организационная модель
• Источники