Use agent memory and autonomous work

How hierarchical memory works

Hierarchical memory lets an agent inherit approved context down a business scope: Organization → Department → Group → Agent. For example, an organization-wide brand rule can be available to eligible agents in one environment, while a claims-group procedure stays inside that group.

Current-user memory can join the same recall when enabled. Session, run, and document memory are separate bounded scopes; they do not automatically become inherited organization context.

What each layer is for

• Organization — durable standards or facts inherited across the current environment within the tenant.
• Department — context shared by one business function, such as Claims or Finance.
• Group — procedures and preferences for a smaller operating team.
• Agent — knowledge specific to one agent’s job and reviewed outcomes.
• User — personal preferences or facts included only for the current user when allowed.
• Session, run, and document — temporary or source-bound context retrieved only for the explicit task.

Share organization memory without crossing boundaries

Organization memory is the broadest inherited scope, not a global pool. Allow Organization in the agent’s write scopes, then explicitly target it when every eligible agent in that environment should be able to recall the fact. Organization cannot be the default write scope. Use department, group, or agent scope when fewer agents need it.

Memory does not cross organizations, and production, test, and development each have separate memory sets. There is currently no sharing-link workflow or API. If the same fact is needed in another environment, maintain a separately reviewed copy there.

Organization is the tenant boundary; environment is the recall boundary.

Fit recall inside the context window

Automatic recall ranks a bounded set by relevance, confidence, recency, and scope, then injects only the highest-ranked memory that fits its memory budget. Lower-ranked items stay out.

The model’s context must also hold instructions, conversation history, tool results, and its response. A large memory library therefore does not mean every item is available on every turn.

Keep memory current

Review fast-changing operational memory monthly and stable policy memory at least quarterly. Edit or remove stale, contradictory, duplicative, weakly sourced, or one-off items. Retention rules can expire old memory, and semantic consolidation already retires near-duplicates.

Broader automatic memory compaction and optimization are planned for future releases. Until then, regular review remains important. Review memory recommendations before turning feedback into durable context, or see Configure scoped memory in the SDK for authoring details.

Writes stay inside the agent’s hierarchy and allowed write scopes. Policy, DLP, and approval checks still decide whether a memory write is permitted.

Use autonomous work deliberately

When autonomous work is enabled, an agent can plan several turns and choose from its approved tools while working toward a bounded goal. Existing policy, connector, approval, and audit controls still apply to every action.