← Docs hub

A2A Experience Supervisor

문서 역할
처음 접하는 독자는 Experience Goal: 명령 수행에서 결과 위임으로에서 전체 AS-IS/TO-BE를 먼저 본다. 이 문서는 장기 경험에서 목표·관찰·재판단 상태를 어떤 Supervisor가 유지하는지에 집중한다.

이 문서는 최근 진행한 A2A Planner, DeviceAgent TaskManager, device context, callback/replan 작업을 바탕으로, 물리 workflow와 대화·퀴즈·이야기·브리핑을 하나의 장기 경험으로 관리하는 Experience Supervisor를 구체화한다.

핵심은 복합명령 step을 더 많이 만드는 것이 아니다. Supervisor가 사용자의 상위 목표를 보존하고, 기기와 콘텐츠 상태를 함께 관찰하고, 상황 변화에 맞춰 경험을 재계획해야 한다.

1. 최근 작업에서 확보한 기반

2026-07-25 비이동 shadow r31의 60/60, read-only 실기기 r32의 10/10은 초기 계약 증거다. 이후 2026-08-05에는 실제 기기에서 단일 청정 시작·정지 callback 종료와 이동 후 스테이션 복귀의 multi-step dependency까지 확인했다. 다만 이 증거는 기존 ODL plan과 TaskManager 실행 backbone을 닫은 것이며, Experience full tier 전체를 승인한 것은 아니다. 현재 판정과 남은 No-Go는 Experience Runtime Validation Closure 2026-08-05를 기준으로 한다.

2. Workflow와 Agentic Experience의 차이

정적인 workflow:

거실 이동 -> 청정 시작 -> 퀴즈 시작

Agentic experience:

목표: 청정을 수행하는 동안 사용자가 지루하지 않게 한다

-> 이동/청정/음성/콘텐츠 상태 관찰
-> 지금 시작할 콘텐츠와 시점 판단
-> 지연, 실패, 사용자 개입 시 계획 변경
-> 기기 작업과 콘텐츠 세션을 독립적으로 pause/resume/cancel
-> 목표 달성 여부를 판단하고 종료

정해진 step을 실행하는 것은 TaskManager의 역할이다. Experience Supervisor는 step 위에서 목표가 여전히 유효한지, 현재 계획이 최선인지, 사용자에게 물어봐야 하는지를 판단한다.

3. Target Architecture

