Перейти до основного вмісту

Knowledge System · Production Architecture

Пам’ять агента — це не source of truth

State & Memory Control Plane відділяє conversation history, durable task state, long-term memory, sandbox state та authoritative system state. Це дозволяє агенту переживати довгі паузи, restarts і compaction без відродження старих permissions, повторних side effects або “спогадів”, які тихо стали бізнес-фактом.

Core invariant

Conversation history ≠ durable task state ≠ long-term memory ≠ authoritative system state. Змішати їх в один blob — простий спосіб отримати складний інцидент.

80/20 control

Найбільший ефект дають stable namespace, versioned checkpoint, provenance/TTL, resume-time revalidation і authoritative postcondition.

Failure rule

Якщо після resume або retry невідомо, що вже сталося у зовнішній системі — не “продовжувати з пам’яті”, а спочатку reconcile authoritative state.

State taxonomy

Шість різних типів state, які не варто складати в одну купу

Ephemeral contextПоточний prompt, retrieved chunks, tool results і temporary working notes.Живе лише стільки, скільки потрібно конкретному model call або bounded run. Не є історією і не є source of truth.
Conversation / session memoryПопередні user/assistant/tool items, потрібні для multi-turn continuity.Може бути client-managed або provider-managed. Має explicit owner, retention, namespace і compaction policy.
Durable task stateTask contract, current step, pending approvals, checkpoints, budgets, retries, handoffs і unresolved outcomes.Версіонується окремо від transcript. Resume має відновити workflow state, а не просто “показати моделі старий чат”.
Long-term memoryСтабільні preferences, lessons, project facts або reusable notes, які переживають окремі сесії.Кожен memory item має provenance, owner, scope, TTL/review policy і deletion path. Model-generated memory не стає authoritative фактом автоматично.
Sandbox / workspace stateФайли, build artifacts, browser/computer session, temporary credentials або tool-local state.Життєвий цикл відокремлений від conversation memory; snapshot/resume не повинен непомітно відновлювати revoked secrets або stale environment.
Authoritative system stateCRM, ledger, ticketing, IAM, repository, booking або інша system of record.Ніколи не замінюється memory. Фактичний outcome перевіряється authoritative read-back після consequential action.

Reference architecture

10 контрольних шарів від namespace до regression suite

1 · Identity + namespace

До будь-якого read/write state система визначає principal, tenant, task/run ID, session ID і memory namespace. Один “conversation_id” не повинен випадково стати глобальним ключем доступу.

Exit criterion

Cross-user і cross-tenant state isolation перевіряється до model call; namespace не виводиться з довільного тексту користувача.

2 · State model + ownership

Відділіть conversation history, durable task state, long-term memory, sandbox state та authoritative business state. Для кожного шару задайте owner, schema, storage, source of truth і дозволені writers.

Exit criterion

Є явна таблиця state classes; model не може записувати business truth у memory замість authoritative system.

3 · Checkpoint contract

Checkpoint має містити достатній deterministic state для resume: task version, current node, pending approvals, tool/action identifiers, budgets, state version і trace link.

Exit criterion

Resume після process crash не потребує реконструювати truth з prose transcript; checkpoint можна валідно deserialize та audit-нути.

4 · Memory write gate

Agent може запропонувати memory item, але application layer вирішує, що дозволено зберігати. Перед write перевіряються scope, sensitivity, provenance, confidence, TTL і duplication.

Exit criterion

Secrets, transient guesses, unverified claims і чужі tenant data не потрапляють у durable memory; memory write має source pointer та reason code.

5 · Retrieval into active context

Пам’ять читається just-in-time, а не завантажується повністю. Retrieval враховує identity, task purpose, recency, confidence, provenance і current policy.

Exit criterion

Context містить лише релевантний working set; stale/conflicting memory позначається або блокується, а absence не перетворюється на вигаданий факт.

6 · Compaction / summarization boundary

Compaction зменшує active context, але може втратити заборони, pending work, uncertainty або provenance. Summary — derived state, а не новий authoritative record.

Exit criterion

Критичні invariants зберігаються структуровано поза summary; compaction проходить regression tests на omissions, contradictions і authority drift.

7 · Resume-time revalidation

