# Context Engineering: How machines remember and forget

Emre Okcular · OpenAI · WeAreDevelopers World Congress NA 2026

> Quản lý context window của agent bằng ba nhóm kỹ thuật: trimming/compaction/summarization, sub-agent, và long-term memory (extract, state, retrieval), đo bằng evals.

Topics: Context Engineering, Agents

Canonical: https://homus.dev/talks/context-engineering-how-machines-remember-and-forget

## 1. Mở đầu: Emre là ai, và vì sao năm nay ai cũng hỏi về memory

MC giới thiệu speaker tiếp theo: Emre, Senior Solutions Architect ở OpenAI, người giúp các doanh nghiệp thiết kế và deploy những hệ thống agentic AI phức tạp. Chủ đề hôm nay là context engineering: máy nhớ thế nào, rồi quên thế nào, và đi vào chi tiết.

Emre tự giới thiệu: anh làm solutions architect ở OpenAI được khoảng một năm rưỡi. Vai trò của anh về cơ bản là giúp doanh nghiệp build các AI use case. Use case gì cũng có: voice agent, long-running agent, document understanding, image generation. Nên anh được làm với rất nhiều loại use case và nhiều model khác nhau để cùng khách hàng build agent. Trước OpenAI, theo trang giới thiệu của sự kiện, anh là Solutions Architect ở Google.

