← Docs hub

DeviceAgent Agentic Function And Data Catalog

이 문서는 A1 기기의 기능을 새로운 Agentic 시나리오로 조합하기 위한 기능·데이터 카탈로그다. MR6 DeviceAgent, IotAgent, on-device Agent, Cloud A2A Planner, TaskManager의 실제 경계를 기준으로 작성했다.

핵심은 함수를 호출할 수 있다와 장기 workflow의 한 단계로 안전하게 연결할 수 있다를 구분하는 것이다.

0. 분석 기준

이 문서의 현재는 위 working tree를 포함한다. base SHA만 checkout하면 일부 TaskManager, on-device bridge, Cloud orchestration 파일이 없을 수 있다.

1. 기능 성숙도

MR6의 TaskExecutorBootstrap에는 60개 등록 task method가 있고, 이 method들은 11개 executor 객체에 나뉘어 매핑된다. 등록 method 수와 executor 구현체 수는 같은 지표가 아니다. 또한 DeviceAgent 전체 기능은 이보다 훨씬 넓다. MainApi, AMR/Vision/IoT/Streaming/WSS AIDL, domain manager가 가진 기능 중 일부만 TaskManager에 편입된 상태다.

현재 자동 감사 범위에는 AMR·Vision·IoT·Streaming AIDL의 68개 저수준 AIDL method도 포함한다. 이 중 47개가 AMR, 3개가 Vision, 4개가 IoT, 14개가 Streaming surface다. 이 목록은 Planner에 직접 노출되는 목록이 아니다. 저수준 함수, lifecycle 관리 함수, 의미 capability를 같은 평면으로 취급하면 LLM이 안전 정책과 완료 조건을 우회하게 된다.

1.1 네 개의 실행 평면

요약하면 68개 저수준 AIDL method, 60개 TaskManager 등록 method, 24개 Capability Card 연결 task method를 서로 다른 실행 평면으로 관리한다.

Capability Card ID와 Cloud runtime capability ID는 항상 같지 않다. 예를 들어 설계 Card start_room_cleaning은 현재 Cloud catalog의 stationary_purify에 연결된다. 반복·일회성 예약은 SCH와 scheduleTask/scheduleWorkflow, 단계 상대 지연은 after_step workflow primitive를 사용한다. 이 연결은 deviceagent-cloud-runtime-binding.v1 manifest로 관리한다.

Capability Card의 runtime.task_methods에는 MR6 TaskExecutorBootstrap에 실제 등록된 method만 둔다. Binder·TaskManager framework API인 submitWorkflow, scheduleWorkflow, getDevicePlanningContext는 framework_methods로 분리한다. 이는 발화 규칙이 아니라 실행 평면 정합을 위한 경계다. 즉 발화 규칙이 아니라 실행 평면 정합을 관리한다.

60개 method의 Cloud 계획, On-device 전달, DeviceAgent 완료 증거를 분리한 상세 표는 DeviceAgent Executor Closure Matrix를 기준으로 한다.

1.2 기능군을 Agent 관점으로 다시 묶기

이 표에서 Decide는 임의 DeviceAgent method 선택을 뜻하지 않는다. Cloud Planner/Supervisor가 목표와 의미 capability를 선택하고, DeviceAgent가 현재 상태·정책·resource·물리 완료를 다시 판정한다.

2. 시스템 책임과 데이터 흐름

아래는 목표 폐루프다. 현재 MR6 DeviceAgent, Cloud A2A, on-device Agent feature_a2a_task_orchestration_bridge에는 planning context, orchestration response, workflow 제출, task-event relay 골격이 연결돼 있다. task event와 semantic observation은 DurableOrderedDeviceEventOutbox를 통해 app-private queue에 먼저 저장되고 순서대로 전송된다. 다만 이 파일을 포함한 일부 bridge는 현재 working tree의 untracked WIP이므로, branch 추적과 실기기 kill/restart replay 증거는 아직 남아 있다.

