Кратко

  • Индивидуальный проект IETF проводит границу между советом агента и решением компании. Предложение становится обязательством организации только по явному правилу принятия уполномоченным субъектом; действующий токен такой подписью не служит.
  • При передаче задачи проект требует сохранить цель, пределы полномочий, существенный контекст, ссылку на решение, вид доказательства и ответственного владельца. Вызов инструмента, совершённое действие и наблюдаемый итог тоже проверяются отдельно.

Совет дошёл, а председатель не пришёл

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

Карточка IETF Datatracker датирует версию 00 19 октября 2026 года и относит её к активным индивидуальным Internet-Draft. Автор формулирует организационные требования, а не новый протокол передачи сообщений. Их смысл виден без нового формата: цифровые участники могут безупречно проверять друг у друга права доступа, но так и не предъявить решения, которое позволило связать компанию обязательством.

Техническое разрешение и организационная власть расходятся уже на первом шаге. Токен отвечает на вопрос, может ли программа вызвать интерфейс. Полномочие отвечает, вправе ли она для данной цели и в данных пределах решать или действовать за организацию. Передача должна указывать отправителя, цель и исключения, а получатель наследует лишь ограниченную часть прав отправителя. Ключ от переговорной открывает дверь, но не даёт голос в совете директоров. Именно эту простую мысль цепочка агентов может потерять за серией зелёных уведомлений.

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

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

Ответ инструмента — ещё не исход дела

После решения проверка продолжается. Вызов инструмента — запрос. Действие — вмешательство, которое действительно произошло. Итог — перемена, замеченная позднее. Даже самовольное действие остаётся действием и должно попасть в историю: реальность поступка и его законность различаются. Ответ API «успешно» не доказывает изменение договора с поставщиком. Собственный рассказ агента о сделанном тоже не доказывает, что она состоялась.

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

При передаче задачи с ней должен ехать существенный контекст. Первый агент мог знать, что менять поставщика разрешено только в одном регионе, а договор подписывать нельзя. Если второй получает короткое «смени» и действующий токен, ограничения исчезают, хотя право доступа осталось. Проект называет существенным контекст, потеря которого меняет смысл, разрешение или риск. Его надо сохранить. Доверие к отправителю не переходит к получателю автоматически; получатель должен обосновать доверие для своих условий.

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

Первичные материалы