![Emre Okcular trên Stage 1, slide tiêu đề Emre Okcular, Solutions Architect @ OpenAI](https://homus.dev/photos/IMG_3888.JPG)

Emre đứng ở bục Stage 1, màn hình chiếu slide mở đầu "Emre Okcular, Solutions Architect @ OpenAI". Deck mở trong Google Slides với tên file "Agent Memory Systems", đúng trọng tâm của talk: memory của agent.

Hôm nay anh nói về context engineering, với trọng tâm là memory: agent memory, và máy nhớ rồi quên ra sao. Anh đã làm với rất nhiều khách hàng để build AI agent có memory, và theo anh năm nay memory ngày càng quan trọng. Khách hàng hay hỏi: vì sao memory quan trọng, làm sao tạo ra một AI agent "kỳ diệu" thật sự hiểu mình, được personalize cho mình? Talk này gom lại các tips and tricks để trả lời đúng câu hỏi đó.

Agenda rất dày. Anh sẽ nói về các khái niệm của context engineering; rồi các kỹ thuật như reshape and fit, isolate and route; rồi đi vào vài kỹ thuật cụ thể như trimming, compaction và summarization; và cuối cùng là memory evals cùng best practices.

![Slide agenda năm phần](https://homus.dev/photos/IMG_3889.JPG)

Slide agenda có năm phần. 01 Context Engineering: core principles, và các vấn đề context burst, poisoning, noise, conflict. 02 Context Engineering Techniques: reshape + fit, isolate + route, extract + retrieve. 03 Reshape + Fit: áp dụng trimming, compacting, summarization và injection. 04 Conclusion: memory evals và best practices. 05 Q&A.

## 2. Context engineering là gì

Anh nói chắc mọi người đã nghe keyword "context engineering" rất nhiều, nhất là trong năm nay. Định nghĩa của anh: đó là nghệ thuật và khoa học của việc lấp đầy context window bằng **đúng lượng thông tin cần thiết** để AI agent cho ra output tốt nhất.

Lý do nó thành một lĩnh vực: người ta nhận ra nếu không đưa đủ context cho một AI engine thì nhiều khả năng sẽ không có output tốt nhất. Có thể thiếu một mẩu thông tin nào đó, có thể có thông tin mâu thuẫn nhau. Chính nhận thức đó mở ra cả một mảng engineering mới bên trong AI engineering.

Nó là một lĩnh vực đa ngành (multidisciplinary). Trên slide có structured outputs, RAG, state, history, memory và prompt engineering: context engineering là tổ hợp của nhiều kỹ thuật dùng cùng một lúc, chứ không phải một kỹ thuật riêng lẻ.

Định nghĩa của Emre vẽ lại thành sơ đồ: nhiều kỹ thuật (prompt engineering, structured outputs, RAG, state, history, memory) cùng quyết định thứ gì được đưa vào một context window có giới hạn, nhằm cho agent output tốt nhất.

## 3. Core principles và ba chiến lược: reshape, isolate, extract

Có vài core principle. Context engineering quan trọng vì những agent chạy lâu (long-running) và dùng nhiều tool (tool-heavy) sẽ làm context phình ra với rất nhiều token. Chất lượng có thể giảm vì poisoning, noise và confusion (bị đầu độc, bị nhiễu, bị rối).

Để xử lý có ba chiến lược cốt lõi: **reshape and fit**, **isolate and route**, và **extract and retrieve** là nhóm cuối cùng.

Với prompt và tool, việc "dọn dẹp" vẫn quan trọng. Nghĩa là bạn phải đọc lại system prompt của mình, bảo đảm nó gọn (lean), rõ ràng và có cấu trúc tốt. Có thể dùng một bộ nhỏ few-shot examples, và giảm tối đa các tool chồng chéo nhau để agent chọn tool không bị lẫn. Mục tiêu là có tập token nhỏ nhất, đậm đặc nhất, high-signal nhất trong context window, sao cho tối đa hoá khả năng đạt kết quả tốt nhất. Cách diễn đạt này trùng với định nghĩa mà Anthropic dùng trong bài [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) ("the smallest possible set of high-signal tokens").

Nếu bạn là người build AI agent, đây là ba nhóm kỹ thuật có thể áp dụng:

- **Reshape and fit**: nhóm đơn giản nhất, gồm context trimming, context compaction và context summarization.

- **Isolate and route**: đẩy context và tool sang sub-agent.

- **Extract and retrieve**: xoay quanh memory, gồm memory extraction, state management và memory retrieval.

![Slide Context Engineering Techniques với ba cột](https://homus.dev/photos/IMG_3890.JPG)

Slide "Context Engineering Techniques" chia ba cột. Reshape and Fit: Context Trimming, Context Compaction, Context Summarization. Isolate and Route: Context and Tool Offloading to Subagents, kèm chữ nghiêng "selective handoff" (chỉ chuyển giao phần cần thiết). Extract and Retrieve: Memory Extraction, State Management, Memory Retrieval.

Emre xếp hai nhóm đầu vào loại **short-term memory**: mọi thứ bạn làm chỉ nằm trong một session, đóng chat là mất. Còn extract and retrieve thuộc **long-term memory**, tức là cross-session: nếu hôm nay user nói gì đó trong một session, bạn vẫn nhớ được nó ở session ngày mai, tuần sau hay tháng sau.

## 4. Context là tài nguyên hữu hạn: agent quên và agent nhớ

Vậy vấn đề nằm ở đâu? Vì sao LLM có vấn đề với context? Vì context là một **tài nguyên hữu hạn**. Mọi language model hiện nay đều có context window giới hạn: có model 256.000 token, có model 1 triệu, có model 10 triệu token, nhưng chắc chắn là có giới hạn.

Khi model càng mạnh, thách thức thật sự dịch chuyển: từ chuyện viết một prompt hoàn hảo sang chuyện **chọn lọc cẩn thận cái gì nên nằm trong context window**. Làm vậy sẽ giải phóng chỗ trống trong cái context window hữu hạn đó. Và chắc chắn có một "ngân sách" (budget) mà bạn phải cân nhắc: cái này có nên đưa vào context hay không?

### Ví dụ: IT troubleshooting agent

Anh đưa ví dụ memory implementation cho một agent hỗ trợ xử lý sự cố IT điển hình. Bên trái là agent không có memory, không quản lý context. Sau rất nhiều lượt (turn), nó bị lạc: user vẫn nói kiểu "nào, mình sửa lỗi này đi", còn agent trả lời "tôi rất vui được giúp, nhưng tôi không nhớ chúng ta đang làm gì".

Cùng một IT troubleshooting agent sau nhiều turn. Bên trái bị lạc; bên phải nhớ đã giải quyết gì, còn gì, thiết bị nào, và nối tiếp đúng chỗ dở.

Bên phải mới là đích của những người build AI agent. Agent này có memory: sau rất nhiều turn, user hỏi một câu và agent vẫn nhớ cái gì đã giải quyết xong, cái gì còn lại. Nó nói kiểu "mình quay lại phần còn dở lúc nãy nhé; trước đó mình đã bàn về thiết bị của bạn, đó là thiết bị này", rồi dựa trên những gì đã bàn để đi tiếp. Đó là ví dụ rất tốt về một agent "kỳ diệu": thật sự nhớ bạn đang làm gì và thật sự hiểu bạn.

## 5. Bốn failure mode: burst, conflict, poisoning, noise

Sau khi nói về vấn đề, Emre đưa ra các hệ quả của nó, tức là các failure mode. Đây là những thứ anh thấy thường gặp ngoài thực tế khi làm cùng người build AI agent:

- **Context burst**: bạn đột ngột đổ một lượng token rất lớn vào context window.

- **Context conflict**: có thông tin mâu thuẫn nhau trong system prompt, hoặc trong tool.

- **Context poisoning**: có thông tin sai nằm trong context.

- **Context noise**: thêm rất nhiều instruction na ná nhau, có thể là về tool, có thể là trong system instructions.

Cách gọi tên các failure mode này gần với bài [How Long Contexts Fail](https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html) của Drew Breunig (context poisoning, distraction, confusion, clash).

### Context burst

Để minh hoạ, anh đưa một biểu đồ: trục X là số turn đã hoàn thành, trục Y là phần trăm context window đã dùng. Quanh turn 20 có một tool call, và tool call này đổ hàng đống token vào context. Ở các turn sau, agent phải làm việc tiếp với một context đã bị lấp gần kín.

Đường phần trăm context tăng chậm, rồi nhảy vọt tại một tool call quanh turn 20, và agent phải chạy tiếp với context gần đầy.

### Context conflict

Ví dụ về conflict: trong system message bạn viết một instruction rất mạnh, "không bao giờ hoàn tiền nếu tình trạng bảo hành không còn active". Nhưng ở đâu đó trong tool call lại nói "khách VIP được hoàn tiền". Rõ ràng là mâu thuẫn, và agent có thể bị rối. Kết quả là nó trả lời kiểu "vì chuyến đi gấp của bạn, tôi có thể hoàn tiền toàn bộ". Đây là minh hoạ rất rõ cho conflict trong context window.

Ví dụ dưới đây dựng lại theo lời Emre kể, không phải chữ nguyên trên slide:

```
System message: Never issue refunds if warranty status is not active.
Tool output:    VIP customers are eligible for refunds.
Agent:          Given your urgent travel, I can issue a full refund.
```

### Context poisoning

Ví dụ tiếp theo là poisoning. Hãy tưởng tượng có một thông tin sai, hoặc một hallucination, nằm đâu đó trong context. Nếu bạn dùng context summarization, cái sai đó sẽ tiếp tục sống trong context, có thể trong bản summary, có thể ở chỗ khác. Nghĩa là bạn sẽ lan truyền thông tin hallucinate đó sang các turn tiếp theo.

## 6. Nhìn vào context của agent: lifecycle, profile, fixed và variable tokens

Đã nói về vấn đề và các failure mode, giờ Emre chuyển sang giải pháp. Một kỹ thuật quản lý context tốt là gì? Ý tưởng là quản lý context một cách hiệu quả bằng các kỹ thuật đã nêu ở đầu talk. Có thể xem nó là bước tự nhiên tiếp theo sau prompt engineering; anh cho rằng đó là một định nghĩa khá tốt.

### Context lifecycle

Anh đưa một kiểu visualization khác. Theo anh, thật sự không dễ để nhìn thấy chuyện gì đang diễn ra trong context của agent, nên đây có thể là một biểu đồ rất hữu ích để bạn tự vẽ cho agent của mình. Bạn sẽ thấy các phần: instructions, tool definitions, examples, memory, tool results. Khi agent bắt đầu làm việc qua nhiều turn, bạn sẽ thấy từng loại token này tích luỹ dần.

![Slide Context Lifecycle với biểu đồ stacked area](https://homus.dev/photos/IMG_3891.JPG)

Slide "Context Lifecycle": biểu đồ "AI Agent Context Allocation Over Turns (Percent of Context Window)". Trục X là Turns Completed (0 tới khoảng 45), trục Y là phần trăm context window. Các lớp chồng lên nhau từ dưới lên: Instructions, Tool Definitions, Examples (gần như phẳng), rồi Conversation History (phình to nhất), Retrieved Knowledge, Tool Results, Memories, và phần Reserve còn trống. Hai đường chấm ngang ở mức 40% và 80% chính là các ngưỡng kích hoạt Emre nói ở phần reshape and fit.

### Ba profile context của AI agent

Tuỳ bạn build gì và use case là gì, agent có các "profile" context khác nhau:

- **RAG-heavy**: agent làm báo cáo, agent hỏi đáp chính sách. Context chủ yếu là knowledge được retrieve, có thể là file hay PDF.

- **Tool-heavy workflow**: có thể hình dung các ops agent, CRM agent dùng hàng loạt tool khác nhau.

- **Conversational**: gần với lập kế hoạch và coaching. Loại này chủ yếu bị chiếm bởi dialogue history đang lớn dần, tức user message và assistant message cộng lại.

![Slide Context Profiles of AI Agents](https://homus.dev/photos/IMG_3892.JPG)

Slide "Context Profiles of AI Agents". RAG-heavy analyst (reports, policy Q&A): context bị chiếm bởi retrieved knowledge và citations. Tool-heavy workflow (automation/ops agents, CRM): context bị chiếm bởi các tool call dày đặc và payload trả về; càng nhiều loại tool thì càng dễ context confusion. Conversational concierge (planning, coaching): context bị chiếm bởi dialogue history lớn dần; lượng assistant token tăng theo độ dài session, câu hỏi điển hình cần câu trả lời dài.

### Token cố định và token thay đổi

Trong context có loại token bạn điều khiển được và loại gần như không. **Fixed tokens** gồm system instructions, tool definitions và examples: thường là cố định, bạn tune một lần rồi nó luôn nằm đó. Còn phần động là **variable tokens**: tool results, retrieved knowledge, memories và conversation history. Đó là những thành phần thay đổi liên tục trong context window.

Cách chia của Emre: phần cố định tối ưu một lần; phần động mới là chỗ các kỹ thuật reshape, isolate, extract phải xử lý.

## 7. Reshape and fit: trimming, compaction, và khi nào nên kích hoạt

Bắt đầu với kỹ thuật đầu tiên, reshape and fit. Đây là một trong những giải pháp thẳng thắn nhất khi build AI agent.

- **Trimming**: nếu bạn đang tới gần giới hạn context, cứ cắt bớt context. Bỏ các message cũ và tiếp tục với N message gần nhất.

- **Compaction**: bỏ những loại message cụ thể, như tool call và tool call result, rồi tiếp tục với các message assistant và user nằm giữa chúng.

Vẽ lại hai kỹ thuật đầu của reshape and fit theo lời Emre. Kỹ thuật trimming có ví dụ code trong cookbook của chính Emre: [Context Engineering - Short-Term Memory Management with Sessions](https://cookbook.openai.com/examples/agents_sdk/session_memory).

### Heuristic để chọn và để kích hoạt

Muốn quyết định dùng cái nào, anh gợi ý phân tích chính các session của mình:

- Context window điển hình của bạn trông thế nào, kích thước context trung bình tính theo token trong một session.

- Số task trong một session.

- Kích thước token trung bình mỗi turn, để hiểu user đang nói chuyện với agent về cái gì.

Và đừng đợi tới lúc chạm giới hạn context window. Hãy theo dõi mức phân bổ context, đặt trigger ở **40% và 80%** context window, và luôn biết tổng ngân sách context của mình là bao nhiêu. Hai ngưỡng này chính là hai đường chấm ngang trên biểu đồ Context Lifecycle ở phần 6.

## 8. Summarization, và chọn giữa summarization với trimming

Summarization là một kỹ thuật khác. Ý tưởng đơn giản: lấy các turn cũ, đưa cho một LLM khác và bảo "tóm tắt context này đi". Rồi dùng bản summary đó ở turn tiếp theo, và agent tiếp tục làm task.

Anh cũng có một minh hoạ cho kỹ thuật này: sau khi summarize, phần context bị chiếm co lại hẳn trên biểu đồ phân bổ, context còn ít token hơn, và agent tiếp tục làm việc ổn định về sau.

Summarization theo lời Emre. Lưu ý đi kèm từ phần failure mode: một hallucination nằm trong các turn cũ sẽ sống tiếp trong bản summary (context poisoning).

### Summarization hay trimming?

Mỗi cách có ưu và nhược, và phụ thuộc hẳn vào use case. Nếu các phần trong use case của bạn phụ thuộc lẫn nhau, có những thông tin từ các turn trước cần giữ lại trong context, thì dùng summarization hoặc compaction. Còn nếu thật sự không cần các đoạn hội thoại cũ, dùng trimming: nhanh hơn summarization, và không cần gọi thêm một LLM khác để tóm tắt context.

## 9. Isolate and route: đẩy context và tool sang sub-agent

Nhóm thứ hai là isolate and route. Ví dụ: bạn có một agent duy nhất gắn hàng loạt tool, và thấy context ngày càng dài. Một best practice ở đây là dùng **sub-agent** để uỷ thác một phần context đi.

Trên slide có một agent chính, và các sub-agent Order Ops và Refund Policy. Agent chính uỷ thác các subtask này để mỗi sub-agent làm việc trên context riêng của nó. Khi task xong, bạn đưa kết quả của task đã giải quyết đó trở lại agent chính, tức orchestrator agent. Đây là cách rất hay để quản lý context bằng sub-agent.

![Slide Context and Tool Offloading to Subagents](https://homus.dev/photos/IMG_3893.JPG)

Slide "Context and Tool Offloading to Subagents: handing off the context and tools to specialized sub agents that can work with isolated context". Bên trái: một agent duy nhất với một cột message dài (system, user, assistant, tool_call, tool_result lặp đi lặp lại) và năm tool gắn quanh: Billing, Orders, Refund, Logistics, Ticket. Bên phải: agent chính chỉ còn system, user, assistant, user và Billing Tool; Order Ops Agent giữ Orders Tool và Logistics Tool; Refund Policy Agent giữ Ticket Tool và Refund Tool, mỗi sub-agent có system và user riêng.

Ở phía bên phải của slide, bạn thấy agent chính vẫn làm việc tiếp với một context sạch (fresh context). Kiến trúc sub-agent giúp giảm tối đa context conflict và tăng độ tập trung khi reasoning. Trong OpenAI Agents SDK, cơ chế chuyển việc cho agent chuyên trách này có tên là [handoffs](https://openai.github.io/openai-agents-python/handoffs/).

## 10. Extract and retrieve: memory trông như thế nào, và nên nhớ gì

Nhóm cuối cùng của context engineering là extract and retrieve. Trước khi vào kỹ thuật, Emre muốn nói về định nghĩa và "hình dạng" của một memory trong AI agent.

Lấy lại IT troubleshooting agent. Dạng memory đơn giản nhất có thể chỉ là: vấn đề gì, và đã giải quyết chưa, với một flag cơ bản. Rất đơn giản, là các cặp key-value. Phức tạp hơn là một danh sách bullet markdown: với use case đó bạn nhớ sản phẩm, vấn đề, đã thử những gì, các identifier liên quan, và vài milestone của user đó. Đó vẫn là một dạng memory tốt để giải task. Và dạng phức tạp nhất là một đoạn văn, thậm chí nhiều trang markdown. Đó cũng là một dạng memory cho agent, cho bạn nhiều chỗ hơn và dài dòng hơn để theo dõi chuyện gì đang diễn ra.

Ba hình dạng memory Emre nêu cho cùng một IT troubleshooting agent. Lời khuyên: bắt đầu từ trái, chỉ tiến sang phải khi cần.

### Nên nhớ gì

Gợi ý của anh: **bắt đầu đơn giản và phát triển khi cần**. Có thể dùng các format có cấu trúc, như kỹ thuật state management. Và ưu tiên những gì một nhân viên là người thật sẽ tự nhiên nhớ, điểm này rất quan trọng. Hãy nghĩ xem với task của bạn, cái gì quan trọng cần nhớ.

Nếu đang giải quyết sự cố IT, có lẽ bạn nên nhớ thiết bị, firmware, kết nối Internet và các chi tiết kỹ thuật kiểu đó. Nhưng nếu bạn build một AI life coach, bạn có thể nhớ mục tiêu sống của người đó, sở thích, trạng thái cảm xúc. Tuỳ hoàn toàn vào use case mà chọn cái gì quan trọng để nhớ. Hãy tự hỏi: nếu mình là một người thật, mình sẽ nhớ gì về user này, rồi đưa đúng những thứ đó trở lại context.

## 11. Các thao tác trên memory: extraction tool, state object, retrieval

Agent memory có nhiều thao tác khác nhau.

### Memory extraction

Thao tác đầu tiên chắc chắn là memory extraction: bạn cần một cách để rút memory ra từ hội thoại. Một cách là dùng memory extraction tool. Bạn build một tool đơn giản kiểu "save note", và agent tự ghi chú qua các turn, tự quyết cái gì quan trọng cần nhớ dựa trên description của tool.

Ví dụ tool dưới đây dựng lại theo lời Emre kể, không phải chữ nguyên trên slide:

```
Tool: save_memory_note(note)
Description: Save a short note about something important to remember
for this user and this task (device, firmware, what was tried,
what is solved, what remains, milestones).
```

### State object

Kỹ thuật thứ hai là state object. Bạn duy trì một state object đi cùng agent, trong đó có goals, các phase, chi tiết về ticket của khách hàng, ngày, độ ưu tiên và milestones. Bạn theo dõi state object đó, và thêm vào hoặc xoá bớt khỏi nó qua nhiều turn. Emre có một cookbook riêng về cách này: [Context Engineering for Personalization - State Management with Long-Term Memory Notes](https://cookbook.openai.com/examples/agents_sdk/context_personalization).

```
{
"goals": [...],
"phase": "...",
"ticket": { "id": "...", "date": "...", "priority": "..." },
"milestones": [...]
}
```

### Memory retrieval

Retrieval chắc chắn quan trọng. Giả sử bạn đã extract được memory, câu hỏi tiếp là: khi nào và bằng cách nào đưa các memory này trở lại agent? Đây là một cơ chế retrieval điển hình, kiểu RAG: bạn đặt memory vào một long-term store, rồi filter, rank, và inject context đó trở lại context window của agent.

![Slide Memory-as-a-tool: Retrieval](https://homus.dev/photos/IMG_3894.JPG)

Slide "Memory-as-a-tool: Retrieval: enrich each agent turn with the right context before responding". Các bước: user message dẫn tới memory check; retrieve từ Long-Term Store (facts, preferences, logs) và Vector DB (các hội thoại liên quan, examples); filter + rank; inject vào context. Sơ đồ bên phải: User Message Received → Memory Check → (Long-term store, Vector DB) → Filter, Rank, & Inject Context → AI Agent.

## 12. Bài học 1 tới 3: hiểu context, nhớ và quên đúng lúc, memory luôn thay đổi

Để kết, Emre đưa ra bốn bài học quan trọng rút từ deck.

### 1. Hiểu context điển hình của bạn

Hiểu context điển hình của agent và xác định cái gì có ý nghĩa, cái gì quan trọng để agent giải task là điều rất quan trọng. Hãy nghĩ về use case, về việc user đang cố giải quyết gì, và nên nhớ gì về user cụ thể đó; rồi may đo theo use case của mình.

### 2. Quyết định nhớ thế nào, khi nào, và quên khi nào

Khi đã quyết cái gì quan trọng cần nhớ, bạn nghĩ tiếp: khi nào dùng nó? Inject vào mọi session, hay chỉ đưa lại khi cần? Rồi: có nên quên không? Vì theo thời gian bạn sẽ thấy memory tích luỹ dần, và đôi khi cần consolidate. Ví dụ tuần này tôi nói "tôi mê chó", tuần sau tôi nói "tôi thích mèo". Phải có một bước consolidation để quên đi những memory cũ, những memory đã lỗi thời (stale) trong agent.

### 3. Memory thay đổi như trí nhớ con người

Sở thích của chúng ta thay đổi. Hôm nay tôi có thể bảo AI agent "tôi thích so sánh các lựa chọn đặt cạnh nhau", nhưng biết đâu năm sau tôi lại nói "hãy trả lời ngắn gọn thôi". Nghĩa là bạn phải build một hệ thống hiểu rằng preference của user đang thay đổi: quên cái cũ và nhớ cái mới.

Và tất nhiên có khía cạnh tối ưu: làm sao tối ưu memory, gồm các bước distillation (chưng cất), consolidation (hợp nhất) và injection (đưa vào context). Đó là những chiều khác của cùng một bài toán.

Các bước Emre gọi tên khi nói về tối ưu memory, xếp thành một vòng: extract, distill, consolidate, inject, và quên những memory đã stale.

## 13. Bài học 4: evals is still all you need

Cuối cùng là evals: "evals is still all you need". Theo anh, trong AI engineering mọi thứ rốt cuộc đều quay về evals.

Bạn có thể build evals cho chính các kỹ thuật context engineering: chạy bộ core evals của mình, áp dụng một kỹ thuật context engineering, chạy lại, và xem có khác biệt hay không.

Với memory, có thể nghĩ tới các unit eval: đánh giá chất lượng distillation, chất lượng extraction và chất lượng consolidation. Và tất nhiên có thể chạy evals với memory bật và tắt để xem có khác gì không. Có khi bạn không cần memory chút nào: agent vẫn làm tốt, vẫn giải được task. Có khi bạn cần memory chỉ để personalize. Hoặc có khi bạn thật sự cần nó: agent phải nhớ các task trước và các bài học đã rút ra. Tuỳ use case, và evals là cách tốt nhất để biết.

Ba cách dùng evals Emre nêu, vẽ lại thành ba khối.

Anh cảm ơn khán giả đã lắng nghe.

## 14. Hỏi đáp: chi phí sub-agent, prompt summarization, "flexible memory"

MC báo vẫn còn thời gian và có vài câu hỏi gửi lên, nhờ Emre đọc lại rồi trả lời.

### Sub-agent có tốn token hơn agent theo vai trò không?

Câu hỏi: dùng sub-agent có tốn nhiều token hơn so với các agent có vai trò cụ thể không? Emre: tuỳ bạn dùng model nào. Nhiều khả năng bạn sẽ dùng model nhỏ hơn cho sub-agent, nên vẫn tối ưu được, nhưng đó là một trade-off. Sub-agent cho bạn context mới và context tốt hơn, nhưng bạn phải spawn thêm sub-agent; chuyện đó tuỳ use case và tuỳ lựa chọn của bạn. Theo kinh nghiệm của anh, có những use case thấy rõ lợi ích khi dùng kiến trúc sub-agent, dù phải spawn thêm các model nhỏ.

### Khi summarize: để agent tự quyết, hay mình kiểm soát?

Câu hỏi: khi summarize, bạn để agent tự quyết cái gì cần tóm tắt, hay review và kiểm soát quá trình đó? Emre khen câu hỏi hay. Nếu build một bài toán summarization, bạn phải tune prompt summarization lặp đi lặp lại, để agent nhớ đúng thứ quan trọng với use case của mình. Thay vì một câu đơn giản "hãy tóm tắt context", hãy đưa nhiều chi tiết hơn: tóm tắt context, nhưng nhớ rằng với IT troubleshooting thì chi tiết thiết bị là quan trọng; nhớ cái gì đã giải quyết và cái gì chưa; nhớ các milestone. Anh nói tune prompt summarization là một quá trình lặp để tìm ra phiên bản tốt nhất.

Ví dụ prompt dưới đây dựng lại theo lời Emre kể trong phần hỏi đáp, không phải chữ nguyên trên slide:

```
Summarize the conversation so far. Keep in mind:
- Device details are important for IT troubleshooting.
- What has been solved and what is not solved yet.
- Key milestones.
```

### Có khái niệm "flexible memory" không?

Câu hỏi cuối: còn "flexible memory" thì sao, có khái niệm đó không? Emre nói anh không quen với định nghĩa "flexible memory". Nhưng theo anh, một điều cần nhớ là bạn nên để memory tiến hoá, tức là linh hoạt, và để agent tự quyết cái gì cần nhớ và cái gì inject vào context window. Có lẽ đó chính là định nghĩa của khái niệm flexible memory.

MC cảm ơn Emre. Anh nói sẽ còn ở quanh đây, ai muốn thì cứ tới nói chuyện sau talk.

## Nguồn và link

- Trang session chính thức: [Context Engineering: How machines remember and forget](https://www.wearedevelopers.com/world-congress-north-america/agenda/sessions/context-engineering-how-machines-remember-and-forget-1220402) (WeAreDevelopers World Congress NA 2026)

- Emre Okcular, OpenAI Cookbook: [Context Engineering - Short-Term Memory Management with Sessions](https://cookbook.openai.com/examples/agents_sdk/session_memory) (trimming, summarization)

- Emre Okcular, OpenAI Cookbook: [Context Engineering for Personalization - State Management with Long-Term Memory Notes](https://cookbook.openai.com/examples/agents_sdk/context_personalization) (state object, memory notes)

- OpenAI Agents SDK: [Sessions](https://openai.github.io/openai-agents-python/sessions/) · [Handoffs](https://openai.github.io/openai-agents-python/handoffs/)

- Anthropic, [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

- Drew Breunig, [How Long Contexts Fail](https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html)

- Chưa tìm được nguồn: bản slide công khai của talk.