← Docs hub

Experience Goal Deep Dive

목표 보존형 Agentic Orchestration의 이론, 계약, 효과, 평가

문서 역할
프로젝트 변화와 AS-IS/TO-BE를 먼저 이해하려면 Experience Goal: 명령 수행에서 결과 위임으로를 본다. 이 문서는 그 구조를 형식 모델, 외부 이론, 연구 가설과 평가 설계로 확장하는 학술 근거 문서다.

Experience Goal은 사용자의 한 문장을 더 많은 명령으로 확장하는 기능이 아니다. 여러 Agent, 기기 step, 대기 구간, callback을 통과하는 동안 사용자가 기대한 결과가 무엇인지, 어떤 관찰이 성공을 입증하는지, 언제 계속·질문·재계획·종료할지를 보존하는 상위 orchestration 계약이다.

핵심 명제: Goal은 자연어 명령의 복사본이 아니고, Plan은 Goal 자체가 아니며, Task callback은 단순 진행률이 아니다. 이 세 요소를 분리하고 다시 결속해야 장시간·복합·조건부 경험을 안전하게 운영할 수 있다.

초록

현재의 음성 Agent는 단일 turn에서 family와 skill을 선택하거나 한 개의 기기 명령을 실행하는 데에는 강하다. 그러나 "편하게 쉬게 도와줘", "청정이 끝나면 오늘 뉴스를 요약해줘", "주방에 갔다가 상태가 괜찮으면 바이탈사인을 시작해줘"처럼 결과 위임, 시간 관계, 상태 관찰, 여러 provider가 결합된 요청에서는 단일 intent 분류만으로 충분하지 않다.

이 문서는 SK-Intellix A2A 시스템에 추가된 Experience Goal을 다음과 같이 정의한다.

1. Main Router와 Planner가 만든 owner·skill·typed step을 실행의 유일한 원천으로 유지한다.
2. Planner와 같은 structured output에서 goal 의미 증거를 sidecar로 수집한다.
3. deterministic admission과 canonical effect catalog로 false activation과 임의 capability 생성을 차단한다.
4. DeviceAgent TaskManager callback을 관찰 증거로 변환해 목표 상태를 갱신한다.
5. 정상 진행은 규칙 기반 state transition으로 처리하고, 실패·모순·사용자 입력이 필요한 경계에서만 bounded Supervisor 판단을 연다.

따라서 Experience Goal의 연구적 의의는 "LLM이 더 많은 행동을 생성한다"가 아니라, 의미 목표, 실행 계획, 물리 실행 사실을 서로 다른 권한 계층으로 분리하면서도 긴 경험의 연속성을 유지하는 구조에 있다.

1. 연구 문제

1.1 단일 intent가 잃어버리는 정보

전통적인 음성 명령 처리 흐름은 대체로 다음과 같다.

utterance -> intent -> slot -> API call -> response

이 구조는 "주방으로 가", "청정 켜줘", "오늘 날씨 알려줘"에는 적합하다. 그러나 아래 요청은 한 개 intent로 축약하는 순간 중요한 의미를 잃는다.

"청정이 끝나면 오늘 뉴스를 짧게 알려줘."

이 발화에는 최소 다섯 종류의 정보가 있다.

Experience Goal은 이 손실을 막기 위한 계층이다.

1.2 해결하려는 세 가지 단절

의미 단절

Planner가 만든 각 step은 실행에는 충분하지만, 여러 step이 왜 하나의 경험인지 설명하지 못할 수 있다.

시간 단절

장시간 작업은 음성 session보다 오래 지속된다. session이 끝난 뒤에도 목표는 유지되어야 한다.

증거 단절

LLM이 "완료했습니다"라고 생성한 문장은 물리적 완료 증거가 아니다. 성공 판정은 TaskManager callback과 context observation에 연결되어야 한다.

1.3 연구 질문

이 설계는 다음 연구 질문을 다룬다.

2. 핵심 개념과 형식 모델

