Databricks에서 Agent Memory 소개: 과거 작업을 재사용 가능하게 만들기

Databricks는 베타로 agent memory를 도입하며, 엔터프라이즈 에이전트가 이전 대화에서 학습한 내용을 다시 발견하게 만드는 관행에 도전장을 던졌다. 10월 20일 발표된 Introducing Agent Memory on Databricks는 회사의 에이전트 개발 플랫폼인 Agent Bricks에 지속적 컨텍스트를 탑재한다. 실질적인 질문은 경험을 보존하는 것이 변화하는 비즈니스 작업 전반에서 신뢰할 수 있는 개선으로 이어지느냐는 것이다.

핵심 비교 대상은 관리형 메모리와 반복적인 재발견, 그리고 맞춤형 메모리 인프라다. 엔터프라이즈 개발자는 자체 시스템을 유지하는 것이 여전히 엔지니어링 비용만큼의 가치를 제공하는지 판단해야 한다. Amazon의 AgentCore는 이미 관리형 메모리를 제공하고 있으므로, Databricks는 에이전트가 축적한 지식이 어디에 존재해야 하는지를 둘러싼 기존 경쟁에 뛰어든 셈이다.

구매자에게 이 발표는 어시스턴트가 선호하는 응답 형식을 기억하는지보다 더 구체적인 질문을 제기한다. 플랫폼이 유용한 수정 사항을 보존하고, 이를 적절히 적용하며, 기억된 정보가 답변에 영향을 미친 시점을 설명할 수 있는가? 이 조합은 메모리가 운영상의 이점이 될지, 아니면 또 다른 오류 원인이 될지를 결정한다.

Databricks에서 Agent Memory 소개: 컨텍스트를 지속적으로 유지하다

Databricks는 세션 간 메모리를 운영형 서비스로 패키징하여 구현 부담의 일부를 애플리케이션 팀에서 덜어내고 있다.

회사의 agent memory 발표는 관리형 대화 기록, 지속형 메모리, 그리고 에이전트가 보존해야 할 내용을 통합하는 백그라운드 프로세스를 설명한다. 이 서비스는 Databricks의 관리형 Postgres 데이터베이스인 Lakebase에서 실행된다. Databricks는 개발자가 기억된 항목을 검사, 내보내기, 삭제할 수 있다고 설명한다.

이는 엔터프라이즈 애플리케이션의 출발점을 바꾼다. 이전에는 지속성을 직접 구축하는 팀이 스토리지를 유용한 정보의 선택 및 검색 규칙과 연결해야 했다. 관리형 옵션을 사용하면 해당 팀은 자체 구현에 전념하기 전에 기존 구현을 평가할 수 있다.

대화 기록을 보존한다고 해서 자동으로 유용한 메모리가 만들어지는 것은 아니므로 이 구분은 중요하다. 대화 기록에는 실수, 포기한 접근 방식, 임시 가정까지 포함해 일어난 일이 기록된다. 유용한 메모리를 만들려면 어떤 부분이 향후 작업에 영향을 미칠 가치가 있는지 판단해야 한다.

수익 정의에 관한 수정을 받는 분석 어시스턴트의 사례를 생각해 보자. 그 수정은 특정 부서, 보고 기간 또는 특정 대시보드에만 적용될 수 있다. 범위 없이 문장만 기억하면 어제의 답변을 다른 질문에 적용할 위험이 있다.

이 지점에서 이 발표는 개인화를 넘어선 의미를 갖는다. 어조에 관한 선호는 표현 방식에 영향을 준다. 반면 기억된 비즈니스 정의는 답변의 내용과 이후 수행될 수 있는 행동에 영향을 준다.

따라서 엔지니어링 의사결정은 스토리지만큼이나 책임에 관한 문제다. 개발자가 관리형 메모리를 도입하더라도, 어떤 보존 정보가 자신의 애플리케이션에 속하는지 판단해야 한다. 또한 권위 있어 보이지만 더 이상 적용되지 않는 항목에 이의를 제기할 방법도 필요하다.

Introducing Agent Memory on Databricks는 이러한 팀에 인프라 옵션을 제공한다. 모든 대화가 지속 가능한 지식을 만들어야 한다는 사실을 입증하지는 않는다. 특히 사용자가 지속적인 선호와 임시 요청을 섞어 사용하는 경우, 선택적 보존은 여전히 제품 의사결정으로 남는다.