사용자 목표
  -> Cloud A2A Router / Planner
     - 의미 capability 선택
     - 단계, 의존관계, 조건, 시간 구조화
  -> on-device Agent Bridge
     - Cloud plan을 DeviceAgent Bundle 계약으로 변환
     - task event와 context를 Cloud로 relay
  -> DeviceAgent TaskManager
     - queue, timeout, cancel, completion, retry, schedule 소유
  -> domain manager
     - AMR / Cleaning / Vision / WSS / Streaming / LLM / Schedule
  -> 물리 상태와 callback
     - task event + device context
  -> Cloud A2A bounded replan

2.1 현재 on-device 경로

현재 feature_a2a_task_orchestration_bridge@b857a620의 실제 경로:

STT
  -> ForegroundService.buildVoiceContext
     -> DeviceCommunicator.getDevicePlanningContext
     -> voice_context.device_context
  -> Cloud chat request
  -> orchestration.device_workflow_requests / device_task_requests
  -> DeviceCommunicator submitWorkflow / submitTask
  -> DeviceAgent TaskManager
  -> onTaskEvent callback
  -> Cloud /task_event
  -> workflow delta / 후속 device request / bounded replan

현재 branch의 VoiceContext, ChatRequest, OrchestrationResponse, TaskEventRequest에는 필요한 payload가 있고, DeviceCommunicator도 getDevicePlanningContext, workflow/task 제출, callback relay를 구현한다. 다만 다음 문제가 남는다.

• callback relay의 durable queue·순서 전송·restart replay 코드는 연결돼 있지만 실기기 kill/restart와 운영 dead-letter 검증이 없음
• CloudTaskEventOrchestration, TaskManagerDeferredScheduleGateway는 runtime call site에 연결돼 있으나 현재 untracked WIP 파일이므로 branch 추적과 통합 검증이 필요함
• orchestration 처리 뒤에도 choices[0]을 강제해 orchestration-only 응답이 실패할 수 있음
• token budget 계산 뒤에 voice_context.device_context가 추가돼 request 크기 증가가 budget에 반영되지 않음
• debug log가 전체 outbound JSON을 출력하는 경로가 있어 context privacy와 log size 제어가 필요함

따라서 이 문서의 Agentic 시나리오를 실사용하기 전에 on-device bridge를 현재 branch 안에서 추적 가능한 단위로 정리하고, ordered durable callback, workflow persistence, Binder reconnect 시 명령 보존, orchestration-only 응답 처리를 먼저 해결해야 한다.

3. 자율주행과 Map

3.1 실제 함수

AMR AIDL은 다음 저수준 기능을 제공한다.

• Mapping 시작·중지, Map 조회·저장·복사·초기화
• 주행 시작·일시정지·재개·중지
• x/y/theta 목표 이동, Area/Position 목표 이동
• 스테이션 복귀·도킹, 스테이션 재위치
• 수동 v/w 이동, 회전
• Follow-me 시작·상태 조회
• Lidar, sensor query, emergency stop
• motor 진단, AI calibration, OTA, version/temperature 조회

Planner가 직접 저수준 AIDL method를 고르지는 않는다. 의미 capability가 아래 TaskManager method로 변환된다.

3.2 관찰 데이터

현재 device_context.v1에 포함되는 Map/위치 데이터:

map:
  available: true
  editable: false
  room_count: 4
  rooms:
    - id: "2"
      name: "거실"
      x: "..."
      y: "..."
      theta: "..."
      station: false
location:
  current_room_id: "2"
  current_room_name: "거실"
  x: "..."
  y: "..."
  theta: "..."
  is_on_station: false
movement:
  moving_status: 0
  is_moving: false
  is_paused: false

3.3 조합 제약

• Planner는 임의 좌표를 생성하지 않고 runtime room catalog를 사용한다.
• map.editable=true이거나 room catalog가 없으면 이동 plan을 제출하지 않는다.
• 이동 완료는 명령 수락이 아니라 movement.arrived와 idle을 기준으로 한다.
• 청정 중 이동이 필요하면 stopCleaning -> cleaning.stopped -> setMoveTo로 구성한다.
• 장애물·주행 오류·배터리 부족은 local retry와 Cloud replan을 구분한다.