Experience Goal은 BDI, Goal Reasoning, HTN, affordance grounding, mixed-initiative, autonomic control에서 개념적 렌즈를 가져오지만 어느 한 이론을 그대로 구현한 시스템은 아니다. 현재 구현을 설명하기 위한 최소 형식 모델은 다음과 같다.

2.1 Context: 관찰된 현재 상태

시점 t의 context를 다음처럼 본다.

B_t = <D_t, T_t, M_t, S_t, E_t>

B_t는 완전한 세계 상태가 아니다. source, freshness, availability를 가진 부분 관찰 snapshot이다. 따라서 context가 비어 있거나 오래됐을 때는 추정이 아니라 질문, 보류, 안전 종료가 필요하다.

2.2 Goal: 보존할 사용자 결과

Experience Goal G를 다음 tuple로 정의한다.

G = <g_id, summary, effects, constraints, temporal, consent, budget>

Goal은 발화 문자열을 저장한 객체가 아니다. 발화가 여러 번 바뀌어도 보존되어야 할 결과와 성공 조건을 표현한다.

2.3 Plan: 실행 가능한 typed DAG

Planner가 만드는 plan을 directed acyclic graph로 본다.

P = (V, E)

V_i = <step_id, owner, capability, operation, args, wait_policy>
E_ij = dependency(V_i, V_j)

• V는 실행 가능한 typed step 집합이다.
• E는 순서와 의존관계다.
• action은 catalog에 존재하는 capability와 operation으로 grounding되어야 한다.
• Experience Goal은 V를 임의로 생성하지 않는다.

2.4 Effect: 행동이 아니라 관찰 가능한 결과

Effect e는 "무엇을 호출할지"가 아니라 "호출 결과로 무엇이 참이 되어야 하는지"다.

e = <effect_id, provider, terminal_evidence, confidence_policy>

예를 들어:

action: setMoveTo(room="주방")
effect: target_location_reached
evidence: movement.arrived + resolved room identity

action: startBasicAirClear(...)
effect: air_cleaning_active
evidence: cleaning.started 또는 cleaning.is_running=true

이 구분이 없으면 "명령 제출 성공"을 "사용자 목표 달성"으로 잘못 판단한다.

2.5 Observation: callback을 의미 증거로 변환

TaskManager event와 context update를 관찰 Z_t로 표현한다.

Z_t = <event, workflow_id, step_id, reason, state_delta, freshness>

Observation은 다음 중 하나를 입증한다.

• step이 시작됨
• step이 진행 중임
• step이 완료됨
• desired effect가 관찰됨
• 실패·timeout·차단이 발생함
• 사용자의 직접 입력이나 consent가 필요함
• 기존 plan과 현재 현실이 모순됨

2.6 Supervisor: 제한된 목표 상태 전이

Supervisor 정책은 다음처럼 표현할 수 있다.

pi(G, B_t, P, Z_t, budget)
  -> {continue, ask, replan, complete, suspend, cancel}

여기서 중요한 제한은 pi가 매 progress event마다 LLM을 호출하는 자유로운 Agent loop가 아니라는 점이다.

normal event
  -> deterministic state transition

failed / blocked / timeout / semantic contradiction / user input
  -> bounded decision gate

3. Goal, Plan, Task, Response를 분리해야 하는 이유

3.1 Goal은 Command가 아니다

"잠깐 편하게 쉬게 도와줘"

이 문장은 직접 capability 이름을 포함하지 않는다. 그러나 가능한 goal은 restful_environment_supported처럼 표현될 수 있다. 실제 plan은 기기 상태, 사용자 동의, capability availability에 따라 달라진다.

3.2 Plan은 Runtime state가 아니다

step_clean이 plan에 있다는 사실은 청정이 실행 중이라는 뜻이 아니다. queue에 대기 중일 수도 있고, 사용자가 PUI로 취소했거나, 이전 movement가 완료되지 않아 blocked 상태일 수도 있다.

3.3 Response는 Evidence가 아니다

"요청하신 작업을 순서대로 수행할게요"는 acknowledgement일 뿐이다. WORKFLOW_COMPLETED와 terminal effect evidence가 없으면 목표는 완료되지 않았다.