애플리케이션은 사용자의 선호 보고 형식을 기억하면서도 잠정적인 예측은 보존하지 않는 것이 합리적일 수 있다. 두 진술 모두 대화를 통해 전달되지만, 서로 다른 기대를 수반한다. 이를 동일하게 취급하면 지속성 구현은 쉬워지지만 신뢰하기는 어려워진다.

따라서 즉각적인 변화는 구체적이지만 제한적이다. 이제 Databricks는 개발자에게 대화 전반에 걸쳐 경험을 보존할 관리형 공간을 제공한다. 그 경험이 재사용할 가치가 있는지는 애플리케이션의 규칙과 각 메모리를 뒷받침하는 근거에 달려 있다.

이 경계는 상업적 이해관계를 형성한다. 팀은 인프라 작업을 플랫폼으로 이전할 수 있지만, 무엇이 유효한 비즈니스 지식인지에 대한 이해까지 이전할 수는 없다.

엔터프라이즈 팀은 다른 구축-구매 결정을 마주한다

압박을 받는 팀은 메모리 인프라와 이에 의존하는 에이전트를 함께 유지하는 팀이다.

내부 플랫폼 그룹에 맞춤형 메모리는 지속적인 책임을 만든다. 누군가는 누락된 항목, 부적절한 검색, 상충하는 수정 사항, 실패한 업데이트를 조사해야 한다. 이러한 책임은 초기 시연이 성공한 후에도 계속된다.

관리형 서비스는 비교 기준을 기능 제공 여부에서 운영 가치로 바꾼다. 문제는 맞춤형 구현이 유지 비용을 정당화할 만큼 충분한 제어 또는 전문성을 제공하는가가 된다. 이는 단순히 에이전트가 정보를 저장할 수 있음을 보여주는 것보다 더 엄격한 기준이다.

맞춤형 접근 방식을 유지할 정당한 이유도 있다. 조직에는 특수한 보존 규칙, 이례적인 배포 경계 또는 기존 시스템 전반에서 공유되는 메모리 형식이 필요할 수 있다. 이러한 요구 사항은 관리형 인프라가 항상 우세하다고 가정하기보다 평가할 가치가 있다.

반대로 일반적인 요구 사항을 가진 팀은 애플리케이션을 이미 소유하고 있다는 이유만으로 익숙한 기반 기능을 다시 구축해도 얻는 것이 거의 없다. 부족한 엔지니어링 역량은 더 나은 평가나 더 명확한 사용자 제어를 통해 더 큰 가치를 만들 수 있다.

Databricks의 진입은 엔터프라이즈 구매자에게 또 다른 비교 기준도 제공한다. Amazon의 AgentCore memory types 문서는 원시 상호작용 스토리지와 백그라운드 처리로 추출된 장기 기록을 설명한다. 또한 이후 세션에 걸친 통합과 검색도 설명한다.

이러한 중첩은 경쟁의 기준선을 설정한다. 지속형 메모리는 이미 다른 주요 공급업체가 제공하는 플랫폼 기능이다. Databricks는 구현 품질, 운영 적합성, 고객이 실제로 실행하는 워크로드와의 통합으로 경쟁해야 한다.

공개된 문서만으로는 이 서비스들 사이의 성능 우위를 입증할 수 없다. 아키텍처 설명은 의도된 동작을 설명하지만, 동등한 테스트를 대체하지는 못한다. 공정한 비교라면 작업, 모델, 기록, 채점 규칙을 동일하게 유지해야 한다.

구매자에게 이는 공급업체 선택이 애플리케이션의 실패 양상을 따라야 함을 의미한다. 선호를 잊는 지원 어시스턴트는 반복적으로 잘못된 소스를 선택하는 분석 에이전트와 다른 요구 사항을 제시한다. 메모리 품질은 구매를 통해 해소하려는 구체적 문제에 맞춰 측정해야 한다.

조달 논의 역시 편의성과 의존성을 구분해야 한다. 인프라를 통합하면 조직이 운영하는 시스템 수를 줄일 수 있다. 하지만 축적된 컨텍스트가 애플리케이션 동작의 일부가 되면 마이그레이션의 영향도 더 커질 수 있다.

내보낼 수 있는 항목은 도움이 되지만, 내보내기만으로 다른 환경에서 동등한 동작이 보장되지는 않는다. 다른 시스템은 다른 메모리를 선택하거나 동일한 보존 텍스트를 다르게 해석할 수 있다. 이식성은 데이터 전송 테스트뿐 아니라 동작 테스트도 필요하다.

