A2A Experience Workflow: 설계 이론과 현재 구현
문서 역할
Experience의 필요성과 제품 전환을 먼저 이해하려면 Experience Goal: 명령 수행에서 결과 위임으로를 본다. 이 문서는 Goal, plan binding, observation, bounded decision이 실제 아키텍처에 어떻게 배치되는지 설명한다.
Experience Workflow는 복합명령에 step을 더 붙이는 기능이 아니다. 사용자가 원하는
상위 결과를 보존하고, 이미 검증된 실행 계획과 결속하며, TaskManager와 의미 관찰
결과를 근거로 제한된 시점에만 다음 판단을 수행하는 상위 orchestration 계층이다.
30초 요약
| 질문 | 답 |
|---|---|
| 무엇을 해결하는가? | 여러 step이 끝날 때까지 사용자의 상위 목표와 성공 기준을 잃지 않게 한다. |
| 기존 Planner와 무엇이 다른가? | Planner는 실행 가능한 plan을 만들고, Experience Workflow는 그 plan 위에 Goal과 관찰 정책을 결속한다. |
| TaskManager와 무엇이 다른가? | TaskManager는 queue·dependency·timeout·완료 사실을 소유하고, Experience는 그 사실이 사용자 목표에 어떤 의미인지 제한된 경계에서 판단한다. |
| 매 callback마다 LLM을 호출하는가? | 아니다. 정상 진행은 deterministic하게 처리하고 실패·차단·사용자 입력·의미 변화 같은 decision event에서만 판단한다. |
| 지금 제품에서 켜져 있는가? | 기본값은 off다. 로컬에서는 content_only tier만 제한적으로 live 검증하며 제품 활성화는 아직 No-Go다. |
| 지금 주장할 수 있는가? | admission, effect grounding, plan binding, observation policy, bounded Supervisor 계약과 핵심 TaskManager callback backbone은 검증됐다. full Experience device tier는 별도 gate다. |
한 줄로 요약하면 다음과 같다.
Planner가 실행 방법을 만들고,
TaskManager가 실행 사실을 관리하며,
Experience Workflow가 목표와 성공 의미를 보존한다.
1. 현재 결론
2026-08-02 기준 Cloud A2A에는 feature-gated 1차 live slice가 구현됐다.
사용자 발화
-> Main Router 1회
|- Experience 의미 입장 판단
`- 기존 catalog 기반 실행 계획
-> deterministic runtime gate
-> Goal contract와 검증된 step 결속
-> 기존 Planner -> TaskManager 실행
-> task/semantic observation
-> 제한된 Supervisor 판단
중요한 안전 경계는 다음과 같다.
experience_request자체에는 dispatch 권한이 없다.- Goal Composer는 catalog로 검증된 cloud content step만 제한적으로 구성하며 새 device action을 만들지 않는다.
- candidate가 활성화되지 않으면 기존 Planner가 제안한 device request도 최종 dispatch gate에서 억제한다.
- Router가 만든 기존 step ID와 dependency에만 결속한다.
- capability가 없거나 확인이 필요한 목표는 실행하지 않는다.
- 기본 모드는
off이며live는 로컬 제한 검증용이다. - 정상 진행 이벤트마다 LLM을 다시 호출하지 않는다.
따라서 현재 구현은 범용 자율 Goal Composer가 아니라, 의미적으로 승인된 Goal을
기존 grounded plan 또는 안전한 content skill 위에 올리는 단계다. 최신
content_only 구현 계약과 검증 수치는
Experience Goal Composer Live Slice 2026-08-02에서
관리한다.
기존 Planner의 owner·typed step·TaskManager 실행 권위를 그대로 유지하면서 Experience sidecar가 어디에 결속되는지, false admission이 왜 핵심 회귀 위험인지, 일반 대화·단일 명령·다단계·기존 이벤트·외부 이벤트가 각각 어떻게 처리되는지는 Experience Goal과 기존 Planner 통합 구조에서 예시와 계약 JSON으로 본다.
Experience Goal 자체의 형식 모델, BDI·Goal Reasoning·HTN·affordance grounding·mixed-initiative와의 관계, 사용자·시스템 효과, 연구 가설과 평가 설계는 Experience Goal Academic Deep Dive에서 학술 소개 수준으로 분리해 다룬다.
현재 구현 상태
| 구성 | 현재 상태 | 실행 권한 |
|---|---|---|
| Semantic admission | Router의 동일 응답에서 선택적으로 생성 | 직접 실행 불가 |
| Effect catalog | 15 effects, 10 capability providers, 3 skill providers | provider 검증만 수행 |
| Runtime activation gate | admission, plan, effect, consent, terminal evidence, live tier 검증 | 통과한 plan만 활성화 |
| Goal Composer | exact skill provider로 안전한 content step 구성 | device/action plan 생성 불가 |
| Goal contract | goal, success criteria, constraints, plan binding 저장 | workflow 상태 보존 |
| TaskManager | queue, dependency, wait, timeout, cancel, terminal callback | 실제 기기 실행 소유 |
| Semantic observation | catalog와 subscription에 맞는 event만 승격 | telemetry 자체는 재계획 불가 |
| Experience Supervisor | continue, ask, replan, complete 중 제한 판단 | decision budget과 별도 replan budget 안에서만 동작 |
최신 Cloud 기준선과 commit·실기기 gate는 A2A Planner-TaskManager Baseline Readiness 2026-08-02에서 별도로 관리한다.
실행 모드
| Mode | Router 출력 | Goal 활성화 | TaskManager 영향 | 용도 |
|---|---|---|---|---|
off |
Experience admission metadata 없음 | 없음 | 없음 | 기본 운영·일반 라우팅 |
shadow |
admission 관찰 객체만 생성 | 금지 | 없음 | positive/near-negative 의미 경계 측정 |
live |
admission과 effect binding 사용 | deterministic gate 통과 시 가능 | 현재 content_only tier만 로컬 허용 |
로컬 제한 E2E |
shadow나 live라는 이유만으로 자동 실행되지 않는다. admission 객체는 항상
dispatch_allowed=false이며, 실제 device workflow는 기존 Planner가 만든
catalog-grounded step에서만 나온다. Goal Composer가 추가할 수 있는 것은
side effect와 consent가 없고 route_result로 종료되는 cloud content step뿐이다.
2. 설계 이론적 배경
이 구조는 한 논문을 그대로 구현한 것이 아니라 여러 Agent 설계를 제품 경계에 맞게 조합했다.
| 이론·기법 | 핵심 관점 | A2A 적용 |
|---|---|---|
| BDI | belief, desire, intention을 분리 | 관찰 상태, 목표/effect, 결속된 plan을 분리 |
| HTN | 상위 목표를 순서와 의존성을 가진 task로 분해 | typed step, depends_on, wait/condition |
| ReAct | 행동과 관찰을 번갈아 다음 판단을 갱신 | callback 이후 필요한 경우만 Supervisor 판단 |
| MAPE-K | monitor-analyze-plan-execute와 공유 지식 | DeviceAgent-Supervisor-Planner-TaskManager-workflow state |
| Bounded rationality | 모든 순간이 아니라 가치 있는 경계에서 판단 | event allowlist와 decision budget |
참고 자료:
- BDI Agents: From Theory to Practice
- UM-CP: hierarchical task-network planning
- ReAct: Synergizing Reasoning and Acting in Language Models
- An architectural approach to autonomic computing
BDI 관점
현재 시스템을 BDI 용어로 해석하면 다음과 같다.
| BDI 요소 | 구현 데이터 |
|---|---|
| Belief | device context, workflow state, task event, semantic observation |
| Desire | goal_summary, desired_effects, success_criteria |
| Intention | plan_binding, active workflow, dependency와 wait policy |
다만 현재 시스템은 정식 BDI interpreter가 아니다. belief revision 논리나 intention selection formalism을 구현한 것이 아니라, 목표와 실행 상태를 섞지 않기 위한 구조적 참조다.
HTN 관점
Main Router의 steps는 HTN과 유사하게 상위 목표를 실행 가능한 하위 단계로
분해한다. 차이는 현재 구현이 범용 HTN search engine이 아니라 capability catalog와
LLM 계획 결과를 deterministic validator로 제한한다는 점이다.
ReAct와 MAPE-K 관점
정상 QUEUED, RUNNING, PROGRESS는 telemetry와 UI만 갱신한다. 실패, 차단,
사용자 입력 필요, 목표에 영향을 주는 의미 관찰에서만 Supervisor가 다음 행동을
판단한다. 이 방식은 action-observation loop를 유지하면서도 지연과 토큰 사용을
방어한다.
3. Admission과 Activation
Router는 문구나 family 이름이 아니라 발화 전체의 의미 증거를 반환한다.
experience_request:
request_kind: action_request
delegated_outcome: true
coordination_requirements:
- state_observation
- sequencing
- adaptation
goal_summary: 사용자가 편안하게 쉴 수 있도록 돕는다
desired_effects:
- quiet_environment
- rest_guidance_delivered
constraints:
- user_can_cancel
admission_status: candidate
Runtime은 이 결과를 그대로 신뢰하지 않는다. 아래 조건을 모두 확인한다.
- mode가
live - admission이
candidate - 의미 증거가 완전하고 delegated outcome이 존재
- observation, sequencing, waiting, consent, cross-agent, adaptation 중 실제 coordination이 존재
- 미해결 확인 사항이 없음
- 기존 plan이 존재
- step ID가 고유하고 dependency가 앞선 step만 참조
- 모든 desired effect가 canonical catalog에 존재
- 각 effect가 정확한 capability operation 또는 skill provider에 결속
- terminal evidence가 존재하고 미해결 동의 요구가 없음
거절 사유는 experience_activation.reason으로 trace에 남는다.
Admission에서 실행까지
experience_request
-> semantic evidence 검사
-> desired effect canonicalization
-> 기존 plan step과 provider binding
-> consent / terminal evidence 검사
-> Goal contract 생성
-> TaskManager workflow에 correlation
이 과정에서 admission은 “무엇을 원하는가”만 표현한다. “어떤 기기 명령을 실행할 것인가”는 capability catalog와 기존 plan의 책임이며, 두 결과가 deterministic gate에서 일치하지 않으면 Experience를 활성화하지 않는다.
Effect-capability evidence
이제 desired_effects는 자유 문자열이 아니라
experience_effect_catalog.v1.json의 canonical ID로 검증한다.
canonical desired effect
-> exact capability operation 또는 skill provider
-> plan step의 effect_bindings
-> authoritative terminal evidence
현재 catalog는 15개 effect, 10개 capability provider, 3개 skill provider를 정의한다. 각 provider는 제공 effect, 전제 조건, 부수 효과, 동의 필요 여부, 종료 증거를 선언한다.
Runtime은 발화 문구를 매칭하지 않는다. typed
capability_id + operation_id 또는 명시된 skill_id만 검증하며 다음 경우
실행을 차단한다.
- 미등록 desired effect
- plan에서 충족되지 않은 effect
- 해당 provider가 공급하지 않는 effect binding
- terminal evidence가 없는 완료 주장
- 동의가 필요한 provider의 자동 활성화
바이탈사인은 특히 측정 성공을 주장하지 않는다. 현재 terminal 범위는
vital_interaction_ended, 즉 앱 세션이 완료 또는 취소됐다는 사실뿐이다.
4. Goal Contract
활성화되면 아래 compact contract가 workflow state에 저장된다.
experience:
contract_version: a2a-experience-policy-v1
experience_id: exp-...
goal_summary: 사용자가 편안하게 쉴 수 있도록 돕는다
desired_effects:
- quiet_environment
- rest_guidance_delivered
success_criteria:
- quiet_environment
- rest_guidance_delivered
constraints:
- user_can_cancel
plan_binding:
plan_id: wellness_reset
step_ids:
- step_prepare
- step_guide
step_count: 2
task_event_policy:
decision_events:
- FAILED
- BLOCKED
- TIMEOUT
- NEEDS_USER_INPUT
terminal_events:
- COMPLETED
- CANCELLED
- WORKFLOW_COMPLETED
decision_budget:
max_decisions: 3
max_replans: 1
success_criteria는 최종 종료 증거를 정의한다. 현재는 effect catalog의
operation/skill별 terminal evidence와 연결되며, TaskManager 또는 agent runtime이
그 증거를 실제 callback으로 제공해야 달성 판정을 신뢰할 수 있다.
5. 실행과 관찰 책임
| 계층 | 소유 책임 | 하지 않는 일 |
|---|---|---|
| Main Router | 의미 입장, owner/skill/step 계획 | 장기 실행 상태 소유 |
| Experience runtime gate | 입장·plan 정합 검증, Goal 결속 | action 생성 |
| TaskManager | queue, dependency, timeout, 실제 완료 | 사용자 목표 추론 |
| DeviceAgent | 기기 상태와 callback 사실 제공 | 의미 기반 대안 선택 |
| Experience Supervisor | 목표 보존, 예외 시 continue/ask/replan/complete | safety policy 우회 |
| Workflow state | etag, event, plan, Experience 계약 보존 | 독자적 의미 추론 |
정상 경로는 deterministic하게 TaskManager가 소유한다. 의미 판단이 필요한 경계만 Supervisor가 사용하며, 결정 예산을 넘으면 자동 행동을 확대하지 않는다.
Callback 이후의 판단 경계
| 들어온 상태 | 기본 처리 | LLM/Supervisor 판단 |
|---|---|---|
QUEUED, RUNNING, PROGRESS |
workflow와 UI 상태만 갱신 | 호출하지 않음 |
COMPLETED |
terminal evidence와 다음 dependency 확인 | 목표 달성 의미가 불명확할 때만 |
FAILED, BLOCKED, TIMEOUT |
reason과 실패 step 저장 | continue/ask/replan 판단 가능 |
NEEDS_USER_INPUT |
workflow를 waiting_user로 전환 |
좁은 확인 질문 생성 가능 |
CANCELLED |
사용자·PUI 취소 사실을 terminal로 기록 | 대체 행동을 자동 확대하지 않음 |
| 의미 관찰 변화 | subscription·freshness·scope 검증 | requires_cloud_decision=true일 때만 |
재계획은 callback 문장을 다시 처음부터 해석하는 구조가 아니다. 기존 Goal, plan binding, 완료 step, terminal evidence, 실패 reason을 compact context로 만들어 제한된 다음 결정을 수행한다.
6. 구현 위치
Cloud repo:
gemini/a2a/planner/experience_admission.py
gemini/a2a/planner/main_router_api.py
gemini/a2a/registry/experience_effect_catalog.v1.json
gemini/a2a/runtime/experience_goal_composer.py
gemini/a2a/runtime/experience_effects.py
gemini/a2a/runtime/experience_workflow.py
gemini/a2a/runtime/observation_policy.py
gemini/a2a/runtime/experience_supervisor.py
gemini/a2a/runtime/session_state.py
gemini/a2a/tools/local_lambda_shim.py
Trace에서 확인할 필드:
experience_admission
experience_activation
experience_goal
experience_goal_composer
planner_decision
steps
device_task_requests
device_workflow_requests
Text Console에서 확인해야 하는 흐름:
experience_admission
-> experience_activation
-> experience_goal.plan_binding
-> planner steps
-> device_workflow_requests
-> TaskManager callback / semantic observation
-> supervisor decision
-> terminal evidence
7. 로컬 검증
.venv/bin/python -m gemini.a2a.tools.local_lambda_shim \
--host 127.0.0.1 \
--port 18080 \
--experience-workflow-mode live \
--experience-live-tier content_only
GEMINI_API_KEY 등 필요한 환경 변수는 shell 환경에서 주입하며 문서나 저장소에
기록하지 않는다.
2026-08-02 Goal Composer 변경의 집중 회귀는 151 passed, Cloud 전체 suite는
735 passed, 47 skipped다. live E2E에서는 content 직접 응답, 비입장 대조군,
activation 실패 시 candidate device request 억제를 확인했다. 세부 trace는
live-slice 문서에서 실행 시점별로 관리한다.
검증된 내용은 activation gate, plan 결속, dependency 차단, 확인 필요 차단, Goal
상태 저장, effect-provider coverage, terminal evidence, consent 차단,
Supervisor 입력, observation policy, semantic observation ingest, shim mode,
trace 노출, direct content 응답 계약 fallback이다. 전체 관리 suite와 집중 회귀는
모두 2026-08-02 현재 소스에서 실행했다. 이 수치는 non_motion 또는 full
tier의 제품 rollout 승인을 의미하지 않는다.
일반 라우터 기준선은 v13 policy 82.56%, latest-axis original policy
84.05%, HOLDOUT5 policy 83.45%, infrastructure error 0이다. 이 값은
Experience 품질 점수가 아니라 Experience 변경을 포함한 현재 Router 전체의
회귀 기준선이다.
일반 Router 요청에는 effect catalog를 주입하지 않는다. Experience shadow/live에서만 약 6.6 KB, 보수적 문자 환산 약 1.65K token의 compact catalog가 추가된다.
2026-08-05에는 실제 기기에서 단일 청정 시작·정지의 COMPLETED 종료와
이동 -> 복귀 dependency callback을 추가로 확인했다. 이 결과, failure UX,
회귀 범위와 남은 No-Go는
Experience Runtime Validation Closure 2026-08-05를
최신 기준으로 사용한다.
8. 아직 구현하지 않은 것
- device action까지 생성하는 범용 Goal Composer
- 모든 effect terminal evidence와 PUI 취소의 capability별 반복 실기기 검증
- task abnormal callback과 semantic observation의 완전한 단일 Supervisor loop
- 제품 live kill switch, consent policy, rollout metric, rollback 자동화
- 대표 간접 발화의 fresh Gemini 평가
- 이동·청정·바이탈·콘텐츠가 섞인 반복 실기기 E2E
따라서 제품 활성화 판단은 아직 No-Go다. 다음 단계는 문구별 규칙이 아니라
effect-capability metadata, terminal evidence, negative over-action 지표를
보강하는 것이다.
다음 승격 gate
| Gate | 통과 조건 |
|---|---|
| Semantic quality | 간접 목표 positive와 near-negative에서 과승격·누락이 허용 범위 안에 있음 |
| Cost | ordinary route에는 Experience catalog가 주입되지 않고 decision event 호출량이 상한 안에 있음 |
| Device evidence | 이동·청정·외부 앱·PUI 취소·schedule의 callback과 terminal evidence가 실기기에서 연결됨 |
| Replan safety | failure/block에 bounded replan이 동작하고 정상 progress에는 추가 추론이 없음 |
| Consent | 측정·privacy·외부 앱처럼 확인이 필요한 provider가 자동 활성화되지 않음 |
| Observability | Goal, plan, callback, decision, evidence가 Text Console에서 같은 workflow ID로 추적됨 |
9. 대표 검증 장면
오늘 너무 피곤해. 10분 동안 편하게 쉴 수 있게 도와줘.
기대 흐름:
- 발화를 단순 상태 진술이 아닌 delegated action goal로 판단
- 휴식에 필요한 관찰·순서·조정을 의미 증거로 기록
- 현재 catalog와 context로 가능한 정상 plan 생성
- runtime gate가 admission과 plan을 독립 검증
- Goal contract를 plan에 결속
- TaskManager가 정상 step을 실행
- 실패·차단·사용자 변경에서만 Supervisor 판단
- success criteria의 terminal evidence가 모이면 완료
이 흐름이 특정 발화 하나에만 맞는 rule이 되지 않으려면, 같은 effect와 constraint를 가진 다른 표현에서도 동일한 admission과 plan 품질이 나와야 한다.
10. 관련 문서
- Experience Runtime Validation Closure 2026-08-05
- Experience Goal Academic Deep Dive
- A2A Planner-TaskManager Baseline Readiness 2026-08-02
- Experience Goal Composer Live Slice 2026-08-02
- Experience Goal과 기존 Planner 통합 구조
- Experience Admission Shadow Phase 1
- A2A Experience Supervisor
- Cloud·On-device·TaskManager Closed Loop
- DeviceAgent Agentic I/O Coverage Matrix
- A2A Text E2E Console