How Memory Management Impacts LLM Agents: An Empirical Study of Experience-Following Behavior

Meta info.

• Authors: Zidi Xiong, Yuping Lin, Wenya Xie, Pengfei He, Zirui Liu, Jiliang Tang, Himabindu Lakkaraju, Zhen Xiang
• Affiliation: Harvard University; University of Georgia; Michigan State University; University of Minnesota-Twin Cities
• Paper: https://aclanthology.org/2026.acl-long.27/
• Code: https://github.com/yuplin2333/agent_memory_manage
• Published: May 21, 2025 (arXiv preprint); ACL 2026 Main (Long Papers)

TL; DR

agent memory의 add/delete만 분리하여 측정하면 long-term 성능은 evaluator 품질에 의존, 약한 LLM judge는 memory를 갱신하지 않는 것보다도 악화.

• 왜: 기존 memory 연구는 전부 “어떤 memory 시스템을 설계할까”에 집중, 메모리에서 가장 기초적인 두 연산(add, delete)이 시간에 따라 agent 행동을 어떻게 바꾸는지는 아무도 규명하지 않음.
• 제안: 새 방법론 제안이 주목적이 아닌 empirical study. 다만 부수적으로 history-based deletion이라는 새 삭제 전략 제안.
• 발견: (1) experience-following property, (2) error propagation, (3) misaligned experience replay. 미래 task의 실행 결과가 저장된 memory의 label이 된다는 실용적 결론

---

1) 좌상단 query가 입력되고,
2) memory에서 검색해서 planning → execution
3) 우측 Memory Management 블록에서 그 결과를 add할지/delete할지 판단
4) 그 결과가 다음 timestep의 memory bank. loop 반복

Background

agent memory의 기본 구조

• LLM agent의 3가지 long-term memory (Sumers et al., 2023)
  • semantic memory: 세계 지식, 환경에 대한 이해
  • procedural memory: 규칙과 절차. LLM weight 안에 암묵적으로 있거나 guideline으로 명시됨
  • episodic memory: task별 경험 기록. 이 논문의 대상
• Figure 1 episodic memory의 동작 방식
  • memory bank $D = \lbrace (q_1, e_1), \dots, (q_N, e_N) \rbrace$
    • $q$: task query (agent input)
    • $e$: execution trajectory (agent output)
  • Memory Reading:
    • 새 query $q$가 오면 가장 관련 있는 $K$개 부분집합 $\xi_K \subset D$ 검색.
    • 보통 text encoder로 embedding 얻고 cosine similarity 고르기
    • in-context demonstration으로 써서 새 execution $e$ 생성
  • Memory Management: 끝난 $(q, e)$를 저장할지 addition, 오래되거나 중복된 걸 지울지 deletion 결정

Related Work

memory 시스템은 많은데, 그 시스템이 시간에 따라 스스로를 오염시키는 과정을 잰 연구는 없음.

• 기존 memory management 전략: 전부 특정 agent 타입(e.g. chatbot)에 맞춰, 서로 다른 agentic system을 관통하는 통합 설계 부재
  • structural transformation (ArIGraph, Zeng et al.)
  • merging (Think-in-Memory, HiAgent)
  • summarization (MemoryBank, Pan et al.)
  • reflection (Reflexion, ExpeL)
• memory bank 최적화 연구: add/delete가 본질적으로 noisy할 때 memory bank의 dynamics가 long-term 성능에 어떤 영향을 주는지에 대한 이해 부재
  • EM 기반 (Yin et al., 2024)
  • MDP formulation (Zhou et al., 2025 / AgentFly)
• static KB를 쓰는 ICL 연구 (Luo et al., 2024)와 차이
  • agentic memory는 (a) retrieval pool 자체가 시간에 따라 변하고 (b) 저장되는 내용이 agent 자신이 만든 noisy output

---

Problem States

memory bank가 연속적인 memory 연산에 의해 진화할 때, 그 dynamics가 장기 agent 실행에 어떻게 영향을 주는가?

• 가장 기본적인 연산만 분리해서 측정하는 실증 연구 필요
  • add와 delete는 memory management의 최소 단위
  • 그럼에도 불구하고 그 효과가 제대로 측정된 적 없음
• 틀린/잘못된 경험이 재검색 → 다음 실행을 오염시키는 경로 추적 필요
  • agent가 저장하는 건 자기가 만든 output
  • 그 output은 오류 가능성 내포, 즉 틀릴 수 있음
