WukongDojo.AIAI is here, just build it
English

Docs - Memory observability

See what your agent remembers

On WukongDojo, you don't just write the prompt - you manage the memory. Every fact, commitment and trajectory your agent has learned is visible, editable, and annotatable. You can also see exactly which memories were injected into the LLM context on any given turn.

1. Why this is a world-first

On ChatGPT, Claude, Gemini, Coze, Dify - the agent's long-term memory is a black box. You write the prompt, then the agent goes off and remembers things, forgets things, and answers in ways you can't trace. When the agent says something wrong, you have no idea why.

WukongDojo is the first agent platform to open the memory layer directly to the builder:

  • Visible - every fact, commitment, and trajectory is on screen.
  • Editable - the LLM extracted it wrong? Fix it. Shouldn't have remembered it? Delete it.
  • Annotatable - leave a note under any agent reply: "next time, ask the budget first."
  • Traceable - for every turn, see which memories were sent to the model, and where each memory was extracted from.

This is not a ChatBot upgrade. This is where conversational AI starts becoming a digital being.

2. Three modules - the whole picture

ModuleQuestion it answersWhere to look
Where the memory came fromWhich conversation extracted it? Which turn? Written by LLM or by you?Session Memory section, Memory Snapshot Card, the "Learned [date]" link in Latest Memory
How the memory got usedOn this exact turn, which memories were placed into the context window? How was the session summary compressed?Memory At Turn popup (click the 🧠 N facts · M commitments button on any turn)
What you, the builder, can do about itEdit, delete, or annotate. Your changes feed straight into the next turn.Latest Memory drawer (edit/delete), Memory Snapshot Card (add a fact), Builder Message Memory (per-message note)

3. Getting in

Builder Dashboard → pick an agent → user list → pick an end-user → Conversation Memory View. URL form: /agents/{agentId}/conversations/{userId}/memory. At the top you see the agent name, the end-user's email, session count, and total earnings. Below that: four collapsible memory-tier tabs, then the chronological transcript timeline.

4. Four memory tiers (the top tabs)

Memory isn't one bucket. It's split by lifecycle into four tiers - each with its own color, icon, and purpose.

🧠 Latest Memory - what the agent currently has in mind

The most common entry point. Opens a drawer with two halves.

Short-term memory (0-6 months) - listed as Facts and Commitments. Each fact row shows the text, a Learned 2026-05-28 timestamp (clickable - jumps the transcript to the exact message that produced it), and Edit / Delete buttons. Each commitment row carries a status pill (OPEN / DONE / ABANDONED), the commitment body, and the committed date.

Long-term memory (6 months+)- compressed prose plus Trajectory. Long-term patterns are read-only paragraphs. Trajectory is a multi-line editable textarea: this is the agent's narrative understanding of who this user is becoming, and you can rewrite it.

Builder powers here: edit or delete facts; rewrite the trajectory.

💾 Session Memory - what one conversation compressed

When a conversation grows past the context window, session-level compaction kicks in. This tab shows the structured result.

Sub-blocks: Open Threads (description, next action, blocked-on, priority), User Profile (domain literacy, interaction style, inferred project, stated goals, notable insights), Facts, Key Events (T5, summary, outcome), and a Prose Summary.

Read-only. It tells you what the agent saw in this single conversation.

🔮 Short-Term Memory - the cross-session user portrait

Tier 2. Injected into Block 0 of the system prompt at the start of every new conversation.

Each row carries: a confidence dot (green = confirmed, amber = inferred), the content, a status pill (active / stale / resolved / contradicted / archived), a confidence label, last-seen (today / yesterday / Nd ago), expiry (no expiry / expires in Nd / expired), agent-kind tag, custom tags, and the evidence (italic) if present. Grouped by type: Fact ◆ / Commitment ◉ / Trajectory ⟶, each group showing active vs inactive counts.

Read-only here - to edit, go back to Latest Memory.

🌐 Long-Term Memory - the permanent portrait

Tier 2.5. Harvested weekly from stale short-term rows. Six-months-plus compressed history.

Each entry shows: status (Active / Superseded), version + harvest count, the prose summary in italic quotation marks, tags (cyan pills), source row count ("sourced from N short-term rows"), and first-created date. Active version stays on top; previous versions are collapsed beneath.

Read-only. This is your agent's long-form portrait of the user.

5. Per-turn trace - how memory got used at each turn