User goal
  -> Cloud A2A Main Router
  -> Experience Supervisor
       |- Device plan  -> TaskManager -> DeviceAgent/domain manager
       |- Content plan -> DEF / FRG / STM / ETR
       |- Time plan    -> SCH
       `- Observe      <- task event / device context / user turn
  -> continue | pause | substitute | ask | replan | complete

4. Experience State

기존 workflow state 위에 아래 compact state를 추가한다.

experience:
  contract_version: experience.v1
  experience_id: exp_cleaning_companion_001
  goal: 청정 중 사용자가 지루하지 않게 한다
  status: active
  current_phase: waiting_for_cleaning_start
  success_criteria:
    - device_goal_completed
    - content_session_started
  constraints:
    - safety_policy_first
    - user_can_cancel_anytime
    - respect_quiet_hours
  observation_subscriptions:
    - movement.arrived
    - cleaning.started
    - cleaning.completed
    - task.failed
    - voice.interrupted
    - content.user_response
  active_sessions:
    device_workflow_id: wf_device_001
    content_session_id: quiz_001
  replan_budget:
    automatic_retries: 1
    user_questions: 1

중요한 것은 device workflow와 content session을 같은 lifecycle로 합치지 않는 것이다. 청정은 끝났지만 퀴즈는 계속될 수 있고, 퀴즈를 중단해도 청정은 유지할 수 있다.

대표 샘플을 gemini-2.5-flash-lite로 계측했을 때 experience.v1은 compact JSON 656 bytes, 175 tokens였다. 현재 2-step workflow_context와 결합한 크기는 1,784 bytes, 512 tokens였다. 이 상태를 prompt에 한 번 넣는 비용보다, event마다 LLM을 추가 호출하는 구조가 훨씬 큰 성능 위험이다.

상태 크기, 호출 횟수, p50/p95 회귀 기준은 A2A Experience Supervisor을 따른다.

5. Observation And Decision Loop

최신 catalog/effect/terminal authority와 실측 결과는 Experience Catalog, Evidence, and Bounded Replan 2026-08-09을 기준으로 한다. Supervisor의 재계획은 자유 action 생성이 아니라, 그 문서에 정의된 provider 후보와 terminal evidence 안에서 미달 효과를 해결하는 제한된 탐색이다.

Supervisor는 모든 raw sensor sample마다 LLM을 호출하지 않는다.

판단을 다시 실행하는 조건:

• 물리 step의 완료가 관찰됨
• FAILED, BLOCKED, TIMEOUT, NEEDS_USER_INPUT 발생
• 사용자가 수정, 중단, 질문으로 개입
• 콘텐츠 세션 완료, 취소, 장시간 무응답
• 계획에 영향을 주는 battery, policy, location, voice state 변경
• 예약한 Experience의 실행 시점 도달

정상 QUEUED, RUNNING, PROGRESS, STEP_COMPLETED는 telemetry와 UI 갱신만 수행한다.

Supervisor decision:

continue
pause
resume
substitute
ask_user
retry_local
replan_cloud
complete
cancel

모든 변경은 reason_code, 관찰 근거, 이전 계획, 변경 계획을 trace에 남긴다.

6. 대표 Agentic Experience

6.1 Cleaning Companion

사용자: 거실로 가서 청정하면서 퀴즈 내줘

초기 계획:

거실 이동
-> 청정 시작 확인
-> 퀴즈 세션 시작
-> 청정과 퀴즈 상태 병행 관찰

재계획:

• 이동이 지연되면 기다리는 동안 퀴즈를 먼저 시작한다.
• 사용자 음성 개입이 발생하면 콘텐츠를 pause하고 현재 발화를 우선 처리한다.
• 청정 실패 시 퀴즈는 유지하면서 재시도, 대체, 사용자 확인 중 하나를 선택한다.
• 퀴즈 난이도는 정답률과 사용자 반응에 맞춰 조정한다.
• “청정은 계속하고 퀴즈만 그만”을 서로 다른 lifecycle에 반영한다.

6.2 Bedtime Companion

사용자: 매일 밤 아이들 방 공기를 관리하면서 동화를 들려줘

Supervisor는 예약 시각에 현재 방, 공기질, 배터리, 야간 정책을 확인한다. 청정이 필요 없다면 동화만 시작할 수 있고, 기기 작업이 차단돼도 콘텐츠 세션은 독립적으로 판단한다. 지난 이야기 위치는 세션 memory로 이어간다.

6.3 Information After Task

사용자: 청정 끝나면 오늘 뉴스 요약해줘

뉴스는 명령 등록 시점이 아니라 청정 완료 callback 이후 FRG가 조회한다. 청정 실패를 완료로 처리하지 않으며, 작업이 오래 걸리면 뉴스를 먼저 들을지 사용자에게 물을 수 있다.

6.4 Open-Ended Chore Companion

사용자: 내가 집안일 하는 동안 심심하지 않게 해줘

이 시나리오는 정적인 workflow로 만들기 어렵다. Supervisor가 사용 가능한 시간, 현재 기기 작업, 최근 사용자 반응과 승인된 선호를 보고 퀴즈, 이야기, 브리핑, 대화 중 하나를 선택한다. 초기 제품에서는 선택 가능한 범위를 알리고 한 번 확인한 뒤 시작한다.

7. User Intervention

문장별 hardcode가 아니라 active goal, foreground owner, 실행 중 task/content state를 Main Router에 제공해 의미적으로 판단한다.

8. Autonomy Boundary

초기 Experience Supervisor는 L2-L3까지만 허용한다.

로컬 deterministic 영역:

• capability 존재 여부
• safety/policy blocker
• context freshness
• duplicate event 억제
• timeout/retry 상한
• 사용자 cancel 즉시 전달

LLM 판단 영역:

• 경험 목표 해석
• 콘텐츠 선택과 전환
• 실패 후 대안 비교
• 사용자 질문 필요 여부
• Agent 결과 통합

9. Implementation Roadmap

Phase 1: Shadow Supervisor

• experience.v1 contract와 trace만 생성
• 기존 TaskManager 실행 경로는 변경하지 않음
• fake task event로 Supervisor 판단 비교

Phase 2: Content Coordination

• TaskManager callback과 DEF/STM/FRG 콘텐츠 시작 연결
• content session pause/resume/cancel 추가
• device workflow와 content lifecycle 분리

Phase 3: Bounded Replanning

• 실패, 지연, 사용자 개입에만 replan 실행
• automatic retry와 사용자 질문에 budget 적용

Phase 4: Proactive Experience

• 승인된 시간대와 루틴 안에서만 Experience 제안
• 장기 선호는 사용자 확인 후 저장

10. Runtime Budget

Experience Supervisor는 매 event마다 LLM을 추가 호출하는 계층이 아니다. compact goal state와 의미 있는 상태 전이만 유지하는 event-gated control plane이다.

QUEUED, RUNNING, PROGRESS, heartbeat와 중복 event는 local state와 UI만 갱신한다. 실패·차단·사용자 변경·계획에 영향을 주는 context 변화만 의미 판단을 연다. 상태에는 device context 원문 대신 etag와 필요한 observation만 저장한다.

11. Monitoring UX

Text Console은 Planner 선택 이유와 Experience 판단을, Task Monitor는 실제 기기 실행과 완료 evidence를 보여준다. 두 화면 모두 같은 correlation ID를 사용한다.

GOAL -> OBSERVE -> DECIDE -> ACT -> EVIDENCE

필수 표시 항목은 goal, phase, last observation, decision, reason, replan budget, device workflow와 content session, token·latency다. 물리 Task와 콘텐츠 세션은 서로 다른 lane으로 표시하며, 일부 trace가 없으면 이전 상태로 완료를 추정하지 않는다.

12. Acceptance Criteria

1. 하나의 Experience에서 device workflow와 content session이 각각 식별된다.
2. TaskManager 완료 전에는 의존 콘텐츠 단계를 완료로 처리하지 않는다.
3. 정상 progress마다 Cloud LLM을 재호출하지 않는다.
4. 사용자는 콘텐츠만 중단하고 물리 작업을 유지할 수 있다.
5. 실패 시 continue, substitute, ask, replan, cancel 중 하나가 근거와 함께 기록된다.
6. capability가 없는 음악·영상 기능을 임의로 약속하지 않는다.
7. 모든 자동 변경은 trace에서 이전/이후 계획을 비교할 수 있다.

13. 구현·운영 기준

14. Next Action

1. PUI 취소를 실기기에서 반복해 dependent step이 제출되지 않는지 확인한다.
2. 이동·청정·복귀·설정·바이탈·콘텐츠 provider별 terminal evidence matrix를 닫는다.
3. 실제 busy, timeout, policy failure가 Cloud의 구조화된 failure UX와 일치하는지 확인한다.
4. Experience positive와 near-negative에서 false admission과 기존 owner delta를 측정한다.
5. restricted device tier의 feature flag, rollback, token/P95 gate를 통과한 provider만 승격한다.

15. Related Documents

• Experience Goal-Directed Creative Motion Scenarios
• Experience Runtime Validation Closure 2026-08-05
• DeviceAgent Long-Running Observer And Proactive Agent
• TaskManager Device Context Planning Spec
• Voice Agent To SoC TaskManager Closed Loop
• TaskManager Live Monitor
• Memory and Personalization