теория
Мы навели порядок на входе агента. Теперь взгляни на выход — и увидишь знакомый пунктир с другой стороны.
Ответ агента читают не только люди. Когда ассистент готовит заявку на возврат, её потребитель — код: фронтенд рисует карточку, оркестратор кладёт заявку в очередь оператору. Код ждёт структуру: сумма числом, причина из списка, номер заказа по маске. А модель порождает текст — и даже если вежливо попросить её «отвечать строго в JSON», она время от времени добавит запятую не туда или дружелюбное «вот ваша заявка!» перед фигурной скобкой. Парсер падает. Это то же неявное знание, что и промпт, только теперь на выходе: потребитель надеется на форму, которую никто не гарантирует.
Лечение — : ответу назначается JSON-схема, и она становится контрактом. Современные модели умеют соблюдать схему на уровне самой генерации — недопустимый токен просто не может быть порождён, — а на нашей границе стоит валидатор: невалидный ответ не проходит дальше, а возвращается модели на пересдачу. Обрати внимание на асимметрию: схема гарантирует форму, но не истинность — сумма возврата будет числом, но правильное ли это число, схема не знает. Форму проверяет контракт, содержание — правила и человек из прошлого модуля.
Осталась последняя деталь — время. Покупательница написала утром, ушла на работу, вернулась вечером — а ассистент должен продолжить с того же места. Значит, сессия переживает процесс: состояние сериализуется и хранится. Где — вопрос из девятого модуля, и критерии те же: владение, доступ, срок жизни. Ничего агентно-специфичного: обычные данные, обычное хранилище, обычная дисциплина.
Считай этот модуль ритуалом взросления: оба конца агента — вход и выход — перестали быть пунктиром.