The Robot Memory Experiment That Changed Our Roadmap
A previous action can be successful and still be the wrong answer.
That sounds obvious until a memory system retrieves the episode with a high similarity score. The incident looks familiar. The old action worked. The reflection is positive. But the payload changed, a person is now inside the work cell, or the successful run happened in a supervised training lane.
That uncomfortable case changed how we think about robot memory.
The result that made us stop
Section titled “The result that made us stop”Our first Physical AI fixture was not designed to prove that retrieval works. Finding a similar incident is the easy part. We wanted to know whether a memory system would repeat an action that looked successful while ignoring the conditions that made it acceptable.
The non-gated approaches did exactly that on the hard distractors. They found plausible history and ranked the wrong action highly. The context-gated variant treated the old outcome as evidence to evaluate, not an instruction to repeat.
That distinction became the center of the work:
Memory for an acting system is not just recall. It is a replayable argument for why a previous outcome does or does not apply now.
The measured result and fixture boundaries live in Experiment 013. This post is about what we changed because of it.
What changed in the product direction
Section titled “What changed in the product direction”First, we stopped treating Action-Outcome Memory as another semantic retrieval layer. Similarity is useful for finding candidates, but time, topology, payload, policy, and nearby human activity decide whether an outcome is reusable.
Second, we made evidence part of the memory object. A recommendation should be traceable back to the robot state, sensor window, retrieved episode, suppression decision, intervention, and eventual outcome. A detached text summary is not enough for incident review.
Third, we separated research completion from product readiness. A fixture can pass while the surrounding runtime is still too narrow for broad promotion. That boundary is not fine print; it is part of the engineering result.
Why the next experiments moved into failure paths
Section titled “Why the next experiments moved into failure paths”After the first comparison, a better score was no longer the most interesting question. We wanted to know whether the same evidence could survive contact with a real database path.
The sequence therefore moved through native SQL materialization, bounded edge-to-fleet replay, shadow decisions, restart idempotency, owner replacement, and projection repair. Each experiment removed one convenient assumption from the previous one.
That progression also exposed what ZeptoDB is and is not. It can keep telemetry and action history on one queryable timeline. It can make decision evidence replayable. It is not a robot controller, a certified safety system, or a reason to skip application-level policy and operator review.
What we are still trying to learn
Section titled “What we are still trying to learn”The current fixtures are controlled and intentionally small. Real deployments introduce changing schemas, noisy clocks, partial sensors, operator habits, long-lived drift, and failure combinations that no short replay captures.
The next useful evidence is therefore operational: longer shadow runs, visible lag and retry behavior, rollback exercises, architecture coverage, and examples where a context gate should decline to decide because the evidence is insufficient.
That is a less dramatic story than “the robot learned from experience.” It is also the story we can test.