현재 구현상 추가 위험:

• setMoveTo strict validator는 positionId, positionName, position, positionIds만 허용하지만 executor는 areaId, targetRoom, roomName도 입력으로 사용한다. strict 검증이 켜지면 정상적인 room-grounded plan이 거절될 수 있다.
• 좌표는 비어 있지 않은지만 검사하고 숫자 범위·Map 내부·장애물 영역을 엄격히 검사하지 않는다.
• 방 이름 부분 일치의 첫 결과를 선택할 수 있어 모호한 POI가 잘못 resolve될 수 있다.
• 좌표 숫자 변환 실패가 0으로 남으면 station 좌표로 오인될 가능성이 있다.
• MapManager.getAreaListById* 두 경로가 TODO로 남아 있고, 일부 station 판정은 문자열 값 비교가 아닌 참조 비교 ==를 사용한다.
• 취소 terminal은 취소 method 호출 성공과 실제 AMR 정지를 완전히 구분하지 못한다.

따라서 외부 Planner 입력에는 strict numeric/range/map validation과 모호한 POI 거부가 필요하다.

4. 청정과 환경

4.1 실제 실행 기능

4.2 환경 데이터

현재 Planner context가 받는 실내 데이터:

• PM10, PM2.5, PM1.0
• TVOC, NOx, HCHO, CO2
• 온도, 습도
• 통합 공기질 등급
• 청정 실행/일시정지, 최근 action, 대상 area

DeviceAgent에는 실외 공기질·날씨, AQM 목록, outdoor 연동 청정, 청정 리포트도 존재하지만 모두 device_context.v1에 포함되지는 않는다.

현재 MR6 공기질 snapshot은 센서 원천의 source_valid, observed_at_ms, freshness_ms, ttl_ms, stale, usable을 포함한다. 웜업 중 sample은 source_state=warming_up, usable=false로 표시하며, Cloud는 해당 수치를 조건과 답변에서 제외한다. 다만 방별 과거 추세와 실기기 sample cadence에 근거한 TTL 검증은 남아 있으므로, 단일 현재값만으로 장기 자율 청정 정책을 확정하지 않는다.

4.3 Agent 활용

상태 조회 -> 수치 해석 -> 사용자 상황/시간대 확인
-> 청정 제안 또는 자동 실행 -> 개선 추세 관찰 -> 종료/연장 결정

공기질 수치 자체는 task가 아니라 observation이다. Planner는 수치 이름을 그대로 TTS로 나열하지 않고, freshness와 등급을 확인한 뒤 사용자 언어로 요약한다.

배터리와 공기질은 주기 sample TTL을 사용하고 AWS·음성 LLM 상태는 현재 부팅에서 producer가 보고한 event-driven 상태로 관리한다. 자세한 필드와 호환 정책은 Device Source Freshness Contract를 참조한다.

4.4 실행 계약 점검

• basic 청정은 cleanMinTimeMs=0이 기본이고 완료 목표가 cleaning.stopped다. 호출자가 dwell을 주지 않으면 시작 직후 stop 경로로 진행될 수 있다.
• stopCleaning·ampStop은 TaskManager executor에는 등록돼 있지만 LegacyCommandAdapter와 FrameworkCommandBridge에는 대응 command가 없다. 등록 여부와 실제 domain 실행 가능 여부를 같은 것으로 보면 안 된다.
• 방별 공기질 순회 기능은 AirQualityMappingController에 있지만 1급 TaskManager method와 completion contract로 승격되지 않았다.

5. Vision AI와 사람 인식

5.1 현재 로컬 Vision 기능

VisionAIManager는 VisionAgent의 object detection report를 받아 class, confidence, bbox, light_level을 처리한다.

Vision은 setVisionEnable로 활성화/비활성화되며, 카메라 연결을 3초 주기로 점검해 camera error를 보고한다.

5.2 현재 한계

