Skip to content

[API + Memory] GET /api/v1/memories does not return full episode + episode.summary falls back to content[:200] #131

Description

@shiluanzzz

[API + Memory] GET /api/v1/memories does not return full episode + episode.summary falls back to content[:200]

Issue Body(English Version - Recommended to post this)

Problem Description

While using EverMemOS for benchmarking and third-party integrations, I discovered two clear design/implementation inconsistencies in the /api/v1/memories interface. These issues prevent external users from seeing the true episodic content:

  1. GET /api/v1/memories does not return the complete episode field
    The interface only returns a lightweight version containing title and summary, while the core episode (the full content actually used by internal retrieval, BM25, rerank, and LLM) is not exposed at all.

  2. episode.summary is low quality and actually degenerates into content[:200]
    The system does not instruct the LLM to generate a real summary, nor does it reuse the upstream MemCell.summary. Instead, it directly falls back to truncating the first 200 characters of the content.

Reproduction Steps

  1. Call GET /api/v1/memories
  2. Check any returned memory entry
  3. Compare the internally stored episodic_memory.episode with the returned summary

Evidence Chain (verified on latest main branch)

Issue 1: episode not exported

  • src/agentic_layer/fetch_mem_service.py: The conversion function only uses EpisodicMemoryModel and maps only title and summary — no episode or full content is included.
  • src/api_specs/memory_models.py: The EpisodicMemoryModel definition does not even contain an episode field.
  • Internal retrieval heavily relies on the full episode (src/agentic_layer/agentic_utils.py:146, src/agentic_layer/retrieval_utils.py:88).
  • The storage layer clearly holds the complete content (src/infra_layer/adapters/out/persistence/document/memory/episodic_memory.py:29).

Issue 2: summary fallback

  • src/memory_layer/prompts/en/episode_mem_prompts.py: The episode extraction prompt only asks for title + content — no summary field is mentioned.
  • src/memory_layer/memory_extractor/episode_memory_extractor.py (in the _extract_episode function):
    if "summary" not in data or not data["summary"]:
        data["summary"] = data["content"][:200]   # ← This is the source of the pseudo-summary
  • The upstream boundary detection already generates a high-quality MemCell.summary (src/memory_layer/memcell_extractor/conv_memcell_extractor.py:641), but the episode pipeline never reuses it.

Impact

  • External benchmarks, audits, and third-party systems cannot see the real memory content
  • Users mistakenly treat summary as the complete memory, severely degrading integration quality
  • Strong internal capabilities (full episode) vs. weak external contract → inconsistent experience

Suggested Fix (for reference)

  1. Short-term: Add a query parameter ?full=true to GET /api/v1/memories to optionally return the full episode field (backward compatible).
  2. Medium/long-term:
    • Update the episode prompt to explicitly request a high-quality summary
    • In the extractor, prioritize reusing MemCell.summary (with fallback as last resort)
    • Extend EpisodicMemoryModel to include an optional episode field

This improvement would be extremely valuable for all external users (especially those doing benchmarks). Looking forward to the team's thoughts and feedback!

Additional Information

  • Environment: Latest main branch (March 2026)

Activity

  1. cyfyifanchen commented on Jun 6, 2026

    @cyfyifanchen
    Collaborator

    Closing this as part of the EverOS 1.0 issue triage. This issue references the pre-1.0 API or retired infrastructure such as /api/v1/memories, /api/v3/agentic/*, MongoDB, Elasticsearch, Milvus, Redis, Kafka, longjob, or old memory type names. EverOS 1.0 uses POST /api/v1/memory/{add,flush,search,get} with Markdown + SQLite + LanceDB. Migration notes are tracked in PR #258: #258. If the same behavior still occurs on current main with the 1.0 API, please open a fresh issue with a 1.0 repro.

  2. cyfyifanchen commented on Jun 6, 2026

    @cyfyifanchen
    Collaborator

    Post-triage verification: keeping this closed because the old GET /api/v1/memories behavior is gone. Current POST /api/v1/memory/get and /search document and return full episode fields where appropriate; SearchEpisodeItem includes both summary and episode. If a current 1.0 response omits episode content, that should be filed as a new 1.0 API bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions