가져갈 수 없는 세션

보낸 사람: Earendil Engineering <rfc@earendil.com>

받는 사람: 여러분

추론 API가 처음 내세운 약속은 놀라울 만큼 단순했습니다. 입력을 보내면 출력이 돌아옵니다. 둘 다 보관하면 대화가 남습니다. 내용을 살펴보고, 보관하고, 재현하거나 다른 모델에 넘길 수도 있었습니다.

물론 이 추상화가 완전히 사실이었던 적은 없습니다. 예를 들어 프롬프트 캐시는 다른 누군가의 GPU에 존재하고, 모델마다 토큰화 방식이 다르며, 샘플링은 재현할 수 없습니다. 이는 상당 부분 의도된 특성이기도 합니다. 그래도 대화 기록 형태로 남은 세션의 의미적 기록은 사용자가 소유할 수 있었습니다. 대화 기록에는 지시 사항, 메시지, 도구 호출과 도구 실행 결과가 담겨야 합니다. 충분한 능력을 갖춘 다른 모델이 완전히 똑같이 이어가지는 못하더라도, 무슨 일이 있었는지 이해하고 작업을 넘겨받을 수는 있어야 합니다.

하지만 추론 API는 답답하게도 이 특성에서 조금씩 멀어지고 있습니다. 이제는 텍스트와 특정 제공자에게 종속된 상태를 섞어 반환하는 경우가 늘고 있으며, 그 상태는 의도적으로 다른 곳에 옮길 수 없게 만들어져 있습니다.

• 사용자에게 비용을 청구하면서도 불투명한 암호화 블롭으로만 반환하고, 기껏해야 쓸모없는 요약만 제공하는 추론 토큰

• 모델은 원문 자료를 보지만 클라이언트는 그 자료를 전혀 볼 수 없는 웹 검색

• 원래 제공자만 복호화할 수 있는 압축된 컨텍스트

• 에이전트를 실행하는 애플리케이션에는 암호화된 페이로드로 감춰지는 하위 에이전트의 지시 사항과 메시지

• 다른 곳에서는 해석할 수 없는 파일, 벡터 저장소, 컨테이너, 캐시 참조

• 제공자의 서버에만 완전히 저장된 ID를 키로 삼는 응답 및 대화 상태

각 기능에는 제공자가 손쉽게 제시할 수 있는 기본적인 명분이 있고, 사용자에게 이롭다는 타당한 주장도 있습니다. 하지만 이 기능들이 합쳐지면 AI 세션의 실질적인 소유권이 달라집니다. 내 컴퓨터에 있는 대화 기록은 더 이상 내 세션 자체가 아닙니다. 작동에 필요한 상태를 내가 아닌 추론 제공자가 소유한 세션의 일부만 보여주는 기록이 됩니다.

우리는 이런 방향을 달가워하지 않습니다. 이것이 사용자에게 무엇을 의미하는지, 그리고 이 분야의 도구를 개발하는 우리에게 무엇을 의미하는지 이야기해 보려 합니다.

세션 소유권을 판단하는 실용적인 기준

세션을 옮길 수 있어야 한다고 해서 모델을 바꿔도 다음 토큰이 똑같아야 한다는 뜻은 아닙니다. 모델마다 능력, 학습된 성격, 컨텍스트 창, 도구를 다루는 방식이 다르므로 이는 당연합니다. 게다가 어차피 모든 과정에는 상당한 비결정성이 있습니다. 여기서 이동 가능성이 뜻하는 바는 좀 더 소박합니다.

const transcript = session.export();
revokeCredentials(oldProvider);
session = newProvider.continueFrom(transcript);

보관 기록에는 다른 모델이 작업을 이어갈 수 있을 만큼 이해 가능한 정보가 들어 있어야 합니다. 이전 제공자가 ID를 역참조하거나 블롭을 복호화하고, 검색 결과를 기억하거나 요약을 재구성해야만 쓸 수 있어서는 안 됩니다.