• raw detection은 device_context.v1에 없다.
• WSS 경로에는 vision.low_light_changed, security.person_detected, security.verification_result 의미 이벤트가 연결돼 있다.
• WSS는 Vision listener를 사용하지만, 다른 Agentic 시나리오가 같은 detection stream을 안전하게 구독하는 계약은 없다.
• WSS request_id는 domain 인증 세션 상관관계이며 Cloud workflow_id/step_id로 대체하지 않는다. TaskManager가 시작한 WSS session은 별도 allowlist correlation을 코드상 보존하지만 실기기 E2E 증거는 아직 없다.
• 코드상 privacy 확인이 고정값인 구간이 있어, Planner 노출 전에 실제 privacy gate 정합이 필요하다.
• Vision report null 검사에 &&가 사용돼 null 입력에서 예외가 날 수 있다.
• Vision service disconnect 뒤 callback 해제 순서가 안전하지 않다.

따라서 현재처럼 지속 감지된 사람, 저조도, 인증 outcome만 노출하고 raw bbox/frame과 이름, member ID, 얼굴 유사도, PIN은 Cloud prompt에 넣지 않는 것이 맞다. Cloud Planner는 이 중 non-stale allowlist event를 최대 6건만 다음 turn context로 사용하며, event type만으로 재계획하지 않는다.

5.3 현재 의미 관찰 경계

VisionAIManager raw report
  -> WssVisionObserver debounce/confidence 판정
  -> WssManager domain 의미 확정
  -> WssSemanticObservationAdapter
  -> identity-free semantic observation

세 이벤트는 현재 requires_cloud_decision=false인 telemetry다. TaskManager 시작 Security session은 workflow/step correlation을 포함할 수 있지만, correlation 존재나 event type만으로 실시간 Supervisor 재계획을 주장하지 않는다.

6. WSS 보안 순찰

6.1 실행과 상태

WSS는 단순 카메라 on/off가 아니라 이동·사람 탐지·PIN/얼굴 인증· event asset 업로드를 포함한 자체 state machine이다.

현재 TaskManager registry와 Cloud security_patrol capability에는 start/pause/resume/stop이 연결돼 있다. 이미 같은 상태인 요청은 idempotent 성공으로, 불가능한 전이는 abort로 기록한다. 이 성숙도는 코드·JVM 회귀 기준이다.

2026-07-30에는 platform-signed MR6 DeviceAgent를 실기기에 배포하고 TaskManager security queue의 startSecurityMode dry-run이 PENDING -> STARTED -> COMPLETED와 terminal callback으로 끝나는 것을 확인했다. 실제 checkSecurityBasicAvailability도 MainApi 경로에서 완료됐지만 현재 보드 상태는 available=false, reasonCodes=5였다. 이 bitmask는 WSS 미구독과 PIN 미등록을 뜻하며 privacy, home lock, network, tilting, camera 오류는 아니다. 따라서 실제 WSS session의 시작·pause·resume·stop과 Vision 연계 E2E는 아직 검증 전이다.

6.2 WSS 상태 모델

wss:
  running_state: stopped | started | paused
  stage: idle | person_detecting | verify_pin | verify_face
  moving_state: stopped | moving | paused
  current_index: 0
  current_room: "거실"
  paused_by_low_battery: false
  mode: basic | all | selected
  repeat_patrol: true
  patrol_interval: 300
  end_time: "23:00"

가용성 차단 사유:

• 미구독, 얼굴 벡터/PIN 없음
• 프라이버시 모드, 홈 잠금
• 네트워크 오류, 배터리 부족, Map 없음
• 주행부·틸팅·카메라 오류
• VitalSign 등 다른 상호배타 기능 실행 중

6.3 재계획 포인트

• 배터리 부족: 순찰 pause, 스테이션 복귀, 충전 후 resume.
• 사람 감지: 이동 pause, PIN/얼굴 검증, 결과에 따라 재개 또는 사용자 알림.
• 저조도: 증거 품질 저하를 알리고 대체 확인 수단 사용.
• 네트워크 단절: 로컬 감지는 유지하고 업로드 recovery queue로 전환.
• 종료 시각 도달: WSS domain이 종료하고 terminal event를 발행.

7. LiveView와 원격 이동

