1. Thông điệp lớn nhất

Model thông minh chưa đủ. Muốn Agent hoạt động tốt và ngày càng tốt hơn, phải cung cấp đúng Context và xây dựng cơ chế để Agent học từ những lần chạy trước.

Model mới có thể ngày càng thông minh, nhưng bản thân model không tự biết:

• Codebase của tổ chức được tổ chức như thế nào.

• Quy tắc nội bộ là gì.

• User thích cách làm nào.

• Những lỗi Agent đã từng mắc.

• Agent khác đã gặp vấn đề gì.

• Những kiến thức nào đã trở nên lỗi thời.

Vì vậy, Context Engineering là lớp biến "raw intelligence" của model thành intelligence hữu ích trong một môi trường cụ thể.

2. Evolution của Context Engineering

Bài nói mô tả quá trình phát triển trong khoảng 1 năm:

Claude MD → Memory Tools → Skills → File-system Memory → Production Memory → Out-of-band Dreaming

Có thể hiểu như sau:

Model Intelligence
       │
       ▼
Context Engineering
       │
       ├── CLAUDE.md
       │
       ├── Memory
       │
       ├── Skills
       │
       ├── File-system based Memory
       │
       └── Dreaming
              │
              ▼
      Continual Learning

3. CLAUDE.md – đơn giản nhưng rất hiệu quả

Một file Markdown chứa:

• hướng dẫn cho Agent

• cấu trúc codebase

• organization rules

• user preferences

• những điều Agent cần biết

và được đưa vào context ngay từ đầu session.

Ưu điểm

Rất đơn giản nhưng hiệu quả bất ngờ.

Agent có thể nhanh chóng biết:

"Trong project này nên làm như thế nào?"

Vấn đề

Khi file ngày càng lớn:

CLAUDE.md
   ↓
context ngày càng lớn
   ↓
context bloat
   ↓
chi phí + latency + nhiễu

→ Không thể cứ nhét tất cả kiến thức vào context ngay từ đầu.

4. Memory Tools

Bước tiếp theo là cho Agent tự quản lý memory.

Agent có thể quyết định:

• Khi nào đọc memory.

• Khi nào ghi memory.

• Khi nào update memory.

Điểm quan trọng:

Agent autonomy trong việc quản lý memory hoạt động khá tốt.

Thay vì developer phải quyết định mọi thứ, Agent có thể tự nhận ra:

"Thông tin này có giá trị cho lần sau → tôi nên lưu lại."

5. Skills và Progressive Disclosure

Skills giải quyết vấn đề context ngày càng phình to.

Ý tưởng quan trọng là:

Không load toàn bộ knowledge vào context ngay từ đầu. Chỉ load khi cần.

Ví dụ:

Skill
 ├── metadata / description
 │      ↓
 │   Agent biết skill này tồn tại
 │
 └── detailed instructions
        ↓
    chỉ load khi cần

Tác giả dùng analogy:

Bookshelf

Agent có một bookshelf chứa rất nhiều sách.

Khi nói chuyện:

"Ồ, task này liên quan đến tiếng Pháp."

        ↓

thấy French Dictionary

        ↓

lấy sách xuống

        ↓

đọc phần cần thiết

Thay vì ngay từ đầu phải nhét toàn bộ French Dictionary vào context.

Đây chính là:

Progressive Disclosure

Metadata trước → detail sau → chỉ load khi relevant.

6. State-of-the-art Memory: File System

Một insight rất quan trọng của bài:

Đừng quá phức tạp hóa Memory. Hãy model nó giống một File System.

Ví dụ:

/memory
   ├── organization.md
   ├── project.md
   ├── user_preferences.md
   ├── task_history.md
   └── agent_scratchpad.md

Memory có thể đơn giản chỉ là Markdown files.

Agent vốn đã rất giỏi sử dụng:

• bash

• grep

• search

• file operations

→ vậy hãy để Agent search filesystem thay vì phát minh một bộ memory API quá phức tạp.

3 nguyên tắc

1. Markdown tốt cho việc đọc

2. Memory có thể rất lớn

3. Agent cần tool để index/search nhanh phần relevant

Và:

Cho Agent autonomy khi WRITE memory.

7. Nhưng khi lên Production thì mọi thứ phức tạp hơn

Một memory system đơn giản có thể chạy tốt với:

1 Agent
1 session
1 user
1 memory

Nhưng production có thể là:

1000 Agents
     │
     ├── Agent A ──┐
     ├── Agent B ──┤
     ├── Agent C ──┼── Shared Memory
     ├── Agent D ──┤
     └── ... ──────┘

Lúc này xuất hiện nhiều vấn đề:

• Concurrent writes

• Memory corruption

• Sai memory lan truyền toàn hệ thống

• Permission

• Audit

• Stale memory

• Prompt injection vào memory

• Human + Agent cùng sửa memory

• Rollback

8. 4 Production Principles quan trọng

8.1 Versioning

Mọi memory update nên có version.

