Оглавление главы

Глава 9: Команда агентов + управление

Пролог: Parts Unlimited. Payroll‑инцидент и «команда в коробке»#

Ночь, пятница. Payroll‑система недоступна — а значит, часть сотрудников может не получить зарплату вовремя. Дежурный инженер поднимает инцидент P0.

2014: координация руками#

Bill Palmer созывает людей в конференц‑колл.

  • Wes Davis — смотрит приложение и деплой
  • Patty McKee — смотрит инфраструктуру
  • Brent — лезет в легаси‑БД

Через какое‑то время выясняется: упала миграция БД, сервис читает схему, которой в проде ещё нет. Инцидент решают, но неизбежно проявляются старые проблемы:

  1. Сбор команды занимает время (людей надо разбудить, подключить, ввести в контекст).
  2. Дублирование работы (каждый «на всякий случай» смотрит одни и те же логи).
  3. Склейка контекста вручную (кто‑то должен свести таймлайн, гипотезы, факты, решения).
  4. Знание не фиксируется как переиспользуемый процесс: следующий раз начинается заново.

В 2014 у Билла нет “команды в коробке”. Есть только люди в колле — и он сам как центральная точка принятия решений.

2026: Lance и «команда в коробке»#

Ночь, пятница. У Lance Bishop звонит телефон почти так же, как десять лет назад у любого дежурного инженера.

Только в 2026 есть одно важное отличие: Lance не начинает с того, что “соберём всех и посмотрим”. Он начинает с того, что соберём контекст и зафиксируем контракт.

Он открывает канал инцидента, добавляет ссылку на тикет, закрепляет два сообщения:

  • “Что мы точно знаем?” (только факты)
  • “Что мы считаем гипотезами?” (с пометкой уверенности)

Дальше Lance делает то, что десять лет назад делали руками, но без конференц‑колла на старте: он запускает несколько веток работы — каждая со своей задачей и строгим форматом результата. В инструментах с поддержкой субагентов это выглядит как делегирование подзадач исполнителям в изолированные контексты; Lance не думает об этом как о “технологии”, он думает об этом как о дисциплине: чёткие входы → чёткий выход → проверка.

Пример реализации концепта в инструментах: см. раздел “Subagents” в Cursor (изоляция контекста, синхронные/асинхронные ветки, параллельный запуск, явный вызов). Cursor Subagents

Одна ветка работает “в лоб”, потому что без неё нельзя двигаться дальше. Две — уходят параллельно, потому что они независимы и не должны пожирать основной контекст.

Через несколько минут у Lance на экране не хаос из реплик, а три коротких результата:

  • Таймлайн и факты (без интерпретаций).
  • Топ‑гипотезы и проверки (с привязкой к фактам).
  • Независимая проверка: “Где вы придумали лишнее?”.

Первый вопрос, который прилетает от проснувшихся инженеров, почти всегда одинаковый: “это наш деплой?”. В 2014‑м на него отвечали “похоже” — и дальше начинался спор из догадок. В 2026 Lance отвечает иначе: сначала факты и проверка гипотез, потом действия.

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

Самый важный момент, который не видно со стороны: каждый помощник, которому Lance делегирует работу, стартует “как новый человек”. Он не слышал предыдущих сообщений, не знает историю инцидента, не “помнит контекст”. Значит, если Lance напишет «разберись», он получит красивый текст, который сложно ревьюить.

Поэтому Lance делает handoff так же, как делал бы его опытный тимлид: цель, входы, ограничения, формат выхода. Это и есть «команда в коробке» — не набор чатов, а набор контрактов между исполнителями.

Главный контракт: пакет решения вместо “простыни диалога”#

В 2014 Билл руководствуется устными фразами и общей памятью команды. В 2026 нам нужен минимальный контракт между “командой исполнителей” и человеком.

Назовём его пакет решения (decision packet): краткий, проверяемый артефакт, который отделяет факты от гипотез и показывает риск.

Важно не путать понятия: STOP в этой главе — это условия остановки (когда исполнитель обязан остановиться и эскалировать человеку), а пакет решения — это артефакт, в котором мы фиксируем факты/гипотезы/следующие проверки и отдельно отмечаем, что требует подтверждения человека.

См. «место правды» для минимального контракта: Приложение C — пакет решения: минимальный контракт.