StreamingManager는 별도 IStreamingControl 계약을 사용한다.

현재 No-Go: WssService와 StreamingService가 exported 상태지만 signature permission이 없고, Streaming Binder Stub의 start/stop/upload/ manual movement/rotate에 호출자 UID·패키지·서명 검증이 없다. 현재 상태로 외부 Agentic capability에 노출해서는 안 된다.

스트리밍 시작 시 Vision AI와 자원 경합을 조정하며, VitalSign 실행 중에는 시작을 거부한다. 현재 LiveView는 TaskManager registry에 포함되지 않아 복합 workflow 중간 단계로 직접 사용하면 안 된다.

필요한 보강:

1. Service signature permission과 Binder caller 이중 검증.
2. startLiveView/stopLiveView semantic capability.
3. streaming.started/stopped/failed terminal event.
4. WSS/Vision/VitalSign/LLM과의 resource lease.
5. 사용자 consent와 privacy policy.
6. signed URL 만료와 업로드 failure recovery.

8. LLM, STT, TTS와 콘텐츠 Agent

8.1 DeviceAgent LLM 상태

8.2 실제 기능

• LLM 상태 변경, 음성 guide type, language 변경
• TTS 요청·중단, wake-word에 의한 외부 TTS cancel
• 실외 날씨/공기질 데이터 전달
• privacy/home-lock 변경 알림
• AI log와 S3 URL response
• Follow-me TTS와 pending TTS
• Cloud/on-device LLM 실행 상태 관찰

TaskManager에는 setChangeLlmStatus, setLlmTts, stopLlm, stopTts가 등록돼 있다. 다만 setLlmTts는 재생 요청 완료일 뿐 TTS 재생 종료가 아니다. tts.playbackCompleted가 없으므로 “안내가 끝난 뒤 이동” 같은 강한 순서 계약에는 아직 사용할 수 없다.

콘텐츠 Agent는 DEF/FRG/STM/ETR 등이 소유하고, DeviceAgent는 음성 출력과 세션 상태만 소유한다. 퀴즈·이야기·뉴스 요약을 DeviceAgent method로 하드코딩하지 않는다.

9. AWS IoT, MQTT와 Cloud

9.1 실제 경로

AWS IoT MQTT topic
  -> IotAgent CmdTopic
  -> command JSON parsing
  -> IIotControl.sendModuleCommand
  -> DeviceAgent MainApi
  -> legacy 실행 또는 TaskManager submitTask
  -> response publish

IotTaskManagerBridge는 command에 task metadata 객체가 있을 때 기존 method를 submitTask로 감싼다. task.managed=false를 명시하면 legacy 경로를 유지하고, managed가 생략된 task 객체는 현재 구현상 true가 기본값이다. task 객체 자체가 없으면 legacy 경로를 유지한다.

보존되는 metadata:

• executionMode, priority, queueKey
• completionTarget, completionAreaId
• preemptPolicy, failurePolicy
• cancelMethod, compensationMethod
• timeoutMs, cancellable, stateAware
• cloud_workflow_id, cloud_step_id, cloud_plan_id
• cloud_output_key, wait_policy
• traceId, correlationId, replyTo

따라서 AWS 명령 전체가 자동으로 TaskManager에 들어가는 것은 아니다. 기존 topic 호환을 유지하면서 task metadata가 있는 명령을 lifecycle 관리 대상으로 승격하며, 명시적 opt-out은 managed=false다.

9.2 AWS 기능군

• 설정·초기 상태·Map·AQM·청정·이동 명령
• schedule 등록/조회/동기화
• firmware version·latest version·OTA
• outdoor weather/air-quality 요청
• device log 업로드
• AI log와 S3 signed URL
• WSS subscription, event asset, streaming control
• command response와 correlation 기반 결과 publish

9.3 관찰 주의

DeviceAgent의 getAwsConnect는 live probe가 아니라 IotAgent callback이 써주는 캐시다. aws_connect_cached, Wi-Fi 상태, 최근 publish error, 마지막 성공 시각을 함께 봐야 Cloud 가용성을 판단할 수 있다.

