May 19, 20267 min readЧитать на русском

Two-Chat Architecture — Splitting a Project into an Autonomous Internal Chat and an Approval-Gated Client Chat

A studio coordinates a complex production project across one shared Telegram chat: client, team, lead producer, and an AI agent all in the same room. The agent is set to autonomous; it acknowledges, summarises, requests files, probes for blockers. Two weeks in, the team is satisfied with the chat's velocity. Then the agent sends an acknowledgement to a client message in the client's voice — it routed the wrong way, treated a piece of internal status as if it were client-facing, and the client now has a status update the team had not approved. The instinct fix — pull the agent back to non-autonomous mode everywhere — kills the velocity. Either the agent is fast (and breaks things into client communication) or it's slow (and offers nothing).

What follows is the pattern I name Two-Chat Architecture. The same project lives in two separate Telegram chats — one purely internal (team only, agent fully autonomous), one purely external (client only, every reply approval-gated through the operator). The agent occupies both chats but operates them under different rules. Information flows from the external chat into the internal chat by rewriting in own words (never forwarding); information flows back from internal to external only through the operator. The two-chat split is what makes tiered-agent-autonomy work in practice: tiers are clean because they map one-to-one to chats.

The mechanism is two chats, an explicit routing rule, and a "never forward" prohibition. The agent's chat configuration (in OpenClaw, monitored_chats.json) marks each chat with an autonomous flag — true for the internal chat, false for the client chat. When the agent reads a message from the client chat, it can write to the internal chat autonomously (by paraphrasing the client's message into the team's language). When the agent has something to send to the client, it drafts a reply, sends it to the operator's private notification channel, and waits. Across this whole flow the agent never uses Telegram's "forward" feature — every transition is a rewrite, in own words, with own attribution.

Why one shared chat fails

The instinct to put client and team into the same chat is right on velocity grounds and wrong on governance grounds. In a shared chat:

Tiers cannot map cleanly. The same agent in the same chat needs autonomy on the internal status response and approval-gating on the client status response. The boundary is in the agent's judgement, which the model gets wrong on the long tail.
Forwards leak metadata. A forwarded message in Telegram shows the original author. If the agent forwards a team member's blunt internal status to the client, the client sees the team member's frame and tone — exactly what the rewriting rule exists to prevent.
The client sees the team's working state. Half-finished thoughts, false starts, frustrations expressed offhandedly to a colleague — none of this is meant for the client. In a shared chat it leaks.
Status updates become performative. When everyone is watching, every "status" message gets written as a deliverable. The team's actual coordination — fast, dirty, full of "wait, is this the latest?" — has nowhere to live.

The split is what restores both governance and operational candour. The team can talk like a team in the internal chat. The agent can keep speed in the internal chat. The client only ever sees what the operator has reviewed.

The two chats, in detail

The case-study setup for the Swiss-watch project:

Internal chat — Team WATCH (renaming away from the brand):

