Nox-Lumen Mfgmemory-sdk
Capabilities
Provides a full long-term memory (LTM) management API:
| Tool | action | Purpose |
|---|---|---|
record_knowledge | write | Write / update memory |
record_knowledge | delete | Delete memory |
record_knowledge | list | List all memories |
unified_search | search | Semantic memory retrieval |
Five memory types
| Type | Purpose | Example |
|---|---|---|
fact | Objective facts | “Project uses Java 17 + PostgreSQL 15” |
preference | User preferences | “Prefer concise Chinese output, no emoji” |
program | Operational workflows | “Deploy: lint → test → build → push” |
error_pattern | Bug patterns / false positives | “Heartbeat timeout must trigger disconnect” |
chunk_node | KB cognitive grouping | Recorded after retrieval (usually not manual) |
Default behavior
If the user did not configure explicitly, the Agent automatically at appropriate times:
- Writes stated preferences to
preference - Writes project constraints and facts to
fact - Writes reusable workflows to
program - Writes pitfalls / false positives to
error_pattern
How to trigger
Natural language examples:
- “Remember I prefer replies in Chinese”
- “From now on remember this project’s coding standard is Google Java Style”
- “Forget the convention you just saved for me”
- “List everything you remember about me”
Hook policy templates
memory-sdk ships built-in memory policy Hooks:
| Hook | When it fires | Default behavior |
|---|---|---|
on_user_preference | User states a preference | Auto-write preference |
on_error_learn | After Agent execution errors | Analyze root cause → error_pattern |
on_task_complete | Task completes | Summarize flow → program |
Enable or disable these in Agent configuration.
Extension: structured data → LTM processing pattern
The sections above cover single-turn memory flow (memory born in conversation). The platform also has another path:
Periodically turn structured KB data into LTM insights
The first implementation of this pattern is bug-import — it aggregates standalone Bug records along module / cross-module / file / root cause dimensions and periodically emits bug_pattern-style fact entries for L2 code review.
Why call this out separately
Single-turn memories are fragmented (one preference, one fact). They answer “how should the Agent interact with me?”
Structured-data processing yields aggregated memories — they answer “what patterns has this project / organization accumulated?” That is organizational memory, not personal preference.
Extensible processor types
Following the same “KB → cron → LTM fact” pattern, you could add:
| Processor | Input | LTM fact output | Use case |
|---|---|---|---|
bug-import (implemented) | Historical bugs | bug_pattern | L2 review hits |
| Requirement-change processor (hypothetical) | Change history | Hot change areas / churn directions | Requirement review alerts |
| Review-comment processor (hypothetical) | Past review threads | Common critique themes | Developer self-check lists |
| Incident processor (hypothetical) | Postmortems | Recurring incident types / preventions | SRE change review |
Only bug-import exists today. Processors are skills — to add one, design it like bug-import via skill-architect.
Underlying architecture
See Core concepts · Memory — processing path.
Related concepts
- Core concepts · Memory
- Hook system
- graft — another cross-session pattern (session-level, coarser grain)