현재 Connected callback 뒤 subscribe를 요청하면 연결 완료로 처리하며 SUBACK evidence는 없다. 앞으로는 transport_connected, subscription_ready, last_transition_at, publish ACK를 분리해야 한다.

추가 계약 위험:

• MQTT task metadata가 execution mode, priority, queue, timeout, cancel/compensation, dryRun까지 override할 수 있다. device-side allowlist가 최종 정책을 소유해야 한다.
• 기존 moveTo response는 물리 도착이 아니라 “이동 시작 accepted”에 가깝다. response와 terminal event를 분리해야 한다.
• correlation ID가 단일 mutable 상태인 구간은 중첩 명령에서 결과가 섞일 수 있다.
• timestamp parse 실패가 명령 거부로 수렴하지 않는 구간과 WSS/Streaming freshness 검사가 다른 구간이 있다.

10. 스케줄, Interaction, 앱 세션

10.1 세 가지 시간 계층

Cloud가 시간을 직접 세지 않는다. Planner는 시간과 의존관계를 구조화하고 DeviceAgent가 Alarm/queue/condition을 관리한다.

10.2 제품 Interaction

세부 단계:

started -> arrived -> actionStarted -> actionEnded -> returning -> completed

기존 interaction은 pause/resume/return 정책이 있으므로 Planner가 내부 동작을 작은 raw command로 다시 만들기보다 interSchedule domain capability를 호출하는 것이 안전하다.

10.3 VitalSign과 Launcher 앱

VitalSign은 setLauncherScreen으로 앱을 열고 setAppStatus를 통해 app.sessionStarted/Ended를 관찰할 수 있다.

현재 한계:

• session end가 측정 성공인지 사용자 취소인지 구분하지 못한다.
• 사용자가 실제 측정을 완료할 때까지 terminal 시점이 길고 불확실하다.
• Streaming/WSS와 상호배타 상태다.

따라서 현재는 app.sessionEnded 뒤 사용자 확인 또는 typed result event가 필요하다. 단순 timeout을 성공으로 처리해서는 안 된다.

11. 기기 건강, 정비와 정책

DeviceAgent 내부에는 다음 데이터가 있다.

배터리·공기질·Map·이동·청정 외에 AWS cache, LLM pipeline, WSS Security, 최근 의미 관찰까지 현재 planning context에 들어왔다. 다음 확장 우선순위는 policy_blockers -> streaming -> maintenance -> resource다.

12. 현재 Planning Context와 Blind Spot

12.1 현재 제공

device_context.v1:
  main_state: "..."
  battery: {}
  map: {}
  location: {}
  air_quality: {}
  cleaning: {}
  movement: {}
  network:
    aws_iot_connected: false
    source: "iot_agent_status_cache"
  voice_llm:
    pipeline_state: "idle"
    voice_session_active: false
    model_readiness: "unknown"
  security:
    session_state: "stopped"
    stage: "idle"
    current_area_id: ""
    low_light: false
  interactions:
    registered_count: 0
    exposed_count: 0
    registered_schedules: []
  semantic_observations:
    contract_version: "device-semantic-observation.v1"
    event_count: 0
    recent: []
  task_manager:
    busy: false
    running_tasks: []
    queue_summary: []
  capabilities:
    movement: true
    room_cleaning: true
    return_to_station: true
    tts: true
    schedule: true

network, voice_llm, security, interactions, semantic_observations는 현재 DevicePlanningContextProvider가 생성한다. 다만 AWS 값은 live probe가 아니며, LLM model readiness는 native 생존 증거가 없어 unknown이다.

policy blocker·Streaming·maintenance·resource는 아직 미노출 상태다.

semantic observation과 task-event 응답이 같은 OrchestrationResponse 실행 관문을 사용한다. 이 관문은 workflow state와 agent activity를 반영한 뒤 device_workflow_requests, device_task_requests, device_control_requests를 기존 TaskManager bridge에 전달한다. 서비스 handler가 없는 경우에는 DeviceCommunicator의 범용 fallback을 사용하고, 기존 task-event handler도 호환 경로로 유지한다.

