← Docs hub

A2A Memory and Personalization

메모리 설계의 최종 목적은 A2A가 이전 맥락과 사용자 특성을 바탕으로 더 정확한 추론을 하게 만드는 것이다.

메모리 단위

저장 단위별 의미

메모리는 “대화를 많이 저장하는 기능”이 아니라, 다음 A2A 판단에 필요한 근거를 계층화하는 기능이다.

현재 구현된 최소 계약

현재 Cloud repo에는 완성된 DB memory system이 아니라, planner-safe memory context를 주고받는 최소 runtime 계약이 구현되어 있다.

현재 계약의 중요한 제한:

• Cloud DB migration/repository/sync worker는 아직 구현 완료 상태가 아니다.
• profile_candidates는 구조만 있고 실제 extractor/promotion은 후속 구현 대상이다.
• 현재 구현은 memory를 “증거”로 전달하지만, 장기 profile 확정 로직은 아직 없다.
• 따라서 지금 단계에서는 memory가 route family를 직접 바꾸는 기능이 아니라 planner-safe support context다.

현재 실제로 되는 동작

현재 소스 기준으로 “된다”고 말할 수 있는 범위는 아래와 같다.

현재 입력 예시

현재 runtime은 아래와 같은 memory snapshot을 받을 수 있다.

{
  "voice_context": {
    "recognized_text": "나는 거실을 자주 청정해",
    "session_id": "memory-session",
    "memory_snapshot": {
      "source": "ondevice_cache",
      "short_term": {
        "recent_pairs": [
          {
            "user": "거실 청정해줘",
            "assistant": "시작할게요"
          }
        ],
        "session_summary": "오늘 거실 청정을 자주 요청함"
      },
      "mid_term": {
        "daily_summaries": [
          {
            "day": "2026-06-24",
            "summary": "저녁에 청정을 자주 요청"
          }
        ],
        "weekly_digest": "저녁에 청정을 자주 요청"
      },
      "long_term": {
        "profile_items": [
          {
            "key": "preferred_room",
            "value": "거실"
          }
        ]
      },
      "sync": {
        "cursor": "cur-2",
        "version": "v2"
      }
    }
  }
}

현재 normalized memory output

Planner에는 아래처럼 정규화되어 들어간다.

{
  "contract_version": "a2a-memory-context-v1",
  "source": "ondevice_cache",
  "current_turn_priority": "required",
  "short_term": {
    "recent_pairs": [
      {
        "user": "거실 청정해줘",
        "assistant": "시작할게요"
      }
    ],
    "session_summary": "오늘 거실 청정을 자주 요청함"
  },
  "mid_term": {
    "daily_summaries": [
      {
        "day": "2026-06-24",
        "summary": "저녁에 청정을 자주 요청"
      }
    ],
    "weekly_digest": "저녁에 청정을 자주 요청"
  },
  "long_term": {
    "profile_items": [
      {
        "key": "preferred_room",
        "value": "거실"
      }
    ]
  },
  "sync": {
    "cursor": "cur-2",
    "version": "v2"
  }
}

현재 runtime memory update output

Turn 실행 후 runtime은 아래 형태의 update 후보를 만든다.

{
  "contract_version": "a2a-memory-context-v1",
  "source": "cloud_a2a_runtime",
  "sync": {
    "cursor": "cur-2",
    "version": "v2"
  },
  "write_candidates": {
    "short_term_pair": {
      "user_text": "나는 거실을 자주 청정해",
      "assistant_text": "",
      "route_family": "DEF",
      "workflow_id": ""
    },
    "profile_candidates": []
  },
  "device_cache_update": {
    "active_workflow_id": "",
    "last_route": "DEF",
    "session_summary": ""
  }
}

이 output의 의미:

• 현재 turn을 short-term pair 후보로 남길 수 있다.
• cursor/version을 보존해 on-device cache 또는 Cloud DB write 경로로 넘길 수 있다.
• 아직 profile 후보는 자동 생성하지 않는다.
• assistant_text는 현재 최소 구현에서는 비어 있으며, 후속 구현에서 route result summary를 채워야 한다.

