Persist AI agent memory beyond the sandbox
Persist agent memory outside Polyaxon sandbox lifetimes using application stores, scoped connections, versioned snapshots, and reproducible evaluation.
Agent memory should not depend on whether one sandbox is still running. A process can be replaced, a session can expire, and a workspace can be cleaned up without losing the information the application intentionally retained.
Use Polyaxon for execution and evidence, and choose a durable application store for mutable memory. Keep working files, conversation records, and reusable knowledge separate because they have different access and consistency needs.
Separate memory by purpose
| Memory type | Example | Appropriate treatment |
|---|---|---|
| Working state | Intermediate calculation or temporary file | Session-scoped and disposable |
| Conversation state | Prior turns and pending tool requests | Durable application record |
| Episodic evidence | What happened during one task | Versioned report or artifact |
| Shared knowledge | Reviewed engineering guidance | Curated retrieval store |
| User preference | Approved defaults | User-scoped record with update rules |
A vector database can support retrieval, but it is not automatically the authoritative record of a task. Likewise, an artifact store preserves files but does not provide all the query and transaction behavior of a session database.
Put durable memory behind a trusted interface
Let the controller read and update memory through an application-owned service or database. Use configured Polyaxon connections where a trusted workload needs access.
Namespace records by tenant and user, validate ownership on each request, and define which fields an agent may propose versus directly modify. Do not let a model choose an arbitrary memory partition.
Generated code often needs only a selected snapshot. Upload that snapshot to the sandbox workspace instead of mounting unrestricted access to the memory store.
Make updates explicit and recoverable
Record an update identifier and expected prior revision when changing durable state. This helps detect stale writes and reconcile retries after a lost response.
For a coding assistant, completing a task might append a reviewed summary and a patch reference. It should not automatically convert every model conclusion into shared organizational knowledge.
Keep provenance with the memory entry: source run UUID, input revision, evaluator result, and review status. A future agent should be able to distinguish a verified procedure from an unreviewed hypothesis.
Snapshot the context used for evaluation
When comparing agent revisions, record which memory snapshot each candidate received. Otherwise a better result may come from richer context rather than a better policy or model.
Use tracking metadata for snapshot identifiers and artifacts for approved evaluation context. Avoid duplicating sensitive conversation content into broadly visible logs.
Include cases where memory is stale, contradictory, absent, or contains untrusted instructions. The application should preserve authorization and tool policy regardless of what the retrieved text says.
Treat deletion and retention as application behavior
Define how a user's deletion request affects primary records, derived retrieval indexes, snapshots, and backups. Expiring the sandbox does not perform those operations.
Retain only the information needed for the product and its evidence requirements. Temporary debugging notes and raw tool outputs should not become permanent memory by accident.
This design lets Polyaxon workloads come and go while useful knowledge remains under explicit control. The sandbox holds active work; the application memory layer owns continuity; tracking and artifacts explain how that continuity influenced a result.