Participants: lead producer, two specialists (textures/light, 3D modelling), agent
Type: Telegram forum chat with topics per deliverable
Language: Russian (the team's working language)
autonomous: true
Agent's job: forward-paraphrase client feedback inbound, probe for blockers, render statuses, log decisions, escalate gaps to the operator

Client chat — Project x Client (renaming away from names):

Participants: lead producer, agent, client lead
Type: Telegram forum chat with topics for production stream
Language: English (the client's working language)
autonomous: false — every reply gates through the operator
Agent's job: draft client-facing replies, hand to operator, send only after approval; never write to this chat on initiative

The two chats have parallel topic structures so a message about Variant A 39.5mm in the client chat maps to a topic about Variant A 39.5mm in the internal chat. The agent maintains the mapping in its memory.

The flow rules

Four flow rules govern movement between the chats. The case study encodes them as a small ASCII diagram in the agent's config:

┌──────────────────┐                    ┌──────────────────┐
│  Client chat     │                    │  Internal chat   │
│  (gated)         │                    │  (autonomous)    │
│                  │    ┌──────────┐    │                  │
│  Client → msg    │───►│  Agent   │───►│  Agent → team    │
│                  │    │          │    │  (rewrite, RU)   │
│  Client ← msg    │◄───│  via     │◄───│  Team → result   │
│                  │    │ operator │    │                  │
└──────────────────┘    └──────────┘    └──────────────────┘

Client → Agent → Team: autonomous. The agent rewrites the client's message into the team's language and the team's frame. Not a forward; not a quote; a paraphrase with the agent as the author.
Team → Agent → Client: gated. The agent drafts the client-facing version, the operator reviews, the operator sends (or has the agent send on instruction).
Never forward. Both directions. Forwarding preserves metadata that leaks the team's working state to the client and the client's tone to the team. Rewriting is the only legal mode.
Topic discipline. Before sending to a forum chat, the agent verifies the target topic matches the subject. (A rule promoted to the config after a wrong-topic incident; see incident-driven-configuration.)

Why "never forward"

The "never forward" rule is doing a lot of work. Forwarding looks faster and more accurate — the message goes through verbatim, no transcription error, no time spent paraphrasing. But forwarding does three things the studio doesn't want:

It preserves the author's voice and tone. A blunt internal "this is impossible by Wednesday" turns into client-facing text in the team member's voice, with their tone intact. The client sees the team's working state.
It signals automated relay. A long chain of forwards is the calling card of a script. A rewritten paraphrase is the calling card of a person who actually read the message and translated it.
It loses translation. The internal chat is in Russian; the client chat is in English. Forwards don't translate. Rewriting does.

The rule's enforcement is at the action level: the agent's send function rejects any path that uses the forward primitive. The only available send modes are "new message" and "reply" — both of which require the agent to compose the text itself.

Per-direction tiering within one chat

The two-chat split is a clean version of a more general pattern: tiers can apply per-direction even within a single chat. The case study's two-chat setup makes this easy — the chats are the directions — but the underlying logic generalises. Information inbound to a low-stakes context (team status, paraphrase of client) can be autonomous; information outbound to a high-stakes context (client communication, scope statements, deadline commitments) cannot.

When a project can't have two chats (single-chat client setups, communication-platform constraints), the split still applies but at the message level: the agent classifies each outbound message by destination tier and either sends autonomously or escalates. The two-chat architecture is the clean physical instantiation of the rule.

What it gives the operator

The operator's job in the two-chat setup is more focused than in the shared-chat setup. They:

Read the internal chat the way a manager reads a team chat — for situational awareness, not for review of each message.
Review client-facing drafts in their notification channel — a queue of "Arina drafted this for the client, approve / edit / reject".
Send approved drafts back. The agent posts them to the client chat in the agent's voice.
Catch escalations (STOP-protocol triggers) from either chat.

The operator no longer has to monitor a single shared chat for "did the agent overstep just now". The architectural split removes the question.

When the pattern fits

Agency or studio production work with a client-team-agent triangle.
Sales pipelines with internal qualification (autonomous) and external outreach (gated).
Support escalations where Tier 1 is autonomous and Tier 2 (engineering, account exec) is gated.
Crisis-prone projects where the value of clean separation between internal candour and external composure outweighs the cost of two-chat overhead.

It is weakest in casual or one-shot interactions where two chats are bureaucratic overhead — a personal-assistant agent doesn't need a two-chat setup with one user.

Two failure modes

Two chats but tier configuration ignored. Both chats are set to autonomous because "the agent is good now". The first overstep into the client chat is the moment the architecture stopped existing. Fix: autonomous: false on the client chat is non-negotiable; the cost of one extra approval round per reply is small.
Topic mismatch between chats. The internal chat has topics for variants A/B/C; the client chat has topics for deliverables not variants. The agent maps the wrong way. Fix: maintain the topic map in agent memory; verify on send.