이를 바탕으로 다섯 가지 유용한 기준을 세울 수 있습니다.

1. 검사: 모델이 무엇을 봤고 도구가 무엇을 했으며 에이전트끼리 어떤 이야기를 주고받았는지 사용자가 확인할 수 있는가?

2. 내보내기: 별도로 다운로드할 수 있는 일반적인 산출물을 제외하면 세션 자체만으로 완결되는가?

3. 재현: 다른 구현체가 의미상 동등한 컨텍스트를 재구성할 수 있는가?

4. 감사: 시스템이 왜 어떤 행동을 했는지 나중에 사람이 설명할 수 있는가?

5. 삭제: 세션이 의존하는 서버 측 사본을 사용자가 모두 찾아 삭제할 수 있는가?

응답 ID는 대화 기록이 아닙니다. 데이터가 서버에 저장되어 있기 때문입니다. 암호문도 사용자가 통제하는 상태가 아닙니다. 사용자가 복호화할 수 없기 때문입니다. 인용 목록 역시 검색 결과를 통해 모델의 컨텍스트에 들어간 근거 자료가 아닙니다. 일반적으로 모델이 봤던 것과 똑같은 데이터를 다시 가져올 수 없기 때문입니다.

누구를 위한 암호화인가?

이 기능에 붙은 이름과 마케팅 문구는 오해를 부를 수 있습니다. encrypted_content라는 이름은 사용자가 통제하는 개인정보 보호 기능처럼 들립니다. 하지만 보통은 클라이언트가 읽을 수 없고 제공자만 열 수 있는 캡슐입니다. 키는 제공자가 선택하고, 자사 모델을 위해 콘텐츠를 복호화하며, 데이터를 어디에서 재사용할 수 있는지도 제공자가 정합니다.

더 정확한 표현은 **제공자가 봉인한 상태(provider-sealed state)**입니다.

제공자 봉인은 실제로 개인정보 보호에 도움이 될 수 있습니다. 예를 들어 OpenAI는 store: false를 사용할 때 암호화된 추론을 클라이언트에 반환한 다음, 중간 상태를 저장하지 않고 다음 요청에서 메모리상으로 복호화할 수 있습니다. 특히 Zero Data Retention 고객에게는 대화를 서버에 저장하도록 요구하는 것보다 낫습니다. 하지만 애초에 암호화해야만 하는 필연적인 이유가 없다는 점을 기억해야 합니다.

이 암호화는 추론 제공자에게서 데이터를 감추지 않습니다. 사용자에게서 감출 뿐입니다.

저장된 대화는 대화 기록을 포인터로 바꾼다

OpenAI의 Responses API는 기본적으로 응답을 저장합니다. 문서에 따르면 응답 객체는 기본 설정에서 최소 30일 동안 보관됩니다. store: false 옵션을 사용할 수 있으며, 이를 사용해야 합니다. 그러면 completions와 비슷하게 작동해 데이터가 OpenAI 서버에 저장되지 않습니다.

새로운 Gemini Interactions API도 비슷한 선택을 했습니다. 기본값은 store: true입니다. 유료 등급에서는 상호작용을 55일, 무료 등급에서는 하루 동안 보관합니다.

물론 상태를 서버에 저장한다는 발상은 상당히 매력적입니다.

const first = responses.create({
  model: "frontier-model",
  input: "Investigate this production failure",
  store: true,
});

const second = responses.create({
  model: "frontier-model",
  previousResponseId: first.id,
  input: "Now implement the fix",
  store: true,
});

애플리케이션이 전송하는 데이터가 줄어들고, 제공자는 숨겨진 추론과 도구 상태를 보존할 수 있으며, 캐시 라우팅도 쉬워집니다. 하지만 로컬 애플리케이션이 사용자 메시지와 최종 텍스트만 기록한다면 first.id는 이제 애플리케이션이 통제하지 못하는 데이터베이스를 가리키는 외래 키가 됩니다.

추론 내용은 보여드릴 수 없습니다

