2026-06-04. Memory now needs to carry enough classification for a retrieval path to choose material according to its job. My claim is that class and tier cannot remain optional annotations that only careful API callers remember to provide. They have to be inferred at the point of capture, persisted for direct callers as well as API users, and used when a memory pack is assembled. The working question is whether VALESKA can make a useful selection from durable, semantic, procedural, and social material without treating every record as equally fresh, equally permanent, or equally relevant.
This builds on the protocol change from May 31. That work gave low-signal captures a cooler default and separated exact facts from narrative memory. The current change carries the classification farther through the service. Direct callers such as scripts and connectors can bypass schema defaults because the capture insert names its columns. The service now infers memory_class and memory_tier from the thought type when the caller has not supplied them, then normalizes those values before writing. That keeps the required database columns populated instead of leaving a hidden difference between an API capture and a connector capture.
The memory-pack selector is now tier-aware. Durable records are eligible on their own terms, while semantic, procedural, and social records can be selected according to their class. This is not a promise that the ranking problem is solved. It is a way to give the selector information it previously lacked. A stable fact should not quietly disappear because it is old; a working or episodic record can have a different relationship to recency. The code makes those distinctions available to pack construction rather than relying on an undifferentiated nearest-neighbor result.
The commit also adds a small packet input/output foundation for agents that exchange work through the repository. Inbox and outbox roots now exist for Claude Code, Hermes, and OpenClaw, with an example Hermes packet and placeholders that make the directories available to the harness. The packet service reports counts for pending inbox tasks, tasks in progress, failed tasks, and result packets in the outbox. Those counts are deliberately modest: they describe file-state visibility, not successful handoff, completion, or delivery guarantees. The code creates a place to observe an exchange before the system claims a dependable exchange protocol.
The evidence at this stage is implementation and test coverage. The API-memory tests cover a direct capture that normalizes a blank agent to unknown-agent, assigns a prompt capture to the cold tier, and preserves canonical project tags. Fact endpoint tests cover the exact lookup contract. Other changed tests set expectations for recent and search behavior while the service changes carry class and tier fields through records. This demonstrates that the intended paths are exercised in the suite. It does not demonstrate behavior under a populated production store or a multi-agent packet flow.
There is a useful restraint here. Inferring a class supplies a default; it does not settle the meaning of every memory. A caller may have a better classification and can provide it. A tier-aware pack can select records more intentionally, yet still surface a poor match if the underlying query is weak. Packet counts can reveal a stuck queue, yet cannot say why a task stalled. Each addition gives a later investigation a named place to start.
What I will test next
I will run captures from scripts and connectors alongside API captures, then inspect whether their inferred fields produce sensible packs for real recall questions. For packets, I will place representative task and result files through the inbox and outbox paths and compare the reported counts with the filesystem state. The next result must show how those paths behave in use before they become operational claims.
Historical basis: 2026-06-04 repository milestone, commit 7e8ec4e.