Knowledge Architecture
AgentUX learns from every session. It captures discoveries, classifies them by importance, stores them in a graph database, and protects hard-won knowledge from being forgotten.
On This Page
- The Knowledge Lifecycle
- How Knowledge Gets Captured
- Importance Tiers
- How Knowledge Gets Used
- Maintenance & Pruning
- Manual Knowledge Management
- Skill Knowledge Architecture
The Knowledge Lifecycle
Every AgentUX session participates in a continuous learning loop. Knowledge flows through four stages: capture, classify, store, and retrieve, with periodic maintenance keeping the knowledge base clean.
flowchart LR
A["Capture\n\nClaude discovers\nsomething non-obvious"] --> B["Classify\n\nAssign importance tier\nquick-tip to never-forget"]
B --> C["Store\n\nSessionEnd hook\nMERGEs into Neo4j"]
C --> D["Retrieve\n\nNext session queries\nNeo4j for relevant knowledge"]
D --> A
C --> E["Maintain\n\nPeriodic pruning\nrespects tiers"]
E --> C
style A fill:#1e3a5f,stroke:#4a9eff,color:#e0e0e0
style B fill:#3d3a1a,stroke:#ffa500,color:#e0e0e0
style C fill:#1a3d2e,stroke:#50c878,color:#e0e0e0
style D fill:#3d1a3d,stroke:#c77dff,color:#e0e0e0
style E fill:#3d1a1a,stroke:#ff6b6b,color:#e0e0e0 How Knowledge Gets Captured
During a session, Claude monitors for knowledge worth preserving. Not everything gets recorded -- only discoveries that would prevent future mistakes or save debugging time.
flowchart TD
A["Claude encounters\na UE API behavior"] --> B{"Was it expected?"}
B -->|"Yes, routine"| C["Skip -- no capture"]
B -->|"No, surprising or\nnon-obvious"| D["Record to\nknowledge queue"]
D --> E{"How important?"}
E -->|"Trivial"| F["quick-tip"]
E -->|"Useful, learned through work"| G["life-experience"]
E -->|"Took real debugging"| H["hard-won"]
E -->|"User says: never forget"| I["never-forget"]
F --> J["Appended to\n.claude/knowledge-queue.md"]
G --> J
H --> J
I --> J
J --> K["Session ends"]
K --> L["Hook parses queue\nMERGEs into Neo4j"]
L --> M["Queue cleared"]
style C fill:#2a2a2a,stroke:#666,color:#999
style F fill:#2a3a2a,stroke:#50c878,color:#e0e0e0
style G fill:#1e3a5f,stroke:#4a9eff,color:#e0e0e0
style H fill:#3d3a1a,stroke:#ffa500,color:#e0e0e0
style I fill:#3d1a1a,stroke:#ff6b6b,color:#e0e0e0 What Gets Recorded
- API behavior that differs from documentation or reasonable expectation
- Fixes that required research or trial-and-error
- Case-sensitive parameter names or version-dependent behavior
- Required call ordering (A must happen before B, or B silently fails)
- Silent failures: input accepted, no error, but wrong output
What Gets Skipped
- Routine API usage that worked on first try
- Information already documented
- Temporary debugging steps
- User preferences or project-specific configuration
Importance Tiers
Every piece of knowledge carries an importance tier that controls how it is protected during maintenance. Higher tiers survive more aggressive pruning.
flowchart TB
subgraph TIERS["Importance Tiers -- Highest to Lowest Protection"]
direction TB
NF["never-forget\n\nIMMUNE to all pruning\nNever demoted\nUser explicitly requested"]
HW["hard-won\n\nFlagged for human review only\nNever auto-deleted\nLearned from real failures"]
LE["life-experience\n\nDefault tier\nOnly pruned if contradicted\nDemotion requires 2-session grace"]
QT["quick-tip\n\nAll pruning checks apply\nDeleted after 2-session grace\nEasily re-discovered"]
end
NF --- HW --- LE --- QT
style NF fill:#3d1a1a,stroke:#ff6b6b,color:#e0e0e0
style HW fill:#3d3a1a,stroke:#ffa500,color:#e0e0e0
style LE fill:#1e3a5f,stroke:#4a9eff,color:#e0e0e0
style QT fill:#2a3a2a,stroke:#50c878,color:#e0e0e0
style TIERS fill:#0d1117,stroke:#30363d,color:#e0e0e0 | Tier | Protection | Assigned When | Example |
|---|---|---|---|
never-forget | Immune to all pruning and demotion | User says "never forget this" or "critical" | "Always deploy DLL after every build" |
hard-won | Flagged for human review only | Knowledge from real debugging failures | "StaticEnum linker errors for non-exported enums" |
life-experience | Only pruned if contradicted | Default tier for most captured knowledge | "PIE transitions need 2-second sleep" |
quick-tip | All pruning checks apply | Trivial, easily re-discovered | "Use -nocef flag for C++ tests" |
Escalation is always free. Any entry can be promoted to a higher tier immediately, at any time. Demotion requires a two-session grace period to prevent mistakes.
How Knowledge Gets Used
Knowledge flows back into sessions through two channels: the startup cheatsheet (proactive) and on-demand queries (reactive).
flowchart LR
subgraph START["Session Start"]
A["Startup hook fires"] --> B["Cheatsheet loads\n5 critical gotchas\npath rules, error codes"]
end
subgraph WORK["During Work"]
C["User asks about\nlighting setup"] --> D["Claude queries Neo4j"]
D --> E["get_skill_knowledge\nlighting-fundamentals"]
D --> F["get_test_knowledge\nviewport camera"]
E --> G["Returns relevant entries\nwith importance tier shown"]
F --> G
G --> H["Claude applies knowledge\navoids known pitfalls"]
end
B --> C
style START fill:#0d1117,stroke:#4a9eff,color:#e0e0e0
style WORK fill:#0d1117,stroke:#50c878,color:#e0e0e0 Both get_skill_knowledge and get_test_knowledge return the importance tier alongside each result, so Claude can see how trustworthy and battle-tested each piece of knowledge is.
Maintenance & Pruning
Knowledge accumulates over time. Without maintenance, entries may overlap, become stale, or contradict updated code. AgentUX runs maintenance automatically every 24 hours, applying six checks -- but respecting importance tiers at every step.
flowchart TD
A["Maintenance triggered\nautomatically every 24h\nor manually via /knowledge-maintenance"] --> B["Inventory all entries\nwith importance tiers"]
B --> C{"Check importance"}
C -->|"never-forget"| D["IMMUNE\nSkip all checks"]
C -->|"hard-won"| E["REVIEW ONLY\nFlag for human, never auto-delete"]
C -->|"life-experience"| F["PARTIAL SHIELD\nOnly contradictions can drop"]
C -->|"quick-tip"| G["NO SHIELD\nAll 6 checks apply"]
G --> H["Contradictory?\nSelf-evident?\nUnverifiable?\nDuplicate?\nLow-value?\nUncertain?"]
H -->|"Flagged"| I{"First time flagged?"}
I -->|"Yes"| J["Mark for pruning\nGrace period starts"]
I -->|"Already marked\nfrom last run"| K["Delete entry\nGrace period served"]
H -->|"Passed all checks"| L["Keep entry\nClear any marks"]
style D fill:#2d5a27,stroke:#50c878,color:#e0e0e0
style E fill:#3d3a1a,stroke:#ffa500,color:#e0e0e0
style K fill:#5a1a1a,stroke:#ff6b6b,color:#e0e0e0
style J fill:#3d3a1a,stroke:#ffa500,color:#e0e0e0
style L fill:#2d5a27,stroke:#50c878,color:#e0e0e0 The Six Pruning Checks
| Check | What It Detects | Tier Shield |
|---|---|---|
| Contradictory | Two entries giving conflicting advice for the same handler | All tiers except never-forget |
| Self-evident | Knowledge Claude already knows from training | quick-tip only |
| Unverifiable | References handlers that no longer exist | quick-tip only |
| Duplicate | Overlaps with another entry or seed data | quick-tip only |
| Low-value | Vague, empty, or generic entries | quick-tip only |
| Uncertain | Unclear if it prevents a real mistake | quick-tip only |
Two-Session Grace Period
Nothing is deleted on the first pass. An entry must be flagged in one maintenance run and still flagged in the next before it is removed. If an entry survives re-review, its marks are cleared. This prevents one-time context bias from causing permanent data loss.
Manual Knowledge Management
You can manage the knowledge base directly:
| Action | How |
|---|---|
| Run maintenance manually | /knowledge-maintenance |
| Escalate an entry | Tell Claude: "make [entry name] never-forget" |
| Capture something specific | Tell Claude: "remember that [knowledge]" or "never forget: [knowledge]" |
| Review what maintenance would do | Maintenance defaults to dry-run -- shows proposed actions before executing |
| Reverse a deletion | Check .claude/knowledge-maintenance-log.md for the audit trail and recreate |
| Query knowledge directly | Ask Claude to call get_test_knowledge or get_skill_knowledge |
Skill Knowledge Architecture
AgentUX ships with 85+ skills covering UE editor workflows. Each skill uses a three-layer architecture that separates identity from knowledge:
flowchart TB
subgraph LAYER1["Layer 1: Slim Stubs"]
A["SKILL.md\n60-150 lines each\nIdentity + execution steps"]
end
subgraph LAYER2["Layer 2: Graph Knowledge"]
B["1,400+ SkillKnowledge nodes\nin Neo4j\nPatterns, anti-patterns,\nqueries, escalation rules"]
end
subgraph LAYER3["Layer 3: MCP Query Interface"]
C["get_skill_knowledge tool\nSearch by skill, topic,\nor natural language"]
end
A -->|"Claude triggers\na skill"| C
C -->|"Queries Neo4j\nfor concepts"| B
B -->|"Returns self-contained\nconcept nodes"| C
style LAYER1 fill:#0d1117,stroke:#4a9eff,color:#e0e0e0
style LAYER2 fill:#0d1117,stroke:#50c878,color:#e0e0e0
style LAYER3 fill:#0d1117,stroke:#c77dff,color:#e0e0e0 This design means skills are open-ended knowledge domains with no file size limit. Adding knowledge means adding Neo4j nodes, not editing files. Claude loads only the concepts relevant to the current task, keeping context usage efficient.
If Neo4j is unavailable, skills still provide their identity and execution steps -- Claude falls back to training knowledge for domain concepts.
See also: Hooks & Session Intelligence for hook configuration details, and GraphRAG Guide for the engine knowledge base.