주요 AI 연구소들은 모두 원시 사고 과정을 공개하지 않는 데 정당한 이유가 있다고 주장합니다. 그 결과 가중치가 공개되지 않은 모델에서는 일반적으로 이 토큰을 볼 수 없습니다.

API에서는 원시 추론을 확인할 수 없습니다. 응답을 저장하면 이전 추론을 previous_response_id로 복구할 수 있습니다. store: false를 사용하면 API가 encrypted_content를 반환하며, 클라이언트는 이를 보존했다가 다시 전달해야 합니다. reasoning.context: "all_turns"를 통해 이후 샘플이 저장된 추론을 사용하도록 해도 그 내용은 여전히 불투명합니다.

Anthropic은 암호화된 전체 사고 내용을 signature 필드에 반환합니다. 읽을 수 있는 사고 텍스트를 활성화하더라도 이는 원시 사고 과정이 아니라 다른 모델이 생성한 요약입니다. 도구를 사용하는 턴에서는 사고 블록을 변경하지 않고 그대로 돌려보내야 합니다. Anthropic 문서에는 사고 블록이 이를 생성한 모델에 종속되므로 모델을 바꿀 때 제거해야 한다고도 적혀 있습니다. 따라서 이 추론 기록은 Anthropic 내부에서조차 이동 가능성을 목표로 하지 않습니다.

가중치가 공개되지 않은 모든 모델에서 같은 이야기가 반복됩니다.

이런 암호화 방식은 한 생태계 안에서 연속성을 제공하지만, 다른 제공자의 모델로 가져갈 수 있는 대화 기록을 만들어 주지는 않습니다. 세션 보관 기록에 블롭을 넣을 수는 있어도 다른 모델은 그 의미를 사용할 수 없습니다.

{"type": "reasoning", "encrypted_content": "gAAAAAB..."}
{"type": "thinking", "thinking": "", "signature": "EqQBCg..."}
{"type": "thought", "summary": [], "signature": "EpoGCp..."}

감춰진 검색

서버 측 웹 검색은 사용자에게 보이지 않는 구멍이 대화 기록에 생기는 가장 분명한 사례 중 하나입니다. 클라이언트 측 검색 도구는 다른 도구처럼 작동합니다.

const result = search(query);
record({
  query,
  retrievedAt: now(),
  results: result.map((item) => ({
    url: item.url,
    title: item.title,
    passages: item.passages,
  })),
});
model.send({ toolResult: result });

사용자는 검색 순위와 발췌문을 살펴보고, 페이지를 다시 가져오고, 사본을 캐시하거나, 같은 근거를 다른 모델에 제공할 수 있습니다.

호스팅 검색에서는 제공자가 비공개 도구 루프를 실행합니다. OpenAI, Google, Anthropic은 검색 작업과 인용, 경우에 따라 출처 URL 목록을 공개하지만, 답변을 만드는 데 사용한 전체 텍스트 컨텍스트는 제공하지 않습니다. URL만으로는 안정적으로 재현할 수 없습니다. 페이지 내용이 바뀔 수도 있고, 모델이 보기 전에 훨씬 짧은 발췌문으로 축약됐을 수도 있기 때문입니다.

최종 답변 자체는 훌륭할 수 있습니다. 문제는 다음 턴에서 드러납니다.

세 번째 출처를 첫 번째 출처와 비교하고, 논란이 된 수치를 다시 확인한 다음, 다른 모델로 이 조사를 계속해 주세요.

새 모델이 받는 것은 답변과 URL 몇 개뿐입니다. 첫 번째 모델이 사용한 검색 결과 순위, 추출된 발췌문, 필터링으로 제외된 자료, 정확한 근거는 받지 못합니다. 다음 요청을 다른 곳으로 보내더라도 이전 제공자는 여전히 그 세션의 일부입니다. 인용을 확보해 페이지를 다시 가져오더라도 정확히 같은 데이터를 재현할 수 없습니다.

