Vì sao memory pipeline của tôi 4 đêm liền không học được gì — và quyết định 'cho phép sai'

TL;DR

• Sleep-Time Agent của JARVIS chạy 4 đêm liên tiếp, ra proposal đẹp, cost rẻ — nhưng 0 proposal nào được apply.
• Lỗi không nằm ở LLM. Lỗi nằm ở UX khâu approval: tôi phải mở JSON 200KB, đọc 8-12 candidate raw, decide all-or-nothing. Cognitive cost cao nên tôi né luôn 4 đêm.
• Tối nay vừa debug vừa thiết kế lại: chia memory thành 3 tier theo blast radius — memory + lesson auto, wisdom manual.
• Insight rút ra: não người không permissive 100% như tôi tưởng. Nó cũng gating — chỉ là gate đặt ở chỗ khác.

Mở đầu — Telegram báo “REM Sleep FAIL exit=1”

Tối qua tôi nhận Telegram bot: “REM Sleep FAIL exit=1”. Không phải lần đầu — 4 đêm liên tiếp.

Mở terminal, ssh vào VPS production, tail log. Pattern rõ:

[2026-05-06T13:00:02Z] rem_sleep START
ERROR: staging dir not found /opt/aae/JARVIS/workspace/dreams/staging/2026-05-06
[2026-05-06T13:00:03Z] rem_sleep END exit=1

Cron đêm chạy đều. Light Sleep upstream cũng chạy đều. Nhưng input rỗng — Light báo 0 jsonl file(s) to process. Pipeline đẹp nhưng đói.

Lý do: rsync conversation log từ máy chính lên VPS đã chết từ 02/05. Mac launchd không có job nào schedule cái rsync này — thiết kế cũ giả định “tôi sẽ chạy thủ công”. Tôi không chạy thủ công. 4 ngày sau pipeline starve.

Đó là bug đầu tiên. Tôi tưởng fix xong là done. Nhưng đào sâu hơn ra một câu hỏi lớn hơn nhiều.

Câu hỏi thật sự: vì sao 4 đêm 0 proposal apply?

Tôi check lại folder workspace/dreams/proposals/:

2026-05-02-003155-proposal.json   ← run cách đây 4 ngày
applied_proposals.log              ← rỗng

1 proposal duy nhất. Chưa từng apply. Sleep-Time Agent build từ Sprint 3 (02/05) đến giờ chưa promote 1 fact nào vào memory permanent.

Tôi đọc lại workflow đã thiết kế cho mình:

1. Mở file JSON proposal (~200KB).
2. Đọc 8-12 candidate raw.
3. Manually edit JSON, set gate_pass=false cho cái không muốn.
4. Chạy python3 deep_consolidation.py --apply-proposal <path> --execute.
5. All hoặc nothing — không có per-candidate approval.

Đây là UX của 1 dev viết tool cho server, không phải UX cho 1 founder dùng hàng ngày. Tôi viết nó với tư duy “anh approve được mà”. Thực tế thì cứ thấy file 200KB là tôi né. 4 đêm liên tiếp.

Đây không phải bug code. Đây là bug thiết kế tâm lý.

Lần đầu tôi đề xuất “permissive 100% như não người”

JARVIS hỏi tôi muốn fix UX kiểu gì. Tôi vote permissive:

“sao không auto lưu vào brain luôn cho rồi, trong quá trình làm việc, có gì sai thì lại điều chỉnh — giống não người, cứ cho phép được sai, rồi điều chỉnh từ từ”

Logic của tôi: não tôi cũng learn from feedback. Anchor lệch thì conversation sau correct lại. Sai 1 fact thì 1 tuần sau realize — không ai chết.

Em phản biện. Em không mượn cớ “policy nên thế”, em chỉ cho thấy 1 case cụ thể: trong session đó tôi đã vi phạm rule “tên anh là Tiên, không phải Tiến” 2 lần — dù memory đã có rule đó, dù đã được nhắc 100,001 lần.

Bug “anh Tiến” này không phải bug memory. Nó là bug generation. Memory load đúng, nhưng khi sinh token, attention layer pattern-match training data (“Đặng Hồng” → autocomplete “Tiến”) override rule.

Nếu tôi permissive 100%, Deep Sleep extract sai “anh Tiến” và tự ngấm vào memory → reinforcing bias. Sai dội ngược. Tệ hơn nữa.

Đây là moment tôi phải honest với chính mình: não tôi cũng không permissive 100%.

