Двухчатовая архитектура — разделение проекта на автономный внутренний чат и согласуемый клиентский

Студия координирует сложный продакшн-проект в одном общем Telegram-чате: клиент, команда, ведущий продюсер и AI-агент в одной комнате. Агент установлен в автономный режим; подтверждает, суммирует, запрашивает файлы, проверяет блокеры. Через две недели команда довольна скоростью чата. Потом агент отправляет подтверждение клиентскому сообщению в голосе клиента — маршрутизация уехала не туда, кусок внутреннего статуса оказался обработан как клиентский, и у клиента теперь статус-апдейт, который команда не одобряла. Первая реакция — отозвать агента в неавтономный режим везде — убивает скорость. Либо агент быстрый (и что-то ломает в клиентской коммуникации), либо медленный (и ничего не даёт).

***Паттерн, который я называю Двухчатовая архитектура. Один и тот же проект живёт в двух отдельных Telegram-чатах: один чисто внутренний (только команда, агент полностью автономный), один чисто внешний (только клиент, каждый ответ согласуется с оператором). Агент присутствует в обоих чатах, но работает в них по разным правилам. Информация течёт из внешнего чата во внутренний через перепись своими словами (никогда forward); обратно из внутреннего во внешний — только через оператора. Двухчатовое разделение — это то, что заставляет tiered-agent-autonomy работать на практике: уровни чистые, потому что они отображаются один-в-один на чаты.

Механизм — два чата, явное правило маршрутизации и запрет «никогда не forward». Конфигурация чатов агента (в OpenClaw — monitored_chats.json) помечает каждый чат флагом autonomous — true для внутреннего, false для клиентского. Когда агент читает сообщение из клиентского чата, он может писать во внутренний автономно (перефразируя сообщение клиента в язык команды). Когда у агента есть что отправить клиенту, он готовит черновик, отправляет его в приватный канал уведомлений оператору и ждёт. На всём этом потоке агент никогда не использует Telegram-форвард — каждый переход это перепись, своими словами, со своей атрибуцией.

Почему один общий чат ломается

Инстинкт посадить клиента и команду в один чат верен по скоростным соображениям и неверен по соображениям governance. В общем чате:

• Уровни не отображаются чисто. Один и тот же агент в одном и том же чате должен быть автономен на внутреннем статусном ответе и проходить согласование на клиентском статусном ответе. Граница в суждении агента, в котором модель ошибается на длинном хвосте.
• Forward'ы текут метаданными. Пересланное сообщение в Telegram показывает оригинального автора. Если агент forward'ит грубоватый внутренний статус члена команды клиенту, клиент видит фрейм и тон члена команды — ровно то, ради чего существует правило переписи.
• Клиент видит рабочее состояние команды. Недоговорённые мысли, false start'ы, фрустрации, выраженные мимоходом коллеге, — ничего из этого не предназначено клиенту. В общем чате это утекает.
• Статусы становятся перформативными. Когда все смотрят, каждое статусное сообщение пишется как deliverable. Реальной координации команды — быстрой, грязной, полной «погоди, это последняя версия?» — негде развиваться.

Разделение — то, что возвращает и governance, и операционную откровенность. Команда может говорить как команда во внутреннем чате. Агент может держать скорость во внутреннем чате. Клиент видит только то, что оператор проверил.

Два чата, в деталях

Сетап кейса для часового проекта:

Внутренний чат — Team WATCH (переименовано от бренда):

• Участники: ведущий продюсер, два специалиста (текстуры/свет, 3D-моделирование), агент
• Тип: Telegram-форум с топиками по deliverable
• Язык: русский (рабочий язык команды)
• autonomous: true
• Работа агента: forward-перепись фидбека клиента входящим, проверка блокеров, рендеринг статусов, логирование решений, эскалация дыр оператору

Клиентский чат — Project x Client (переименовано от имён):

• Участники: ведущий продюсер, агент, клиент-лид
• Тип: Telegram-форум с топиками по производственным потокам
• Язык: английский (рабочий язык клиента)
• autonomous: false — каждый ответ проходит через оператора
• Работа агента: готовить черновики клиентских ответов, передавать оператору, отправлять только после одобрения; никогда не писать в этот чат по своей инициативе

У двух чатов параллельные структуры топиков, так что сообщение о варианте A 39.5мм в клиентском чате соответствует топику о варианте A 39.5мм во внутреннем. Агент поддерживает маппинг в своей памяти.

Правила потока

Четыре правила потока управляют движением между чатами. В кейсе они закодированы в маленькой ASCII-диаграмме в конфиге агента:

┌──────────────────┐                    ┌──────────────────┐
│  Клиентский чат  │                    │  Внутренний чат  │
│  (согласуется)   │                    │  (автономный)    │
│                  │    ┌──────────┐    │                  │
│  Клиент → msg    │───►│  Агент   │───►│  Агент → команда │
│                  │    │          │    │  (перепись, RU)  │
│  Клиент ← msg    │◄───│  через   │◄───│  Команда → итог  │
│                  │    │ оператор │    │                  │
└──────────────────┘    └──────────┘    └──────────────────┘

• Клиент → Агент → Команда: автономно. Агент переписывает сообщение клиента в язык команды и фрейм команды. Не forward; не цитата; перефраз с агентом как автором.
• Команда → Агент → Клиент: согласуется. Агент готовит клиентскую версию, оператор проверяет, оператор отправляет (или агент отправляет по указанию).
• Никогда forward. Оба направления. Forward сохраняет метаданные, утекающие рабочее состояние команды клиенту и тон клиента команде. Перепись — единственный легальный режим.
• Дисциплина топиков. Перед отправкой в форум-чат агент проверяет, что целевой топик соответствует теме. (Правило, промоутированное в конфиг после инцидента с неверным топиком; см. incident-driven-configuration.)

Почему «никогда не forward»

Правило «никогда не forward» делает много работы. Forward выглядит быстрее и точнее — сообщение проходит дословно, без транскрипционной ошибки, без времени на перефраз. Но forward делает три вещи, которых студия не хочет:

1. Сохраняет голос и тон автора. Грубоватое внутреннее «к среде это нереально» превращается в клиентский текст в голосе члена команды, с его тоном. Клиент видит рабочее состояние команды.
2. Сигналит автоматический реле. Длинная цепочка forward'ов — визитка скрипта. Перефразированная перепись — визитка человека, который реально прочитал сообщение и перевёл его.
3. Теряет перевод. Внутренний чат на русском; клиентский — на английском. Forward не переводит. Перепись — да.

Принуждение правила — на уровне действия: функция отправки агента отвергает любой путь, использующий forward-примитив. Доступны только режимы «новое сообщение» и «ответ» — оба требуют, чтобы агент сам составил текст.

Уровни по направлению внутри одного чата

Двухчатовое разделение — чистая версия более общего паттерна: уровни могут применяться по направлению даже внутри одного чата. Сетап двух чатов в кейсе делает это лёгким — чаты являются направлениями, — но базовая логика обобщается. Информация входящая в низкорисковый контекст (статус команды, перефраз клиента) может быть автономной; информация исходящая в высокорисковый контекст (клиентская коммуникация, обязательства по scope, дедлайны) — нет.

Когда у проекта не может быть двух чатов (single-chat-клиентские сетапы, ограничения коммуникационной платформы), разделение всё равно применимо, но на уровне сообщения: агент классифицирует каждое исходящее сообщение по уровню назначения и либо отправляет автономно, либо эскалирует. Двухчатовая архитектура — чистая физическая инстанциация правила.

Что это даёт оператору

Работа оператора в двухчатовом сетапе более сфокусирована, чем в общем чате. Он:

1. Читает внутренний чат как менеджер читает командный чат — для ситуационной осведомлённости, не для ревью каждого сообщения.
2. Просматривает клиентские черновики в своём канале уведомлений — очередь «Арина подготовила это клиенту, одобрить / поправить / отклонить».
3. Отправляет одобренные черновики обратно. Агент публикует их в клиентский чат в голосе агента.
4. Ловит эскалации (срабатывания протокола СТОП) из любого чата.

Оператор больше не должен мониторить один общий чат на «не превысил ли агент полномочия только что». Архитектурное разделение убирает этот вопрос.

Где паттерн подходит

• Агентская / студийная продакшн-работа с треугольником клиент-команда-агент.
• Sales-пайплайны с внутренней квалификацией (автономно) и внешним outreach (согласуется).
• Support-эскалации, где Tier 1 автономен, Tier 2 (инженерия, account exec) согласуется.
• Кризисоустойчивые проекты, где ценность чистого разделения между внутренней откровенностью и внешней собранностью перевешивает стоимость двухчатового оверхеда.

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

Два режима отказа

• Два чата, но конфигурация уровней игнорируется. Оба чата установлены автономными, потому что «агент теперь хороший». Первый overreach в клиентский чат — момент, когда архитектура перестала существовать. Решение: autonomous: false для клиентского чата не подлежит обсуждению; цена одного дополнительного раунда одобрения на ответ маленькая.
• Несовпадение топиков между чатами. Внутренний чат имеет топики для вариантов A/B/C; клиентский чат имеет топики для deliverable, а не вариантов. Агент маппится не туда. Решение: поддерживать карту топиков в памяти агента; проверять на отправке.

См. также

• tiered-agent-autonomy — более широкий паттерн governance, который двухчатовое разделение делает физически чистым
• persona-through-prohibitions — голос агента, выживающий шаг переписи
• openclaw-autonomous-agent-paper — полный кейс, где эта архитектура развёрнута