따라서 Cloud가 만든 의미 판단을 On-device 실행 요청으로 연결하는 코드 공백은 닫혔다. 다만 platform-signed 실기기에서 observation → Supervisor → replan → TaskManager → physical terminal까지 확인한 E2E 증거는 아직 없다.

12.2 추가해야 할 관찰 계약

raw frame, bbox, 전체 로그를 prompt에 넣지 않는다. 각 domain이 freshness가 있는 semantic summary를 제공해야 한다.

12.3 Autonomy의 현재 의미

현재 MR6에서 AUTONOMOUS는 독립적인 자율 Planner가 아니라 TaskSource와 caller policy의 출처 분류 수준이다. 별도 autonomy producer, plan provenance, 취소·보상·physical terminal 계약은 아직 없다. 따라서 “DeviceAgent가 자체 목표를 세우고 재계획한다”고 표현하면 안 된다.

13. 실제 TaskManager lifecycle

현재 MR6에서 실제 사용하는 task event:

• STARTED, PROGRESS, COMPLETED, FAILED, CANCELLED
• WORKFLOW_STEP_STARTED, WORKFLOW_STEP_WAITING, WORKFLOW_STEP_COMPLETED
• 예약 task admission의 BLOCKED

TIMEOUT, NEEDS_USER_INPUT을 모든 task의 독립 event name으로 가정하면 안 된다. 일반 task의 timeout과 정책 차단은 주로 FAILED와 reason_code=TIMEOUT|STATE_CONDITION_FAILED|CAPABILITY_UNAVAILABLE처럼 reason으로 구분한다. 다만 예약 task는 admission 시점의 busy 또는 missed-run 만료를 BLOCKED + reason_code=TASK_MANAGER_BUSY| MISSED_RUN_EXPIRED로 내보낸다. Cloud A2A는 경로별 event 이름과 reason을 함께 해석해야 한다.

movement.arrived, cleaning.stopped, security.started 등은 task event 이름이 아니라 executor가 기다리는 completion target이다.

14. 기능 조합 레시피

현재 E2E에 가까운 이동·환경·Interaction 조합은 Adaptive Welcome & Care Supervisor에서 본다. 자율주행·Vision·WSS·AWS·LLM까지 DeviceAgent 전체 기능을 하나의 목표로 묶은 장기 대표 설계는 Adaptive Home Guardian Supervisor에서 본다.

15. 대표 Agentic 시나리오: Adaptive Home Guardian

전체 Goal/Observe/Decide/Act/Evidence 흐름, 현재 연결 상태, 검증 시나리오는 전용 Supervisor 문서에 정리했다.

15.1 목표

사용자 부재 중 집을 순찰하고, 환경과 보안 상태를 관찰하며, 배터리· 네트워크·프라이버시 제약에 맞춰 계획을 바꾸는 장기 Agent다.

goal:
  protect_home: true
  preserve_privacy: true
  return_to_station: true
success_criteria:
  - requested_patrol_areas_observed
  - meaningful_events_handled
  - device_safely_docked
constraints:
  - never_bypass_device_policy
  - no_raw_video_to_llm
  - user_can_cancel
  - bounded_cloud_replan

15.2 초기 계획

1. WSS 가용성, Map, 배터리, 네트워크, privacy 확인
2. 순찰 Area와 종료 조건 확정
3. WSS 시작
4. 각 Area 이동
5. Vision person/low-light event 관찰
6. 의미 event가 있으면 이동 pause + PIN/face 검증
7. 필요할 때만 암호화 clip 업로드와 사용자 알림
8. 순찰 완료 또는 배터리 조건에서 스테이션 복귀
9. 결과 요약

15.3 관찰과 재계획

15.4 Experience state

experience:
  contract_version: experience.v1
  kind: adaptive_home_guardian
  status: active
  phase: patrolling
  current_area_id: "2"
  remaining_area_ids: ["3", "6"]
  device_workflow_id: "wf_guardian_001"
  security:
    state: started
    stage: person_detecting
    paused_by_low_battery: false
  observation_subscriptions:
    - movement.arrived
    - security.person_detected
    - security.verification_result
    - vision.low_light_changed
    - security.patrolCompleted
    - network.awsChanged
    - battery.low
    - voice.sessionChanged
  replan_budget:
    local_retries: 1
    cloud_replans: 2
    user_questions: 1

