Memory

Memory is the harness stage that lets agents carry context beyond a single run. Managed memories are shared, policy-governed knowledge stores agents read from and write to under explicit access rules.

#Overview

A run is isolated by design — an agent reasons, calls tools, and produces output, then the run ends. Memory is the Remember stage of the harness pipeline: a managed store that persists knowledge across runs so an agent can build on what it learned before instead of starting cold every time.

Memories are not private scratchpads. They are shared knowledge stores managed in the control plane. Every memory has a defined scope, a sensitivity level, and an explicit set of access rules that decide which principals can read or write it. Agents use memory through that governed surface — they never gain unbounded, unaudited recall.

Note

Memory is a managed control plane capability, not an open SDK call. You define memories and their access policy centrally; agents read and write within the rules those policies establish.

#Scopes

Every memory is created at one scope. The scope determines how widely the knowledge is shared and which agents can be granted access to it.

organizationscopeOptional

Knowledge shared across the entire organization — durable facts and conventions that apply to every team and agent.

workspacescopeOptional

Knowledge scoped to a single workspace, isolating context between distinct environments or product lines.

teamscopeOptional

Knowledge shared by the agents and members of one team, kept separate from other teams in the same workspace.

agentscopeOptional

Knowledge belonging to a single agent — its own accumulated context, not visible to other agents unless explicitly shared.

#Memory types

Each memory is one of two types, reflecting how the knowledge is meant to be used.

  • Core — persistent, actively maintained knowledge an agent relies on every run: durable facts, conventions, and operating context.
  • Archival — historical knowledge retained for reference and recall: prior outcomes and accumulated history that need not be loaded into every run.

#Sensitivity levels

Every memory carries a sensitivity level. It classifies how protected the stored knowledge is and constrains how it may be shared — essential when agents operate over regulated or confidential data.

publicsensitivityOptional

Non-sensitive knowledge that carries no disclosure constraints.

internalsensitivityOptional

Internal knowledge intended to stay within the organization.

confidentialsensitivityOptional

Sensitive knowledge requiring deliberate, restricted access.

restrictedsensitivityOptional

The most protected class, for the most tightly controlled knowledge.

Sensitivity is enforced as a ceiling, not a suggestion. Granting access to a memory above its appropriate level is surfaced as a warning, so access to sensitive knowledge stays a deliberate, reviewable decision.

#Access control

Access to a memory is governed by explicit rules, not by which agent happens to ask. Each rule binds a principal to a role on a specific memory.

  • viewer — may read the memory.
  • user — may read and use the memory during a run.
  • editor — may read and write the memory's content.
  • admin — full control, including managing access rules.

Grants can be issued manually or established by policy, and a grant can carry an expiry so elevated access is time-bounded rather than permanent. This is the same policy model the platform applies to every governed capability — see Governance & Policies for how rules, roles, and just-in-time authorization fit together.

#Audit

Every interaction with a memory is recorded — reads, writes, shares, attachments, and lifecycle changes — with the actor, the action, and a timestamp. The result is a complete history of who touched what knowledge and when, so memory access stays accountable end to end.

That history is part of the platform's broader compliance record. See Audit & Compliance for how memory events sit alongside the rest of the immutable audit trail.

#Next steps

  • Governance & Policies — How policies, roles, and just-in-time authorization decide who and what can access governed capabilities.
  • Observability — See memory access alongside step-level run traces, metrics, and live execution.
  • Core Concepts — Where memory sits in the harness model — connectors, skills, memory, and actions.