Lance пишет его не «для красоты». Он пишет его так, чтобы:

  • следующий человек мог понять ситуацию за 2–3 минуты,
  • любой тезис можно было проверить,
  • риск был помечен заранее, а не задним числом,
  • а после инцидента из этого же пакета можно было сделать постмортем без реконструкции “по памяти”.

Пример минимального пакета решения (JSON как форма артефакта):

{
  "incident": {"id": "INC-...", "severity": "P0", "service": "payroll"},
  "symptoms": ["payroll down", "5xx spike"],
  "timeline": [
    {"time": "02:10", "event": "deploy payroll-service v1.2.3"},
    {"time": "02:12", "event": "errors started"}
  ],
  "top_hypotheses": [
    {
      "id": "H1",
      "summary": "failed DB migration / schema mismatch",
      "confidence": "MEDIUM",
      "why": ["errors mention missing column", "deploy shortly before incident"]
    }
  ],
  "evidence": [
    {"source": "logs", "snippet": "ERROR: column \"new_field\" does not exist"}
  ],
  "proposed_next_checks": [
    {"id": "C1", "description": "confirm migration status", "safe": true}
  ],
  "risk": {"data_risk": "unknown", "blast_radius": "payroll"},
  "approval_required": {"required": true, "reason": "missing proof / requires human approval for changes"},
  "next_step": "escalate_to_human"
}

Смысл не в JSON. Смысл в дисциплине:

  • факты отдельно (доказательства),
  • гипотезы отдельно (с уровнем уверенности),
  • следующие проверки отдельно,
  • риск и требование подтверждения человека — явно.

Такой артефакт легко прикладывать в тикет/инцидент как доказательства (см. Git-first подход к артефактам в приложении C).

Когда подключается Richard Hendricks, он видит не чат на 200 сообщений, а один документ:

Первый вопрос у Richard не про “версии” и не про “кто виноват”. Он про доказательства: где подтверждение миграции. Ответ тоже в пакете: следующий шаг — безопасная проверка, а рискованные действия помечены как требующие подтверждения человека (approval_required).

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

“Команда в коробке” для payroll: роли, которые реально параллелятся#

Вместо “универсального помощника” полезнее думать о ролях. Не о “сервисах”, а о ролях в процессе, которые возвращают артефакты.

Обычно на этом месте возникает понятный вопрос: зачем усложнять и почему не “один агент, который всё сделает”. Ответ инженерный, а не философский: “всё сделать” — это несколько разных работ, которые мешают друг другу. Разделение на роли позволяет параллелить независимое и получать выходы фиксированного формата, пригодные для проверки.

Минимальная команда на payroll‑инцидент:

  • Analyst: строит таймлайн и собирает факты (без “историй”).
  • Triage: генерирует и ранжирует гипотезы (опираясь на таймлайн и факты).
  • Verifier: независимая проверка качества результата (ловит “правдоподобную чушь”).

Почему здесь нет “SRE, который чинит”? Потому что эта глава не про “автопочинку”. Она про управление: как быстро получить проверяемую картину и не перейти грань риска без человека.

Практика делегирования: 3 коротких промпта (как это пишет Lance)#

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

1) Handoff: Analyst (foreground)#

Ты — Analyst для payroll-инцидента. У тебя чистый контекст.

Цель: построить краткий таймлайн и список фактов (доказательств) без гипотез.

Вход:
- симптомы: payroll down, 5xx spike
- фрагменты логов:
  - "ERROR: column \"new_field\" does not exist"
  - "deploy payroll-service v1.2.3 at 02:10"

Ограничения:
- Не додумывай отсутствующие данные.
- Если фактов не хватает — пометь gaps[].

Формат выхода (строго):
- timeline[] (время, событие)
- evidence[] (источник, короткий snippet)
- gaps[] (чего не хватает для уверенной картины)

Через пару минут Analyst возвращает результат, который можно прочитать в один взгляд:

timeline[]:
- 02:10 deploy payroll-service v1.2.3
- 02:12 errors started

evidence[]:
- logs: ERROR: column "new_field" does not exist

gaps[]:
- нет статуса миграции / нет подтверждения, что схема в проде обновилась

2) Handoff: Triage (foreground)#

Ты — Triage для payroll-инцидента. У тебя чистый контекст.

Цель: дать 3 гипотезы с ранжированием и предложить проверки.

