← Docs hub

SK-Intellix Reactive and Proactive Operation

이 문서는 SK-Intellix의 reactive / proactive 동작 축을 정리한다.

기존 A2A 설명은 주로 “사용자가 말하면 Cloud가 판단하고 실행한다”는 reactive voice-turn 중심이었다. 하지만 실제 Cloud repo에는 proactive request branch, proactive feedback branch, proactive planner/runtime/assets/schema가 존재한다. 따라서 위키에도 reactive/proactive를 별도 운영 모드로 포함해야 한다.

1. 배경

SK-Intellix가 단순 음성 명령 시스템에서 context-aware 기기/로봇 brain으로 확장되려면 두 가지 입력 모드를 모두 다뤄야 한다.

즉 proactive는 reactive를 대체하는 것이 아니라, planner를 깨우는 입력 원천을 늘리는 것이다.

2. 왜 필요한가

3. 현재 Cloud 구현 근거

현재 Cloud Lambda는 아래 request kind를 분기한다.

현재 작업 브랜치에서 확인된 source:

lambda_function.py
src/objects.py
gemini/a2a/runtime/__init__.py

주의:

현재 작업 브랜치(feature_a2a_task_orchestration_cloud)에는 proactive request/feedback 분기와 import fallback 흔적은 있다.
하지만 gemini/a2a/proactive, agents/proactive, runtime/proactive_* 원본 .py/schema 파일은 현재 브랜치에 없고 __pycache__만 남아 있다.
따라서 proactive 실제 구현 source는 proactive_planner 브랜치와 통합/복원 대조가 필요하다.

proactive_planner 브랜치에서 확인된 source:

gemini/a2a/agents/proactive/planner_api.py
gemini/a2a/proactive/candidate_builder.py
gemini/a2a/proactive/decision_validator.py
gemini/a2a/proactive/dispatch_composer.py
gemini/a2a/proactive/execution_arbiter.py
gemini/a2a/proactive/models.py
gemini/a2a/proactive/risk_policy.py
gemini/a2a/proactive/rollout_policy.py
gemini/a2a/proactive/trigger_gate.py
gemini/a2a/proactive/assets/mini_proactive_planner.system_prompt.txt
gemini/a2a/proactive/assets/mini_proactive_planner.response_schema.json
gemini/a2a/proactive/assets/proactive_lambda_request.schema.json
gemini/a2a/proactive/assets/proactive_lambda_response.schema.json
gemini/a2a/proactive/assets/proactive_feedback_request.schema.json
gemini/a2a/proactive/assets/proactive_feedback_response.schema.json
gemini/a2a/proactive/assets/dispatch/*.schema.json
gemini/a2a/proactive/assets/shared_context/*.schema.json
gemini/a2a/registry/proactive_capability_policy.json
gemini/a2a/runtime/proactive_orchestrator.py
gemini/a2a/runtime/proactive_feedback_handler.py
test/test_lambda_proactive_handler.py
test/test_proactive_candidate_builder.py
test/test_proactive_execution_arbiter.py
test/test_proactive_feedback_handler.py
test/test_proactive_orchestrator.py
test/test_proactive_planner_api.py
test/test_proactive_trigger_gate.py

4. Reactive 흐름

Reactive는 사용자가 먼저 말하는 흐름이다.

user speech
-> STT recognized_text
-> voice_context / device_context / memory_snapshot
-> A2A planner
-> Agent/Skill step
-> Cloud-only answer 또는 device_task_requests
-> On-device Bridge / DeviceAgent TaskManager
-> task_event / memory update

대표 특징:

• 현재 발화가 최상위 입력이다.
• STT_NULL guard가 먼저 동작한다.
• 필요한 경우 multi-turn follow-up을 묻는다.
• device 실행은 ODL/device step으로 내려간다.

5. Proactive 흐름

Proactive는 user speech 없이 signal bundle이 먼저 들어오는 흐름이다.

sensor / state / policy / routine signal
-> signal_bundle
-> trigger gate / candidate builder
-> mini proactive planner
-> decision validator / execution arbiter
-> dispatch composer
-> recommend / ask_confirmation / execute / create_schedule / suppress
-> proactive feedback
-> memory / preference policy update

5.1 Proactive 단계별 책임

proactive_planner 브랜치 기준 proactive는 아래 단계로 나뉜다.

5.2 Candidate family 예시

candidate_builder는 event type을 proactive trigger family로 매핑한다.

5.3 Trigger Gate 기준

Trigger gate는 모든 signal을 action 후보로 보내지 않는다.

이 기준 때문에 proactive는 기본적으로 보수적으로 동작한다.

5.4 Mini Proactive Planner 기준

Mini proactive planner prompt의 핵심 원칙:

Use only the compact input facts.
Do not invent missing sensor or user facts.
If uncertainty is high, prefer suppress or recommend.
If the action is privacy-sensitive or high-risk, prefer ask_confirmation.

즉 proactive planner는 “똑똑하게 먼저 실행하는 모델”이 아니라, 제한된 사실 안에서 안전한 decision을 고르는 좁은 planner다.

5.5 Execution Arbiter 기준

Execution arbiter는 proactive decision을 그대로 통과시키지 않는다.

핵심은 proactive planner의 결정을 safety/profile/policy가 다시 중재한다는 점이다.

대표 decision:

6. Reactive와 Proactive의 경계

핵심 원칙:

• proactive는 기본적으로 보수적으로 시작한다.
• 모든 proactive event가 action으로 가면 안 된다.
• recommend 또는 ask_confirmation이 기본이며, execute는 policy/profile/safety가 허용할 때만 가능하다.
• 사용자가 발화하면 reactive turn이 우선한다.

7. Proactive Request / Response 계약

7.1 Proactive request

Proactive request는 request_kind=proactive이거나 signal_bundle이 있으면 감지된다.

{
  "request_kind": "proactive",
  "device_id": "device_001",
  "signal_bundle": {
    "bundle_id": "bundle_001",
    "device_id": "device_001",
    "observed_at": "2026-04-06T12:00:00+09:00",
    "signals": [
      {
        "event_type": "air_quality_degraded",
        "event_family": "environment_change",
        "severity": "medium",
        "confidence": 0.94,
        "duration_sec": 420,
        "metrics": {
          "value": 86,
          "threshold": 60
        },
        "tags": ["persistent", "indoor"]
      }
    ],
    "device_state": {
      "mode": "idle"
    },
    "user_context": {
      "quiet_hours": false
    },
    "policy_context": {
      "rollout_mode": "RECOMMENDATION_ONLY"
    }
  },
  "manual_decision": {},
  "request_meta": {
    "source": "sensor_policy",
    "rule_id": "air_quality_pm10_persistent"
  }
}

7.2 Proactive response

{
  "request_kind": "proactive",
  "device_id": "device_001",
  "proactive": {
    "status": "ok",
    "trace_id": "trace_xxx",
    "candidate_id": "pc_xxx",
    "gate_decision": "allow",
    "gate_reason": "gate_passed",
    "arbitration": {
      "decision": "accept_proactive_only",
      "winner": "proactive_planner",
      "reason": "proactive_allowed"
    },
    "decision": "recommend",
    "payload": {
      "decision_type": "recommend",
      "action_family": "air_quality_response",
      "selected_capability_id": "air_cleaning.auto",
      "utterance": "공기질이 나빠졌어요. 청정을 시작할까요?"
    },
    "delivery": {
      "delivery_mode": "dry_run",
      "status": "ok"
    }
  }
}

7.3 Dispatch channel

8. Proactive Feedback 계약

Proactive feedback은 recommendation/confirmation/execute 결과를 memory/policy로 되돌리는 경로다.

8.1 Feedback request

{
  "request_kind": "proactive_feedback",
  "device_id": "device_001",
  "feedback_event": {
    "event_type": "recommendation_accepted",
    "device_id": "device_001",
    "action_family": "air_quality_response",
    "trace_id": "trace_abc",
    "dispatch_type": "recommendation",
    "decision_type": "recommend",
    "selected_capability_id": "air_cleaning.auto",
    "explicit_user_preference": true,
    "signal_trace": {
      "bundle_id": "bundle_001",
      "event_type": "air_quality_degraded",
      "rule_id": "air_quality_pm10_persistent"
    }
  }
}

8.2 Feedback 처리

proactive_feedback_handler는 feedback을 정규화하고 promotion gate를 통해 memory target을 결정한다.

이 feedback loop가 있어야 proactive가 단순 rule engine이 아니라 사용자 반응을 학습하는 구조가 된다.

9. Context-aware와의 관계

Context-aware는 reactive와 proactive의 공통 기반이다.

따라서 proactive를 하려면 단순 trigger rule만 있으면 안 된다. grounded_state, context provider, safety layer, preference policy가 함께 필요하다.

10. 구축 이점

11. 운영 리스크와 대응

12. 검증 시나리오

13. 브랜치 통합 체크리스트

현재 위키 기준으로 proactive를 실제 제품 구조에 포함하려면 아래를 확인해야 한다.

14. 실제 시나리오

14.1 Reactive 복합제어

사용자 발화:

거실로 갔다가 안방으로 이동해서 청정해줘

처리 흐름:

이 시나리오는 reactive voice turn이다. 사용자가 직접 명령했고, planner는 발화 기반 plan을 만든다.

14.2 Proactive 공기질 제안

Signal:

air_quality_degraded, confidence=0.94, duration_sec=420

처리 흐름:

이 시나리오는 proactive signal turn이다. 사용자가 말하지 않았고, signal이 planner를 깨운다.

14.3 Reactive가 Proactive를 이기는 경우

상황:

공기질 악화 signal이 들어왔지만 사용자가 동시에 "안방으로 와"라고 발화한다.

처리 원칙:

핵심은 proactive가 사용자 발화 흐름을 방해하지 않아야 한다는 점이다.

15. 제품화 체크포인트

Reactive/proactive를 제품화하려면 아래 경계가 닫혀야 한다.

16. 위키 내 위치

Reactive/proactive는 아래 문서들과 연결된다.

17. 후속 작업