Não người thực ra cũng gating — chỉ ở chỗ khác

Tôi ngồi nghĩ lại. Não tôi:

• Câu chuyện ai mới gặp 5 phút trước → ghi sticky note tạm. Sai thì correction lần gặp sau, không impact gì.
• Worldview “AIC focus 100% 2026” → mất 2 tháng debate với chính tôi + đội ngũ trước khi commit. Sai cái này = strategic mistake năm.
• Tên người yêu, tên con → ngấm vĩnh viễn. Sai = relationship damage không undo được.

Não tôi cũng có 3 tier theo blast radius. Khác AI là tier nào nằm chỗ nào não tự biết — không cần giải thích. AI thì phải phân tier rõ.

Tier-based permissive — quyết định cuối

Tôi và JARVIS chốt 3 tier:

Tier	Auto/Manual	Lý do
memory/<file>.md (per-machine: feedback, project, user, reference)	AUTO	Như sticky note. Per-machine, MEMORY.md index, sai dễ revert. ~80% candidate rơi vào đây.
brain/lessons/<bug>.md (lesson learned)	AUTO nhưng evidence ≥ 5 thay vì 3	Lesson critical. Cần evidence chắc hơn 1 chút.
brain/wisdom/<topic>.md (triết lý, rule lớn)	MANUAL approve y/n từng cái	Sai 1 wisdom = bias toàn bộ tư duy AI. ~15% candidate.

Output policy: velocity 80% với safety 20%.

Implement:

# Chạy mỗi đêm — tự apply 80%
python3 deep_consolidation.py --propose --auto-promote
# Tier-allow default: memory + brain/lessons

# Anh review 20% còn lại
/approve_dream latest
# Interactive y/n từng wisdom candidate, tự commit + push sau approve

Không còn JSON 200KB. Không còn all-or-nothing. Wisdom candidate hiện ra 1 cái 1 lúc, có evidence, có rationale, có scores breakdown. Tôi y/n trong 30 giây.

Đêm nay test thử

Sau khi code xong, tôi run pipeline full 30 ngày window:

• Light Sleep: process 128 staging file (Claude conversation từ April + 6 Gemini Antigravity recovered)
• REM Sleep: 128/128 OK 0 fail, 137K chars output
• Deep Sleep: 8 candidate, 1 gate_pass

1 candidate gate_pass = lesson về AI anchor bias (gravitate về baseline gần nhất thay vì verify current state). Tier brain/lessons → AUTO ngấm. Done.

7 candidate còn lại: gate_pass=false, score 0.50-0.72 (chưa đủ evidence) → Opus tự loại. Không phải tôi review — Opus tự decide thiếu signal.

Wisdom tier: 0 candidate trong batch này. /approve_dream latest báo “0 pending”. Đúng — lý thuyết thì wisdom tier hiếm hơn memory/lesson, đợi tuần sau có thêm signal mới.

Cảm giác sau khi build xong

Khác hẳn 4 đêm trước. Đêm nay tôi commit 3 lần, push 3 lần, đi ngủ với memory đã có 1 lesson mới ngấm. Sáng mai mở Claude, lesson đó tự load vào context — không phải tôi nhắc.

Cảm giác giống như sticky note đã chuyển từ desktop sang muscle memory. Cái nhỏ. Nhưng compound qua tuần qua tháng — đó là cách JARVIS lớn lên thật, không phải qua marathon build mà qua dòng chảy daily ops.

Bài học rút ra

Bottleneck của AI agent không nằm ở LLM. Nằm ở khâu human-in-the-loop.

LLM Opus 4.7 đủ giỏi để extract pattern, score 6-signal, đề xuất 4-action. Cái nó không làm được là decide blast radius — vì nó không biết tier nào trong life của user là per-machine, tier nào là global identity.

Phân tier là việc của user. Một lần. Implement đúng thì 1 năm sau vẫn đúng.

Permissive 100% nghe sexy nhưng không khả thi cho permanent memory. Strict 100% (manual all) nghe an toàn nhưng kết quả là 0 promotion 4 ngày — pipeline chết âm thầm.

Tier-based là middle path. Như não người. Không phải sang khác — đúng cách.

Post draft viết sau marathon đêm 06→07/05. Memory pipeline event-driven shipped, 1 lesson auto-promoted, user guide done. Sáng nay quyết định viết lại quá trình thiết kế tier-based — vì insight này quan trọng hơn code.