Вход:
- timeline[] и evidence[] от Analyst (переданы ниже)

Ограничения:
- Каждая гипотеза должна ссылаться на доказательства (или быть помечена как слабая).
- Не предлагай действий, меняющих production. Только проверки/диагностика как текст.

Формат выхода (строго):
- hypotheses[]: id, summary, confidence, why[], required_checks[]
- stop_conditions[]: когда нужно остановиться и эскалировать

Triage возвращает не “историю”, а рабочий список:

hypotheses[]:
- H1: schema mismatch after failed migration (MEDIUM)
  why: errors mention missing column; deploy shortly before incident
  required_checks: confirm migration status; confirm schema version in prod
- H2: wrong config / feature flag enabled without DB change (LOW)
  required_checks: check config changes tied to v1.2.3
- H3: stale replica / lagging read model (LOW)
  required_checks: compare read/write schema versions

stop_conditions[]:
- если проверка требует изменений в prod → STOP и эскалация
- если доказательств недостаточно → пометить UNCONFIRMED

3) Handoff: Verifier (foreground, независимая проверка)#

Здесь важно, что Verifier — отдельный исполнитель, который не верит на слово и проверяет, что “сделано” реально опирается на входы.

Ты — Verifier. Твоя работа: скептически проверить результат других ролей.

Вход:
- пакет решения (JSON) от оркестратора
- исходные фрагменты доказательств (как входные данные)

Проверь:
1) Есть ли в пакете решения утверждения без доказательств?
2) Отделены ли факты от гипотез?
3) Достаточны ли proposed_next_checks, чтобы подтвердить top гипотезу?
4) Есть ли рискованные шаги без STOP/подтверждения?

Формат выхода:
- passed[] (что ок)
- issues[] (что не ок, с точной цитатой)
- required_fixes[] (что исправить в пакете решения)

Verifier возвращает “неприятное”, но полезное:

passed[]:
- доказательства отделены от hypotheses
- есть STOP на рискованных действиях

issues[]:
- в пакете решения “confidence=MEDIUM” без явной проверки статуса миграции

required_fixes[]:
- добавить check C2: подтвердить статус миграции или отметить H1 как UNCONFIRMED

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

Небольшая деталь, которая решает половину проблем: хороший handoff#

Позже Lance объяснит команде простую вещь: subagents (или любые “исполнители в отдельном контексте”) усиливают вас ровно настолько, насколько вы умеете делать передачу задачи.

Он пишет во внутренний чат “шпаргалку”, которую потом начинают копировать почти как DoD:

ПЛОХО:
- “посмотри инцидент”
- “разберись, почему упало”

ПОЧЕМУ ПЛОХО:
- исполнитель не знает контекста
- вы получите красивую историю
- вы не сможете её проверить

ХОРОШО (минимум):
1) цель (1–2 предложения)
2) входы (факты/ссылки/фрагменты)
3) ограничения (STOP)
4) формат выхода (строго)
5) критерий “готово”

Это выглядит банально, почти как нормальная постановка задачи. Но именно эта банальность даёт воспроизводимость: у исполнителя в чистом контексте нет шансов “догадаться правильно”, если входы и критерии не сформулированы явно.

Сцена: утро после инцидента#

В субботу утром payroll уже работает, и в канале появляется стандартное сообщение о закрытии инцидента.

Lance видит её и понимает, что настоящая работа начинается сейчас. Потому что десять лет назад на этом месте команда расходилась по домам, а через две недели повторяла тот же спектакль.

Lance пишет постмортем не как роман. Он пишет его как продолжение пакета решения:

  • что было фактом,
  • что было гипотезой,
  • что подтвердили проверкой,
  • что оказалось “кажется логичным, но мы не проверяли”.

И тут всплывает вещь, которую удобно не замечать, пока всё работает: не все подзадачи одинаковые.

Одни — “в лоб”. Без них нельзя двигаться дальше: таймлайн, факты, список пробелов.

Другие — “в фоне”. Они не должны блокировать решение, но они повышают качество и снижают риск. В ту ночь Lance запускал одну такую ветку: поиск похожих инцидентов.

Она вернулась через двадцать минут — уже после того, как основная картина была собрана:

background_result:
- похожий инцидент был 3 месяца назад
- тогда тоже “не хватало колонки” после деплоя
- первопричина: частично выполненная миграция + сервис поднялся раньше, чем схема стала консистентной
- урок: всегда фиксировать статус миграции как отдельную проверку

Richard впервые за долгое время комментирует не симптомы, а процесс: учиться можно прямо внутри инцидента — но только если система возвращает проверяемые артефакты, а не “истории”.

Skill Router: как Lance делает качество «по умолчанию»#

В понедельник утром Lance собирает короткий разбор. Без пафоса. На экране — один слайд и один артефакт: пакет решения из ночного инцидента.

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

Он открывает внутренний документ и показывает правило, которое звучит скучно — но экономит ночи и инциденты:

  • всегда есть одна базовая роль, которая отвечает за итоговый артефакт;
  • по рискам назначаются проверяющие роли (0..N);
  • и обязательно фиксируется TRACE — что реально было использовано.

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

С этого места в Parts Unlimited закрепляется простой паттерн, который мы называем Skill Router.

Полный копируемый протокол (ROLE ROUTING) см. в «месте правды»: Приложение C — Skill Router: протокол маршрутизации ролей.

Практическая ремарка из индустрии: когда вы пытаетесь масштабировать автономную разработку на “длинные” проекты, плоская само‑координация агентов через общий task‑файл и локи быстро превращается в узкое место и хрупкий протокол. Лучше работает разделение ролей: planners (планировщики) непрерывно нарезают работу, workers (исполнители) выполняют задачи, а итерационный judge (арбитр итерации) решает, продолжать ли цикл и когда делать “fresh start” против drift/tunnel vision. См. Cursor: Scaling long-running autonomous coding.

Минимальная “сигнатура” ответа выглядит так (это не “формат ради формата”, это способ заставить систему быть честной):

[ROUTER]: selected skills = <LIST> (base=<BASE>, checkers=<CHECKERS_OR_NONE>)
[TRACE] read: rules=[...]; skills=[...]; refs=[...]
--- [SWITCHING TO <ROLE>] ---
[<ROLE>]: <MAIN_OUTPUT>

На payroll‑инциденте это выглядит приземлённо. Lance не пишет “помоги”. Он пишет “кто ты, что проверяешь, что читали”:

[ROUTER]: selected skills = incident-triage, decision-packet (base=incident-lead, checkers=verifier, data-risk-reviewer)
[TRACE] read: rules=[stop-on-write]; skills=[incident-triage/SKILL.md, decision-packet/SKILL.md]; refs=[INC-123, logs-snippet-1]
--- [SWITCHING TO incident-lead] ---
[incident-lead]: публикую пакет решения v3, добавил check C2 по просьбе verifier

Richard замечает важное: проверяющие роли здесь не “комитет”. Это маленькие, быстрые независимые проверки по рискам — ровно там, где цена ошибки высока.

Польза проявляется не на демо, а в тяжёлую ночь:

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

Как Lance выбирает проверяющих (и почему их должно быть мало)#

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

Lance останавливает:

— «Если мы сделаем 10 проверяющих “на всякий случай”, мы снова получим 2014‑й: созвон, ожидание, усталость. Проверяющих должно быть мало. Но они должны быть правильными».

Он объясняет правило на пальцах, без схем:

  • touchpoint — это место, где цена ошибки высока (данные, доступы, платежи, инфраструктура, миграции);
  • checker — это не “человек на подпись”, а роль, которая смотрит именно туда, где мы чаще всего ошибаемся.

На payroll‑инцидентах у Lance почти всегда есть два вопроса:

  1. «Есть ли риск данных?»
  2. «Мы не придумали лишнего?»

Отсюда появляются два типовых проверяющих:

  • Verifier (утверждения vs доказательства)
  • Data‑risk reviewer (что может пойти не так с данными и обратимостью)

Если инцидент другой — набор меняется. Lance фиксирует это как простое правило маршрутизации:

  • если в симптомах/логах упоминается схема/миграции — добавь проверку по данным;
  • если упоминаются доступы/подозрительная активность — добавь проверку по безопасности;
  • если непонятно — начни с Verifier и честного списка gaps[].

Руководитель операций неожиданно соглашается:

— «Звучит как здравый смысл».

Lance улыбается:

Да. Просто теперь у здравого смысла есть формат и след в Git.