따라서 관리형 메모리 구매의 가장 강력한 근거는 실용적이다. 서비스는 애플리케이션에 필요한 제어를 유지하면서 유지보수를 줄여야 한다. 구매자는 인프라 통합을 개선으로 간주하기 전에 두 결과 모두에 대한 근거를 기대해야 한다.

압박은 맞춤형 구현과 관리형 공급업체 모두에 가해진다. 각각은 단지 에이전트가 보존할 수 있는 정보량을 늘리는 것이 아니라, 어떻게 완료된 작업을 개선하는지 설명해야 한다.

이 메커니즘은 재사용할 가치가 있는 것을 선택하는 데 달려 있다

핵심 설계 문제는 어떤 경험이 다음 작업에 영향을 미쳐야 하는지 결정하는 것이다.

Databricks의 memory pipeline 문서는 지속적인 정보를 추출하고, 중복되는 항목을 병합하며, 저장된 메모리를 재구성하는 백그라운드 처리를 설명한다. 개발자는 무엇을 보존할지에 관한 지침을 제공할 수 있다. 문서화된 설계는 실시간 소스에서 가져와야 하는 변동 값보다 재사용 가능한 사실과 절차를 우선한다.

이 구분은 엔터프라이즈 분석에 직접적인 영향을 미친다. 지표 계산 방식을 기억하면 에이전트가 유효한 워크플로를 반복하는 데 도움이 될 수 있다. 지표의 이전 값을 기억하면 기반 비즈니스가 변화했을 때 오래된 답변을 만들 수 있다.

가상의 영업 어시스턴트는 그 차이를 명확히 보여 준다. 특정 보고서에서 팀이 취소된 계약을 제외한다는 규칙은 보존할 수 있다. 하지만 다음 보고서를 준비할 때는 여전히 최신 계약 데이터를 가져와야 한다.

보존된 규칙은 새로운 근거를 대체하지 않으면서 재발견을 줄인다. 그러나 조직이 해당 규칙을 변경한다면 메모리도 적절히 수정되어야 한다. 따라서 성공적인 재사용은 보존과 수정 모두에 달려 있다.

백그라운드 처리는 또 다른 의사결정 경계를 만든다. 파이프라인 문서는 수동 실행 또는 약 24시간마다의 예약 실행을 허용한다. 따라서 예약된 통합은 모든 새로운 수정 사항이 즉시 모든 이후 상호작용을 바꾼다는 보장이 아니라, 지연된 처리로 이해해야 한다.

애플리케이션 설계자에게 시사점은 간단하다. 사용자의 다음 요청에 필요한 수정은 이후 통합을 기다릴 수 있는 지식과 다르게 처리할 가치가 있다. 사용자는 수정이 적용되었는지 알기 위해 처리 일정을 이해할 필요가 없어야 한다.

문서는 유지보수가 에이전트가 직접 저장한 항목도 변경할 수 있다고 설명한다. 이는 저장된 메모리가 대화에 대한 진화하는 해석의 일부임을 의미한다. 반드시 원래 진술의 영구적인 복사본인 것은 아니다.

이는 제품 팀에 책임성에 관한 질문을 제기한다. 통합 과정에서 기억된 지침이 변경된다면, 애플리케이션은 그에 따른 동작을 설명할 충분한 근거를 갖춰야 한다. 그렇지 않으면 사용자는 이해할 수 있는 이유 없이 어시스턴트가 해석을 바꾸는 모습을 보게 된다.

유용한 비유는 작업 메모를 관리하는 분석가다. 메모는 관련 조건을 보존하고 검증된 소스 자료와 구별될 때만 도움이 된다. 에이전트의 보존된 요약도 비슷한 수준의 검토를 받아야 한다.

같은 구분은 personal knowledge management에서도 나타난다. 정보를 수집하는 일과 이를 유용하게 만드는 일은 연관되어 있지만 별개의 작업이다. 엔터프라이즈 에이전트에서는 보존된 정보가 현재 요청에 여전히 적절한지 여부도 유용성을 좌우한다.

이 메커니즘은 메모리를 애플리케이션 동작의 능동적 일부로 만든다. 다음 작업이 시작되기 전에 경험을 선택하고, 압축하고, 업데이트한다. 서비스를 평가하는 팀은 성공적인 저장을 종착점으로 여기기보다 이러한 변환을 판단해야 한다.

