Skip to main content
anthropicclaudeai-automation

Claude тепер вміє забирати пам'ять з інших ШІ

Anthropic додав у Claude імпорт пам’яті з інших ШІ-інструментів. Для бізнесу це важливо з однієї причини: знижується вартість переходу між моделями та зникає частина ручної роботи при перенесенні довготривалих робочих контекстів та агентних сценаріїв, що забезпечує безперервність робочих процесів.

Що Anthropic насправді викотила

Я заглибився в опис фічі, бо заголовок звучить гучно, а диявол тут якраз у деталях. На початку березня 2026 року Anthropic відкрила в Claude функцію Memory Import, і це не просто “встав чат повністю”. Claude приймає експорт з іншого AI-сервісу, переробляє його і перетворює на власні об'єкти пам'яті.

Тобто це не буквальне перенесення один в один. Я б назвав це інтерпретованою міграцією: ви даєте матеріал, а Claude витягує з нього стійкі факти, вподобання, робочі звички, деталі проєктів і зберігає це як свої memory edits.

Імпорт запускається вручну через Settings → Capabilities → Memory. Anthropic дає спеціальний промпт для запиту експорту в іншого провайдера, або можна принести Markdown руками. Після вставки Claude показує зміни, їх можна перевірити через Manage edits, а сама пам'ять може оновитися не миттєво, а протягом 24 годин.

Тут я одразу зробив уявну позначку: це зручно, але не детерміновано. У документації прямо сказано, що функція експериментальна, не кожен запис буде перенесено, і Claude краще тримається за робочий контекст, ніж за особисті нотатки “про всяк випадок”.

Чому це чіпляє саме в dev та агентних сценаріях

Мене в цій новині зачепила не сама “пам'ять”, а зниження тертя при зміні інструменту. Якщо в команди накопичився шар звичок, naming conventions, деталі архітектури, застереження щодо стеку, вимоги до стилю коду та обмеження проєкту, раніше все це доводилося заново вбивати в нову модель. Це нудний і дорогий податок на перемикання.

З Memory Import цей податок став меншим. Не нуль, але менше. Для developer workflow, де люди стрибають між Claude, ChatGPT, Gemini, локальними тулзами та кодовими агентами, continuity раптом стає не маркетинговим словом, а цілком прикладною штукою.

Особливо на тлі того, що частина розробників останніми тижнями активно порівнює Claude Code, Opus та Codex. Я бачу обговорення в один і той же бік: якщо якість основної моделі просідає, люди не хочуть ще й заново пояснювати проєкт новому інструменту. І ось тут імпорт пам'яті різко зменшує біль від міграції.

Де реальна користь, а де маркетинговий блиск

Якщо дивитися тверезо, це не “єдина пам'ять між усіма AI”. Це місток. Нерівний, місцями ручний, але вже корисний. Claude не обіцяє зберегти все, і це нормально: пам'ять у моделей взагалі погано переноситься як строга база даних.

Але для команд, де є довгоживучі асистенти, внутрішня документація, пресейл-боти, інженерні copilot-сценарії та ШІ автоматизація навколо розробки, навіть такий місток економить години. Не тому, що модель стала розумнішою, а тому, що люди менше повторюються.

Я б особливо дивився сюди тим, хто будує ШІ рішення для бізнесу не у форматі “один чат для натхнення”, а як систему: агент, CRM, knowledge base, таск-трекер, кодовий контур. У такій архітектурі ШІ-рішень контекст коштує грошей. Якщо його можна переносити між шарами екосистеми, впровадження стає помітно практичнішим.

Програють тут, по суті, лише вендори, які тримали користувачів на lock-in через накопичену історію. Коли пам'ять можна хоча б частково забрати з собою, вибір моделі починає сильніше залежати від реальної якості та ціни, а не від страху втратити напрацьований контекст.

Що б я робив на місці команди прямо зараз

Я б не сприймав Memory Import як привід бездумно мігрувати все підряд. Я б зробив короткий тест на одному живому процесі: наприклад, перенесення пам'яті для coding-асистента, support-агента або внутрішнього аналітичного бота. Одразу стане видно, що доїжджає добре, а що краще зберігати поза пам'яттю моделі, у нормальному knowledge layer.

Це, до речі, головний інженерний висновок. Пам'ять моделі зручна, але не повинна бути єдиним джерелом істини. Ми в Nahornyi AI Lab зазвичай розводимо це на два шари: оперативна пам'ять агента та зовнішня база контексту. Тоді і впровадження ШІ виходить стійкішим, і зміна моделі вже не виглядає як міні-катастрофа.

Я - Вадим Нагорний, і в Nahornyi AI Lab я руками збираю такі штуки: AI-агентів, n8n-сценарії, контурну ШІ інтеграцію та робочі пайплайни, де контекст не розсипається після першої зміни моделі.

Якщо хочете обговорити ваш кейс, замовити ШІ автоматизацію, створити ШІ агента або зібрати n8n-автоматизацію під ваш процес - пишіть. Я подивлюся, як це краще розкласти по пам'яті, даних та інструментах без зайвої магії.

Поділитися статтею