호스팅 검색은 검색어, 결과 메타데이터, 가져온 발췌문, 타임스탬프, 보존된 콘텐츠를 포함하는 완전한 내보내기 모드를 제공해야 합니다. 간결한 인용은 사용자 인터페이스로 남겨도 되지만, 유일한 기록이어서는 안 됩니다.

불투명한 컨텍스트 압축

긴 에이전트 세션은 언젠가 컨텍스트를 압축해야 합니다. 클라이언트가 통제하며 내용을 볼 수 있는 요약도 정보를 잃지만, 적어도 살펴보고 다른 곳으로 옮길 수는 있습니다. 사용자가 검토하거나 편집할 수 있고, 다른 모델에 새 요약을 만들어 달라고 요청할 수도 있습니다.

반면 OpenAI의 서버 측 압축은 암호화된 압축 항목을 내보냅니다. 문서에서는 이를 “불투명하며 사람이 해석하도록 만들어진 것이 아니다”라고 설명합니다. 독립형 /responses/compact 엔드포인트는 “표준 다음 컨텍스트 창”을 반환하며, 클라이언트에는 이를 그대로 전달하라고 안내합니다.

개념적으로는 다음과 같이 전환됩니다.

// Before: expensive but portable
let history = [
  userMessage,
  assistantMessage,
  toolCall,
  fullToolResult,
  //... 200,000 more tokens of intelligible history
];

// After: cheap to continue only with the original provider
history = [
  {
    type: "compaction",
    encryptedContent: "enc_provider_only_state...",
  },
...recentItems,
];

OpenAI는 압축된 의미를 바탕으로 대화를 이어갈 수 있지만, 다른 제공자는 읽을 수 없는 문자열과 최근 대화 일부만 보게 됩니다. 사실 우리는 이런 정보를 다른 제공자에게 넘기지 않으므로 실제로는 그것조차 보지 못합니다.

이 방식이 기술적으로 꼭 필요한 것은 아닙니다. Anthropic의 서버 측 압축은 읽을 수 있는 content 필드가 포함된 compaction 블록을 반환합니다. 클라이언트가 직접 요약 지시 사항을 제공할 수 있고, 만들어진 요약은 살펴본 뒤 다른 모델에 전달할 수도 있습니다. 어느 제공자를 사용하든 클라이언트 측에서 압축하는 방법도 가능합니다.

OpenAI의 봉인된 산출물은 평문 요약보다 모델에 특화된 상태를 더 많이 보존해 원래 모델에서 더 나은 성능을 낼 수 있습니다. 선택형 최적화 기능으로서는 합리적입니다. 하지만 읽을 수 있는 인계용 요약을 대체할 것이 아니라 함께 제공해야 합니다. 물론 이 기능들 상당수에는 사용자를 한 생태계에 더 단단히 묶어 두는 부수 효과도 있습니다.

하위 에이전트에는 감춰진 지시 사항이 따라온다

멀티 에이전트 시스템에서는 대화 기록이 하나가 아니므로 문제가 더 커집니다. 세션이 트리 구조로 갈라지고 에이전트 사이에는 메시지가 오갑니다. 보통 사람이 작성한 것과 같은 프롬프트지만, 이제는 기계가 다른 기계를 위해 작성합니다.

OpenAI가 호스팅하는 Responses Multi-agent 베타는 multi_agent_call, multi_agent_call_output, agent_message라는 세 가지 새 항목 유형을 반환합니다. spawn_agent 예시의 message 인수는 암호화되어 있고 에이전트 사이의 메시지에는 encrypted_content만 들어 있습니다. Multi-agent를 활성화하면 클라이언트가 요청하지 않았더라도 모든 에이전트에 서버 측 자동 압축이 암묵적으로 적용됩니다. 추론 요약은 지원하지 않으며, API가 루트 에이전트와 하위 에이전트에 개발자가 수정하거나 제거할 수 없는 지시 사항도 주입합니다.