4. 전체 아키텍처

User utterance
  -> Main Router / Planner
     - owner_selection
     - typed steps
     - experience_request sidecar
  -> deterministic admission
  -> effect/provider grounding
  -> Goal contract + plan binding
  -> existing TaskManager compiler
  -> On-device bridge
  -> DeviceAgent TaskManager
  -> executor / Android / robot function
  -> callback + context observation
  -> workflow state reducer
  -> effect evaluator
  -> deterministic continue OR bounded Supervisor decision
  -> user response / next step / complete

4.1 권한 경계

이 분리는 안전장치이자 성능 최적화다.

5. Admission: 어떤 요청을 Experience로 승격할 것인가

Experience Goal의 가장 중요한 성능은 많이 입장시키는 것이 아니라 필요한 요청만 입장시키는 것이다.

5.1 의미 증거

입장 후보는 다음 의미 축을 조합해 판단한다.

단순히 문장이 길거나 "도와줘"라는 단어가 있다는 이유로 입장시키지 않는다.

5.2 입장 상태

not_admitted
  = 일반 대화 또는 단일 명령으로 충분

candidate
  = 의미 증거는 있으나 grounding·consent·plan binding 검증 전

activated
  = effect provider와 typed step, 시간 관계, 실행 tier 검증 완료

blocked
  = 목표는 유효하지만 현재 실행 조건 미충족

5.3 Negative boundary

아래 요청은 기본적으로 Experience가 아니다.

Experience는 기존 family 경계의 오류를 감추는 fallback이 아니다.

6. Goal lifecycle

Experience Goal의 lifecycle은 BDI goal lifecycle에서 제시하는 pending, active, suspended, terminal 관점을 참고하되 현재 시스템의 execution boundary에 맞춰 축소·재정의한다.

6.1 Suspend와 wait의 차이

• waiting은 계획된 시간·event·사용자 입력을 기다리는 정상 상태다.
• suspended에 해당하는 운영 의미는 voice session의 PAUSE, PUI 개입, 안전 정책 차단처럼 외부 이유로 실행을 멈추되 goal을 유지하는 경우다.
• 단순히 callback이 늦다는 이유로 goal을 매번 재계획하지 않는다.

6.2 성공 판정

Goal completed
  iff
  all required effects have acceptable terminal evidence
  AND no unresolved mandatory constraint remains

Task 제출 성공, TTS acknowledgement, 마지막 step의 시작 event만으로는 완료가 아니다.

7. Effect grounding

7.1 왜 canonical effect catalog가 필요한가

LLM은 "편안한 환경", "공기가 좋아짐", "원하는 장소에 도착" 같은 결과를 자연스럽게 표현할 수 있다. 하지만 그 표현을 곧바로 device method로 변환하면 hallucinated capability가 생긴다.

canonical effect catalog는 다음 mapping을 제공한다.

(capability_id, operation_id)
  -> canonical effect
  -> terminal evidence policy

현재 구현에는 15개 canonical effect, 10개 capability provider, 3개 skill provider가 등록되어 있다.

7.2 Capability affordance와 의미 가능성

언어적으로 그럴듯한 plan과 기기가 실제로 수행 가능한 plan은 다르다. SayCan이 언어 모델의 고수준 의미와 실제 skill affordance를 결합한 것처럼, 이 시스템도 Planner의 semantic proposal을 capability catalog와 current context로 제한한다.

다만 현재 시스템은 학습된 value function으로 skill 성공 확률을 계산하지 않는다. catalog availability, argument validation, device context, policy gate를 이용하는 symbolic grounding에 가깝다.

7.3 Effect closure

각 required effect는 다음 상태를 가진다.

unbound -> bound -> pending -> observed | contradicted | expired

• bound: provider와 plan step이 정해짐
• pending: 실행 또는 event를 기다림
• observed: terminal evidence 수신
• contradicted: 현재 context가 목표와 반대
• expired: freshness 또는 timeout 한도 초과

8. 시간 의미와 조건

시간 관계는 문장 문자열을 TaskManager rule로 직접 바꾸는 것이 아니라 Planner가 typed relation으로 구조화한다.