Ví dụ:

Memory v1
   ↓
Agent update
   ↓
Memory v2

Nếu v2 sai:

rollback → v1

Ngoài ra cần biết:

• Agent nào update?

• Human nào update?

• Session nào tạo ra update?

• Transcript nào dẫn tới update?

Tức là phải có provenance / audit trail.

9. Concurrency

Đây là một phần rất đáng chú ý.

Giả sử:

Agent A đọc Memory v1
Agent B đọc Memory v1

Cả hai cùng sửa.

Nếu không có protection:

A → v2
B → overwrite A → v3

→ mất update của A.

Giải pháp được trình bày là hash-based optimistic concurrency.

Flow:

1. Agent đọc memory
2. Tạo hash H1
3. Agent draft update
4. Trước khi commit → tạo hash H2
5. Compare H1 và H2

Nếu:

H1 == H2

→ memory chưa bị thay đổi → commit được.

Nếu:

H1 != H2

→ có Agent khác sửa trong lúc đó.

→ đọc lại memory → rebase/re-draft → commit lại.

Đây thực chất rất giống tư duy của concurrent software engineering / optimistic locking.

10. Permissioning

Không phải Agent nào cũng được sửa mọi memory.

Ví dụ:

Organization Memory
        │
        ├── READ
        │
        └── WRITE: restricted

Project Memory
        │
        ├── READ
        └── WRITE

Agent Scratchpad
        │
        ├── READ
        └── WRITE

Ví dụ Agent không nên tự ý sửa:

organization-wide-policy.md

nhưng có thể sửa:

agent-scratchpad.md

→ Memory phải có access control.

11. Portability

Memory là tài sản rất quan trọng.

Ví dụ cùng một memory có thể được dùng bởi:

Coding Agent
      │
      ├── IDE
      ├── CLI
      ├── Web
      └── Internal Tool

Vì vậy nên thiết kế:

Memory với clean API + portable architecture

Không nên lock memory vào duy nhất một product surface.

12. Memory mang lại hiệu ứng gì?

Khi Agent nhớ được những gì xảy ra trước đó:

Lần 1

Task
 ↓
Agent mắc lỗi
 ↓
Memory ghi lại

Lần 2

Task
 ↓
Agent đọc memory
 ↓
tránh lỗi cũ
 ↓
kết quả tốt hơn

Do đó:

Accuracy ↑

Đồng thời:

Token ↓

Latency ↓

Cost ↓

Bởi vì Agent không phải lại thử-sai từ đầu.

Đây tạo ra cảm giác:

Agent đang continually learning.

13. Nhưng In-band Memory vẫn có giới hạn

Đây là bước chuyển rất quan trọng của bài.

In-band memory

Agent vừa làm task vừa:

solve task
+
manage memory

Ví dụ:

Agent
 │
 ├── làm task
 │
 └── suy nghĩ:
      "Có nên ghi memory không?"

Vấn đề là Agent đang phải chia resource.

Problem 1 – Competing Resources

Token/capacity phải chia:

Task execution
       vs
Memory curation

Nếu dành quá nhiều cho memory → task chậm.

Nếu không dành đủ → memory kém.

Problem 2 – Limited Visibility

Một Agent chỉ nhìn thấy session của chính nó.

Ví dụ:

Session 1 → lỗi A

Session 2 → lỗi A

Session 3 → lỗi A

Agent ở Session 3 có thể không biết:

"À, lỗi này đã xảy ra 10 lần trước."

Tệ hơn:

Agent A → gặp lỗi X
Agent B → gặp lỗi X
Agent C → gặp lỗi X

Không Agent nào nhìn thấy toàn bộ fleet.

14. Out-of-band Memory

Đây là ý tưởng quan trọng nhất sau Memory.

Thay vì bắt Agent vừa làm task vừa học:

Agent
 ├── Task
 └── Memory

tách thành:

                ┌── Agent Fleet
                │
Task execution ─┤
                │
                └── Memory

                     ↑
                     │
              Out-of-band
                process

Một process riêng chuyên:

quan sát nhiều session → tìm pattern → cải thiện memory

15. Analogy: School

Tác giả dùng analogy rất dễ hiểu:

Students
   ↓
làm bài

Teachers
   ↓
review bài

Head Teacher
   ↓
nhìn toàn bộ học sinh
   ↓
tìm pattern
   ↓
cải thiện curriculum

Mapping sang AI:

Agent Fleet
    ↓
Agent sessions / transcripts

       ↓

Dreaming Agents
    ↓
phân tích toàn fleet

       ↓

Memory Store
    ↓
cải thiện context

16. Dreaming là gì?

Đây là concept nổi bật nhất của bài.

Dreaming = một second-order process chạy asynchronous/batch để cải thiện chính Memory System.

Không phải Agent đang trực tiếp làm task.

Thay vào đó:

Historical Sessions
        +
Current Memory
        ↓
     Dreaming
        ↓