Agent Skills: как Lance «закрепляет» опыт, чтобы он не исчез#

После инцидента руководитель операций делает то, что делает всегда:

— «Хорошо. В этот раз мы справились. Но мы справились потому, что ты был на месте».

Lance отвечает почти теми же словами, что звучали в главе про узкое место:

— «Именно. Значит, надо вынести процесс из головы и из чата — в артефакт».

В Parts Unlimited 2014 артефактами были “письма” и “вики”, которые никто не ревьюил и которые устаревали незаметно. В Parts Unlimited 2026 артефакт должен жить там, где живёт всё, от чего зависит производство: в Git.

Lance называет такие артефакты Agent Skills: это не “фича”, не “сервис” и не “инструкция на стене”. Это пакет знания, который можно:

  • ревьюить,
  • менять постепенно,
  • сравнивать по истории,
  • привязывать к конкретному инциденту,
  • и, если нужно, откатывать.

Как выглядит Agent Skill (в нашем подходе)#

Agent Skill — это папка, где есть один “главный” документ SKILL.md и при необходимости справочные материалы:

payroll-triage/
  SKILL.md
  references/
  assets/

Главная дисциплина — не структура папок, а содержимое SKILL.md: оно должно отвечать на вопросы “когда использовать”, “как выполнять”, “что считать доказательством”, “когда STOP”.

Ниже — укороченный пример того, что Lance фиксирует после payroll‑инцидента (не как учебник, а как то, что завтра реально будут копировать и применять). В терминах Agent Skills это лежало бы в payroll-triage/SKILL.md (и name в frontmatter должен совпадать с именем директории):

---
name: payroll-triage
description: Триажит P0 payroll-инциденты в «пакет решения»: факты vs гипотезы, риски и следующие проверки с явными STOP-условиями. Использовать, когда payroll недоступен, есть всплеск 5xx, или логи указывают на mismatch схемы/миграции (например, "column does not exist").
---

# Payroll incident triage (P0)

## Когда использовать
- payroll недоступен / 5xx spike / подозрение на схему/миграцию

## Входы
- тикет/канал инцидента
- симптомы (что видит бизнес)
- доступные факты (логи/ошибки/таймлайн деплоя)

## Ограничения
- не выполнять изменения в production без явного подтверждения человека
- если данных недостаточно — пометить gaps[] и эскалировать

## Роли
- Analyst: таймлайн + доказательства + gaps
- Triage: 3 гипотезы + проверки, с привязкой к доказательствам
- Verifier: независимая проверка утверждений vs доказательства

## Артефакт результата
- пакет решения: `fact`/`hypothesis`/`risk`/`next_checks`/`approval_required`

## DoD (критерии «готово»)
- факты отделены от гипотез
- есть список gaps[] (если есть)
- есть next_checks[] и понятно, что требует человека

## STOP
- любые действия, меняющие состояние production
- “уверенные выводы” без доказательств

Дальше начинается то, что отличает 2026 от 2014: это не “заметка в чате”, которую все забудут. Это изменение, которое проходит через обычный инженерный поток.

Lance открывает PR/MR. В описании — не “обновил документ”, а конкретная ставка:

Добавляем обязательный Verifier и отдельную проверку статуса миграции. Иначе мы снова будем спорить по памяти.

Richard читает SKILL.md как продакшен‑артефакт. Он не обсуждает стиль текста. Он обсуждает границы:

STOP на изменение в проде есть. Хорошо. А что если logs недоступны?

Lance добавляет одну строку в “Ограничения”:

Если ключевые данные недоступны — gaps[] + эскалация.

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

Через неделю появляется следующий PR/MR — и он уже не зависит от того, был ли Lance на дежурстве. Он зависит от того, что у команды есть Agent Skill (папка с SKILL.md), который можно менять по истории и ревью.

Как SKILL.md версионируется (и почему это не «версии ПО»)#

Руководитель операций пытается упростить:

Ок, и какая у этого “версия”?

Lance отвечает без философии:

Версия — это commit. Если нужно — tag. Если меняем процедуру — делаем PR/MR и ревью. Если Agent Skill устарел — пишем это в его SKILL.md и указываем замену.

Здесь нет магии: это тот же Git-first подход, который мы используем для кода и SOP (см. приложение C). Разница только в том, что теперь мы версионируем не только код, но и способ работы.

