{
  "id": 5239919,
  "title": "The extraction returned zero memories, and nothing screamed",
  "url": "https://urgent.news/2026/09/03/the-extraction-returned-zero-memories-and-nothing-screamed",
  "topic": "ai",
  "section": "AI",
  "published": "2026-09-03T03:43:27.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/pm25coder/the-extraction-returned-zero-memories-and-nothing-screamed-3c7c"
  },
  "original_language": "en",
  "account": "The memory extraction process yielded no results, leaving a blank state. The failure stems from three small issues that combined to create silence. The extraction loop in OpenViking asks a vision-language model to convert a conversation into memory events, expecting two outcomes: a structured tool call or JSON that can be parsed. However, the loop encountered three problems that prevented this from happening:\n\n1. The model provided a tool call as markup instead of structured data. Some serving stacks leave the DSML markup in the content field, which the parser looks for but fails to find, resulting in a parsing gap. This gap occurs when the loop doesn't know how to read the input.\n\n2. A prose answer tripped a kill switch meant for a different issue. Thinking models may respond with reasoning instead of a structured tool call or JSON, which is neither expected. The loop's failure branch sets `disable_tools_for_iteration = True`, causing the next iteration to run with tools disabled, contrary to the model's intentions. This misuse of a flag designed for unknown-tool cases causes the model to emit final JSON without tool results, leading to zero memories.\n\n3. The failure was recorded but not surfaced. On the final failure, the loop records an error, but nothing in the commit path propagates that list to the queue or metrics. As a result, the outside world saw commit success, while the true failure remained hidden in container logs and a per-session .failed.json file.\n\nThe reason behind this bug class's persistence is the individual design choices that seem reasonable but fail when combined. A single format-retry budget is reasonable until the one retry is used up by a garbage response, leaving no budget for genuine formatting slips. Reusing a narrow flag (disable tools on unknown tool) as a broad one (disable tools on any parse failure) is another shortcut that punishes the model for one behavior that could have saved the run. Lastly, an errors list that exists but is never aggregated creates an observability gap, making the failure invisible.\n\nThe checklist for maintaining extraction loops includes identifying who spends the retry budget, separating inputs that the parser cannot read from outputs that break the contract, and ensuring the failure handler doesn't punish the model's intent. It is essential to check if the errors list is aggregated and if an empty result is a possible success in the pipeline. A named failure is crucial for identifying and addressing these issues, as it prevents silent failures and enables better tooling to handle the failures.",
  "summary": "A session commit reported success. The memory extraction produced zero memories. No error dialog, no failed state, no metric that moved. The run was recorded as done, and the model's new knowledge simply evaporated. This is the failure mode I want to talk about — not because it is exotic, but because it is the one our tooling is worst at surfacing. It happened in the open on volcengine/OpenViking…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}