대부분의 에이전트 메모리 (Agent memory) 예시들은 사실(facts)에서 시작합니다: 사용자의 선호도, 요약, 문서 청크 (document chunk), 대화에서 추출된 노트 같은 것들 말이죠. 이러한 정보들은 유용하지만, 에이전트가 나중에 추론하기 위해 실제로 필요로 하는 부분의 상당 부분을 놓치고 있습니다. 즉, 에이전트가 무엇을 할 계획이었는지, 무엇을 시도했는지, 무엇이 성공했고 무엇이 실패했는지에 대한 정보입니다.

Engrava는 **액션 레코드 (Action Records)**를 통해 이러한 문제를 해결합니다. 액션 (action)은 채팅 메시지가 아니며, 태스크 러너 (task runner)를 대체하는 것도 아닙니다. 그것은 에이전트가 운영상 의미가 있다고 판단한 상태 변화 (state change)에 대한 영구적인 메모리 기록입니다.

이러한 차이점은 에이전트가 세션 간에 컨텍스트 (context)를 복구해야 할 때까지는 추상적으로 남아 있습니다.

Engrava는 이를 나머지 메모리 그래프 (memory graph)와 동일하게 SQLite 기반의 임베디드 저장소 (embedded SQLite-backed store)에 보관하며, 이는 몇 가지 이유로 중요합니다. 운영 관련 질문을 던지기 위해 별도로 구축해야 하는 서비스가 없습니다. 즉, 생각 (thoughts), 엣지 (edges), 액션 레코드 (action records), 타임스탬프 (timestamps), 라이프사이클 상태 (lifecycle state), 그리고 선택적인 저널 엔트리 (journal entries)가 모두 하나의 로컬 데이터베이스에 존재합니다. 또한 액션 상태 (action state)는 동일한 쿼리 및 검색 모델 (query and retrieval model)에 참여합니다. 에이전트는 요청에 대한 생각을 기록하고, 이를 계획된 액션에 연결하며, 도구 호출 (tool call)이 완료되면 해당 액션을 업데이트할 수 있습니다. 그 후 나중에 MindQL과 Python API를 사용하여 최근 액션을 검사하거나, 상태별로 범위를 좁히거나, 주변 그래프를 다시 불러올 수 있습니다.

저널은 증거이지, 주문(spell)이 아닙니다

저널링 (journaling)이 활성화되면, Engrava는 생각 및 엣지 변이 (mutations)와 액션 상태 전이 (state transitions)를 해시로 연결된 저널 엔트리 (hash-linked journal entries)로 기록합니다. 이는 저널링된 이벤트들에 대해 변조 방지 (tamper-evident) 체인을 형성합니다. 이러한 표현은 의도적인 것입니다. 저널은 선택 사항입니다. 이는 데이터베이스 전체의 무결성 시스템 (integrity system)이 아니며, 외부 부작용 (side effects)을 되돌릴 수 있게 만들지도 않고, 권한을 가진 작성자가 데이터베이스와 저널을 함께 교체하는 것을 막지도 못합니다. 저널이 제공하는 것은 해당 저널이 활성화되었을 때 저널링된 체인의 연속성을 검증할 수 있는 방법입니다. 이는 액션 상태가 일반적인 노트와는 다른 신뢰 프로필 (trust profile)을 갖기 때문에 중요합니다. 만약 에이전트가 나중에 '확인됨 (confirmed)'으로 표시된 액션을 보게 된다면, 애플리케이션은 해당 확인이 예상된 로컬 이력의 일부인지 알고 싶어 할 수 있습니다.

단순한 작업 로그가 아닌

작업 로그 (task log)는 "무슨 일이 일어났는가?"에 답합니다. 에이전트 메모리는 더 넓은 질문에 답해야 합니다. 단순히 어떤 액션이 일어났는지뿐만 아니라, 에이전트가 그 액션을 선택했을 때 무엇을 믿고 있었는지, 어떤 이전 사실들이 그 결과로 이어졌는지, 알려진 상태 시퀀스 (state sequence)를 거쳐 이동했는지, 그리고 실패가 다음번의 검색이나 계획 방식을 변경해야 하는지 등을 포함합니다. 액션 레코드 (Action Records)는 주변 그래프 옆에 존재하는 것이 아니라, 그래프와 '함께' 존재하도록 설계되었습니다. 따라서 실행 메모리 (execution memory)가 비구조화된 산문 (unstructured prose)으로 붕괴되지 않고 의미론적 메모리 (semantic memory)와 가까운 곳에 머물 수 있습니다.

구체적인 예시

에이전트가 설정 변경 (config change)을 실행한다고 가정해 봅시다. 에이전트는 해당 요청에 대한 생각 (thought)을 저장하고, 그 생각과 연결된 PLANNED 액션을 기록하며, 배포 도구 (deploy tool)를 호출할 때 액션을 EXECUTING 상태로 전환합니다. 마이그레이션 단계가 실패하면, 해당 액션은 요약문 속에 파묻힌 한 줄의 문장이 아니라, 리소스 및 관련 생각들과 연결되어 쿼리 가능한 레코드 (queryable record)로서 FAILED 상태에 도달하게 됩니다.

두 세션이 지난 후 에이전트가 해당 작업을 다시 집어듭니다. 실패 사실이 언급되어 있기를 바라며 방대한 양의 노트를 다시 읽는 대신, 에이전트는 저장소 (store)에 직접 질문합니다. 해당 리소스에 대한 마지막 FAILED 액션은 무엇인지, 그리고 그것과 연결된 생각들은 무엇인지 말입니다. 에이전트는 실패한 마이그레이션과 그에 연결된 추론 (reasoning)을 검색하며, 이를 맹목적으로 반복하지 않기로 선택할 수 있습니다.

일반적인 텍스트 로그 (plain text log)에는 "배포 실패"라고 기록될 수 있습니다. 하지만 텍스트 로그는 에이전트가 해당 질문을 정밀하게 던지게 하거나, 답변을 그 결과로 이어진 결정과 연결하거나, 실패한 액션을 단순히 읽은 사실 (fact)과는 다르게 취급하도록 할 수는 없습니다. 이것이 바로 액션을 산문 (prose) 속에 남겨두는 대신, 일급 시민 레코드 (first-class record)로 부여하는 이유입니다.

위치

액션 레코드 (Action Records)는 구성 가능한 저장소 (compositional store)의 한 구성 요소입니다. 관계를 위한 그래프 메모리 (graph memory), 회상을 위한 하이브리드 검색 (hybrid search), 구조화된 읽기를 위한 MindQL, 그리고 선택 사항인 변조 방지 저널 (tamper-evident journal)이 그것입니다. 이 중 그 어떤 것도 메모리가 에이전트를 대신해 "생각"한다고 주장하지 않습니다. 정책 (policy), 승인 (approvals), 그리고 부수 효과 (side effects)는 여전히 애플리케이션의 소유입니다. Engrava는 단지 단순한 사실 그 이상을 기억할 수 있는, 로컬의 쿼리 가능한 기질 (substrate)을 제공할 뿐입니다.