Cloud와 온디바이스 역할

온디바이스:

• 최근 turn과 session context를 보관한다.
• Cloud 요청 시 compact memory snapshot을 보낸다.
• Cloud가 내려준 memory update를 local cache에 반영한다.

Cloud:

• Planner가 필요한 수준으로 memory를 요약한다.
• long-term candidate를 추출한다.
• LangGraph/LangMem 같은 orchestration 도구를 사용하더라도 제품 schema는 유지한다.

Read / Write 흐름

Turn 시작 전 read

On-device local session cache
-> voice_context.memory_snapshot
-> Cloud normalize_memory_context
-> planner input memory_context

Planner에 들어가는 memory는 반드시 compact해야 한다.

Turn 종료 후 write

route execution result
-> build_memory_update
-> write_candidates.short_term_pair
-> On-device local cache update
-> Cloud DB write 또는 pending sync
-> summarizer / promotion worker

write는 즉시 long-term 확정이 아니다.

압축 정책

메모리 압축은 Pair -> Session -> Day -> Week -> Profile 순서로 진행한다.

압축 결과에는 항상 source reference가 필요하다.

profile item
-> source_candidate_ids
-> source_summary_ids
-> source_session_ids
-> source_pair_ids

이 chain이 있어야 잘못된 profile을 나중에 되돌릴 수 있다.

중요한 원칙

• Memory는 현재 발화를 덮어쓰면 안 된다.
• Long-term memory는 candidate와 confirmed state를 분리한다.
• 민감 정보는 저장 정책과 삭제 정책이 있어야 한다.
• A2A route family 판단에 memory를 쓰더라도, 현재 발화의 명확한 의미가 우선이다.

Planner 입력 예시

{
  "recognized_text": "안방으로 가서 청정해줘",
  "voice_context": {
    "session_id": "session-123",
    "last_route": "ODL",
    "active_workflow_id": ""
  },
  "memory_context": {
    "contract_version": "a2a-memory-context-v1",
    "current_turn_priority": "required",
    "short_term": {
      "recent_pairs": [
        {
          "user": "거실 청정해줘",
          "assistant": "거실 청정을 시작할게요.",
          "route_family": "ODL"
        }
      ],
      "session_summary": "오늘 사용자는 방 단위 청정 요청을 여러 번 했다."
    },
    "mid_term": {
      "daily_summaries": [
        {
          "date": "2026-06-24",
          "summary": "저녁 시간대에 안방/거실 청정 요청이 반복됨"
        }
      ],
      "weekly_digest": "최근 일주일간 방 단위 청정 요청이 반복됨"
    },
    "long_term": {
      "profile_items": [
        {
          "category": "device_pattern",
          "value": {
            "preferred_cleaning_rooms": ["거실", "안방"]
          },
          "confidence": 0.83
        }
      ]
    },
    "sync": {
      "cursor": "cur-42",
      "version": "v1"
    }
  },
  "device_context": {
    "current_room": "거실",
    "battery": 82
  }
}

Planner 사용 해석:

• 현재 발화가 안방으로 가서 청정해줘이므로 ODL/device action이 우선이다.
• memory의 “방 단위 청정 반복”은 보조 근거일 뿐, 발화를 다른 family로 바꾸지 않는다.
• profile hint는 slot 추론이나 응답 자연성에는 도움을 줄 수 있지만, 실행 대상은 현재 발화의 안방이 우선이다.

예시: 장기 선호 승격

Day 1: "안방 청정해줘"
Day 2: "안방 좀 깨끗하게 해줘"
Day 4: "잘 때는 안방 먼저 청정해"
Day 6: proactive 추천 "안방 청정을 시작할까요?" -> 사용자 수락

처리:

이때 단발성 “안방 청정해줘” 하나만으로 장기 선호를 확정하면 안 된다.

다음 구현 방향

상세 DB schema, sync cursor, retention/delete 정책은 Memory DB and Sync Contract를 기준으로 관리한다.