예시:

{
  "temporal_relation": "after_planned_step",
  "temporal_anchor_id": "step_move_room",
  "delay_ms": 30000
}

이 계약은 "공간1로 간 뒤 30초 후 바이탈사인을 켜줘"를 다음처럼 분리한다.

step_move_room
  -> movement.arrived evidence
  -> runtime delay 30 s
  -> launch vital interaction

Cloud가 30초를 polling하거나 callback 시 자연어를 다시 해석하지 않는다.

9. Callback, 관찰, 재계획 경계

9.1 모든 callback이 재추론을 요구하지 않는다

9.2 Replan gate

재계획은 다음 조건을 만족할 때만 열린다.

requires_cloud_decision = true
AND recoverable = true
AND decision_budget > 0
AND current context is fresh enough
AND no safety or consent prohibition exists

9.3 Decision budget

{
  "max_decisions": 3,
  "max_replans": 1,
  "deadline_ms": 1800000,
  "fallback": "ask_or_stop"
}

max_decisions는 Supervisor가 의미 판단을 수행할 수 있는 총횟수이고, max_replans는 그중 실행 plan을 바꾸는 replan 또는 return_to_station 결정의 별도 상한이다. 재계획 예산이 소진되면 continue, ask_user, abort, complete는 남을 수 있지만 plan을 다시 바꾸는 action은 허용 목록에서 제거된다.

예산은 무한 Agent loop, token 폭증, 같은 실패 plan의 반복을 방지한다. 현재 구현은 max_decisions와 max_replans를 운영하고, deadline_ms와 fallback은 다음 runtime 계약 확장 항목이다.

10. 기존 Planner 비간섭성

Experience Goal이 유용하더라도 기존 Router와 Planner의 품질을 무너뜨리면 채택할 수 없다. 따라서 다음 불변조건을 둔다.

Invariant 1. Owner authority

Experience cannot overwrite selected_routes or owner_selection.

Invariant 2. Plan authority

Experience cannot dispatch an effect without an existing validated typed step.

Invariant 3. Device truth

Experience cannot mark physical completion without TaskManager/context evidence.

Invariant 4. Negative boundary

Single-turn DEF, FRG, DQR, ODL, SCH requests remain on the original path
unless persistent coordination evidence is present.

Invariant 5. Bounded cognition

Normal callbacks do not create new model calls.

Invariant 6. Rollback

Disabling Experience restores the original planner/runtime behavior.

이 불변조건은 단순한 구현 원칙이 아니라 평가 가능한 acceptance criteria다.

11. 기대 효과

11.1 사용자 효과

결과 중심 상호작용

사용자는 API 순서를 외우지 않고 "무엇을 원하는지" 말할 수 있다.

Before: "주방으로 가. 청정 켜. 끝나면 뉴스 알려줘."
After:  "주방 청정이 끝나면 오늘 뉴스만 짧게 알려줘."

긴 경험의 연속성

음성 session이 종료되어도 active workflow와 goal binding이 남아 callback 이후 다음 행동을 이어갈 수 있다.

예측 가능한 확인과 동의

위험하거나 오래 걸리는 행동, 개인정보가 포함된 행동은 consent boundary에서 사용자에게 질문한다. 모든 모호성을 자동 추론으로 덮지 않는다.

실패의 자연스러운 복구

"실패했습니다"로 끝나는 대신 reason code, 현재 context, 남은 목표를 바탕으로 재시도, 대안, 질문, 안전 종료 중 하나로 수렴한다.

11.2 시스템 효과

책임 분리

• Planner는 의미와 typed plan을 소유한다.
• TaskManager는 실행과 시간·dependency를 소유한다.
• Supervisor는 예외적 목표 상태 전이를 소유한다.

관찰 가능성

goal, plan, task, effect evidence가 분리되어 "왜 이 step이 실행 중인지", "무엇이 완료되지 않았는지"를 추적할 수 있다.

비용 상한

정상 callback을 deterministic하게 처리하고, decision budget으로 추가 model call을 제한한다.