This is the most distinctive part of the Memory UI. No competing platform does this today.

On the transcript timeline, every (user message + agent reply) pair has a blue button on top: 🧠 5 facts · 2 commitments ⌄. Click it. The Memory At Turn popup opens. The title reads "Memory sent at this turn"; the subtitle gives you the turn index and timestamp.

SectionWhat it shows
Session SummariesEvery prior session's summary plus the L5 compaction preview (within-session compression)
FactsThe facts listed in manifest.l3.pinnedFactIds - the exact ones placed into the context window

This is the heart of the full trace:you're not seeing "what the agent probably remembered." You're seeing the actual slice of the context window the model received on that LLM call. The manifest is read directly from runtime - it is not a post-hoc reconstruction.

Read-only here. To change a fact, jump back to Latest Memory.

What it solves:
  • "Why did the agent suddenly say the wrong thing?" - now you can see what context it was given.
  • "Why didn't it use the preference the user mentioned earlier?" - retrieval ranking is visible.
  • "What did session compaction throw away?" - the L5 preview shows the compressed form.

6. Where each memory came from (provenance)

Memory Snapshot Card. At every session boundary in the transcript timeline you'll see a "Memory after Session N" card with a "Post-processed [date]" (or "Not post-processed yet") subtitle. It splits into Facts (with a NEW badge for facts produced in that session, plus Edit / Delete per row), Commitments (status pill, open ones can be deleted directly), and Trajectory (with a NEW badge if updated in this session, plus an Edit button). At the bottom: a + Add fact button - the entry point for builders who want to add a fact by hand.

Note on builder-authored facts: when you add a fact by hand, its provenance is tagged builder_authored (distinct from llm_generated and builder_edited). Retrieval applies stricter rules to these to prevent prompt-injection patterns. The full policy lives in the platform's internal trust-and-injection doc.

"Learned [date]" jump links. Every short-term fact in the Latest Memory drawer carries a Learned 2026-05-28 link. Click it - the transcript scrolls to the original message and highlights it.

That gives you the end-to-end trace: fact → the turn that produced it → every turn where it was later injected. All three legs are visible.

7. Three intervention actions

Memory is not decoration. It's an input to your agent's behavior. There are three ways to intervene.

Edit - fix a fact the LLM extracted wrong

Edit lives on every fact row in Latest Memory drawer and in Memory Snapshot Card. Click Edit, type into the inline textarea, save.

What happens under the hood: provenance flips from llm_generated to builder_edited. On the next retrieval, this fact ranks higher (human-confirmed beats LLM-extracted).

Delete - remove a memory that shouldn't exist

Same entry points. Common use cases:

  • The user said something off-hand and the agent took it as fact.
  • Privacy-sensitive content (phone, address) got accidentally extracted.
  • Stale knowledge from an older prompt version is sticking around.

Delete is a soft delete: removed from retrieval, but the historical timeline is preserved (so audit traces still resolve).

Note - annotate an agent reply

Below every agent reply there's a collapsed + Add memory button. Open it, type your note, save. The note then sits under that reply as 📝 1 memory.

Notes have three audiences:

  • For yourself - next time you revisit, you'll remember what you were thinking.
  • For the WukongDojo platform - your notes are a signal feeding into how we improve the memory engine.
  • For the upcoming Training module - this is builder-labeled data; the future RLHF / DPO loop will eat it.

Example notes:

  • "Should have asked the budget first, not jumped to a premium recommendation."
  • "The user was joking - this shouldn't have been remembered."
  • "Marked commitment as done too early; user hasn't confirmed."

Notes are tagged builder_authored. They are not injected into end-user-facing prompts, so they cannot leak into a real conversation.

8. What happens after you change a memory

You edited a short-term fact: takes effect on the nextconversation. The current session's already-sent prompt does not roll back. The historical turn popup still shows the old value - the trace is never rewritten (this is a design invariant).

You edited the trajectory: takes effect immediately. Trajectory is part of Block 0 - the next conversation reads the new version on first turn.

You deleted a fact or commitment: removed from retrieval right away. The historical trace is preserved- if you open the same turn's popup three months later, you will still see "this fact was injected here at the time."

You wrote a note: no effect on what the agent says to end-users. The note feeds your own review pipeline and the future Training module.

9. In one line

The black-box era is over. From now on, what your agent remembers, what it used, and why it answered the way it did - you can see it, and you can change it.