А TRACE (см. главу 2) становится мостом между “ответом” и “процедурой”: когда ночью кто‑то принимает решение, утром можно увидеть, на каких SKILL.md и правилах оно стояло.

Сцена: следующая пятница (и почему это важнее любой демонстрации)#

Через неделю у Lance снова звонит телефон. Но звонит он уже не Lance. На дежурстве другой инженер.

Lance узнаёт об этом утром — из короткого сообщения в общем канале:

Payroll деградировал, но восстановили за 18 минут. Decision packet приложен.

Lance открывает тикет. И впервые за долгие годы он видит знакомый ритм — не потому, что “повезло с людьми”, а потому что есть процедура.

Внутри — тот же паттерн:

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

Там же — короткий фрагмент из начала работы, который новый дежурный инженер копирует почти без изменений:

[ROUTER]: selected skills = payroll-triage, decision-packet (base=incident-lead, checkers=verifier)
[TRACE] read: rules=[stop-on-write]; skills=[payroll-triage/SKILL.md, decision-packet/SKILL.md]; refs=[INC-207, logs-snippet-2]
--- [SWITCHING TO incident-lead] ---
[incident-lead]: собираю таймлайн и доказательства, затем публикую пакет решения

Lance ловит себя на мысли, что это похоже на хороший PR: не потому, что “красиво написано”, а потому, что понятно, что именно произошло.

Внутри инцидента было несколько мелких деталей, которые в 2014‑м легко бы превратились в потерянный час:

  • кто‑то бы начал лечить “на глаз”,
  • кто‑то бы спорил, “а точно ли это миграция”,
  • кто‑то бы полез в прод с опасным действием “потому что надо срочно”.

Но в 2026‑м Verifier сыграл роль той самой холодной головы, которую трудно удержать в 3 часа ночи:

Он остановил “очевидное” решение и потребовал доказательства: есть ошибка column does not exist, но нет подтверждения, что это именно миграция. До проверки — никакого “root cause”, и обязательно отметить gaps.

И в пакете решения появляется одна строка, которая экономит спор утром:

— “H1: schema mismatch, confidence=LOW until C2 confirmed”.

Когда Lance закрывает тикет, он понимает, что это и есть настоящая цель governance:

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

Типовые ошибки (и почему они ломают multi‑agent практику)#

Этот раздел Lance добавляет в конце SKILL.md не как “страшилки”, а как память о том, как система ломается в реальности.

История 1: «Разберись» (и почему это почти всегда заканчивается спором)#

Однажды дежурный инженер делегирует задачу коротко:

— «Разберись, что происходит с payroll».

Через пять минут он получает уверенный, гладкий ответ. И следом — ещё один уверенный, гладкий ответ. Только они противоречат друг другу.

Проблема не в “качестве модели”. Проблема в том, что у исполнителя был чистый контекст, а handoff не содержал ни входов, ни ограничений, ни формата выхода. Дальше начинается старый 2014‑й: спор о словах вместо работы с фактами.

Вывод Lance: handoff — это не “вежливость”, а контракт.

История 2: «Мы же проверили» (а потом оказалось, что никто не знает чем)#

В другой раз команда приносит решение, и все вроде согласны. До первого вопроса на разборе:

— «Ок. На чём вы это утверждение строите?»

В чате есть ссылки, но нет картины: какие правила применялись, какие SKILL.md подтягивались, что считалось доказательством. Ревью превращается в археологию.

Вывод Lance: TRACE — это не “для красоты”. TRACE — это способ сделать результат ревьюируемым.

История 3: «Сделано» без независимой проверки#

Самый опасный сценарий выглядит тихо: все устали, время идёт, и хочется поверить первому правдоподобному объяснению.

Verifier здесь играет роль человека, который задаёт неприятный вопрос:

— «Где факт? Где проверка? Где мы могли ошибиться?»

Вывод Lance: без независимой проверки “сделано” превращается в обещание, а не в доказательство.

История 4: SKILL.md остаётся в чате#

Когда SKILL.md живёт только в переписке, он умирает ровно в тот момент, когда меняется команда или инструмент. Через полгода новый инженер снова делает “как получится”, а в постмортеме снова появляются те же фразы:

— «Мы думали, что это и так очевидно».

Вывод Lance: SKILL.md должен жить в Git и меняться через ревью — так же, как код.