기능 재사용

새 시나리오마다 발화 문자열 rule을 추가하는 대신 기존 capability와 effect를 조합한다.

11.3 제품·조직 효과

12. 대표 시나리오 분석

12.1 휴식 지원

사용자: "잠깐 편하게 쉬게 도와줘."

가능한 의미:

goal:
  restful_environment_supported

desired effects:
  quiet_environment
  reduced_visual_stimulation
  rest_guidance_delivered

현재 context와 동의에 따라 plan은 달라진다.

if cleaning.is_running:
  ask whether cleaning may be paused

if audio is active:
  lower or mute audio within policy

deliver short rest guidance

이 시나리오의 핵심은 "편하게"라는 단어를 특정 API로 매핑하는 것이 아니다. Planner가 목표와 제약을 해석하고, catalog-grounded provider만 사용하며, consent가 필요한 변경을 구분하는 것이다.

12.2 청정 이후 최신 정보

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

goal:
  fresh_information_delivered

temporal:
  after_existing_event(cleaning.completed)

plan:
  wait for cleaning completion
  -> FRG freshness retrieval
  -> DEF user-facing composition

정상 청정 progress 동안 model call은 없다. 완료 event가 오면 기존 event binding을 해제하고 FRG/DEF step을 실행한다.

12.3 이동 후 바이탈 상호작용

사용자: "안방으로 가서 바이탈사인을 시작하고 끝나면 복귀해줘."

move to room
  -> launch vital interaction
  -> wait for vital completed/cancelled event
  -> return to station

바이탈사인은 사람이 측정을 완료하거나 취소할 때까지 끝나지 않을 수 있다. 따라서 고정 sleep 후 다음 step으로 넘어가면 안 된다. vital_interaction_ended effect는 앱 또는 DeviceAgent의 완료·취소 event를 terminal evidence로 가져야 한다.

12.4 일반 대화와의 비간섭

사용자: "오늘 좀 힘들었어."

delegated outcome과 실행 coordination이 없다면 DEF로 응답한다. 감정 표현을 Experience Goal로 과승격해 기기 action을 제안하면 false admission이다.

12.5 실사용성 목표

Experience Goal의 제품 효과는 복합 plan 생성 건수가 아니라 사용자 부담과 실행 신뢰성의 변화로 평가한다.

현재 구현에서 실사용 범위는 다음처럼 나뉜다.

content_only:
  휴식 안내, 지지 대화, 최신 정보 구성

non_motion pilot:
  공기질·배터리 확인, 고정 청정, 나이트·매너·화면·소리

full lab:
  이동, 복귀, 바이탈 interaction, 이야기 session

provider gap:
  연속 센서 관찰, 범용 result binding, 건강 판단

사용자 여정별 문구, 성공 증거, 취소·실패 복구, pilot KPI는 Experience Goal Usability Playbook에서 구체적으로 정의한다.

13. 성능과 비용 방어

13.1 Model call budget

기본 경로:

1 main planner call
0 admission-only call
0 normal callback call
0 deterministic effect closure call

추가 call은 다음에서만 허용한다.

• 사용자에게 clarification/consent가 필요함
• 계획된 provider가 실패했지만 대안이 존재함
• 현재 context가 plan의 전제를 깨뜨림
• 사용자가 목표를 수정함

13.2 State 크기 제어

매 turn마다 전체 history와 raw telemetry를 모델에 넣지 않는다.

13.3 지연 예산

관찰해야 할 지연은 세 부분으로 나눈다.

T_total = T_planner + T_compile_dispatch + T_exception_decision

• T_planner: 기존 route/plan 생성
• T_compile_dispatch: deterministic compile과 전송
• T_exception_decision: 예외 때만 발생

Experience가 비입장 turn의 T_total을 유의미하게 늘리면 non-interference 실패다.

14. 연구 가설

15. 평가 프레임워크

15.1 계층별 지표

15.2 측정식

Admission Precision
  = correctly admitted experience requests / all admitted requests

Non-interference Rate
  = unchanged correct decisions on legacy set / legacy correct baseline