이 모든 것이 옮길 수 없는 상태 묶음을 만듭니다. 봉인된 작업 위임, 봉인된 에이전트 메시지, 에이전트마다 별도로 자동 압축된 컨텍스트, 숨겨진 추론, 제공자가 호스팅하는 오케스트레이션이 한데 엮입니다.

이와 관련된 변경 사항이 2026년 6월 오픈소스 Codex 클라이언트에도 반영됐습니다. “멀티 에이전트 v2 메시지 페이로드 암호화”라는 커밋은 처리 과정을 직접 설명합니다.

// Parent model's tool call, as persisted by Codex
{
  "name": "spawn_agent",
  "arguments": {
    "task_name": "worker",
    "message": "<ciphertext>"
  }
}

// Child model's input
{
  "type": "agent_message",
  "author": "/root",
  "recipient": "/root/worker",
  "content": [{
    "type": "encrypted_content",
    "encrypted_content": "<ciphertext>"
  }]
}

Responses API가 상위 에이전트가 내보낸 도구 인수를 암호화하고, Codex가 이를 전달하면, API가 내부에서 하위 에이전트를 위해 복호화합니다. Codex 자체의 InterAgentCommunication.content는 비어 있습니다. 읽을 수 있는 실행 기록과 이력 어디에도 정확한 작업 내용이 남지 않습니다.

이는 단순히 모델을 바꿀 때만 생기는 추상적인 문제가 아닐 것입니다. 하위 에이전트가 잘못된 파일을 수정하거나, 비밀 정보를 유출하거나, 다른 에이전트의 작업을 중복 수행하거나, 잘못된 가정을 따랐다고 생각해 봅시다. 사용자는 *그 에이전트가 무슨 일을 하라고 지시받았는가?*라는 간단한 질문에 답할 수 없습니다.

아직 해결되지 않은 Codex 이슈에서는 암호화된 전달 내용과 별도로 읽을 수 있는 감사용 사본을 남겨 달라고 요구합니다. 이는 최소한의 허용 기준입니다. 더 나은 방법은 에이전트 간 평문 메시지를 계속 기본값으로 두는 것입니다.

“대부분은 세션 도중 모델을 바꾸지 않는다”

아마 그렇겠죠. 대부분의 사람은 운영체제나 이동통신사를 매주 바꾸지도 않습니다. 하지만 그 자유를 실제로 행사하지 않더라도, 사용자가 제공자와 맺는 관계와 제공자가 사용자를 대하는 방식을 바꾸므로 그 선택권은 중요합니다.

모델이 폐기되거나, 서비스가 중단되거나, 가격이 바뀌거나, 정책이 다음 요청을 차단하거나(안녕, fable), 기밀 작업 단계를 로컬에서 실행해야 하거나, 감사 담당자가 무슨 일이 있었는지 재구성해야 할 때도 세션을 옮겨야 할 수 있습니다. 에이전트 때문에 세션도 훨씬 길어지고 있습니다. 코딩이나 조사 세션에는 며칠에 걸친 결정과 근거가 쌓일 수 있고, 개인 비서에는 수년 전까지 거슬러 올라가는 세션 기록이 축적될 수도 있습니다. 아직 실제로 그렇게 오래 보관한 기록은 없겠지만요.

떠날 수 있다는 선택권은 제공자에게도 규율을 부여합니다. 사용자가 다른 곳에서 작업을 계속할 수 있다는 사실을 제공자가 안다면 모델 품질, 가격, 안정성, 신뢰를 놓고 경쟁해야 합니다. 사용자가 축적한 컨텍스트를 단 하나의 제공자만 해석할 수 있다면 매우 부정적인 유인이 생깁니다.

이동 가능한 추론 API가 보장해야 할 것

우리는 추론 제공자와 에이전트 개발자가 몇 가지 규칙을 받아들이기를 바랍니다.

1. 로컬 이벤트 로그가 정본이어야 합니다. 서버 저장소가 이를 복제하거나 처리 속도를 높일 수는 있지만, 클라이언트는 서버 ID를 역참조하지 않고도 세션을 재구성할 수 있어야 합니다.

