diff --git a/docs/maestro-workflow/README.md b/docs/maestro-workflow/README.md
index b8cb91f..b5582eb 100644
--- a/docs/maestro-workflow/README.md
+++ b/docs/maestro-workflow/README.md
@@ -15,3 +15,7 @@ Maestro Harmony 제품군의 범용 승인·결정·이력 앱. 구현은 [`work
 - 엄격 모드 대시보드: 토큰 게이트 + WS 첫 메시지 인증 + 자동 재연결 (2026-08-03 스펙)
 - actor 토큰 WS 구독: 자기 결정만 스코프 수신, revoke 시 소켓 종료 (2026-08-04 스펙)
 - 범위 밖: Policy/자동승인, Delegation, 에이전트 decider, executor 실행, 다중 운영자
+
+## 후속 구상
+
+- 채널 에이전트 연동(이메일 triage/reply 승인, 요청 체인): 비전 문서 §4(d) 및 설계 스펙 §9 참조 (2026-08-04 현행화, 미착수)
diff --git a/docs/superpowers/specs/2026-07-31-maestro-workflow-subapp-design.md b/docs/superpowers/specs/2026-07-31-maestro-workflow-subapp-design.md
index 3589cf8..c017a1b 100644
--- a/docs/superpowers/specs/2026-07-31-maestro-workflow-subapp-design.md
+++ b/docs/superpowers/specs/2026-07-31-maestro-workflow-subapp-design.md
@@ -192,3 +192,14 @@ maestro-coding/                     ← 현재 레포 (이름 유지)
 4. **이력 뷰** + 재시작 복구 확인
 5. **CI 잡 추가** + `docs/maestro-workflow/README.md` + 루트 `README.md`에 Maestro Harmony
    제품군(Coding/Workflow/Player) 선언 1개 섹션 추가
+
+## 9. 후속 구상 — 채널 에이전트 연동 (2026-08-04 추가, 미착수)
+
+이메일 등 외부 채널 업무(확인→처리→답변, 분기 포함)를 결정 채널로 관리하는
+구상. 상세는 비전 문서 §4(d) 참조. Workflow에 필요한 확장은 두 가지뿐:
+
+1. 프리셋 subjectType `email-triage` / `email-reply` (표시 전용 — spend/publish 패턴).
+2. `parentRequestId` 요청 체인 + 체인 조회 API (선형·분기 이력 시각화 토대).
+
+커넥터(IMAP/Gmail)·초안 생성·발송 실행은 에이전트 몫으로 Workflow 비범위 —
+record-only와 자격증명 비보유 경계를 유지한다.
diff --git a/docs/vision/2026-07-21-universal-approval-record-service.md b/docs/vision/2026-07-21-universal-approval-record-service.md
index 933daf3..744eb5c 100644
--- a/docs/vision/2026-07-21-universal-approval-record-service.md
+++ b/docs/vision/2026-07-21-universal-approval-record-service.md
@@ -180,6 +180,22 @@ Actor ──요청──▶ DecisionRequest ──판단──▶ Decision ─
 
 **현재와의 거리**: 가장 멀다. 다중 사용자, 사람 신원 체계, RBAC가 전부 필요 — 의도적으로 마지막 단계에 둔다.
 
+### (d) 이메일 등 외부 채널 업무 — 선형 진행 + 분기 관리 (2026-08-04 추가)
+
+이메일처럼 "확인 → 처리 → 답변"으로 선형 진행하다 중간에 분기되는 업무를 Workflow의 결정 채널로 관리한다. **이메일 커넥터 에이전트**(별도 프로세스)가 받은편지함을 읽고, 처리가 필요한 메일마다 DecisionRequest를 올린다 — `email-triage`(분류·처리방침 확인) 또는 `email-reply`(답장 초안 승인, payload에 원문 요약+초안). 사람은 레인 대시보드에서 승인/반려/보완을 결정하고, 에이전트는 **actor 토큰 WS 구독(이미 구현됨)**으로 결정을 실시간 수신해 발송을 실행한다. 발송은 에이전트의 몫 — Workflow는 record-only(`executorAction=none`) 원칙을 그대로 지킨다.
+
+분기 표현: 후속 요청이 이전 결정을 참조하는 **요청 체인(`parentRequestId`)**으로 잇는다. 반려되면 에이전트가 수정 초안을 같은 체인에 새 요청으로 올리고, 하나의 메일 스레드 = 하나의 결정 체인이 되어 이력에서 왕복 전체가 악보처럼 읽힌다.
+
+**필요한 확장 (Workflow 쪽, 후속 스펙 후보)**:
+
+1. 프리셋 subjectType 추가: `email-triage` / `email-reply` — 기존 spend/publish처럼 표시 전용 하이라이트 (작음).
+2. DecisionRequest에 선택 필드 `parentRequestId` + 체인 조회 API — 선형·분기 업무 시각화의 토대 (중간).
+3. 보완(revise) 왕복은 현행 decide comment로 이미 가능 — 체인이 생기면 자연스러운 반복 루프가 된다.
+
+**필요한 확장 (에이전트 쪽 — Workflow 비범위)**: IMAP/Gmail 커넥터, 초안 생성, 발송 실행. Workflow는 이들과 기존 계약(actor 등록·요청·결정·ack·WS)으로만 만난다 — 이메일 자격증명이 Workflow에 들어오지 않는 것이 경계다.
+
+**현재와의 거리**: 계약 층은 오늘 전부 동작한다(actor 토큰·pull/ack·WS 구독). 부족한 것은 프리셋 2종과 요청 체인뿐이며, 커넥터 에이전트는 별도 구현이 경계에 맞다. 이 유스케이스는 (a)의 "지출 승인"과 같은 패턴의 수평 확장이라 아키텍처 변경이 필요 없다.
+
 ---
 
 ## 5. 차별화 / 경쟁
diff --git a/workflow/README.md b/workflow/README.md
index b2ab0d6..102fe87 100644
--- a/workflow/README.md
+++ b/workflow/README.md
@@ -45,3 +45,5 @@ actor도 자신의 actorToken으로 같은 `WORKFLOW_AUTH` 핸드셰이크를 
 - 토큰은 localStorage에 평문 저장된다 — 로컬 신뢰 기기 전제. TLS 없음, 기본
   `HOST=127.0.0.1` 로컬 전용 전제를 유지하라.
 - 다중 운영자/권한 분리는 후속 스펙으로 예약한다.
+- 채널 에이전트 연동(이메일 확인·답장 승인 등)과 `parentRequestId` 요청 체인은
+  비전 문서 §4(d) 구상으로 예약한다 — 프리셋 2종+체인 필드만으로 수용 가능.