Sau vài giờ làm việc liên tục với một AI agent — implement một feature, viết test suite, hay soạn một PRD — context window (bộ nhớ ngữ cảnh) của session đã phình to đến mức mỗi turn tiếp theo đều tốn rất nhiều token, và câu trả lời của model cũng bắt đầu kém chính xác hơn (dấu hiệu điển hình của "context rot" đã đề cập ở các bài trước). Lúc này bạn có hai lựa chọn tồi: tiếp tục nhồi thêm vào một session đã quá tải, hoặc đóng session và mất toàn bộ quyết định, ngữ cảnh đã xây dựng.
Checkpoint (điểm lưu trạng thái) là lối thoát thứ ba. Đây là kỹ thuật viết ra một bản tóm tắt nhỏ gọn, "di động" (portable) về trạng thái hiện tại của session — mục tiêu, quyết định, tiến độ, việc cần làm tiếp — để một session MỚI, với context window sạch, có thể tiếp tục đúng chỗ session cũ dừng lại. Không cần trả lại chi phí token để giải thích lại từ đầu, và không mất đi những ngữ cảnh quan trọng đã tốn công xây dựng.
Bài này sẽ đi vào cách viết một checkpoint có chất lượng, các template cụ thể theo từng vai trò (engineering, QA, product management), cách mở session mới bằng checkpoint, cách tự động hoá việc sinh checkpoint, và những lỗi phổ biến khiến checkpoint mất tác dụng.
Tại Sao Checkpointing Quan Trọng: Vấn Đề Bảo Toàn Trạng Thái
Một session hội thoại dài với AI agent luôn tồn tại một mâu thuẫn cố hữu. Một mặt, session càng dài thì càng chứa nhiều "trạng thái" (state) có giá trị: các quyết định kỹ thuật đã bàn bạc, lý do vì sao chọn phương án A mà không chọn B, tiến độ đã đạt, các artifact (file, đoạn code, bản draft) đã tạo ra. Mặt khác, session càng dài thì context window càng phình to, mỗi turn phải gửi lại toàn bộ lịch sử hội thoại, khiến chi phí token trên mỗi turn tăng dần, và — như đã phân tích ở bài "Managing Conversation Drift" — chất lượng phản hồi của model có xu hướng suy giảm khi context quá tải với thông tin không còn liên quan trực tiếp.
Checkpointing giải quyết mâu thuẫn này bằng một thao tác đơn giản: trích xuất phần trạng thái có giá trị ra một artifact nhỏ, rồi cho phép bạn đóng hoặc reset session cũ một cách an toàn. Bạn không "xóa" công việc đã làm — bạn "nén" nó lại thành vài trăm từ, đủ để một session mới hiểu chính xác bối cảnh mà không cần đọc lại toàn bộ 10.000 token lịch sử hội thoại.
Rủi ro của việc KHÔNG checkpoint thể hiện rõ nhất trong ba tình huống:
- Mất quyết định đã chốt: Bạn và AI agent đã bàn qua ba phương án thiết kế database schema, chốt phương án 2 vì lý do X. Nếu không ghi lại, session tiếp theo (hoặc chính bạn ba ngày sau) có thể đề xuất lại đúng phương án 1 hoặc 3 đã bị loại, vì không ai còn nhớ lý do loại bỏ.
- Phải suy luận lại từ đầu: Không có checkpoint, việc "resume" một session cũ đồng nghĩa với việc đọc lại toàn bộ lịch sử — tốn token, tốn thời gian, và rủi ro hiểu sai vì thông tin bị pha loãng giữa những đoạn không còn liên quan.
- Người khác trong team không thể tiếp tục công việc của bạn: Đây là hệ quả nghiêm trọng nhất ở môi trường làm việc nhóm. Nếu bạn nghỉ phép giữa lúc đang làm một feature với agent, đồng nghiệp không thể "đọc" lại session chat của bạn để hiểu bối cảnh — nhưng họ hoàn toàn có thể đọc một checkpoint 20 dòng và tiếp tục ngay.
Nói ngắn gọn, checkpoint là cách bạn trả phí "ghi trạng thái" một lần với chi phí thấp, để tránh phải trả phí "tái tạo trạng thái" lặp lại nhiều lần với chi phí cao.
Mẹo:
1. Đừng đợi đến khi context window gần đầy mới nghĩ đến checkpoint — hãy checkpoint theo cột mốc công việc (hoàn thành một task con, kết thúc buổi làm việc) chứ không phải theo dung lượng token.
2. Coi checkpoint như một phần bàn giao công việc bắt buộc, giống như viết commit message hay cập nhật ticket — nó là tài sản của team, không chỉ của riêng session.
Cấu Trúc Của Một Checkpoint Hiệu Quả
Một checkpoint tốt không phải là "tóm tắt hội thoại" — nó là một artifact có cấu trúc, được thiết kế để một người (hoặc một AI agent) đọc lần đầu vẫn hiểu được toàn bộ bối cảnh cần thiết để tiếp tục. Có năm thành phần cốt lõi mà một checkpoint hiệu quả cần có.
Component 1: Session Goal and Status
Đây là câu trả lời cho hai câu hỏi: "Session này đặt ra để làm gì?" và "Hiện đã đi được bao xa?". Không cần kể lại toàn bộ hành trình — chỉ cần mục tiêu ban đầu và trạng thái hoàn thành hiện tại, tính theo phần trăm công việc hoặc theo các milestone cụ thể.
Ví dụ ngắn: "Mục tiêu: Implement chức năng export báo cáo PDF cho module Invoice. Trạng thái: Đã hoàn thành backend generate PDF (endpoint /api/invoices/:id/export), đang làm phần frontend trigger download."
Component 2: Key Decisions Made
Đây là thành phần dễ bị bỏ quên nhất nhưng lại quan trọng nhất: không chỉ ghi "đã làm gì" mà phải ghi "tại sao lại làm như vậy". Một quyết định không có lý do đi kèm rất dễ bị người đọc sau (hoặc chính AI agent ở session mới) đặt lại câu hỏi và tranh luận lại từ đầu — gây lãng phí turn và token.
Ví dụ ngắn: "Chọn dùng thư viện pdfkit thay vì puppeteer để generate PDF, vì server không có Chromium runtime và team muốn tránh thêm dependency nặng cho container image."
Component 3: Current State of Artifacts
Thành phần này chỉ cần con trỏ (pointer) tới các output thật — đường dẫn file, tên branch, link Pull Request, link Google Doc, version của draft — không cần dán lại nội dung. Việc dán lại toàn bộ nội dung file hay đoạn code vào checkpoint sẽ làm nó phình to và mất đi lợi ích tối ưu token mà checkpoint mang lại.
Ví dụ ngắn: "Branch: feature/invoice-pdf-export. File chính đã sửa: src/services/pdfExportService.ts, src/routes/invoices.ts. PR draft: #482 (chưa mở review)."
Component 4: Blockers and Open Questions
Đây là những vấn đề chưa giải quyết mà session tiếp theo cần lưu ý hoặc xử lý ngay. Có thể là một câu hỏi cần hỏi Product Owner, một lỗi chưa rõ nguyên nhân, hoặc một dependency đang chờ team khác.
Ví dụ ngắn: "Chưa rõ định dạng số tiền trong PDF nên theo locale nào khi khách hàng ở nhiều quốc gia — cần hỏi PM. Test case export với 0 invoice item đang fail, chưa rõ do logic hay do dữ liệu test."
Component 5: Next Actions
Thành phần biến checkpoint từ một "nhật ký" thành một công cụ có thể hành động ngay. Phải là một hành động cụ thể, đủ rõ để người (hoặc agent) đọc checkpoint biết chính xác việc đầu tiên cần làm, không phải tự suy luận.
Ví dụ ngắn: "Bước tiếp theo: Viết unit test cho hàm formatCurrencyByLocale() trong pdfExportService.ts, sau đó fix lại test case export với 0 invoice item."
Mẹo:
1. Nếu một checkpoint thiếu Component 5 (Next Actions), coi như nó chưa hoàn chỉnh — hãy tự hỏi "nếu tôi đọc dòng cuối cùng này, tôi có biết làm gì tiếp theo không?" trước khi lưu lại.
2. Viết mỗi component ngắn gọn theo dạng bullet, tránh viết văn xuôi dài dòng — checkpoint là tài liệu để scan nhanh, không phải để đọc kỹ từng câu.
Template Checkpoint Theo Vai Trò và Loại Công Việc
Cấu trúc 5 thành phần ở trên là khung sườn chung, nhưng cách trình bày cụ thể nên điều chỉnh theo vai trò và loại công việc — một kỹ sư implement feature quan tâm đến branch và test coverage, một QA quan tâm đến test case và bug, một PM quan tâm đến draft document và feedback stakeholder. Dưới đây là ba template gợi ý, có thể copy và điều chỉnh trực tiếp.
Engineering: Feature Implementation Checkpoint
Dùng khi đang implement một feature hoặc fix một bug lớn, cần lưu lại tiến độ code, quyết định kỹ thuật, và trạng thái branch để session sau (hoặc đồng nghiệp khác) tiếp tục đúng mạch.
## Session Checkpoint — [Tên Feature]
### Goal
[Mục tiêu ban đầu của session, 1-2 câu]
### Completed This Session
- [Việc đã hoàn thành 1]
- [Việc đã hoàn thành 2]
### Remaining Work
- [ ] [Task con còn lại 1]
- [ ] [Task con còn lại 2]
### Technical Decisions
- Decision: [Quyết định] — Rationale: [Lý do vì sao chọn]
- Decision: [Quyết định] — Rationale: [Lý do vì sao chọn]
### Code State
- Branch: [tên branch]
- Files changed: [đường dẫn file 1], [đường dẫn file 2]
- PR/MR: [link nếu có, hoặc "chưa tạo"]
- Test status: [X/Y test pass, test nào còn fail]
### Blockers
- [Blocker hoặc câu hỏi mở, nếu có]
### Start Next Session With
[Hành động cụ thể đầu tiên cần làm]
QA: Test Suite Development Checkpoint
Dùng khi đang xây dựng hoặc mở rộng một bộ test (automation hoặc manual test case), cần lưu lại coverage hiện tại, các quyết định về chiến lược test, và các gap còn tồn đọng.
## Session Checkpoint — Test Suite [Tên Module/Feature]
### Test Coverage Status
- Tổng số test case đã viết: [số lượng]
- Coverage hiện tại: [ví dụ: happy path xong, edge case còn thiếu]
### Test Decisions
- Decision: [Ví dụ: dùng data-driven test thay vì viết case riêng lẻ] — Rationale: [Lý do]
- Decision: [Ví dụ: mock API bên thứ 3 thay vì gọi thật] — Rationale: [Lý do]
### Known Coverage Gaps
- [Chưa có test cho tình huống 1]
- [Chưa có test cho tình huống 2]
### Failing Tests
- [Tên test case] — [Trạng thái/nguyên nhân nghi ngờ, nếu đã biết]
### Artifact Locations
- Test file/suite: [đường dẫn]
- Test plan doc (nếu có): [link]
### Next Session Goal
[Việc cụ thể cần làm đầu tiên, ví dụ: "Viết test case cho luồng thanh toán thất bại do timeout"]
Product Management: PRD/Document Checkpoint
Dùng khi đang soạn hoặc chỉnh sửa một tài liệu dài (PRD, spec, roadmap), qua nhiều vòng feedback từ stakeholder, cần lưu lại trạng thái draft và các quyết định đã thống nhất để tránh bàn lại từ đầu.
## Session Checkpoint — [Tên Document]
### Document Status
[Draft đang ở version/section nào, phần trăm hoàn thành ước tính]
### Key Decisions Made
- Decision: [Quyết định về scope/tính năng] — Rationale: [Lý do, ai đề xuất]
- Decision: [Quyết định về scope/tính năng] — Rationale: [Lý do, ai đề xuất]
### Stakeholder Input Incorporated
- [Feedback từ ai] → [Đã cập nhật vào phần nào của document]
### Open Items
- [Câu hỏi/vấn đề chưa chốt, cần ai trả lời]
### Current Draft Location
[Link Google Doc/Notion/file, kèm version hoặc timestamp cập nhật cuối]
### Next Session Goal
[Việc cụ thể cần làm đầu tiên, ví dụ: "Viết phần Success Metrics dựa trên số liệu đã thống nhất với Data team"]
Mẹo:
1. Không cần cứng nhắc theo đúng field label trong template — hãy tùy biến theo đặc thù công việc, miễn giữ đủ 5 thành phần cốt lõi (goal, decisions, artifacts, blockers, next action).
2. Nếu một task vừa mang tính engineering vừa mang tính QA (ví dụ: vừa code vừa viết test), có thể kết hợp hai template — nhưng vẫn giữ mỗi phần ngắn gọn để tránh checkpoint quá dài.
Checkpoint Như Một Prompt Mở Đầu Session
Giá trị thật sự của checkpoint chỉ hiện rõ khi bạn dùng nó để mở một session mới. Đây là lúc bạn "trả" chi phí token đã tiết kiệm được thành hiệu quả thực tế: thay vì phải giải thích lại từ đầu, bạn chỉ cần dán checkpoint và ra lệnh tiếp tục.
Mở một session mới bằng checkpoint
Cách làm đơn giản nhất là dán toàn bộ nội dung checkpoint làm message đầu tiên của session mới, kèm theo một chỉ dẫn rõ ràng về việc bạn muốn AI agent làm gì với nó — không nên chỉ dán checkpoint rồi im lặng, vì model có thể hiểu sai là bạn muốn nó "tóm tắt lại" thay vì "tiếp tục làm".
Ví dụ prompt mở session:
Đây là checkpoint từ session làm việc trước của chúng ta:
[dán toàn bộ nội dung checkpoint vào đây]
Hãy tiếp tục công việc bắt đầu từ mục "Start Next Session With" / "Next Session Goal".
Trước khi bắt đầu code, hãy đọc lại 2 file đã liệt kê trong "Code State" để nắm
đúng trạng thái hiện tại của code, rồi tóm tắt ngắn gọn lại cho tôi những gì
bạn hiểu về nhiệm vụ trước khi thực hiện.
Xác thực checkpoint khi mở session
Một kỹ thuật rất rẻ nhưng hiệu quả cao: trước khi cho AI agent bắt tay vào việc, hãy yêu cầu nó diễn giải lại (restate) sự hiểu của nó về checkpoint. Đây chỉ là một turn ngắn, tốn rất ít token, nhưng giúp phát hiện sớm những hiểu sai — ví dụ model hiểu nhầm "Blockers" thành việc đã xử lý xong, hoặc bỏ sót một quyết định quan trọng trong "Key Decisions".
Ví dụ prompt xác thực:
Trước khi bắt đầu, hãy tóm tắt lại bằng lời của bạn:
1. Mục tiêu tổng thể của task này là gì?
2. Có những quyết định kỹ thuật/nghiệp vụ nào đã được chốt mà bạn sẽ KHÔNG đề xuất lại?
3. Việc đầu tiên bạn sẽ làm là gì?
Nếu có phần nào trong checkpoint không rõ hoặc mâu thuẫn, hãy hỏi tôi ngay,
đừng tự suy diễn.
Nếu câu trả lời cho thấy model hiểu sai — ví dụ nó định đề xuất lại một phương án đã bị loại ở "Key Decisions" — bạn chỉ cần sửa ngay trong 1-2 turn, rẻ hơn rất nhiều so với việc phát hiện sai lầm này sau khi đã đi được nửa chừng công việc.
Mẹo:
1. Luôn thực hiện bước "xác thực" này với các task phức tạp hoặc nhiều người tham gia — chi phí một turn xác thực luôn thấp hơn nhiều so với chi phí sửa sai giữa đường.
2. Nếu checkpoint được viết bởi người khác trong team, bước xác thực còn giúp bạn (người đọc) tự kiểm tra lại hiểu của chính mình, không chỉ của AI agent.
Tự Động Hóa Checkpointing: Prompt Sinh Checkpoint
Viết checkpoint bằng tay mỗi lần kết thúc session tốn thời gian và dễ bỏ sót thành phần. Cách hiệu quả hơn là để chính AI agent tự sinh checkpoint dựa trên toàn bộ lịch sử hội thoại — nó đã "biết" hết những gì đã diễn ra, chỉ cần một prompt tốt để trích xuất đúng cấu trúc.
Prompt sinh checkpoint cuối session
Đây là một prompt template chi tiết, có thể dùng lại (reusable) ở cuối bất kỳ session nào, yêu cầu model tự tạo checkpoint theo đúng 5 thành phần đã trình bày ở trên:
Session làm việc của chúng ta sắp kết thúc. Hãy tạo một checkpoint đầy đủ để
tôi dùng mở một session mới, theo đúng cấu trúc sau:
## Session Checkpoint — [tự đặt tên phù hợp với công việc]
### Goal and Status
- Mục tiêu ban đầu của session là gì, và hiện đã hoàn thành bao nhiêu phần trăm/milestone.
### Key Decisions
- Liệt kê MỌI quyết định quan trọng đã được chốt trong session (kỹ thuật, nghiệp vụ,
thiết kế), kèm lý do (rationale) ngắn gọn cho từng quyết định. Không chỉ ghi
"đã làm gì" mà phải ghi rõ "tại sao".
### Artifacts
- Liệt kê CON TRỎ tới các file, branch, PR, link document đã tạo/sửa trong session.
KHÔNG dán lại nội dung của các artifact này, chỉ dán đường dẫn/tên/link.
### Blockers and Open Questions
- Liệt kê các vấn đề chưa giải quyết, câu hỏi cần ai đó trả lời, hoặc rủi ro
cần lưu ý ở session sau.
### Next Actions
- Việc CỤ THỂ, có thể bắt tay làm ngay, là bước đầu tiên của session tiếp theo.
Không viết mơ hồ như "tiếp tục phát triển feature" — hãy nêu rõ hành động,
file, hoặc test case cụ thể.
Giữ toàn bộ checkpoint dưới 300 từ. Ưu tiên bullet point ngắn gọn, tránh
viết lại chi tiết những gì đã có sẵn trong code/document — chỉ tóm tắt trạng
thái và quyết định.
Giới hạn độ dài (ví dụ "dưới 300 từ") trong prompt rất quan trọng — nó buộc model phải chọn lọc thông tin thật sự cần thiết, tránh sinh ra một checkpoint dài dòng mất tác dụng.
Cập nhật checkpoint theo kiểu tăng dần
Nếu một task kéo dài qua nhiều session (ví dụ một feature lớn mất 4-5 buổi làm việc), việc sinh lại toàn bộ checkpoint từ đầu mỗi lần sẽ vừa tốn token vừa dễ làm mất các quyết định cũ nếu model không nhớ hết. Kỹ thuật hiệu quả hơn là cập nhật tăng dần (incremental update): giữ checkpoint cũ làm gốc, chỉ yêu cầu model bổ sung/sửa những phần đã thay đổi.
Ví dụ prompt cập nhật tăng dần:
Đây là checkpoint hiện tại của task này:
[dán checkpoint cũ]
Trong session vừa rồi, chúng ta đã:
- [liệt kê ngắn gọn việc mới làm]
Hãy CẬP NHẬT checkpoint trên (không viết lại từ đầu):
- Di chuyển các mục ở "Remaining Work" đã hoàn thành sang "Completed"
- Thêm các quyết định mới (nếu có) vào "Technical Decisions", giữ nguyên
các quyết định cũ
- Cập nhật lại "Code State" nếu branch/file đã thay đổi
- Viết lại "Start Next Session With" cho phù hợp với tiến độ mới
Giữ nguyên format và độ dài tương đương checkpoint cũ, không phình to thêm.
Cách này giữ checkpoint luôn ở trạng thái "rẻ" để duy trì — chi phí cập nhật chỉ tỉ lệ với phần thay đổi, không tỉ lệ với toàn bộ lịch sử công việc.
Mẹo:
1. Lưu prompt sinh checkpoint này thành một snippet/prompt template dùng lại được (trong Notion, trong file .md riêng, hay trong tính năng "saved prompt" của tool bạn dùng) để không phải soạn lại mỗi lần.
2. Với các task dài nhiều ngày, đặt lịch checkpoint theo cuối mỗi buổi làm việc (end-of-day) chứ không chỉ khi kết thúc hẳn task — điều này giúp checkpoint luôn phản ánh trạng thái mới nhất.
Độ Chính Xác Của Checkpoint: Các Lỗi Thường Gặp và Cách Tránh
Một checkpoint viết sai cách có thể còn tệ hơn không có checkpoint — vì nó tạo cảm giác an toàn giả, khiến người đọc tin rằng mình đã nắm đủ bối cảnh trong khi thực tế thì không. Dưới đây là bốn lỗi phổ biến nhất.
Lỗi 1: Chỉ ghi kết quả, không ghi quyết định
Ví dụ checkpoint sai: "Đã đổi cách xử lý authentication từ session-based sang JWT." — Câu này chỉ nói "đã làm gì", không nói "tại sao". Session sau đọc được câu này rất dễ đặt lại câu hỏi "sao không dùng session-based nữa?", dẫn đến việc tranh luận lại một vấn đề đã được giải quyết, tốn turn và token vô ích, thậm chí có rủi ro đảo ngược một quyết định đúng vì không ai còn nhớ lý do ban đầu.
Cách sửa: Luôn viết theo cặp "quyết định — lý do". Ví dụ: "Đổi từ session-based sang JWT vì hệ thống sẽ scale ra nhiều server không dùng sticky session, và team frontend cần token để gọi trực tiếp API mobile."
Lỗi 2: Checkpoint quá chi tiết
Một checkpoint dán lại toàn bộ đoạn code, toàn bộ nội dung file, hoặc kể lại từng bước nhỏ nhặt đã làm sẽ tự đánh mất chính mục đích của nó — nó trở thành một bản sao thu nhỏ của cả session, vẫn tốn nhiều token để đọc và xử lý ở session mới. Ví dụ sai: dán nguyên 200 dòng code của file pdfExportService.ts vào phần "Code State" thay vì chỉ ghi tên file.
Cách sửa: Checkpoint chỉ nên chứa con trỏ tới artifact (đường dẫn, tên branch, link), không chứa nội dung của artifact. Nếu cần, session mới có thể tự đọc file thật khi cần — đó rẻ hơn nhiều so với việc luôn phải mang theo bản sao trong checkpoint. Giữ giới hạn độ dài (ví dụ 300 từ như prompt mẫu ở trên) là cách kiểm soát thực tế nhất.
Lỗi 3: Tham chiếu artifact đã lỗi thời
Checkpoint viết cách đây một tuần có thể trỏ tới một branch đã bị merge và xóa, một link Google Doc đã đổi quyền truy cập, hoặc một file đã được refactor sang tên khác. Nếu session mới tin tưởng tuyệt đối vào các tham chiếu này mà không kiểm tra, nó có thể lãng phí nhiều turn để tìm một thứ không còn tồn tại, hoặc tệ hơn — vô tình làm việc trên nhánh/tài liệu sai.
Cách sửa: Khi mở session mới bằng checkpoint cũ (đặc biệt nếu checkpoint đã để lâu hơn vài ngày), hãy yêu cầu model xác nhận lại các artifact còn tồn tại và còn đúng trước khi bắt tay vào việc — ví dụ: "Trước khi tiếp tục, hãy kiểm tra branch feature/invoice-pdf-export còn tồn tại và các file được liệt kê còn đúng đường dẫn." Đây chính là một phần của bước "xác thực checkpoint" đã nói ở phần trước.
Lỗi 4: Không có "hành động tiếp theo" rõ ràng
Nhiều checkpoint chỉ dừng ở việc mô tả trạng thái ("đã làm A, B, C, còn D, E chưa làm") mà không chỉ ra việc nào cần làm TRƯỚC. Đây thực chất chỉ là một bản nhật ký (log) trạng thái, không phải một checkpoint có thể hành động ngay. Hậu quả là session tiếp theo phải tốn thêm 1-2 turn chỉ để tự quyết định "vậy giờ nên bắt đầu từ đâu" — một chi phí nhỏ nhưng lặp lại nhiều lần sẽ cộng dồn đáng kể, và tệ hơn, các session/người khác nhau có thể chọn điểm bắt đầu khác nhau, gây thiếu nhất quán trong cách tiếp cận.
Cách sửa: Luôn kết checkpoint bằng một mục "Next Actions" / "Start Next Session With" nêu rõ MỘT hành động cụ thể, đủ chi tiết để bắt tay làm ngay không cần suy nghĩ thêm — ví dụ không viết "tiếp tục viết test" mà viết "viết test case cho hàm formatCurrencyByLocale() với input là locale vi-VN và en-US".
Mẹo:
1. Trước khi lưu bất kỳ checkpoint nào, tự rà lại bằng "checklist 4 lỗi" ở trên — chỉ mất 30 giây nhưng loại bỏ được phần lớn checkpoint kém chất lượng.
2. Nếu checkpoint được AI agent tự sinh, hãy đọc lại một lần trước khi lưu — đừng mặc định model luôn tuân thủ đúng cấu trúc 5 thành phần, đặc biệt là phần "lý do" của các quyết định, vì model có xu hướng tóm tắt kết quả dễ hơn là truy xuất lại lý do đã bàn luận trước đó trong hội thoại.