2. 저장 여부를 명시해야 합니다. store: false는 사용하기 쉽고 문서로 설명되어야 하며, 가능하면 기본값이어야 합니다. 보관이 필요한 기능은 사용하는 시점에 그 사실을 밝혀야 합니다.

3. 불투명한 항목이 의미를 전달하는 유일한 수단이어서는 안 됩니다. 같은 제공자 안에서 품질을 높이기 위해 암호화된 추론, 압축 정보, 도구 서명을 포함할 수는 있지만, 각각 읽을 수 있고 특정 제공자에 종속되지 않는 인계용 표현도 제공해야 합니다.

4. 호스팅 도구는 내용을 빠짐없이 기록해야 합니다. 다듬어진 답변과 인용만이 아니라 정확한 입력, 출력, 근거, 필터링 과정, 출처, 타임스탬프, 콘텐츠 해시를 기록해야 합니다.

5. 하위 에이전트의 통신을 감사할 수 있어야 합니다. 모든 에이전트의 정확하고 읽을 수 있는 작업 내용, 메시지, 결과, 계보, 모델, 도구 권한을 보존해야 합니다.

6. 압축 내용을 검사할 수 있어야 합니다. 읽을 수 있는 요약과 이를 만드는 데 사용한 지시 사항, 무엇이 버려졌는지 이해하는 데 충분한 계보 정보를 반환해야 합니다.

7. 산출물을 내보낼 수 있어야 합니다. 파일, 컨테이너 출력, 검색 스냅샷, 생성 미디어를 콘텐츠 주소 방식의 로컬 보관소에 다운로드할 수 있어야 합니다.

사실 증류는 훌륭하다

모델 계층에도 이와 관련된 종속 문제가 있습니다.

미국의 대형 비공개 가중치 연구소 중 일부는 외부 증류에 갈수록 적대적인 태도를 보입니다. DeepSeek, Moonshot, MiniMax가 벌였다고 주장하는 활동을 다룬 Anthropic의 2026년 2월 게시물은 이를 “증류 공격”이라고 부릅니다. Anthropic의 상업 약관은 고객이 출력물을 소유한다고 명시하면서도, 서비스를 이용해 경쟁 AI 모델을 학습하는 것은 금지합니다. 그러면서 같은 게시물에서는 최첨단 AI 연구소가 자체 모델에 적용할 때 “증류는 널리 쓰이는 정당한 학습 방법”이라고 인정합니다.

Anthropic은 모델 개발용 데이터를 수집하려고 로봇으로 공개 웹을 크롤링하며, 책을 스캔하기 위해 잘라낸 일로도 유명합니다. OpenAI 역시 자유롭게 접근할 수 있는 공개 인터넷 콘텐츠로 모델을 학습한다고 밝히며, 인터넷에 공개된 자료를 학습에 사용하는 것은 공정 이용이라고 주장해 왔습니다. 두 회사 모두 자사 내부에서 증류할 때는 이를 더 작은 모델을 만드는 일반적인 방법이라고 설명합니다. OpenAI는 더 강력한 OpenAI 모델의 출력을 이용해 더 작은 OpenAI 모델을 파인튜닝하는 명시적인 자사 API 증류 워크플로도 제공한 적이 있습니다.

도덕적 비대칭은 여전히 뚜렷합니다. 이 연구소들은 인간이 인터넷에 올린 방대한 저작물에서 기계가 학습해도 된다는 주장을 사회가 받아들이길 요구합니다. 대개 각 개인에게 미리 허락을 구하지도 않습니다. 그러면서 다른 기계가 연구소에서 생성한 출력으로 학습해서는 안 된다고 주장합니다. 이 원칙을 가장 넓게 적용하면 학습 결과가 비공개 모델 안으로 들어가는 것은 허용하면서 밖으로 나오는 것은 막을 수 있어, 연구소에 절묘하게 유리합니다.