벤치마크는 제한적인 성능 주장을 뒷받침한다

Databricks는 자사 엔터프라이즈 벤치마크에서 개선을 보고하지만, 그 결과가 보편적인 향상을 입증하지는 않는다.

회사의 MemCurrent 연구는 이번 출시를 뒷받침하는 아키텍처를 설명합니다. Databricks는 내부 벤치마크에서 MemCurrent 사용 시 통과율이 68.4%였으며, 메모리를 사용하지 않을 때의 22.3%와 비교된다고 밝혔습니다. 또한 토큰 사용량은 31% 적고 실행 속도는 26% 빨랐다고 보고했습니다.

내부 벤치마크에는 29명의 사용자와 2,233개의 과거 세션이 포함된 114개 사례가 담겼습니다. Databricks는 기업 데이터 대화로부터 평가를 구성하고 사례를 검토했다고 말합니다. 이는 회사가 보고한 결과이며, 모든 배포 환경에 대한 독립적인 검증은 아닙니다.

이 연구는 예시적인 워크플로 개선도 보고합니다. 이전 작업에 11회의 도구 호출과 거의 6분이 필요했던 뒤, 관련 후속 작업에는 도구 호출 2회와 41초가 소요됐습니다. 이 사례는 반복적인 탐색을 피한다는 제안된 메커니즘을 뒷받침합니다. 하지만 고객이 기대할 수 있는 평균적인 개선 폭을 입증하지는 않습니다.

사례와 기대되는 결과를 구분하는 일은 중요합니다. 재사용 가능한 맥락이 있는 반복 작업은 메모리를 활용하기에 유리한 기회를 제공합니다. 관련 없는 요구사항을 가진 새로운 작업은 과거 정보에서 얻는 이점이 거의 없을 수 있습니다.

마찬가지로, 더 적은 토큰 수는 특정 자원만 측정할 뿐 전체 운영 부담을 뜻하지는 않습니다. 팀은 메모리를 생성, 유지, 점검, 평가하는 데 필요한 작업도 고려해야 합니다. 배포 결정은 애플리케이션 전체를 고려해야 합니다.

이러한 결과는 구체적인 가설을 검증해야 할 이유로서 가장 유용합니다. 에이전트가 안정적인 비즈니스 지식을 반복적으로 다시 찾아내고 있다면, 축적된 경험은 그러한 반복을 줄여야 합니다. 과거 대화가 관련 정보를 거의 제공하지 않는다면 이 가설은 약해집니다.

평가에는 메모리가 사용되지 않아야 하는 작업도 포함해야 합니다. 그렇지 않으면 시스템은 모든 답변에 과거 맥락을 삽입하는 방식으로 성공한 것처럼 보일 수 있습니다. 관련 없는 기억은 그 자체로 주의를 분산시키므로 선택성이 중요합니다.

독립 연구는 더 폭넓은 평가 프레임워크를 제공합니다. ICLR 2025에서 발표된 LongMemEval 벤치마크는 추출, 세션 간 추론, 시간적 추론, 지식 업데이트, 응답 보류를 테스트합니다. 응답 보류란 이용 가능한 근거가 답변을 뒷받침하지 않을 때 답변을 거부하는 것을 의미합니다.

이 범주들은 단순한 회상이 불완전한 척도인 이유를 보여줍니다. 어시스턴트는 오래된 진술을 정확하게 검색하고도 잘못된 시점에 적용할 수 있습니다. 메모리에 관련 근거가 없는데도 확신에 차서 답변하는 방식으로 실패할 수도 있습니다.

따라서 기업 구매자에게 유용한 질문은 메모리가 벤치마크 점수를 높이는지보다 더 좁습니다. 변경된 정의나 상충하는 지침이 있는 사례를 포함해, 메모리가 직원들이 실제로 수행하는 업무를 개선하는가?

Databricks의 Agent Memory 출시는 관리형 인프라를 통해 이러한 비교를 실행할 기회를 만듭니다. 공개된 결과는 주목할 만하지만, 보고된 메커니즘이 실제로 적용되는지는 애플리케이션 자체의 평가가 판단해야 합니다.

이는 증거에 대한 타당한 해석입니다. 회사는 설명된 평가와 함께 측정 가능한 주장을 제시했습니다. 고객은 여전히 각자의 이력, 권한, 비즈니스 의사결정을 반영하는 결과가 필요합니다.

메모리 소유권에는 사용자 식별자 이상이 필요합니다