• evaluator(trajectory evaluator)가 add/delete를 결정하는데, 그 evaluator의 품질이 어디까지 중요한지 아무도 안 잼 → evaluator 품질 대비 장기 성능 곡선이 필요
• 실제 배포 환경은 task 분포가 바뀌고 저장 공간이 유한함 → distribution shift와 memory 용량 제약 하에서도 성립하는지 확인이 필요
  • 과거 실행 결과가 미래에도 유효할지는 보장 불가함에도, 과거 평가 기록을 그대로 사용하는 것을 경계

---

Suggestions

📌 공통 표기

• addition 결정: evaluator $\pi$의 이진 판정
  • $\pi(q, e) = 1$이면 저장
  • $\pi(q, e) = 0$이면 폐기
• deletion 결정: 기준 $\phi$
  • $\phi = 1$이면 memory bank에서 제거

4가지 Memory Addition

task가 하나 종료되면 만들어지는 $q$와 $e$ pair에 대해 memory에 넣을지 말지 결정하는 판정자 $\pi$를 무엇으로 두느냐만 바꿔가며 비교.

• Fixed-memory baseline $\pi_{\text{fixed}} = 0$ : training set에서 정답 실행만 골라 만든 고정 memory. 아무것도 추가하지 않음.
• Add-all $\pi_{\text{all}} = 1$ : 마주친 모든 task와 실행을 무조건 저장
• Selective addition, coarse $\pi_{\text{automatic}}$ : LLM이 맞은 거 같은지를 판정
  • C1(GPT-4o-mini) < C2(GPT-4.1-mini) < C3(GPT-4.1-mini를 정답 판정 300개로 fine-tune 후 질의) 순으로 정확
    • (RegAgent) 예측값과 정답의 절대 오차 threshold로 정의: C1=1.6, C2=1.4, C3=1.2 (threshold가 작을수록 엄격 = 정확한 evaluator)
• Selective addition, strict $\pi_{\text{human}}$ : 사람(oracle) 판정.
  • 실제로는 생성 결과를 gt와 직접 비교해서 시뮬레이션 (upper-bound)

Findings 1 Experience-Following Property

• 현재 query와 검색된 기록의 query 사이 input similarity가 높으면, 두 실행 결과 사이의 output similarity도 높음
  • 직관적으로는 “비슷한 질문을 만나면 agent가 과거 답을 추론하는 대신 베낀다”

\[\text{output\_similarity} = \exp\left(-\gamma \lVert v_1 - v_2 \rVert^2\right), \quad \gamma = 1.0\]

• 유사도 정의는 agent마다 다름: RegAgent와 AgentDriver는 RBF kernel을 사용
  • EHRAgent는 코드가 출력이라 pycode_similar의 코드 표절 점수를 output similarity로 씀
• 두 출력 벡터가 가까울수록 1에 가깝고 멀수록 0으로 떨어지는 지수 감쇠 함수

Findings 2 Error Propagation

• 틀린 기록이 demonstration으로 검색 → 현재 실행도 실패 → 그 결과가 다시 저장 → 미래 task로 오류 전파
  • experience-following이 강할수록 이 전파도 강화
  • 성질 자체는 중립이더라도 저장내용이 오염되면 증폭

3가지 Memory Deletion: 세 가지 전략

• Periodical-based Deletion: 인간 인지의 forgetting rate에서 착안, “지난 구간 동안 $\alpha$번 이하로만 불려나온 기록은 쓸모없으니 지운다”
  • memory 크기에 상한: $M \leq \alpha(t - t’)K$ ($K$는 실행당 검색 개수)
  • 품질은 전혀 고려하지 않고 오직 인기도만 확인

\[\phi_{\text{per}}(q_i, e_i, t, t') = \mathbb{1}\left[ fr_t(q_i, e_i) - fr_{t'}(q_i, e_i) \leq \alpha \right]\]

• $fr_t$: 시각 $t$까지 이 기록이 검색된 누적 횟수
• $\alpha$: 구간 $[t’, t]$ 안에서 요구되는 최소 검색 횟수
• History-Based Deletion (본 연구 제안!): 기록 자체를 채점하는 게 아니라, 그 기록을 참조한 미래 실행들의 성적표로 소급 채점.
  • 미래 task 평가가 저장된 memory의 free quality label이 되는 것
  • “저장된 경험의 품질과, 그 경험이 검색됐을 때 나온 미래 실행의 품질 사이에 상관이 있을 것”
    • 기록이 불려나갔던 과거 실행들의 평균 점수를 보고 판단