Terminal Evidence Integrity
  = completed goals with valid terminal evidence / all completed goals

Replan Utility
  = recovered workflows after replan / all workflows that invoked replan

Goal Completion Rate
  = goals satisfying all required effects / all activated goals

15.3 테스트셋 구성

평가셋은 문장 다양성보다 경계 다양성을 우선한다.

15.4 Ablation

15.5 사용자 연구

실기기 성공률만으로 경험 품질을 설명할 수 없다. 동일 목표를 다음 두 방식으로 비교할 수 있다.

1. 명령 연쇄 방식: 사용자가 각 step을 직접 지시
2. Goal 보존 방식: 결과를 한 번 위임하고 시스템이 상태를 관찰

측정:

• 발화 turn 수
• 사용자 수정·취소 횟수
• 진행 상태 이해도
• 예상과 실제 결과 일치도
• 자동화에 대한 신뢰
• 개인정보·동의 부담

16. 실패 모드와 한계

16.1 False admission

일반 대화나 단일 명령을 Experience로 입장시키면 Planner가 불필요하게 복잡해지고 기기 action을 과승격할 수 있다.

대응:

• semantic evidence 조합
• negative holdout
• legacy family non-interference
• shadow mode

16.2 Effect hallucination

모델이 catalog에 없는 결과나 provider를 생성할 수 있다.

대응:

• canonical IDs
• provider binding validation
• dispatch_allowed=false sidecar
• unknown effect reject

16.3 Stale context

기기가 이미 이동했는데 이전 위치를 기준으로 plan을 만들 수 있다.

대응:

• source timestamp와 freshness
• 실행 직전 prerequisite 재검증
• current state와 callback correlation

16.4 Callback correlation failure

중복 event, 순서 역전, 다른 workflow event가 목표에 결속될 수 있다.

대응:

• workflow, plan, step, task correlation ID
• idempotent reducer
• monotonic state transition
• stale event rejection

16.5 Over-replanning

progress 변화마다 재계획하면 지연과 token이 증가하고 plan이 흔들린다.

대응:

• deterministic normal path
• explicit reason code
• bounded decision budget
• plan repair를 전체 재생성보다 우선

16.6 Human-in-the-loop

바이탈, live view, 개인정보, 외부 연락, 민감한 화면은 자동 완료로 간주할 수 없다.

대응:

• consent state
• user-completed event
• timeout 후 강제 성공 금지
• 취소와 안전 종료를 terminal state로 구분

16.7 현재 이론적 한계

현재 구현은 다음을 아직 제공하지 않는다.

• 완전한 BDI belief revision과 intention reconsideration
• 학습 기반 affordance value function
• 최적 정책을 학습하는 reinforcement learning
• 일반 목적 HTN domain compiler
• 무제한 장기 자율 목표 생성
• 형식 검증된 safety theorem

따라서 이 문서는 기존 이론을 설계 렌즈와 평가 근거로 사용하며, 구현 범위를 그 이론 전체와 동일시하지 않는다.

17. 현재 코드와의 매핑

현재 구현의 정량 snapshot:

canonical effects:        15
capability providers:     10
skill providers:           3
default live boundary:     restricted/content-only 계층
normal callback decision:  deterministic 우선
default supervisor budget: max_decisions=3
default replan budget:     max_replans=1

2026-08-03 기준 재계획 예산은 Experience contract 정규화, workflow supervisor state, decision input의 allowed_actions, 실행 후 사용량 갱신까지 연결되어 있다. 재계획 한도가 소진된 뒤 모델이 replan을 반환해도 schema-valid transition으로 수용하지 않는다.

실행 상세와 최신 검증값은 Experience Goal과 기존 Planner 통합 구조와 Experience Goal Composer Live Slice에서 분리해 관리한다.

18. Rollout과 Go/No-Go

Tier 0. Shadow

• plan과 goal 후보만 기록
• 실행 영향 없음
• admission precision과 legacy delta 측정

Tier 1. Content-only

• DEF/FRG/STM 등 비기기 effect만 제한 활성화
• device dispatch 차단
• cross-agent continuation 검증