기억된 정보는 이를 만들어 낸 대화보다 오래 남을 수 있으므로, 지속적 맥락에는 명시적인 보안 및 삭제 규칙이 필요합니다.

Databricks의 메모리 및 세션 문서는 세션을 삭제해도 메모리는 삭제되지 않는다고 명시합니다. 또한 사용자 파티셔닝과 접근 제어를 구분합니다. 액터 식별자는 작업이 사용할 항목의 소유자를 선택하지만, 저장소 접근 권한이 있는 주체는 다른 액터에 속한 항목을 읽을 수 있습니다.

문서는 신뢰할 수 있는 애플리케이션 코드에서 검증된 ID를 바탕으로 해당 식별자를 도출할 것을 권장합니다. 엄격한 테넌트 격리를 위해서는 별도의 저장소를 권장합니다. 또한 베타 버전의 인터페이스와 동작은 변경될 수 있다고 경고합니다.

이는 이번 출시를 평가하는 구매자에게 중요한 구현 세부사항입니다. 정보를 사용자별로 표시하는 필드가 자동으로 보안 경계를 강제하는 것은 아닙니다. 애플리케이션은 ID, 권한, 저장 구조를 올바르게 연결해야 합니다.

예시적인 고객 지원 배포는 이러한 우려를 보여줍니다. 기억된 선호도는 고객 자신의 계정 안에서는 무해할 수 있지만, 다른 고객과의 대화에서는 부적절할 수 있습니다. 올바른 검색을 위해서는 모델이 메모리를 요청하기 전에 애플리케이션이 올바른 ID를 설정해야 합니다.

삭제는 다른 문제를 제기합니다. 사용자는 대화를 제거하면 어시스턴트가 그 대화에서 학습한 내용도 제거된다고 합리적으로 믿을 수 있습니다. 파생된 정보가 남아 있다면 제품은 그 차이를 명확히 설명해야 합니다.

이는 특정 배포 환경이 삭제를 잘못 처리한다는 증거가 아니라, 애플리케이션 설계에 관한 함의입니다. 문서화된 분리는 팀이 답해야 하는 질문으로 만듭니다. 완전한 삭제 정책은 원래 상호작용과 거기서 보존된 정보를 모두 다뤄야 합니다.

수정도 비슷한 주의가 필요합니다. 잘못된 메모리를 교체하면 향후 동작에 영향을 줘야 하지만, 팀은 그 수정이 남아 있는 이력과 어떻게 상호작용하는지도 이해해야 합니다. 그렇지 않으면 동일한 기저 증거가 다시 잘못된 해석을 뒷받침할 수 있습니다.

메모리는 결코 지속적인 권위를 얻어서는 안 되는 지침도 보존할 수 있습니다. 오해를 불러일으키는 운영 지침이 담긴 예시적 문서를 생각해 보십시오. 에이전트가 그 지침을 승인된 관행으로 요약하면, 그 오류는 원래의 문서 검토를 넘어 이후 작업에 영향을 줄 수 있습니다.

이 시나리오는 출처의 권위와 보존 동작을 평가해야 함을 보여줍니다. 이를 Databricks에서 발견된 취약점으로 제시해서는 안 됩니다. 핵심 질문은 애플리케이션이 사용자가 승인한 선호도와 업무 중 접한 신뢰할 수 없는 콘텐츠를 구분하는지입니다.

여기서는 백엔드만큼 제품 경험도 중요합니다. 사용자는 중요한 메모리를 점검하고, 수정하며, 제거를 요청할 수 있는 이해하기 쉬운 방법이 필요합니다. 통제 수단이 영향을 받는 사람들에게 접근 가능하지 않다면 기술적 기능의 실질적인 가치는 제한적입니다.

개발자에게 운영상 교훈은 분명합니다. 메모리는 정보가 답변에 도달하는 또 하나의 경로를 도입합니다. 따라서 디버깅에서는 에이전트가 무엇을 기억했는지, 왜 그 정보를 검색했는지, 애플리케이션이 그 사용을 승인했는지를 고려해야 합니다.

이러한 책임은 관리형 스토리지를 사용한다고 사라지지 않습니다. 이는 관리형 서비스가 애플리케이션의 신뢰 경계에 맞는지 판단하는 과정의 일부가 됩니다.

베타 발표 이후 주목할 점

다음 증거는 관리형 메모리를 반복 가능한 고객 성과 및 더 명확한 운영 한계와 연결해야 합니다.