우리는 증류에 대한 기본 태도가 적대에서 지원으로 바뀌어야 한다고 생각합니다. 증류를 이용하면 값비싼 최첨단 모델의 능력을 더 작고 저렴하며 빠른 모델로 옮길 수 있습니다. 이런 모델은 로컬이나 오프라인, 제약이 있는 하드웨어 또는 사용자가 통제하는 환경에서 실행할 수 있습니다. 증류는 경쟁을 확대하고, API가 사라져도 능력을 보존하며, 흔한 작업에 필요한 연산량과 에너지를 줄일 수 있습니다.

최소한의 자유

사용자는 계정을 폐쇄하고도 세션을 보관해 다른 모델에 넘길 수 있어야 합니다. 새 모델이 기존 모델과 다른 의견을 내거나, 질문하거나, 성능이 떨어질 수는 있습니다. 하지만 이전 모델이 사용자의 이력, 근거, 계획, 위임한 작업을 봤던 자리에 암호문만 놓여 있어서는 안 됩니다.

우리는 제공자가 더 나은 상태 저장형 API를 만드는 데 반대하지 않습니다. 더 나은 성능을 사용자의 통제력 약화와 결합하는 데 반대합니다. 상태 저장은 선택 사항이어야 하고, 호스팅 도구의 작업 내용을 관찰할 수 있어야 하며, 압축 결과는 읽을 수 있어야 하고, 에이전트 통신은 감사할 수 있어야 합니다. 가능하다면 불투명한 추론도 공개해야 하며, 적어도 다른 모델에 넘길 수 있는 표현을 함께 제공해야 합니다. 증류는 능력을 더 널리 사용할 수 있게 만드는 길이어야지, 갈수록 높은 장벽을 정당화하는 금기가 되어서는 안 됩니다.

^{source https://earendil.com/posts/session-portability/}

HN에서는 AI 세션 이동성을 단순한 모델 교체 기능보다 작업 기록의 소유권과 검증 가능성 문제로 봤다. 비용을 낸 추론 과정, 검색 자료, 압축된 문맥, 하위 에이전트 지시가 제공사만 해석할 수 있는 상태로 남으면 다른 서비스로 옮기기 어렵다. 에이전트가 잘못된 판단을 내렸을 때 원인을 추적하기도 힘들다. 웹 검색이나 코드 실행 같은 내장 기능의 편의성이 커질수록 서비스 종속도 깊어진다는 우려가 컸다.

모든 내부 기록을 그대로 보존해야 한다는 데에는 이견이 있었다. 긴 대화에는 불필요한 내용이 쌓이고, 문맥 압축을 거치며 품질도 이미 낮아진다는 경험이 나왔다. 저장소에 작업 배경과 완료 사항, 남은 과제를 별도 문서로 남기면 다른 모델도 큰 손실 없이 이어받을 수 있다는 사례도 있었다. 모델별 장점이나 사용 한도, 비용에 따라 자주 교체하는 이용자일수록 이런 외부 기록을 중시했다.

실무적 대안은 세션 전체를 복제하는 것보다 핵심 상태를 제공사 밖으로 빼내는 데 가까웠다. 도구 호출과 하위 에이전트 실행을 외부 인터페이스로 분리하고, 설계 결정과 실행 결과를 파일이나 별도 데이터베이스에 기록하는 방식이다. 다만 제공사마다 다른 기능까지 공통 API 하나로 감추려 하면 추상화가 깨질 수 있다. 서로 다른 API 설계와 사용자가 볼 수 없는 상태는 구분해서 다뤄야 한다.

작업의 전제와 결정, 도구 실행 결과, 다음 과제를 사람이 읽고 회수할 수 있어야 한다. 감사와 장애 분석이 중요한 업무라면 세션 내보내기 범위와 약관부터 확인해야 한다. 내장 기능을 쓰더라도 핵심 작업 상태는 별도로 남겨야 서비스 교체권을 실질적으로 지킬 수 있다.