\[\phi_{\text{hist}}(q_i, e_i, t) = \begin{cases} \delta(q_i, e_i, t), & \text{if } fr_t(q_i, e_i) > n \\ 0, & \text{otherwise} \end{cases}\] \[\delta(q_i, e_i, t) = \mathbb{1}\left[ \frac{1}{fr_t(q_i,e_i)} \sum_{m=1}^{fr_t(q_i,e_i)} \Phi(q_m, e_m) \leq \beta \right]\]

• $\Phi$: utility evaluator (addition에 쓴 것과 같은 걸 재사용 가능)
• $\Phi(q_m, e_m)$: 이 memory 기록이 $m$번째로 검색됐을 때 나온 결과 실행의 품질 점수
• 조건:
  • (a) 최소 $n$번은 검색된 적 있어야 하고 (평균 추정 편향을 줄이고자),
  • (b) 그 평균 utility가 threshold $\beta$ 이하여야 함

• Note.

  addition과 deletion은 같은 층위의 대칭 연산이 아님. (판정 시점과 근거가 다르고 각각 다른 실패를 대응)

  • addition: 실행 직후 1회, 그 실행 자체가 맞았는지(intrinsic)를 확인 → error propagation을 막는 게이트
  • deletion(history-based): 여러 번 검색된 뒤 누적, 그것을 참조한 후속 실행이 잘 됐는지(downstream)를 확인 → misaligned experience replay를 걷어내는 gate
  • 즉 판정 근거를 intrinsic에서 downstream으로 옮기는 것 논문 제안의 실질
• Combined Deletion : 인기 없거나 성적 나쁘거나 둘 중 하나면 삭제

\[\phi_{\text{comb}} = \phi_{\text{per}} \vee \phi_{\text{hist}}\]

Findings 3 Misaligned Experience Replay

• evaluator judge는 통과해도, 현재 task 분포와 불일치로 demonstration으로서 계속 나쁜 결과를 내는 기록이 있다고
  • 원인:

    • (a) 저장된 trajectory와 현재 실행 맥락 사이의 불일치

      e.g. 저장 시점에는 정답으로 판정됐지만, 현재 task와 맥락이 어긋나 demonstration으로 쓰일 때마다 나쁜 실행을 유도하는 기록

    • (b) evaluator 자체의 한계로 들어간 오류

• 즉 “정답이다”와 “예시로 유용하다”가 다른 축이라는 주장.
  • history-based deletion이 이 부류를 잡는다고 주장.

Effects

• Experimental setup
  • agent: 통제 가능성 스펙트럼과 형식 다양성을 동시에 확보하도록 구성 Tab 3
    • RegAgent (합성, 통제용): demonstration에만 의존하고, memory noise를 직접 조절하며, error를 직접 측정할 수 있어 오염과 성능의 인과를 격리 가능
      • 숨은 가중치 $w \in \mathbb{R}^6$에 대해 $y = w^\top x$를 demonstration 6개로 예측
      • 초기 memory 100건: $\mu \in \lbrace -0.5, 0, 0.5 \rbrace$인 세 가우시안에서 $x$를 뽑고 $y = w^\top x + \epsilon$, $\epsilon \in [-1, 1]$로 생성
      • 실행 스트림 4,000건: $\lvert \hat{y} - y \rvert \leq 1$이면 성공(SR)
    • EHRAgent (Shi et al., 2024): MIMIC-III에 자연어로 질의하면 코드를 생성해 답하는 agent
      • 중복 및 응답불가 제거 후 2,392 task, 초기 memory 100건
        • 검색 4건, text-embedding-3-large, 지표 ACC
      • strict evaluator는 exact match, coarse는 LLM이 생성한 종료 신호
    • AgentDriver (Mao et al., 2024): nuScenes 기반 자율주행 agent
      • 테스트 2,000건, 초기 memory 180건
        • 원 논문의 top-3 검색 후 LLM 선택을 재현성 목적으로 top-1 단일 검색으로 단순화
      • strict evaluator는 UniAD 3초 평균 L2 거리가 2.5 미만이면 저장
    • CIC-IoT Agent (Neto et al., 2023): IoT 패킷 feature로 트래픽 유형 분류
      • 원래 34개 class 중 single-flow feature로 구분 가능한 8개만 남김
        • 테스트 1,000건, 검색 3건, 지표 ACC
      • input similarity는 연속형 feature의 상대 변화량과 이산형 feature의 일치 여부를 평균한 feature 기반 방식
  • backbone: 주 실험은 GPT-4o-mini, 재현 확인은 GPT-4o와 DeepSeek-V3
  • evaluator: Fixed, Add-all, Coarse C1/C2/C3, Strict를 품질 순으로 배치해 연속 변수처럼 취급
  • 도전 조건
    • task distribution shift: 테스트 query 임베딩을 GMM으로 3개 군집화, 군집 순서대로 재정렬해 인위적 분포 이동 생성
    • memory constraint: EHRAgent 100건, AgentDriver 180건으로 용량 고정
      • 초과 시 최저 utility 기록 하나만 제거하도록 combined deletion 수정

  • hyperparameter는 agent마다 개별 설정 (Appendix A.1)

    

    	RegAgent	EHRAgent	AgentDriver	CIC-IoT
    strict $\pi_{\text{human}}$	오차 $\leq$ 1.0	exact match	UniAD 3초 L2 $<$ 2.5	string match
    coarse $\pi_{\text{automatic}}$	오차 $\leq$ 1.6 / 1.4 / 1.2	LLM 종료 신호	LLM yes/no	LLM judge
    periodic 주기, $\alpha$	500, 0	200, 0	500, 0	500, 1
    history $n$, $\beta$	5, 0.5	5, 0.3(coarse) / 0.7(strict·FT)	3, L2 $>$ 5.0	3, 0.7