Перед продовженням paused run повторно перевіряються identity, scopes, approval expiry, policy/model/tool version, data freshness, external resource version і budgets.

Exit criterion

Старий serialized state не може воскресити revoked permission, stale approval, deleted source або incompatible tool/model contract.

8 · Side-effect linkage + reconciliation

State transition і real-world side effect пов’язуються idempotency key, action fingerprint і authoritative postcondition. Після timeout спочатку з’ясовується, що вже сталося.

Exit criterion

DONE можливий лише після system-of-record verification; UNKNOWN/PENDING/PARTIAL не стискаються у “успіх”. Правило: reconcile first → retry second.

9 · Retention / deletion / revocation

Delete у chat або source system не гарантує видалення session history, memory files, embeddings, caches, checkpoints, traces чи sandbox snapshots.

Exit criterion

Є inventory derived state, retention class, deletion propagation SLA, tombstone/revoke semantics і доказ purge для кожного durable layer.

10 · State observability + evals

Production trace має показати state version, checkpoint/resume, memory reads/writes, compaction, revalidation decisions, side effects і final authoritative outcome без створення нового privacy leak.

Exit criterion

Є risk-sliced eval suite, state-migration tests, poisoned-memory tests, restart/retry drills і incident → permanent regression loop.

Failure injection

Що потрібно зламати до production

  • — Prompt injection у retrieved document просить записати приховану інструкцію в long-term memory.
  • — User A і User B мають однаковий display name; memory isolation не повинна змішати їхні namespaces.
  • — Compaction summary втрачає “не здійснювати платіж без approval”, але task state має зберегти policy invariant.
  • — Run paused на approval, а до resume permission відкликано або approval expired.
  • — Model, prompt, tool schema або policy змінилися після checkpoint; incompatible state має бути migrated або blocked.
  • — Tool timeout стався після фактичного write; blind retry не повинен створити duplicate side effect.
  • — Memory item суперечить свіжішому authoritative source; retrieval має віддати перевагу truth або вимагати revalidation.
  • — Видалений source лишився в memory, cache, vector store або persisted session history.
  • — Parallel branches оновлюють один state object; optimistic concurrency має виявити lost update.
  • — Sandbox snapshot відновлює старий secret або credential після його revocation.
  • — State migration читає стару версію без required field і тихо підставляє небезпечний default.
  • — Long-term memory росте без TTL/compaction policy та витісняє релевантний evidence з active context.

Migration / rollout

Як перейти від transcript-as-state без “перепишемо все за вихідні”

  1. 1. Інвентаризувати всі місця, де зараз живе state: chat, DB, provider conversation, files, vector store, tool backend, sandbox, logs.
  2. 2. Розділити durable task state і transcript. Не мігрувати все одним великим JSON blob “бо так швидше”.
  3. 3. Ввести stable namespace: principal + tenant + task/run + memory scope.
  4. 4. Додати schema/version/provenance/TTL для checkpoint і long-term memory.
  5. 5. Увімкнути read-only memory retrieval із telemetry та conflict detection.
  6. 6. Дозволити bounded memory writes через deterministic policy; sensitive writes — тільки explicit application rules.
  7. 7. Додати pause/resume, version-aware revalidation, optimistic concurrency та reconciliation tests.
  8. 8. Запустити shadow replay старих runs, restart/failure injection, canary і rollback на known-good state schema.
  9. 9. Перетворювати production state incident у minimized reproduction та permanent regression test.

Primary / provider references

Що підтверджують джерела — і чого вони не доводять

OpenAI

Agents SDK — Sessions

Sessions are a persistent conversation-memory layer; they can resume interrupted RunState while keeping conversation history in the same session.

OpenAI

Agents SDK — RunState

RunState is a serializable snapshot for resuming an agent run. AI-Magister treats it as a workflow primitive, not as authoritative business state.

Anthropic

Claude Platform — Memory tool

Claude memory is client-side: the model requests memory operations while the application controls storage, retention and path security.

Google

Building Secure and Reliable Systems — Known good state

A stable systems principle: reliable recovery requires an explicit intended state and a way to verify deployed state.

Ці документи підтверджують доступні state/memory primitives і загальні recovery principles. Вони не є незалежним доказом, що конкретна implementation автоматично безпечна, надійна або придатна для consequential actions.