Побудова PM-агента з Claude API і постійною памʼяттю

Травень 2026 · 11 хв читання · Фран Олівареш, засновник OlivaresAI

Агент управління проєктами, побудований на Claude API і постійній памʼяті Alma, відстежує стейкхолдерів, рішення, SLA і нотатки стендапів між днями і тижнями без втрати контексту. Архітектура має чотири частини: цикл розмови Claude, сховище памʼяті, ключоване за сутністю проєкту, екстрактор, що витягує структуровані записи з кожного чату, і ассемблер контексту, що впорскує правильний шматок у кожен промпт. Постійна памʼять — це те, що перетворює Claude з розумного інструменту для чернеток на агента, який памʼятає, що команда вирішила минулого вівторка.

Управління проєктами — це переважно робота з памʼяттю. Хто володіє цим потоком? Що ми домовилися щодо вікна міграції? Чому ми зменшили обсяг рейт-лімітера? Коли юридичний огляд блокує реліз? Агент, що має знову питати ці запитання кожного ранку, — це не агент, це трохи швидший стажер. Ви це змінюєте, надаючи моделі шар постійної памʼяті, який вона може читати і записувати між ходами, заповнений автоматично з розмови. Цей посібник проходить через референсну архітектуру і інтеграційний код, використовуючи Anthropic Claude API як LLM і REST API Alma як шар памʼяті.

Чому PM-агенту конкретно потрібна постійна памʼять?

Три структурні причини. По-перше, сутності, які відстежує PM (люди, рішення, deliverables, SLA, ризики), самі по собі довготривалі — вони переживають будь-яку окрему розмову за визначенням. По-друге, розмовний стиль високочастотний і малозусильний: короткі повідомлення стендапів, швидкі уточнення, запитання «що ми сказали про X?». Дешеве завантаження правильного шматка контексту має значення. По-третє, вартість забування висока: пропущене рішення стає пропущеним релізом, забута залежність стає блокером.

Стейтлес-розмова Claude добре опрацьовує одну сесію планування. Щойно користувач хоче безперервності («вчора ми домовилися...», «що блокує команду auth цього тижня?»), розмова має або повторно програти повну історію у контекстне вікно (дорого, зрештою неможливо), або покладатися на шар памʼяті поза моделлю.

Як виглядає референсна архітектура?

Чотири рухомі частини:

Як мені структурувати категорії памʼяті для PM-агента?

Пʼять категорій покривають більшість команд: stakeholder (люди з роллю + обовʼязками), decision (що було узгоджено, коли, ким, з обґрунтуванням), sla (зобовʼязання перед іншими командами або клієнтами), risk (відкриті питання з власником + помʼякшенням), milestone (цільова дата + обсяг + статус). Кожен спогад несе бал важливості, щоб ассемблер міг пріоритизувати високоризикові пункти у пошуку.

Категорія — не лише для організації, це частина сигналу пошуку. Коли користувач питає «що ми вирішили?», ассемблер вище зважує memories категорії decision. Коли вони питають «хто заблокований?», memories категорії risk піднімаються. Збирання контексту Alma виставляє ваги підсилення для кожної категорії саме для цього кейсу.

Який інтеграційний цикл у реальному коді?

Три фази на повідомлення користувача. Псевдокод нижче використовує Node.js з Alma SDK і Anthropic SDK, але та сама форма працює у Python або будь-якому іншому стеку:

Фаза 3 працює у фоні — користувач негайно бачить streamed-відповідь, а екстракція відбувається у наступну ~1 с без блокування. Нові memories дедуплікуються, суперечності виявляються проти наявних записів, і сховище залишається чистим автоматично. Повна довідка SDK: @olivaresai/alma-sdk; HTTP-еквіваленти у документації REST API.

Як агент опрацьовує мультипроєктну ізоляцію?

Використовуйте environments Alma: один environment на проєкт. Кожен environment має власні memories, episodes, procedures і блоки Soul, повністю ізольовані від інших. Агент передає environmentId у кожному виклику памʼяті; API застосовує межу. Між-проєктні запити просто неможливі без явного перемикання environment — що є правильним замовчуванням для PM-інструменту, де витік рішень з проєкту A у проєкт B — реальна проблема.