• Results
  • Addition of Memory
    • 실행 품질과 memory 크기가 함께 long-term 성능 결정 Tab 1
      • $\pi_{\text{fixed}}$가 RegAgent, AgentDriver, CIC-IoT에서 준수
        • 때로는 coarse evaluator를 앞서기도
        • noisy하거나 저품질인 addition이 memory 효용을 해칠 수 있음
      • $\pi_{\text{human}}$은 고품질 기록만으로 memory를 넓혀 일관되게 우수
        • memory의 품질과 용량이 둘 다 효과적인 long-term 학습의 조건
      • coarse에서는 성능이 judge 능력에 의존
        • 300건 fine-tune한 C3가 다른 coarse와 무필터 addition을 모두 상회
      • 성능 trend Fig 2
        • $\pi_{\text{all}}$과 일부 coarse는 평평하거나 하락 == 결함 기록의 누적
        • $\pi_{\text{fixed}}$는 더 낫긴 해도 memory가 변하지 않아 정체
        • $\pi_{\text{human}}$과 C3만 계속 개선되며 backbone을 바꿔도 동일
      • vanilla LLM을 trajectory evaluator로 그대로 쓰는 것은 작지만 품질 좋은 데이터셋을 직접 만드는 것보다 더 심한 악영향을 줄 수 있다
    • input similarity와 output similarity의 상관성 Fig 3
      • $\pi_{\text{fixed}}$: 두 유사도가 모두 낮게 유지 vs. addition 계열($\pi_{\text{fixed}}$ 제외): input이 오를수록 output도 상승
        • $\pi_{\text{fixed}}$는 RegAgent와 AgentDriver 모두 0.52 vs. addition 계열은 Pearson $r$이 0.9 내외
      • RegAgent에서 memory가 커지고 demonstration이 query와 비슷해질수록 $r \approx 1$에 근접
      • $\pi_{\text{fixed}}$는 순수 모방이 아니라 추론에 의존 → noisy memory를 쓰는 coarse보다 오히려 높은 성능
      • 모방하는 강도는 backbone에 의존적 Fig 12
        • GPT-4o-mini 0.85 > GPT-4o 0.71 > DeepSeek-V3 0.60
      • 강한 evaluator를 쓰면 맞는 실행의 복제로 self-improvement발생 무분별한 addition은 self-degradation을 발생
    • error-free variants의 성능 차 Fig 4 : 검색되는 예시는 동일하게 두고 execution만 ground truth로 교체 구성
      • 두 agent 모두 즉각적인 격차 발생, $\pi_{\text{all}}$과 coarse는 실행이 이어질수록 격차 확대
        • AgentDriver의 $\pi_{\text{human}}$은 초반에 뒤처지나 약 2,000 실행 후 오히려 추월
      • memory의 양과 질이 모두 중요, evaluator를 신중히 선택하고 학습 요망
  • Deletion of Memory
    • 전략적 memory deletion이 agent 성능 개선 Tab 2 : 신뢰할 만한 utility evaluator가 있으면 history deletion이 성능 개선, combined는 성능 유지와 memory 축소 사이 균형 제공
      • periodical-based deletion: 큰 memory 감소를 작은 성능 저하로 달성
        • addition만 하는 설계가 잉여 항목을 자주 축적
      • history-based & combined: utility evaluator 신뢰도에 따라 편차가 큼
        • $\pi_{\text{human}}$을 쓰면 비합성 agent에서 뚜렷한 성능 향상
        • RegAgent는 수백 건의 빈출 실행을 제거해도 성능 하락이 작음
      • error-free memory baseline과 비교 Fig 13
        • AgentDriver에서 $\pi_{\text{human}}$ + history deletion이 error-free 대응을 능가, 폭도 deletion 없는 경우보다 큼
          • downstream utility가 높은 경험을 선택적으로 남기는 것이 장기 성능을 개선할 수 있다
      • evaluator가 coarse하거나 noisy할 때 방향성 Fig 5
        • GPT-4o-mini judge는 EHRAgent에서 이득, AgentDriver에서 저하
        • fine-tuned evaluator는 더 안정적이며 더 작은 memory로 비슷한 성능 달성
    • 삭제 기록과 남은 기록의 품질 차이 Fig 6
      • 맥락과 task 분포의 불일치는 사례별이라 포착이 어려워, evaluator 한계에서 오는 error를 대리 지표로 사용
      • RegAgent의 KDE 비교에서 잔존 demonstration의 error가 삭제된 것보다 낮음
        • $\pi_{\text{human}}$ 조건에서 error 1.0 이하만 저장했는데도 0.5 초과 항목은 오류를 전파해 제거됨
      • 경험의 내재적 품질이 downstream 실행 품질과 연결되며, 미래 실행 품질이 낮은 demonstration을 제거하면 misaligned experience replay를 완화
  • Memory Management under Challenging Scenarios
    • task distribution shift Fig 7
      • 분포 전환 이후에도 no-shift들 대비 격차는 전반적으로 작다고
      • AgentDriver: $\pi_{\text{human}}$ addition만으로 no-shift들을 상회
      • EHRAgent: history-based deletion이 combined보다 저조
      • 분포 이동이 있는 실제 상황에서는 periodic deletion이 단순함에도 안정화에 기여 가능
    • memory resource constraint
      • 용량을 초기 크기로 고정한 조건에서도 memory management 정책이 높은 성능 유지
        • 가장 관련성 높고 품질 좋은 기록만 남겨 제한된 저장 공간을 효율적으로 활용
      • AgentDriver에서 제약 크기를 늘리면 성능이 점진적으로 수렴
      • 자원 제한 환경에서도 memory management가 장기 성능을 개선하며, 무한정한 memory 성장은 불요
• Limitation
  • 다룬 연산이 add/delete 두개 뿐: structural transformation, merging, summarization, reflection은 제외됨
  • 이론적 보증 없이 경험적 분석에만 의존하며 RegAgent 환경이 향후 이론 연구의 발판이 될 수 있다고만 언급

Personal note. 설계가 깔끔해서 배울 게 있었다고 생각합니다. 고민 많이 했을 것 같아요. 이 논문의 add/delete는 전부 framework가 규칙으로 수행하는 것이고, agent가 쓸지 말지를 판단하지는 않습니다. proactivity 측면을 고려해야하는지 고민중인데, 사실은 그정도를 고려하지 않더라도, 규칙으로 시켜도 문제가 없다는 뜻일 수도 있고요. 다만 error-free baseline과 비교에서 AgentDriver에서 실제 실행이 ground-truth 실행을 추월하는데, 정답 trajectory가 반드시 최선의 demonstration은 아니라는 뜻으로 이해됩니다. 실험 설계상 완벽한 메모리(gt)를 줬을 때를 상한으로 상정하고는 하는데, 실제로는 그 gt가 최적은 아니라는 소리니까요. 검색 결과는 고정하고 저장된 실행 내용만 gt로 교체함으로써 retrieval 품질과 저장물 품질을 분리해낸 대조군 설계도 눈여겨볼 만합니다.