첫 번째 신호는 반복적인 기업 업무에 대한 독립적 평가 또는 고객 공개 평가입니다. 유용한 결과는 수정, 변하는 사실, 관련 없는 요청을 포함하면서 동일한 애플리케이션을 메모리 사용 여부에 따라 비교할 것입니다. 그러한 증거는 보존된 맥락이 회사가 선택한 사례를 넘어 업무를 개선하는지 검증할 수 있습니다.

설득력 있는 평가는 성공과 함께 실패도 설명할 것입니다. 성능이 밀접하게 반복되는 질문에서만 개선된다면, 그 이점은 지속적인 비즈니스 이해보다 더 제한적입니다. 관련은 있지만 서로 다른 작업에서도 향상이 유지된다면 재사용 가능한 경험의 근거는 더욱 강해집니다.

두 번째 신호는 운영 제약과 사용자 제어를 둘러싼 제품 개발입니다. 구매자는 일정 관리, 규모, 격리, 점검, 삭제 동작에 관한 문서화된 변경 사항을 주시해야 합니다. 이러한 세부사항은 상당한 보조 인프라를 구축하지 않고도 어떤 애플리케이션이 서비스에 의존할 수 있는지를 결정합니다.

그러한 통제 수단의 진전은 구축 대 구매 논리를 강화할 것입니다. 일반적인 메모리 동작을 관리하기 위해 팀이 여전히 광범위한 맞춤형 장치를 필요로 한다면 운영상 이점은 덜 설득력 있게 됩니다. 관련 척도는 서비스가 실제로 얼마나 많은 책임을 덜어 주는가입니다.

세 번째 신호는 경쟁사들이 자체 메모리 관련 주장을 얼마나 쉽게 검증할 수 있게 만드는지입니다. Amazon의 기존 서비스는 이 범주에 이미 대안이 있음을 의미합니다. 더 명확한 비교 평가는 고객이 동작의 차이와 용어의 차이를 구분하는 데 도움이 될 것입니다.

경쟁사의 대응만으로 Databricks의 우위가 입증되지는 않습니다. 다만 관리형 메모리가 플랫폼 선택의 또 다른 차원이 되었음을 보여줄 것입니다. 애플리케이션이 서비스 전반에서 유용한 동작을 유지할 수 있다는 증거는 구매자가 기대할 수 있는 이식성의 수준도 분명히 할 것입니다.

이 신호들은 구매 대상이 지속적으로 운영되는 시스템이라는 점에서 함께 고려해야 합니다. 통제 없는 성능은 어려운 운영상 질문을 만듭니다. 유용한 업무 개선 없는 통제는 구매자가 가치가 불확실한 또 하나의 기능을 유지하게 만듭니다.

지식 노동자에게 결과는 일상적인 사용에서 드러나야 합니다. 상황이 변할 때는 여전히 반응하면서, 어시스턴트는 반복적인 수정이 덜 필요해야 합니다. 오래된 가정을 더 일관되게 기억하는 것은 핵심을 놓치는 일입니다.

개발자에게 이번 발표는 집중된 실험을 제시합니다. 식별 가능한 메모리 관련 실패가 있는 반복 워크플로를 선택한 뒤, 일관된 조건에서 결과를 비교하십시오. 실시간 증거와 기억된 지침을 분리하고, 과거 정보가 답변에 포함되지 않아야 하는 사례를 살펴보십시오.

Databricks의 Agent Memory 출시는 기업 팀이 기존 접근 방식과 비교해 평가할 수 있는 구체적인 서비스를 제공합니다. 에이전트가 반복적으로 잘못 처리하거나 불필요하게 되풀이하는 업무부터 시작하십시오. 어떤 수정이 지속될 가치가 있는지, 어떤 사실이 현재 출처에 계속 연결되어야 하는지 식별하십시오. 그런 다음 보존된 맥락이 오래된 가정을 이어받지 않으면서 이후 의사결정을 개선하는지 살펴보십시오. 누가 메모리를 점검할 수 있는지, 누가 이를 변경할 수 있는지, 애플리케이션 전반에서 제거가 무엇을 의미하는지 질문하십시오. 공개된 벤치마크는 자체 업무에 대해 검증할 만한 가설로 다루십시오. 도입을 확대하기 전에, 귀하의 팀은 에이전트가 올바른 교훈을 기억하고 그 교훈이 더 이상 적용되지 않을 때 사용을 중단한다는 점을 보여줄 수 있습니까?