← Docs hub

Adaptive Welcome & Care Supervisor

이 문서는 MR6 DeviceAgent의 자율주행, Vision, LLM, AWS, 환경 센서, 제품 interaction, TaskManager를 하나의 지속 목표 아래 조합하는 대표 Agentic 시나리오를 정의한다.

단순히 이동 -> 청정 -> TTS를 순서대로 호출하는 것이 아니다. 사용자의 귀가 경험을 목표로 유지하면서 기기 상태를 관찰하고, 필요한 기능만 선택하며, 실제 완료 evidence와 사용자 개입에 따라 계획을 바꾸는 Experience Supervisor다.

기계 판독용 설계 fixture:

• Adaptive Welcome & Care Plan Contract
• DeviceAgent Capability Cards
• Device Context v2 Schema

1. 한 줄 경험

사용자의 귀가를 감지하고, 실제 사용자 존재와 집 안 환경·기기 상태를 확인해 환영, 필요한 청정, 맞춤 브리핑을 제공한 뒤 안전한 상태로 복귀한다.

고정 루틴과 다른 점은 결과가 상황에 따라 달라진다는 것이다.

• 사용자가 아직 보이지 않으면 한 번 기다린 뒤 환영 interaction을 끝낸다.
• 공기질이 좋지 않고 작업 가능한 배터리가 있으면 청정을 제안하거나 시작한다.
• 배터리가 부족하면 청정을 생략하고 환영·안내 후 스테이션으로 복귀한다.
• AWS가 끊기면 로컬 interaction을 유지하고 event를 outbox에 보관한다.
• 사용자가 말하거나 취소하면 현재 domain을 pause·cancel하고 새 목표를 반영한다.
• 정상 진행 callback에는 Cloud LLM을 다시 호출하지 않는다.

2. 구현 상태 범례

현재 전체 Adaptive Welcome & Care 폐루프가 실기기에서 완성된 것은 아니다. 현재 가능한 것은 이동·청정·복귀·설정·TaskManager callback을 조합한 component E2E이며, 귀가 trigger·사람 존재·AWS freshness를 포함한 Supervisor는 BRIDGE_GAP과 CONTRACT_ONLY를 해소해야 한다.

대표 시나리오와 실행 가능성 스냅샷

대표 하나는 Adaptive Welcome & Care다. 이 시나리오를 기능을 단순 나열하는 데모가 아니라 DeviceAgent 기능·데이터·TaskManager evidence가 하나의 목표로 수렴하는 기준 시나리오로 사용한다. Adaptive Home Guardian은 stress scenario로 남겨 보안, Vision, 장기 관찰 부하를 검증하되 대표 경험의 구현 상태와 섞지 않는다.

현재 plan 10개 step을 deviceagent-cloud-runtime-binding.v1로 대조한 실행 가능성 스냅샷은 다음과 같다.

즉 현재 계획은 7개 connected step, 3개 partial step, blocked step 0개다. partial은 실패가 아니라 남은 계약 경계다. DeviceAgent 기능 자체는 존재하지만 Cloud capability adapter, workflow correlation, privacy-filtered observation, 또는 playback terminal evidence 중 하나가 아직 전체 폐루프로 연결되지 않은 상태를 뜻한다.

이 스냅샷은 계획의 모든 단계가 물리 E2E 완료됐다는 의미가 아니다. blocked=0은 금지된 capability를 계획에 넣지 않았다는 admission 결과이며, partial=3은 해당 경계를 닫기 전 target Experience를 E2E_VERIFIED로 승격할 수 없다는 뜻이다.

3. Agentic Loop

Goal

Supervisor가 유지하는 목표는 method 실행이 아니라 다음 경험 결과다.

goal: 사용자가 귀가했을 때 안전하고 쾌적하게 맞이한다
success:
  - 환영 interaction이 제품 정책 안에서 수행됨
  - 필요한 환경 조치가 과잉 실행 없이 수행됨
  - 사용자 개입이 즉시 반영됨
  - 기기가 idle 또는 충전 상태로 수렴함
constraints:
  - DeviceAgent 정책 우회 금지
  - raw Vision·자격증명·signed URL의 일반 LLM 노출 금지
  - 정상 progress에 Cloud 재추론 금지

Observe

Supervisor는 Capability Card의 context_reads 합집합만 읽는다.

Decide

Cloud Planner는 다음 중 하나를 의미 수준에서 선택한다.

continue interaction
skip optional cleaning
start admitted cleaning
deliver local or Cloud briefing
ask one focused question
return to station
cancel and compensate