Для команд-широких PM-агентів (кілька людей, що взаємодіють з тим самим агентом), використовуйте ресурс teams Alma: кожна команда має спільні memories, видимі всім членам, плюс memories для кожного користувача для особистих вподобань. Контроль доступу за ролями керує тим, хто може що записувати.

Як виглядає хід щоденного стендапу від кінця до кінця?

Повідомлення користувача: «стендап: backend-команда, Марія сьогодні розблоковує міграцію, Хосе на рейт-лімітері; ми вирішили перенести GA-реліз на пʼятницю, бо легал ще переглядає DPA». Потік агента:

Поширені робочі процеси, які варто памʼятати

Археологія рішень. «Чому ми зменшили обсяг рейт-лімітера?» — агент отримує спогад рішення плюс навколишній episode і спогад ризику, на який він посилався. Повертає відповідь з цитатами на записи, щоб користувач міг заглибитися у розмову, якщо потрібно.

Пошук стейкхолдера. «Хто володіє міграцією?» — прямий запит памʼяті проти категорії stakeholder, повертає запис. Якщо відповідь застаріла (роль змінилася минулого тижня), виявлення суперечностей ловить це у наступній розмові, що згадує нового власника.

Генерація повторюваного звіту. «Згенеруй звіт про статус для потоку auth цього тижня» — агент збирає контекстне вікно episodes, рішень і ризиків, позначених для цього потоку, потім складає звіт з цього курованого шматка. Це значно дешевше і точніше, ніж просити Claude резюмувати сиру історію чату.

Як тримати системний промпт малим, але все ж заземленим?

Замовчувані токен-бюджети в ассемблері: ~2 K токенів для memories, ~1 K для episodes, ~500 для procedures, ~500 для блоків Soul. Загалом ~4 K — добре під будь-яким контекстним бюджетом моделі, і потрапляння у кеш амортизуються через розмову. Якщо Ваш проєкт малий (<100 активних memories), Ви можете знизити бюджет ще. Якщо великий (10 K+ memories), ассемблер залишається на ~4 K, бо отримання обмежує кількість включених записів, навіть коли сховище велике.

Дві речі мають значення операційно: блоки Soul (ідентичність агента) мають кешуватися як стабільний префікс системного промпта, щоб повторювані виклики не платили знову за вхідні токени; а динамічний контекст (memories + episodes) має сидіти після точки розриву кеша, щоб кожен виклик повторно завантажував лише змінену порцію. Документація з кешування промптів Anthropic покриває розміщення точок розриву.

Скільки це коштує на практиці?

На типовому PM-потоці команди (~20 повідомлень/день на користувача, переважно стендапи + уточнення) маржинальна вартість домінується самими викликами LLM. Шар памʼяті додає: один виклик assemble (кілька KB читання + отримання, ~30 мс), один виклик extract (Haiku, ~$0.001 на хід). Загальні накладні витрати памʼяті на день на активного користувача: добре під центом. Порівняйте з цінністю того, що PM-команда не втрачає рішення, — і математика очевидна.

Як почати прототипувати?

Тариф Starter Alma ($14/місяць) — початковий тариф і включає шар постійної памʼяті. Зареєструйтесь на alma.olivares.ai, згенеруйте ключ API у Settings і клонуйте SDK-стартер зі сторінки для розробників. Запровадьте трьохфазний цикл у коді Вашого агента, направте його на один тестовий проєкт і запустіть на тиждень. Сховище заповнюватиметься природно з розмов; Ви побачите, як накопичуються рішення, стейкхолдери і ризики без ручного введення даних. Звідти це просто збільшення кількості категорій і налаштування ассемблера.

Повʼязане читання: Постійна памʼять для ШІ: повний посібник 2026 · Як надати ШІ постійну памʼять · Тришарова архітектура памʼяті · Документація зі збирання контексту · Environments.

See plans