15.5 이 시나리오가 Agentic인 이유

• 고정 step 실행이 아니라 집 보호라는 상위 목표를 유지한다.
• Vision, WSS, 이동, 배터리, AWS, LLM 상태를 계속 관찰한다.
• 의미 있는 경계에서만 plan을 바꾼다.
• 네트워크가 끊겨도 로컬 안전 기능은 유지한다.
• 원본 영상 대신 요약 event와 암호화 asset을 사용한다.
• 실패 시 무조건 중단하지 않고 재시도·대체·질문·복귀를 선택한다.

16. 구현 단계

Security Gate: 외부 노출 전 필수

1. WSS/Streaming exported service를 signature permission으로 보호한다.
2. Binder Stub에서 UID, 허용 패키지, platform certificate를 재검증한다.
3. 외부 task metadata는 device-side policy allowlist로 제한한다.
4. 이동 좌표와 Area resolve를 strict validation으로 바꾼다.
5. accepted response와 physical terminal event를 분리한다.

Phase 0: on-device bridge 정합

1. Cloud orchestration request/response와 DeviceAgent TaskManager Binder API를 하나의 coherent branch에 통합한다.
2. reconnect 전후 명령 큐와 초기 상태를 보존한다.
3. task event에 event ID와 idempotency key를 부여하고 durable outbox로 순서 있게 전송한다.
4. workflow 상태를 영속화하고 동시 workflow, PAUSED, terminal dedup을 정의한다.
5. orchestration-only 응답을 choices 없이 처리한다.

Phase 1: 관찰 계약

1. 현재 voice_llm, network, WSS snapshot과 최근 allowlisted semantic event projection을 유지하고 policy 상태를 추가한다.
2. person/low-light/verification event의 workflow/step correlation을 platform-signed 실기기에서 검증하고 asset lifecycle을 연결한다.
3. WSS pause/resume/stop TaskManager capability의 실기기 E2E를 검증한다.
4. task event에 domain stage와 reason freshness를 보존한다.

Phase 2: Resource lease

1. Security·Streaming·VitalSign의 확정 충돌은 typed task와 현재 상태를 사용하는 TaskDomainResourcePolicy로 1차 코드화했다.
2. Planner는 capability를 선택하고 DeviceAgent가 각 workflow step 실행 직전에 admission을 다시 판정한다.
3. recovery를 위해 Security pause/resume/stop은 충돌 상태에서도 허용한다.
4. Vision, motion, mic, display와 parallel child 선점까지 포괄하는 공통 owner/lease registry는 후속 과제다.

Phase 3: Adaptive Home Guardian MVP

1. 보안 순찰 시작·완료·복귀 workflow.
2. 사람/저조도/저전력/AWS 단절 event.
3. local retry와 bounded Cloud replan.
4. A2A console에서 phase, current area, domain state, decision reason 표시.

Phase 4: 기능 확장

• LiveView managed capability
• VitalSign typed result
• maintenance proactive Agent
• 환경 기반 청정 Supervisor
• 콘텐츠/interaction 동반 시나리오

17. 검증 기준

18. 관련 문서

• DeviceAgent Agentic I/O Coverage Matrix
• DeviceAgent Agentic I/O Coverage JSON
• DeviceAgent Semantic Observation Catalog
• Semantic Observation Catalog JSON
• Agentic Capability 조합 가이드
• Device Context v2 계약
• Capability Card Catalog JSON
• Adaptive Home Guardian Supervisor
• Adaptive Home Guardian Plan JSON
• Agentic Capability 변경 이력
• A2A-TaskManager 기능 조합 카탈로그
• Adaptive Welcome & Care Supervisor
• DeviceAgent Long-Running Observer
• A2A Experience Supervisor
• Cloud-On-device-DeviceAgent 데이터 흐름