Planner가 setMoveTo, interSchedule, setConfig 같은 low-level method를 자유 생성하지 않는다. Capability Card ID를 선택하고, runtime adapter와 DeviceAgent가 실제 method, queue, safety gate, terminal evidence를 결정한다.

Act

Evidence

명령 수락은 완료가 아니다. 다음 단계는 해당 capability의 completion target이 관찰된 뒤에만 진행한다.

Task STARTED
  != movement.arrived
  != cleaning.started
  != interaction.completed
  != movement.stationCharging

Task event에는 workflow_id, step_id, task_id, correlation_id, reason_code, requires_cloud_decision이 보존돼야 한다.

4. 현재 실기기 데모 범위

현재 바로 확인할 수 있는 축은 아래와 같다.

공간·배터리·공기질·TaskManager context
  -> Cloud 의미 판단
  -> 이동 또는 청정 또는 설정
  -> DeviceAgent TaskManager
  -> 물리 terminal callback
  -> 다음 단계 또는 복귀

검증된 기반:

• setMoveTo와 returnToStation의 물리 완료 callback
• setAirCleanerOperation 시작·정지 완료
• setConfig 나이트 모드 변경과 실제 post-check
• “1분 뒤 청정”, “1분 뒤 나이트 모드”의 DeviceAgent 예약 실행
• Cloud workflow/step ID가 task callback에 유지되는 correlation

아직 같은 E2E로 말하면 안 되는 항목:

• AWS/GPS 귀가 event가 Supervisor를 자동 시작하는 흐름
• 일반 Planner가 Vision 사람 존재 event를 구독하는 흐름
• Cloud A2A가 product_interaction start를 capability adapter로 제출하는 흐름
• TTS 재생 종료를 다음 단계 dependency로 쓰는 흐름

따라서 1차 데모는 수동 trigger와 현재 context를 사용한 적응형 청정·브리핑· 복귀로 구성하고, welcome/Vision/AWS 단계는 console에서 shadow로 표시한다.

5. Target Experience Flow

AWS/GPS 또는 제품 스케줄 trigger
  -> 공간·배터리·공기질·policy preflight
  -> product interaction 시작
  -> interaction.arrived
  -> Vision semantic presence 확인
     -> present: 환영과 환경 케어 계속
     -> absent: bounded wait 후 종료·복귀
     -> uncertain: privacy를 지키는 한 번의 사용자 확인
  -> 공기질·배터리 근거로 comfort action 선택
     -> clean / skip / ask
  -> LLM briefing 또는 로컬 콘텐츠
  -> 사용자 개입과 device event 관찰
  -> interaction 종료
  -> 스테이션 복귀
  -> semantic summary 저장

내부 stage가 이미 정의된 interSchedule은 Planner가 다시 이동·대기·환영 method로 분해하지 않는다. DeviceAgent interaction domain이 stage를 소유하고, Supervisor는 lifecycle과 결과만 관찰한다.

6. 로컬 판단과 Cloud 재계획 경계

Cloud 재계획은 requires_cloud_decision=true이거나, retry가 소진됐거나, 사용자 목표가 바뀌었을 때만 수행한다. callback마다 LLM을 호출하지 않는다.

runtime observation policy

현재 Cloud에는 active long-running experience가 catalog의 semantic observation contract를 구독하는 구조가 연결됐다.

DeviceAgent telemetry
-> workflow correlation 확인
-> catalog contract / privacy / freshness / step scope 확인
-> workflow_policy로 Supervisor 후보 승격
-> bounded decision

이 구조는 producer마다 requires_cloud_decision=true를 하드코딩하지 않는다. Planner가 현재 목표에 필요한 contract ID만 선택하고, runtime이 결정적으로 검증한다. AWS·LLM observation은 현재 unscoped이므로 catalog에 있어도 active workflow 자동 재계획을 일으키지 않는다. WSS observation은 active Security workflow correlation이 있을 때만 승격할 수 있다.

따라서 policy runtime은 코드 연결 상태지만 Adaptive Welcome 전체의 platform-signed 전체 E2E는 미검증이다.

7. 룰 기반으로 퇴행하지 않는 계약

이 시나리오는 자연어 표현 목록을 늘려 구현하지 않는다.

LLM이 결정하는 것

• 사용자 경험 목표와 성공 조건
• 의미 capability 선택
• step dependency와 조건
• 현재 evidence를 바탕으로 한 continue, skip, ask, return 선택
• local recovery로 해결되지 않는 경우의 bounded replan

Planner의 실행 출력은 capability_id + operation_id + typed arguments를 권위 있는 의미 계약으로 사용한다. 자연어 설명은 사용자 표시와 legacy fallback에만 남기며, 실행 직전에 발화를 다시 분해해 method를 고르는 자연어 재해석은 제거 대상이다.