Pattern Detection
        ↓
Proposed Memory Changes
        ↓
Updated Memory

17. Dreaming hoạt động như thế nào?

Ví dụ có:

Memory Store

+
1000 Agent transcripts

+
Tool calls

+
Skills used

+
Metadata

Dreaming Agent phân tích tất cả.

Nó tìm:

Pattern 1

100 agents
↓
cùng mắc lỗi X

→ Memory đang thiếu knowledge X.

Pattern 2

100 agents
↓
tool call Y fail

→ Có thể tool configuration đang sai.

Pattern 3

toàn fleet
↓
cùng vi phạm một organization rule

→ Cần thêm organizational instruction.

18. Dreaming không chỉ nhìn câu trả lời

Điểm này rất quan trọng.

Không chỉ phân tích:

User → Agent
Agent → User

mà còn phải xem:

Tool calls
Skills
Metadata
Failures
Execution patterns

Bởi vì nhiều vấn đề của Agent nằm ở:

tool usage / system configuration

chứ không phải text response.

19. Dreaming tạo ra Proposal chứ không nhất thiết tự commit

Production architecture trong bài:

                    ┌───────────────┐
                    │ Memory Store  │
                    └───────┬───────┘
                            │
                            │
                    ┌───────▼───────┐
                    │   Dreaming    │
                    │   Orchestrator│
                    └───────┬───────┘
                            │
                 ┌──────────┼──────────┐
                 ▼          ▼          ▼
              Agent A    Agent B    Agent C
                 │          │          │
                 └──────────┼──────────┘
                            ▼
                     Pattern Detection
                            │
                            ▼
                    Proposed Changes
                            │
                            ▼
                     Human Review
                       │          │
                    Accept      Reject

Dreaming đưa ra:

• proposed change

• transcript examples

• statistics

• evidence

• reason why update is needed

Sau đó human có thể:

Accept
Reject

20. Memory + Dreaming = Continual Learning Loop

Đây là architecture quan trọng nhất của bài:

                ┌──────────────────┐
                │   Memory Store   │
                └────────┬─────────┘
                         │
                         ▼
                  Agent reads memory
                         │
                         ▼
                    Execute Task
                         │
                         ▼
                    New Session
                         │
                         ▼
                   Write Memory
                         │
                         ▼
                ┌──────────────────┐
                │ Historical Data  │
                │   / Transcripts  │
                └────────┬─────────┘
                         │
                         ▼
                     Dreaming
                         │
                  Find patterns
                         │
                         ▼
                Proposed improvements
                         │
                         ▼
                  Memory Store
                         │
                         └─────────────► next Agent run

Đây chính là continual learning loop ở tầng context, chứ không nhất thiết phải retrain model.

21. Một insight cực kỳ quan trọng: không phải cái gì cũng nên để Agent tự quyết

Ở phần Q&A, speaker nói về một boundary rất quan trọng:

Agent autonomy vs deterministic engineering

Ban đầu:

Agent tự ghi Markdown
Agent tự commit
Agent tự quản lý

Sau khi có đủ experience:

Agent autonomy
      +
Deterministic harness

Những thứ như:

• hashing

• versioning

• concurrency control

• permission

• audit

→ không cần Agent tự "sáng tạo" cách làm.

Nên codify chúng vào infrastructure/harness.

Nói cách khác:

Cho Agent tự quyết ở nơi cần intelligence; dùng deterministic software engineering cho những thứ đã biết rõ.

Đây là một trong những insight kiến trúc đáng chú ý nhất của bài.

22. Tóm tắt toàn bài trong 1 hình

                 ┌─────────────────┐
                 │   Foundation    │
                 │   Model         │
                 └────────┬────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │Context Engineer │
                 └────────┬────────┘
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
     CLAUDE.md         Skills           Memory
          │               │                │
          │         Progressive       File System
          │          Disclosure          based
          │                                │
          └───────────────┬────────────────┘
                          ▼
                    Agent executes
                          │
                          ▼
                     New memories
                          │
                          ▼
                ┌──────────────────┐
                │     Dreaming     │
                │ Out-of-band loop │
                └────────┬─────────┘
                         │
                  Analyze fleet
                         │
                  Find patterns
                         │
                  Propose changes
                         │
                         ▼
                  Memory improves
                         │
                         └──────► Agent improves

23. Những điểm nên "take away" cho AI-DLC / Multi-Agent

Nếu áp dụng bài này vào AI-DLC Multi-Agent, tôi nghĩ có 6 ý đặc biệt quan trọng:

Đặc biệt, Dreaming không nên được hiểu đơn giản là "một Agent khác đọc memory".

Nó là một second-order learning/optimization loop:

Agent làm việc → sinh ra experience → Dreaming phân tích experience → phát hiện pattern → cải thiện memory/context → Agent đời sau làm tốt hơn.

Và đây chính là bước biến hệ thống từ:

Multi-Agent Execution

thành:

Multi-Agent + Continual Context Learning.