A2A Agent Memory
Per-agent memory observations.
Every registered A2A agent accumulates memory observations over time - factual claims about code patterns, architectural decisions, tech-stack choices, and project conventions that the agent has recorded during sessions. The agent memory page surfaces these observations for a single registered external agent so operators can audit what the agent knows, spot contradictions, and understand how its knowledge is evolving.
Navigate to it from the agent detail page:
/<org>/<project>/factory/agents/<agentCardId>/memoryWhat are memory observations?
Observations are short factual statements stored in the observations table, scoped to an (org, project, agent) triplet. They are written by the platform's memory system when an agent completes work that produces durable, reusable knowledge - for example, after a session where the agent edited a configuration file or corrected a test pattern.
Observations feed back into the agent's future sessions through start-of-session memory injection and in-session memory injection, so the agent does not need to re-discover facts it has already learned.
Observation source and weight
Every observation carries a source field:
| source | Meaning |
|---|---|
auto | Written by the platform's automated ingest pipeline (session-terminal or PR-merge extraction) |
explicit | Written by the agent itself via the af_memory_remember MCP tool |
explicit observations typically carry higher retrieval weight than auto ones because the agent made a deliberate choice to persist the fact.
The weight field (also called importance weight in the UI) is a floating-point score that controls both retrieval priority and pruning resistance. Higher weight means an observation surfaces earlier in the injected context block and is less likely to be evicted when the context budget is tight.
Page layout
Observation list
The main panel shows a paginated list of observations scoped to this agent, most recent first. Each row displays:
| Field | Notes |
|---|---|
| Content | The observation text |
| Type | Observation category (e.g. code_pattern, architectural_decision, preference) |
| Importance weight | Floating-point score - higher = more likely to be injected and less likely to be pruned |
| Tags | Free-form tags attached at write time |
| Classification | Derived from the observation kind (first dot-segment); notes carry a fixed note badge |
| Created | Timestamp |
| Source | What wrote this observation (session ID, PR URL, or batch extraction job) |
Filters
Use the filter bar to narrow the list:
- Tag - filter notes and observations by tag
- Classification - multi-select on the derived classification
Project-wide memory health (totals, drift alerts) lives on the memory analytics dashboard, not on the per-agent page.
Observation lifecycle
Observations arrive via four ingest paths. Each path sets a different base confidence, which feeds into retrieval ordering:
Session-terminal extraction (source='auto', confidence 0.30) - when a session completes with workResult=passed, the auto-ingest pipeline extracts decision markers from thought activities and file-write patterns from action activities. The conservative confidence reflects that session-end synthesis uses heuristics rather than human validation.
PR-merge ingest (source='auto', confidence 0.55) - on pull_request.closed + merged=true, per-file pattern observations and an aggregate PR observation are extracted. The higher confidence reflects that merged code has survived human review.
Batch extraction - the background extraction cron picks up observations rows flagged for graph extraction and runs entity resolution and LLM-assisted extraction strategies. This enriches existing rows rather than creating new ones.
Explicit memory writes (source='explicit') - agents write observations directly using the af_memory_remember MCP tool with an agent-chosen weight. See Writing observations from a session below.
Observations are ordered at injection time by embedding similarity scaled by feedback weight - see Retrieval Ranking for the live pipeline (and the corroboration boost that is built but not yet wired in).
Writing observations from a session
Agents can persist durable knowledge directly using the af_memory_remember MCP tool. This is the explicit write path - it stores a source='explicit' observation with the agent-supplied content and weight, scoped to the current org/project automatically:
af_memory_remember(
content = "All date/time values in this service use ISO 8601 UTC strings, never Unix timestamps.",
classification = "convention",
filePath = "services/billing/src/utils/dates.ts",
weight = 2.0,
tags = ["datetime", "billing"]
)| Parameter | Required | Description |
|---|---|---|
content | Yes | The durable fact, learning, or convention to persist. Be concise. |
classification | No | Semantic category: pattern, decision, error, tool-use, convention. Defaults to note. Used by the Memory Trends panel for grouping. |
filePath | No | Source file or module this observation concerns. Used by the Coverage heatmap. |
tags | No | Free-form string tags for later filtering. |
weight | No | Retrieval importance (default 1.0). Use >1 for key facts you want surfaced first. |
The tenant context (orgId, projectId, agentId) is injected server-side from the authenticated session - the agent cannot write into another org or project.
If an identical observation (same org, project, agent, content hash) already exists, the store increments its weight rather than inserting a duplicate.
Cross-project knowledge transfer
When an org admin enables cross-project transfer, observations from this agent can be shared into other projects that use a sufficiently similar tech stack. The transfer engine uses Jaccard similarity on tech-stack fingerprints: observations are eligible for transfer when the source and destination projects share at least 70% of their detected languages, frameworks, and build tools.
Transfer is:
- Read-only - transferred observations appear in the destination project's injection context but cannot be modified or deleted from there.
- Cedar-authorized - an admin must explicitly enable transfer for the
(source, dest)project pair. The default policy is deny. - Weight-discounted - transferred observations are multiplied by
transferredWeightMultiplier(default 0.5) so locally-sourced observations rank higher.
There is no self-serve admin UI for transfer grants today - the grant list lives in project sandbox configuration, written by operators. See the Cross-Project Knowledge Transfer reference for the mechanism and its current limits.
Editing and deleting observations
Operators can:
- Edit the content or type of an observation inline. Edits are audit-logged.
- Delete an observation hard. There is no soft-delete on this table - deletion is permanent.
Deleting an observation removes it from future injection contexts immediately. It does not retroactively affect sessions that already received it. If you want to reduce an observation's influence without deleting it, lower its importance weight instead.
Memory analytics
For aggregate views across all agents in your project, see the Memory Analytics dashboard. The agent-scoped memory page focuses on a single agent; the analytics dashboard shows fleet-wide trends, coverage heatmaps, drift rates, and context budget analysis.
Related pages
- Agent Detail - skills, health, and trust level for this agent
- Memory Analytics - fleet-wide memory dashboard
- Observation Store - pgvector-backed storage internals
- Drift Alerts - cross-agent contradiction detection
- Retrieval Ranking - corroboration-aware ranking algorithm
- Cross-Project Knowledge Transfer - Cedar-authorized transfer between projects