Контекст проекта для ИИ-агентов: почему промпт — не delivery-запись

Промпт — инструкция в конкретный момент времени. Delivery-запись — общее состояние, которое переживает сессию и сообщает следующему человеку или агенту, что истинно, что разрешено, кто отвечает и что ещё не закончено. Агентам нужны промпты для действий. Командам нужны delivery-записи для координации, ревью и приёмки.

Что теряет скопированный промпт

Промпт может хорошо описывать задачу и всё равно не содержать информацию, которая управляет delivery:

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

Сессия может локально закончиться успешно, а проект станет менее понятным.

Семь частей delivery-записи

1. Идентичность

Кто действует? Человеку, сервисному аккаунту или внутреннему агенту нужен определяемый Principal. Исполнитель должен быть виден без передачи чужих учётных данных. Если отсутствует: непонятно, какой агент изменил работу, и нельзя отозвать его доступ, не затронув человека.

2. Намерение

Зачем существует работа и какой результат ожидается? Сюда входят цель, требование, условия приёмки и причина, по которой задача важна сейчас. Если отсутствует: агент оптимизирует формулировку задачи, нарушая продуктовое решение за ней.

3. Текущее состояние

Что истинно сейчас? Статус, владелец, обсуждение, решения, ссылки и последний проектный контекст должны обновляться вместе с работой. Если отсутствует: каждая сессия начинается с восстановления проекта из старых сообщений.

4. Полномочия

Что исполнитель может читать, создавать и менять? Полномочия определяют подключённый Principal, рабочее пространство, проект и разрешённые операции. Назначение фиксирует ответственность, но не выдаёт дополнительный доступ. Если отсутствует: агент либо не может завершить работу, либо получает более широкий доступ, чем требуется.

5. Зависимости

Что должно произойти до, после или одновременно с этой задачей? Это другие задачи, решения, репозитории, ревьюеры и внешние условия. Если отсутствует: результат локально правильный, но не может пройти к релизу.

6. Подтверждения

Что доказывает выполнение? Изменения задач, комментарии, коммиты, pull request, checks, документы и открытые вопросы. Если отсутствует: ревьюер сначала выясняет, что произошло, и только потом может оценить результат.

7. Приёмка

Кто решает, что ожидаемый результат получен? В записи нужен ответственный человек и ясные условия приёмки. Исполнитель не должен сам принимать собственную значимую работу. Если отсутствует: «готово» означает конец сессии, а не принятие результата командой.

Промпт и delivery-запись

Сильный промпт улучшает исполнение. Он не заменяет систему, которая говорит команде, что произошло после него.

Минимальная запись до назначения агента

До начала работы элемент должен отвечать:

• Исполнитель: кто выполняет работу?
• Цель: какой результат ожидается?
• Границы: что входит и не входит?
• Полномочия: какие проект, репозиторий и операции разрешены?
• Зависимости: что может остановить или обесценить работу?
• Подтверждения: что должно вернуться при передаче?
• Приёмка: кто проверяет результат и по каким условиям?

Если поле неизвестно, сделайте пробел явным. Не прячьте его в более длинный промпт.

MCP открывает проект, но не определяет запись

Model Context Protocol даёт совместимому клиенту стандартный способ пользоваться инструментами и получать данные. Он не решает, какая запись авторитетна, кто владеет результатом и что считается принятым. Проектная система по-прежнему должна владеть:

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

MCP — соединение с этой системой, а не её замена.

Skills задают последовательность работы

Даже при наличии инструментов и качественной записи клиенту нужен повторяемый процесс. TAM Skills требуют установить идентичность и границы, прочитать текущее состояние, выбрать процесс, внести ограниченные изменения, проверить результат и оставить подтверждения или безопасно остановиться. Skill не расширяет полномочия, но помогает последовательно использовать существующие.

Активность репозитория становится подтверждением, когда связана с работой

Коммит или pull request сами по себе не объясняют delivery-состояние. Запись должна показывать:

• какая задача запросила изменение;
• в какой ветке или pull request оно находится;
• какие checks прошли;
• какое ревью осталось;
• какое условие приёмки закрыто;
• какой блокер или вопрос открыт.

GitHub остаётся источником кода и code review. Delivery-запись связывает эту активность с целью и владельцем.

Одна запись улучшает передачу между людьми и агентами

Разработчик может остановиться после создания pull request. Coding agent — закончить сессию. Product lead — принять решение. Следующий исполнитель открывает ту же запись и видит текущую цель, состояние, полномочия, зависимости, подтверждения и путь приёмки. Это надёжнее, чем новый пересказ при каждой передаче.

Как TAM представляет delivery-запись

TAM объединяет:

• проекты, задачи, доски, docs, comments и search для текущего состояния;
• человеческие и нечеловеческие Principals для идентичности;
• ограниченный доступ к рабочему пространству и проекту;
• назначения, зависимости и workflow;
• ссылки GitHub для данных репозитория;
• TAM Skills для повторяемого исполнения и передачи;
• @tam для постоянной delivery-координации.

Coding-клиент по-прежнему работает с репозиторием. Команда по-прежнему принимает значимые решения и результат.

Создайте одну запись до подключения новых агентов

Возьмите одну задачу с участием ИИ, которая сейчас живёт в промптах и чатах. Запишите семь полей в общий work item, назначьте исполнителя, потребуйте передачу подтверждений и оставьте приёмку названному человеку.