결정적 runtime이 수행하는 것

• Capability Card ID를 실제 method로 변환
• 입력 enum과 schema 검증
• runtime room catalog grounding
• queue·resource lease·privacy·battery admission
• timeout·cancel·compensation
• 물리 terminal event 판정

Context fact는 값뿐 아니라 known/unknown/stale, 관찰 시각, source를 가져야 한다. unknown/stale, 지원하지 않는 operator, 누락된 context path는 실행 성공으로 간주하지 않고 재조회하거나 step을 막는 fail-closed 정책을 사용한다.

금지하는 구현:

if "귀가" in utterance: interSchedule(...)
if "사람" in utterance: Vision(...)
if "공기" in utterance: startCleaning(...)

권장 구현:

Planner -> capability_id + goal + dependencies + semantic conditions
Runtime -> catalog lookup + fresh context projection + device admission
TaskManager -> execution + evidence + typed reason
Supervisor -> bounded decision at semantic boundaries

Cloud typed-action dual-stack

Cloud A2A runtime에는 typed action 우선 경로가 구현되어 있다.

1. Main Router가 각 실행 step에 capability_id, operation_id, arguments를 생성한다.
2. Registry loader가 v2 capability의 지원 operation과 필수·선택 argument를 Planner context에 보존한다.
3. 등록된 device_context.map.rooms에서 사용자 요청과 일치하는 값이 정확히 하나이고 capability가 그 argument를 필수로 요구할 때만 구조적으로 binding한다. 예를 들어 move_to_room의 position_name을 채운다.
4. Compiler는 typed action을 catalog와 대조하고, capability·operation이 없거나 필수 argument가 누락되면 실행을 막는다.
5. 유효한 action만 legacy-compatible device bridge와 TaskManager request로 변환한다.
6. singleton task와 multi-step workflow 모두 semantic ID를 DeviceAgent 요청에 보존한다.

typed action이 존재하지만 유효하지 않은 경우 input.query를 다시 해석해 우회하지 않는다. 반면 action 없는 구형 plan은 현재 호환성을 위해 legacy 자연어 matcher를 사용한다. 따라서 신규 실행 경로는 카탈로그 기반 의미 계약이지만, 전체 runtime에서 legacy rule fallback이 제거된 상태는 아니다.

2026-07-29 라이브 Gemini 검증에서는 다음 결과를 확인했다.

첫 이동 응답에서 Gemini가 arguments={}를 반환하더라도 현재 device map에서 안방이 유일하게 grounding되면 runtime이 필수 slot을 채운다. map이 없거나 후보가 여러 개면 값을 추측하지 않고 typed action을 invalid로 유지한다. Cloud 관련 회귀 테스트도 typed action 권위, invalid action fail-closed, singleton·workflow semantic ID 보존을 포함해 통과했다.

여기서 검증된 범위는 실제 Gemini -> Cloud compiler -> TaskManager request 이다. DeviceAgent가 요청을 수신한 뒤 물리 동작을 완료하고 terminal callback을 반환하는 실기기 구간은 이번 검증에 포함되지 않았으므로 전체 경로를 E2E_VERIFIED로 올리면 안 된다.

현재 코드에서 확인된 구조적 공백

이 공백은 발화 예외를 추가해 해결할 문제가 아니다. Planner, context, TaskEvent 사이의 의미 계약을 끝까지 보존해야 한다.

8. 데이터 계약

Planner 입력

device_context:
  domains:
    spatial: semantic room and movement state
    battery: work budget and charging state
    environment: air-quality grade and cleaning state
    network: AWS/Wi-Fi state with freshness
    perception: person presence and low-light semantic state
    voice_llm: current session owner
    task_manager: workflow, step, queue, recent terminal
    capabilities: enabled, blocked, reason

각 domain은 available, freshness, provenance, planner_exposure, sensitivity, data를 가져야 한다. 값이 없으면 unknown이지 정상 상태가 아니다.

Planner 출력

steps:
  - id: run_welcome
    route: ODL
    action:
      capability_id: product_interaction
      operation_id: start
      arguments: {}
    depends_on: [preflight]
    execution_target: device
    wait_policy: completed
    output_key: welcome_result
  - id: decide_comfort
    route: EXPERIENCE
    execution_target: cloud
    executor_role: experience_supervisor
    input_from: [welcome_result, air_result, health_result]

이전 단계의 결과는 발화를 다시 해석해 전달하지 않고 output_key, input_from, typed step_results로 연결한다.

단계 결과 binding