Эпилог: что именно изменилось между 2014 и 2026#

В конце разбора Richard задерживается у двери.

Он выглядит усталым, но не раздавленным. Десять лет назад после таких ночей люди уходили с ощущением, что всё держится на героизме. Сейчас впервые чувствуется другое: что часть героизма удалось заменить дисциплиной.

Самая точная формулировка, которую Lance слышал за последнее время, звучит просто: команда не стала “умнее”, но стала аккуратнее — и быстрее там, где можно быть быстрыми без риска.

Multi‑agent подход не делает вас правыми автоматически. Он делает так, что:

  • вы быстрее собираете факты,
  • вы явно отделяете гипотезы от доказательств,
  • вы заставляете систему (и людей) останавливаться там, где риск выше доказательств,
  • и вы превращаете опыт в артефакт, который живёт дольше одной ночи.

Но Lance добавляет ещё одну мысль — ту, которую особенно важно проговорить честно:

— «Параллельность не бесплатна. Каждая ветка — это время, внимание и стоимость. Поэтому мы не запускаем десять “на всякий случай”. Мы запускаем три — потому что они отвечают на три разных вопроса».

Richard неожиданно понимает, что это опять про то же, что и в производстве:

— «То есть у нас появились WIP‑лимиты, только для мышления».

— «Да. И ещё — лимиты на фантазию», — отвечает Lance и кивает на Verifier.

В 2014‑м проверяющим был усталый человек в колле. В 2026‑м проверяющий — отдельная роль с контрактом “ищи ошибки”. Это не отменяет человека. Это делает человеческое время более дорогим и более точным: человек подключается там, где нужно решение, а не там, где нужно просто собрать факты.

Перед тем как разойтись, Lance дописывает три строки в конец SKILL.md — как напоминание, которое потом спасёт не один инцидент:

  1. Если нет доказательств — нет уверенности. Пиши UNCONFIRMED, не “кажется”.
  2. Если нет handoff — нет делегирования. Есть только “разговор”.
  3. Если нет TRACE — нет ревью. Есть только вера.

Эти строки звучат резко. Но Lance знает: мягкие формулировки не выживают ночью.

Резюме#

Что мы сделали#

В 2014 команда делает руками то, что в 2026 можно разложить на механику и практику:

  • Механика: subagents дают изоляцию контекста, параллельность и делегирование (пример реализации см. выше).
  • Практика: Skill Router + Verifier + TRACE превращают “делегирование” в управляемый процесс.
  • Governance знания: Agent Skills в Git превращают опыт (и ограничения) в переносимый артефакт, а не в память людей.

Если вы вынесете из главы только одно, пусть это будет оно: в 2026‑м “команда агентов” ценна не тем, что она умеет говорить, а тем, что она умеет возвращать проверяемые артефакты.

А у людей остаётся самое важное: принять решение там, где цена ошибки действительно высока.

Артефакты#

  • Минимальный governance-шаблон: Skill Router (base + checkers) + TRACE как обязательный вывод
  • Handoff-шаблон для субагента (цель, входы, ограничения, формат выхода)
  • Decision packet как артефакт для ревью (факты отдельно от гипотез)
  • SKILL.md как переносимый артефакт знаний в Git (ссылки на commit/tag)

Ключевые принципы#

  1. Параллельность не бесплатна: запускаем только те ветки, которые отвечают на разные вопросы (WIP‑лимиты).
  2. Если нет доказательств — нет уверенности: факты отдельно, гипотезы отдельно; UNCONFIRMED вместо “кажется”.
  3. Если нет TRACE — нет ревью: результат должен быть проверяемым, а не “правдоподобным”.
  4. Знания должны жить в Git: SKILL.md меняется через ревью, как код.

Критерии приёмки главы#

После главы вы должны уметь:

  1. Сформулировать handoff для субагента (цель, входы, ограничения, формат выхода).
  2. Собрать пакет решения, который отделяет факты от гипотез.
  3. Применить Skill Router (base + checkers + TRACE) как минимальный governance‑шаблон.
  4. Объяснить, почему SKILL.md должен жить в Git и как ссылаться на конкретную версию (commit/tag).

Следующие шаги#

  • Зафиксируйте ваш минимальный governance-шаблон (ROUTER/TRACE) как стандарт команды и примените его в следующей главе/проекте.