Hola, I’m Hieu, a Software Engineer

Context window của các model đầu bảng giờ là một triệu token. Chừng đó tương đương một codebase cỡ vừa, hoặc vài trăm trang tài liệu, hoặc một buổi chiều rất dài agent gọi tool. Phản ứng hiển nhiên là thôi khỏi nghĩ nên đưa gì vào nữa — nhét hết schema, cả file README, đủ bốn mươi tool, toàn bộ hội thoại, để model tự lọc. Cách đó chạy được cho tới lúc không chạy nữa, và khi hỏng thì nó hỏng rất im lặng. Model không báo lỗi. Nó trả lời, đầy tự tin, dựa trên đúng cái file config sai trong ba file config mâu thuẫn nhau mà bạn vừa dán vào. Latency bò từ bốn giây lên hai mươi giây. Hoá đơn tăng ở mọi lượt gọi chứ không phải một lần, bởi API là stateless và bạn gửi lại toàn bộ ở mỗi lượt. Không dòng log nào ghi “context quá nhiều” — bạn chỉ thấy con trợ lý hơi ngu đi so với tháng trước. Context engineering là kỷ luật quyết định cái gì được chiếm chỗ trong window đó. Nó không phải prompt engineering — chữ nghĩa của prompt chỉ là một phần nhỏ. Nó gần với thiết kế cache hoặc quản lý working...

Có người hỏi làm sao cho agent của họ có bộ nhớ, và câu trả lời rơi xuống như một danh sách mua sắm: một vector database, một bước tóm tắt, một context window to hơn, và nếu cuộc trò chuyện đủ dài thì thêm cả knowledge graph. Tất cả đều là cơ chế có thật. Không cái nào là câu trả lời, vì câu hỏi chưa được tách ra. “Bộ nhớ” đang gọi chung ba bài toán chẳng liên quan gì nhau. Nhớ một sự thật người dùng đã nói — họ deploy từ main , họ ghét emoji trong commit message, database staging của họ là cái ở eu-west-1 . Nhớ một quyết định chính agent đã ra — hồi tháng Ba nó đã bỏ Riverpod ở luồng checkout, và có lý do cho việc đó. Nhớ một việc thường được làm như thế nào — runbook release, năm bước trước khi mở PR, cái thứ về code signing mà lần nào cũng quên. Ba thứ này có hình dạng khác nhau. Một sự thật thì ngắn, ổn định, và chỉ có đúng một đáp án. Một quyết định là một tài liệu nhỏ có ngày tháng và lý do, mà giá trị nằm chủ yếu ở phần lý do. Một quy trình là một danh sách có thứ tự và phả...

The context window on frontier models is now a million tokens. That is roughly a mid-sized codebase, or a few hundred pages of documentation, or a very long afternoon of agent tool calls. The obvious reaction is to stop thinking about what to include and just include everything — dump the schema, the whole README, all forty tools, the full conversation, and let the model sort it out. That works right up until it doesn’t, and when it stops working it does so quietly. The model doesn’t error. It answers, confidently, using the wrong one of the three conflicting config files you pasted. Latency creeps from four seconds to twenty. The bill goes up on every single turn, not once, because the API is stateless and you resend the whole thing each time. Nothing in your logs says “too much context” — you just have an assistant that feels slightly dumber than it did last month. Context engineering is the discipline of deciding what occupies that window. It is not prompt engineering — prompt wo...

Someone asks how to give their agent memory, and the answers arrive as a shopping list: a vector database, a summarisation step, a bigger context window, maybe a knowledge graph if the conversation has gone on long enough. All of these are real mechanisms. None of them is an answer, because the question hasn’t been split yet. “Memory” names three unrelated problems. Recalling a fact the user stated — they deploy from main , they hate emoji in commit messages, their staging database is the one in eu-west-1 . Recalling a decision the agent made — in March it moved checkout state off Riverpod, and there was a reason. Recalling how a task is normally done — the release runbook, the five steps before opening a PR, the thing you always forget about code signing. These have different shapes. A fact is short, stable, and there is exactly one right answer. A decision is a small document with a date and a rationale, and its value is mostly in the rationale. A procedure is an ordered list th...