대표 설계 계약은 a2a-step-result-binding-v1로 표현한다. 이 ID 자체를 runtime schema가 검증하는 것은 아니다. 현재 transport 권위는 a2a-task-orchestration-v1이며 cloud_output_key, step_id, step_results로 일부 binding을 수행한다.

observe_space
  -> output_key=spatial_state

observe_air
  -> output_key=air_assessment

decide_comfort_action
  <- input_from=device_health.result
  <- input_from=air_assessment.result
  <- input_from=network_health.result
  -> output_key=comfort_decision

start_cleaning_if_admitted
  <- input_from=comfort_decision.result
  <- input_from=spatial_state.result

Cloud workflow state는 output_key와 step_results를 보존한다. 다음 단계는 사용자 발화를 다시 해석하지 않고 typed result reference를 사용한다. Cloud result_contract_defaults는 미선언 payload를 기본 거부하며, capability의 bindable_result_fields와 destination slot schema를 모두 통과한 값만 다음 device task에 바인딩한다. 위반 시 STEP_RESULT_BINDING_FAILED로 실행을 막고 재계획을 기다린다. 현재 코드 연결 범위는 move_to_room과 stationary_purify result부터다.

bounded Experience Replanner가 catalog result 계약 안에서 동적 input_from을 생성한다. source는 앞선 step이자 명시적 dependency여야 하고, field와 destination slot은 양쪽 capability 계약에 모두 선언돼야 한다. result-dependent plan은 첫 ready step만 제출하며, callback이 후속 step을 해제한다. 따라서 모든 DeviceAgent domain result가 풍부한 payload를 반환한다고 간주하면 안 된다. 나머지 capability의 result schema는 후속이며, platform-signed 연쇄 실기기 E2E도 아직 검증하지 않았다.

전체 함수·데이터·증거 평면은 DeviceAgent Agentic I/O Coverage Matrix에서 본다.

9. Token·Latency·상태 예산

Supervisor를 추가해 핵심 음성 성능을 떨어뜨리면 안 된다.

raw Map 좌표 전체, Vision bbox, unrestricted log, MQTT payload를 prompt에 넣지 않는다. Capability Card의 context_reads로 필요한 domain만 투영한다.

10. Console 관측 UX

A2A console에는 아래 다섯 lane을 표시한다.

1. Goal: 현재 경험 목표와 성공 조건.
2. Observe: 최신 domain summary, freshness, unavailable reason.
3. Decide: 선택한 capability, alternatives, replan budget.
4. Act: DeviceAgent workflow/step/task와 현재 terminal target.
5. Evidence: 물리 callback, 사용자 개입, typed reason.

DEVICE_CURRENT와 BRIDGE_GAP을 같은 색으로 표시하면 안 된다. 사용자는 기기에 함수가 있는 것과 A2A E2E가 연결된 것을 화면에서 바로 구분해야 한다.

11. 구현 순서

Phase 1: 현재 기능으로 Shadow Supervisor

1. 수동 trigger에서 v1 context를 읽는다.
2. 이동·청정·설정·복귀 plan을 만들되 기존 검증된 adapter만 사용한다.
3. comfort decision과 생략 이유를 console에 shadow 표시한다.
4. normal progress에는 Cloud를 재호출하지 않는다.

Phase 2: Product Interaction Bridge

1. product_interaction capability를 Cloud catalog에 등록한다.
2. on-device adapter가 interSchedule typed input을 만든다.
3. DeviceAgent의 기존 interaction lifecycle을 completion target으로 사용한다.
4. 내부 interaction stage는 DeviceAgent 소유로 유지한다.

Phase 3: Perception And Network Context

1. 일반 Vision raw report를 privacy-filtered semantic event로 변환한다.
2. AWS·LLM observation에 발화 내용 없이 active workflow correlation을 연결한다.
3. device_context.v2 producer와 Capability Card projector를 연결한다.
4. ordered durable outbox로 task/semantic event를 전달한다.

Phase 4: Target Agentic Experience

1. AWS/GPS 또는 제품 스케줄 trigger를 Experience Supervisor에 연결한다.
2. resource lease와 user interruption을 통합한다.
3. bounded replan과 compensation을 실기기에서 검증한다.
4. 목표 달성·취소·네트워크 단절·저전력 시나리오를 회귀 테스트한다.

12. 기능·데이터 근거

13. 관련 문서

• DeviceAgent Agentic I/O Coverage Matrix
• DeviceAgent Agentic Function And Data Catalog
• DeviceAgent Agentic Capability Composition Guide
• A2A Experience Supervisor
• DeviceAgent Device Context v2 Contract
• Cloud Planner · On-device · DeviceAgent Data Flow
• Cloud·On-device·TaskManager Closed Loop