Tier 2. Restricted device

• 낮은 위험의 allowlisted capability만 활성화
• consent, cancel, timeout, rollback 필수

Tier 3. Full bounded workflow

• 검증된 multi-step provider 확대
• 실기기 callback과 PUI cancel 통합
• token/latency budget 운영

Go 기준

• positive admission과 negative rejection 목표 달성
• 기존 family 성능 delta 허용 범위 이내
• false completion 0에 가까움
• callback correlation과 cancel propagation 통과
• 반복 E2E에서 decision budget 초과 없음
• rollback switch 검증

No-Go 기준

• effect만으로 device action 생성
• 일반 대화의 지속적인 false admission
• 정상 callback마다 model call
• stale context로 반복 오동작
• 사용자 취소 후 workflow 지속
• terminal evidence 없이 완료 발화

19. 이론적 배경과 설계 연결

주요 문헌

1. Anand S. Rao and Michael P. Georgeff, BDI Agents: From Theory to Practice, ICMAS, 1995.
2. James Harland, David Morley, John Thangarajah, and Neil Yorke-Smith, An Operational Semantics for the Goal Life-Cycle in BDI Agents, Autonomous Agents and Multi-Agent Systems, 2014.
3. David W. Aha, Goal Reasoning: Foundations, Emerging Applications, and Prospects, AI Magazine, 2018.
4. Kutluhan Erol, James Hendler, and Dana S. Nau, UMCP: A Sound and Complete Procedure for Hierarchical Task-Network Planning, AIPS, 1994.
5. Michael Ahn et al., Do As I Can, Not As I Say: Grounding Language in Robotic Affordances, 2022.
6. Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR, 2023.
7. Jeffrey O. Kephart and David M. Chess 계열의 autonomic computing을 구체화한 Yixin Diao et al., Self-Managing Systems: A Control Theory Foundation, ECBS, 2005.
8. David M. Chess et al., An Architectural Approach to Autonomic Computing, ICAC, 2004.
9. Eric Horvitz, Principles of Mixed-Initiative User Interfaces, CHI, 1999.
10. Richard S. Sutton, Doina Precup, and Satinder Singh, Between MDPs and Semi-MDPs: A Framework for Temporal Abstraction in Reinforcement Learning, Artificial Intelligence, 1999.
11. Axel van Lamsweerde, Goal-Oriented Requirements Engineering: A Guided Tour, RE, 2001.

20. 결론

Experience Goal의 핵심 가치는 더 많은 자동 행동이 아니다. 다음 세 사실을 동시에 유지하는 데 있다.

1. 사용자가 기대한 결과는 여러 turn과 step을 넘어 보존된다.
2. 실행 가능한 행동은 기존 Planner와 capability catalog만 만든다.
3. 목표 완료는 TaskManager와 context가 제공한 증거로만 확정된다.

이 구조가 안정적으로 동작하면 SK-Intellix는 "명령을 잘 분류하는 음성 Agent"에서 "목표를 보존하고 현실을 관찰하며 제한적으로 적응하는 Agentic 시스템"으로 확장된다. 반대로 admission, grounding, evidence, budget 중 하나라도 느슨해지면 Experience는 곧바로 과승격, 임의 action, false completion, 비용 폭증으로 변한다.

따라서 다음 발전 방향은 더 많은 발화 rule이 아니라 다음 네 가지다.

1. semantic admission의 precision과 negative boundary 강화
2. effect-provider-terminal evidence coverage 확대
3. callback correlation과 PUI cancel의 실기기 정합
4. non-interference, cost, trust를 함께 보는 반복 평가

함께 볼 문서

• Experience Runtime Validation Closure 2026-08-05
• Experience Goal Usability Playbook
• Experience Goal과 기존 Planner 통합 구조
• A2A Experience Workflow: 설계 이론과 현재 구현
• Experience Goal Composer Live Slice 2026-08-02
• A2A Experience Supervisor
• A2A Planner Deep Dive
• DeviceAgent TaskManager 기준 사양서
• Semantic Boundary Calibration Playbook