# The Agentic AI Engineer

Benedikt Sanftl & Burak Cemil Özafşar · Mutagent · AI Engineer World's Fair 2026: Online Track

> Chạy vòng đời agent như một loop agentic: spec, build, eval-driven development, diagnose trace production thành eval mới, và demo diagnostics agent.

Topics: Agents, Workflow, Coding Agents

Canonical: https://homus.dev/talks/the-agentic-ai-engineer

## 1. Hai vòng lặp: offline và online

Talk mở đầu bằng lời chào của Bene (Benedikt Sanftl), CEO và co-founder của Mutagent. Anh đi cùng đồng nghiệp là Burak (Burak Cemil Özafşar), CTO của Mutagent. Chủ đề hôm nay, theo lời Burak, là "loops" và cách một Agentic AI Engineer vận hành.

Bene đặt bối cảnh: như mọi người đều biết lúc này, loop đang là chủ đề nóng nhất trong cách build phần mềm, tức là build phần mềm bên trong một agentic loop. Điều Mutagent làm là áp đúng loop đó, nhưng không phải cho việc viết code thông thường, mà cho việc build chính các AI agent.

Trong loop này có hai khái niệm, và Bene tách chúng ra rất rõ:

- **Offline loop**: trong lúc build, bạn iterate trên agent của mình. Bạn test nó, evaluate nó, cải thiện nó, rồi lặp lại tiếp.

- **Online loop**: khi agent đã được deploy lên production, bạn monitor các trace của nó, diagnose những gì đang hỏng, rồi đưa kết quả đó ngược vào vòng optimization. Nhờ vậy bạn iterate tiếp và có được nhiều version liên tiếp của agent.

![Slide mở đầu The Agentic AI Engineer, hai speaker ở góc dưới](https://homus.dev/photos/pSto5YaNGUo-0000.jpg)

Slide mở đầu: "The Agentic AI Engineer", với dòng phụ nói rằng một AI agent không bao giờ "xong", nó sống trong một development loop, và tốc độ của loop đó mới là cả cuộc chơi. Bene (trái) và Burak (phải) xuất hiện ở góc dưới.

![Slide The Loop: vòng tròn bảy stage, nửa offline và nửa online](https://homus.dev/photos/pSto5YaNGUo-0024.jpg)

Slide "An agent is never done. It lives in a loop.": một vòng tròn với bảy stage Conceptualize, Build, Evaluate, Deploy, Monitor, Diagnose, Optimize. Nửa màu xanh là phần offline (build và mài sắc agent), nửa màu tím là phần online (agent chạy thật, thực tế nuôi vòng kế tiếp). Ở giữa: "one loop, offline build, online learn".

## 2. Vòng lặp làm bằng tay quá chậm, và chuyện throughput

Bene kể lại cách mọi người, kể cả chính họ, đã làm cho tới giờ: chạy loop này bằng tay. Và nó khá chậm. Vòng đời của một lần thay đổi thường trông như thế này:

- Bạn có một issue, hoặc bạn muốn thay đổi điều gì đó trong agent.

- Bạn implement thay đổi đó. Có thể bạn "vibe implement" nó nếu bạn dùng coding agent để làm.

- Bạn tạo vài sample cho feature mới hoặc issue này để test.

- Bạn nhìn kết quả, đọc qua các trace, xem outcome trông ra sao.

- Rồi có thể bạn ship nó, chạy A/B testing, và mọi feedback gần như đều thu thập thủ công.

Toàn bộ quá trình mất rất lâu. Bottleneck rốt cuộc là con người: thời gian con người review và thời gian con người build. Cách này không scale được, nhất là khi tổ chức của bạn đang lên kế hoạch roll out hàng trăm agent. Đó là lý do, theo Bene, nhóm của anh tin rằng Agentic AI Engineer là bước tiếp theo tự nhiên trong cách build agent. Anh nhường lời cho Burak để đi sâu vào cách họ rút ngắn thời gian và con đường tới production reliability với Agentic AI Engineer.

Burak nói điểm mấu chốt ở đây: một khi bạn chạm tới một số lượng agent hoặc AI feature nhất định, con người thực hiện loop này không thể scale kịp trong khoảng thời gian có được. Vì vậy, chạy loop theo kiểu agentic là chìa khoá để tăng throughput, vì khi đó bạn nhét được nhiều cycle hơn hẳn vào cùng một khung thời gian.

![Slide Throughput: lưới ô vuông so sánh 12 cycle của người với 242 cycle của agent](https://homus.dev/photos/pSto5YaNGUo-0216.jpg)

Slide "It's throughput, how many cycles fit the same window.": mỗi ô vuông là một development cycle. Hàng trên là con người (vài tuần mỗi cycle), lưới gần như trống, chỉ 12 cycle. Hàng dưới là agent (vài phút mỗi cycle), cùng khung thời gian nhưng lưới kín màu với 242 cycle, và mỗi cycle có thể làm agent tốt hơn một chút. Dòng cuối slide kết luận throughput chính là "moat".

## 3. Bảy stage của vòng đời một agent

Burak giải thích loop vận hành qua một số stage. Phần anh mô tả trước là trường hợp bạn bắt đầu từ con số không.

**Spec.** Giống thực hành phát triển phần mềm hiện nay, việc đầu tiên là tạo một spec cho agent, hoặc cho skill trong trường hợp này. Ở đây bạn phải định nghĩa mọi trách nhiệm và chức năng mà agent cần xử lý, và cả các quyết định nó phải đưa ra trong những điều kiện nhất định. Burak nhấn mạnh: đây mới chỉ là stage định nghĩa.

**Build.** Khi đã định nghĩa xong yêu cầu của agent, bạn mới chuyển sang build. Build là lúc bạn hiện thực hoá spec đó trong một harness hoặc agent framework cụ thể, hoặc ngày nay bạn còn có thể build nó thành một agent của Claude Code hay Codex.

**Evaluate.** Bước tiếp theo là định nghĩa những evaluation rõ ràng để đo hiệu năng của agent. Đây là các metric then chốt cho phép bạn nói: "Agent của tôi hoạt động hay không." Burak so sánh nó với unit test trong lập trình: đây là cách bạn verify rằng agent của mình chạy đúng.

**Ship.** Sau evaluation, nếu mọi thứ ổn, thường bạn có bước ship, tức là deploy agent lên production. Việc này có thể là một bản cập nhật code, có thể là cập nhật trực tiếp trên một agent platform nào đó, hoặc lại là các agent chạy trong harness local của bạn.

**Monitor.** Rồi tới phần online. Agent được monitor liên tục để phát hiện vấn đề, và dựa trên một số điều kiện trigger, bạn có thể khởi động chẩn đoán tự động. Điều kiện đó có thể dựa trên lượng trace mà agent tạo ra, hoặc là các job chạy hằng tuần hay hằng ngày.

**Diagnose.** Tiếp theo là stage diagnosis. Đây là nơi bạn gom mọi failure của agent và làm root cause analysis có cấu trúc để hiểu các failure đến từ đâu.

**Optimize.** Khi đã hiểu và phân loại xong các failure, bạn mới đi tới stage optimization. Ở đây bạn tạo ra những thay đổi, hay "mutation", rất cụ thể cho agent để xử lý các failure mode vừa tìm được. Rồi cả chu kỳ lặp lại: bạn evaluate, và nếu mọi thứ ổn thì deploy lần nữa. Burak hứa sẽ đi sâu vào từng stage ngay sau đó.

![Slide The Machine: sơ đồ toàn bộ vòng đời phát triển AI agent từ nguồn việc tới production](https://homus.dev/photos/pSto5YaNGUo-0304.jpg)

Slide "The AI Engineer, the whole AI agent development lifecycle.": một orchestrator chạy mọi stage từ đầu tới cuối. Việc vào từ bên trái (Cold start: feature hoặc intent mới; Existing feature: bug, incident hoặc enhancement), đi qua chuỗi spec, build, eval, ship, monitor, diagnose, optimize, và đầu ra ở bên phải là code PR, agent update hoặc skill update. Các mũi tên vòng ngược cho thấy bug hay incident được đưa vào diagnose, live events và trace quay về monitor, còn variant mới được re-evaluate.

## 4. Cold start hay feature đã có, và vai trò của spec

Trước khi đi tiếp, Bene hỏi Burak dành nửa phút cho một điểm: trên sơ đồ có hai con đường, một là cold start, một là feature đã có sẵn. Khác nhau ở đâu, và vì sao điều đó quan trọng?

Burak trả lời: hôm nay, nếu bạn ngồi xuống để build một agent thì có hai lựa chọn. Một là bạn đã có agent, nó đã được build, đang chạy ở đâu đó với một độ chính xác nhất định. Hai là bạn tạo agent từ đầu. Khi tạo từ đầu, hiển nhiên bạn thiết kế bắt đầu từ spec và stage conceptualization. Còn nếu là feature đã có, rất có thể agent đã ở đó rồi, và việc của bạn là optimize trên một thứ đang tồn tại.

Hai lối vào cùng một loop: cold start đi từ spec, còn một agent đang chạy thì đi thẳng vào diagnose và optimize. Cả hai cuối cùng đều phải qua cùng một eval suite.

Bene đề nghị đi sâu vào từng phase, bắt đầu với chuyện viết spec cho một agent mới, vì nó có vẻ là một artifact quan trọng.

Burak đồng ý. Với spec-driven development, vốn cũng đang phổ biến khi build các artifact phần mềm ngày nay hay trong mọi workflow dùng coding agent, mục tiêu là nắm được các yêu cầu cho agent, và đặc biệt là **success criteria**. Lý do: ngoài coding agent ra, các agent ở những lĩnh vực khác xử lý những quy trình cụ thể, và quy trình đó khác nhau giữa công ty này với công ty kia. Nó rất chuyên biệt theo môi trường nơi agent sống.

Vì vậy điểm then chốt của spec là định nghĩa rõ:

- những yêu cầu về context mà agent có;

- những integration và tool mà nó cần;

- các jobs to be done, tức các trách nhiệm agent sẽ đảm nhận, và cả những gì nó sẽ không làm;

- cuối cùng là các constraint, và nói chung là ranh giới của agent.

Một khi đã có spec rõ ràng, nó trở thành bản blueprint cho mọi phát triển về sau, và mọi implementation đều được đối chiếu với nó.

## 5. Build: coding agent sinh ra agent, platform phải đổi được

Bene chuyển sang câu hỏi: vậy build một agent từ spec ra sao?

Burak giải thích: spec cho coding agent của bạn biết phải build cái gì, còn việc chọn target platform hoàn toàn là của bạn. Lý do là không gian agent đang thay đổi rất nhanh. Framework bạn dùng hôm nay, có thể một năm nữa bạn sẽ muốn đổi. Chính vì thế spec được tách biệt khỏi chi tiết implementation. Khi quyết định build, bạn chọn target nào cũng được. Coding agent mà bạn chọn sẽ lấy spec đó và đưa cho bạn một version đầu tiên của agent, được tuỳ biến để chạy trên bất kỳ platform nào bạn thấy phù hợp.

![Slide Phase 2 Build: spec đi qua coding agent thành agent v1, chạy trên mọi harness](https://homus.dev/photos/pSto5YaNGUo-0856.jpg)

Slide "Phase 2, Build: Your coding agent generates the agent.": spec đã được duyệt điều khiển một coding agent (Claude Code, Codex, Cursor, Pi, Hermes, cái nào bạn dùng cũng được) để viết ra agent v1. Kết quả là portable: cùng một agent chạy được trên mọi harness, local trong coding agent của bạn hoặc trên cloud được quản lý như Vercel, Mastra, Claude Agents, DeepAgents.

Bene hỏi tiếp: tại sao tôi lại muốn đổi platform một năm sau? Kinh nghiệm của các anh dạy điều gì?

Burak kể từ chính ba năm build agent của mình: đôi khi agent framework hay harness không phải lúc nào cũng có đủ khả năng cần thiết. Thỉnh thoảng bạn đụng phải một bottleneck hay một rào cản, và khi đó bạn phải trông vào framework bên dưới để gỡ nó, việc này có khi mất khá lâu. Điểm mấu chốt là giữ sự linh hoạt, vì về bản chất bạn muốn chọn harness hay framework tốt nhất, cái đáp ứng được yêu cầu của bạn.

Bene bổ sung bằng chuyện ai cũng thấy trong mấy tháng gần đây: những harness mới liên tục ra mắt, và mọi thứ chuyển từ kiểu agent được build trong code sang kiểu agent được định nghĩa như một agent loop runtime. Anh nhắc tới [Hermes](https://github.com/NousResearch/hermes-agent) đang nổi lên, rồi [Deep Agents](https://github.com/langchain-ai/deepagents), và tất cả các framework kiểu này.

## 6. Eval-driven development: eval suite là sản phẩm của discovery

"Được rồi, đi tiếp. Sau build thì chuyện gì xảy ra?", Bene hỏi.

Burak gọi phase này là **eval-driven development loop**. Nó tương đương với test-driven development khi build phần mềm bằng agent, vì agent cần một **termination condition**. Nói cách khác: khi nào thì một AI feature hay một agent là "đủ tốt"?

Eval suite gồm hai phần: các eval (tức metric và criteria bạn dùng để đánh giá) và chính các dataset, thường chứa những case mà agent phải thoả mãn. Theo Burak, có hai cách để tạo eval suite:

- Cách thứ nhất, cách nguyên bản: ngồi cùng các domain expert và cố viết ra các eval metric và criteria bao phủ feature hay agent bạn muốn build. Nhưng hầu hết các team đã làm việc này đều biết là khá khó: bạn không thể đoán trước toàn bộ eval suite ngay từ đầu.

- Cách thứ hai: bạn luôn có thể bắt đầu bằng dữ liệu lịch sử, hoặc dữ liệu tổng hợp từ một mẫu dữ liệu đã biết mà bạn muốn agent được test trên đó.

Nhưng về bản chất, theo Burak, một eval suite thật sự và đầy đủ là **sản phẩm của discovery**. Nghĩa là theo thời gian, từ feedback của user và từ các failure trên production, bạn gom thêm metric và criteria, cùng các case mới cho dataset. Những case này thường đại diện cho edge case, hay những case khó mà agent buộc phải xử lý. Đến lúc đó bạn mới có một evaluation suite để chạy agent và biết chính xác nó hỏng ở đâu.

![Slide Phase 3 Evaluate: criteria và dataset, mỗi criteria là một binary check, success rate 56 trên 100](https://homus.dev/photos/pSto5YaNGUo-1112.jpg)

Slide "Phase 3, Evaluate: Make good measurable.": tạo một dataset gồm các case và một bộ criteria, mỗi criteria là một binary check để khi fail thì chỉ thẳng vào chiều bị hỏng, rồi gộp lại thành một success rate 0 tới 100 cho loop đuổi theo. Bên trái: criteria có thể "guided" (cold start, định nghĩa cùng team từ spec và vài ví dụ) hoặc "discovered" (rút từ trace production: thành công cho biết giữ gì, thất bại cho biết cần kiểm gì); dataset có thể "synthesize" từ ground truth (spec, export lịch sử, ví dụ tốt đã biết) hoặc lấy từ trace. Bên phải: ví dụ một eval system với các check như "Cites its source", "No fabricated facts", "Correct tool used" (FAIL), "Valid output format", "Policy respected", và success rate 56/100.

## 7. Vì sao cần evaluator agent, và chấm điểm mọi layer

Bene dừng lại để hỏi: vì sao Agentic AI Engineer lại giúp nhiều đến vậy ở chỗ này? Họ đang nói về một evaluator agent, vậy vì sao áp khái niệm, hay cách tư duy này, vào quá trình build lại tốt đến thế?

Burak đưa ra một ví dụ: hãy tưởng tượng bạn có một dataset 200 item. Không có eval tự động, việc chạy dataset đó rồi đánh giá bằng mắt người mất khá lâu. Bạn phải cuộn qua một observability dashboard và đọc log, và điều này kéo dài thời gian của mỗi vòng ở stage eval. Ngay khi bạn có nhiều feature cần evaluate và thử nghiệm, việc làm nhanh hay làm song song bỗng trở nên bất khả thi. Con người lại thành bottleneck.

"Vậy là để một agent làm việc lục lọi trace đó", Bene tóm lại. Burak xác nhận: như thời đại hiện nay nói, bạn thiết kế loop cho agent của mình để chúng tự chạy rất nhiều việc như vậy ở background. Việc của bạn trở thành **thiết kế các loop đó với một eval gate hay termination gate rõ ràng**.

Tiếp theo, Bene hỏi một eval tốt nên được xây dựng thế nào và nó đánh giá cái gì.

Burak giải thích: trong bối cảnh agent, nhìn chung thứ quan trọng chủ yếu là **trajectory**. Agent nhận vào input, hay intent, hay task, rồi có một system prompt cụ thể hoặc một kiểu decision tree mà nó vận hành theo. Khi evaluate agent, nói chung ta kiểm:

- **Context có đầy đủ không?** Tức là agent có toàn bộ context cần thiết để làm task từ đầu tới cuối hay không.

- **Từng tool output trong trajectory.** Vì mỗi tool output sai trong một session, cuối cùng đều có thể dẫn tới final output sai.

- **Harness.** Ngoài ra còn nhiều thứ khác để evaluate. Ngày nay chính harness mà agent đang chạy trên đó cũng ảnh hưởng khá mạnh tới hành vi của agent, và đây là một hướng optimization khác nữa.

Nhưng rốt cuộc, khi evaluate một agent, bạn muốn đánh giá tất cả những thứ này cùng nhau, chứ không phải từng thứ một cách tách rời.

![Slide An agent is a whole run: trajectory, tool calls, context và harness đều được chấm](https://homus.dev/photos/pSto5YaNGUo-1520.jpg)

Slide "An agent is a whole run, so you grade every layer.": phần lớn failure của agent không lộ ra ở câu trả lời cuối, mà nằm trong con đường nó đi, các tool nó gọi, context nó có và harness nó chạy trên đó. Sơ đồ cho thấy chuỗi context, tool call, ..., tool call, final output, mỗi bước có một dấu check riêng; bên dưới là harness gồm tools, skills, hooks, sub-agents. Bốn ô cuối: Trajectory (con đường có hợp lý không, đến đích bằng một đường hỏng vẫn là fail), Tool calls và outputs (đúng tool, đúng argument), Context (có hay lấy được đúng thông tin không; slide ghi rằng phần lớn "hallucination" thật ra là thiếu context), Harness (framework và runtime có thực thi đúng các bước, tool và state không).

## 8. Eval thế nào mới đáng tin: actionable, binary, judge đã calibrate

Burak đi tiếp vào câu hỏi: nhìn chung, điều gì làm một eval trở nên hữu ích?

Bạn lúc nào cũng có thể có những metric hay eval chạy theo kiểu **LLM-as-a-judge** và trả về một điểm số. Nhưng để eval hữu ích, nó phải đưa ra **feedback có thể hành động được**. Khi bạn dùng eval dựa trên điểm số, trừ khi rubric được định nghĩa rất kỹ, con số đó không cho bạn biết chính xác phải sửa gì. Trong những trường hợp như vậy, nên dùng eval hay criteria kiểu **binary**, vì ở đó bạn có một "call to action": nếu một eval hay criteria fail, bạn biết chính xác chuyện gì đã xảy ra và cần xử lý vấn đề ra sao.

Điểm thứ hai: giải pháp LLM-as-a-judge của bạn phải được **calibrate**, để không có nhiễu điểm số giữa các judge. Vì LLM không deterministic, điều bạn sẽ gặp nhiều nhất là cùng một judge có thể đánh giá cùng một vấn đề theo những cách khác nhau ở mỗi lần chạy. Bạn phải đảm bảo LLM-as-a-judge xử lý được bài toán variance này. Nếu không, rất khó chạy thử nghiệm và kết luận chắc chắn rằng "version cải tiến của tôi tốt hơn version ban đầu của agent".

![Slide What makes an eval worth trusting: bốn thuộc tính và so sánh eval actionable với không actionable](https://homus.dev/photos/pSto5YaNGUo-1856.jpg)

Slide "What makes an eval worth trusting.": một điểm số chỉ điều khiển được loop khi bạn tin được nó. Luật duy nhất ở trên cùng: agent đang được test không bao giờ tự chấm mình, evaluator phải độc lập, nếu không nó chỉ đóng dấu cho chính việc của nó. Bốn thuộc tính của một eval tốt: Falsifiable (có thể sai, một pass/fail cụ thể chứ không phải cảm giác), Reproducible (variance thấp, judge deterministic: cố định model, prompt, seed của judge để điểm đo agent chứ không đo nhiễu), Valid (gắn với outcome thật mà user cảm nhận), Actionable (khi fail thì chỉ ra chiều bị hỏng). Cách đạt được: lấy từ case thật, mỗi case một mức "must be true" rõ ràng, calibrate theo expert, đánh trọng số theo tác động. Ví dụ không actionable là "Helpfulness: 7.3 / 10"; ví dụ actionable là "Cites a real source per claim?".

## 9. Diagnose: failure mode, root cause và indicator kiểm bằng code

Sau evaluation, agent go live, và đây là lúc bắt đầu gom các failure đã học được, các failure mode, hay những "primary signal" từ các lần thực thi. Ý tưởng của Burak: khi agent gặp một vấn đề, theo thời gian rất có thể vấn đề đó sẽ xuất hiện nhiều lần. Vì vậy quy trình bắt đầu bằng việc xác định agent đã gặp failure mode nào, rồi gom các failure mode đó theo root cause và nơi chúng bắt nguồn. Nơi đó có thể là một đoạn trong agent prompt, có thể là tool bị thiếu, hoặc tool chạy sai.

Khi kết quả chẩn đoán đã được phân loại, bạn có thể làm hai việc. Thứ nhất, tạo eval mới để phát hiện các vấn đề này. Thứ hai, tạo ra các cải tiến và remedy dựa trên chính các vấn đề đó. Theo thời gian, bạn tích luỹ được một kho failure mode đã học, và mỗi agent dần có một bộ dữ liệu lịch sử mà nó luôn có thể đối chiếu.

![Slide Phase 4 Diagnose: trace lỗi được gom theo root cause rồi biến thành eval mới](https://homus.dev/photos/pSto5YaNGUo-1904.jpg)

Slide "Phase 4, Diagnose: Failures cluster into root causes, and become new evals.": khi live, agent được theo dõi. Các trace lỗi (ô đỏ trong lưới live production traces) được cluster theo root cause, ví dụ missing tool / context (7), wrong escalation (4), format / schema (3). Mỗi root cause thành một finding, và mỗi finding được đưa ngược vào như một eval mới (assert tool present, escalation rule, schema check), được hấp thụ vào eval system, thứ lớn lên sau mỗi cycle.

Burak nói thêm về chi phí. Khi bắt đầu diagnose, có một khoản chi phí ban đầu, vì bạn thường phải đọc kỹ các LLM trace để hiểu chuyện gì đang xảy ra. Nhưng theo thời gian, bạn có thể gom được những **indicator kiểm được bằng code** cho từng failure mode. Nghĩa là: có thể có những đoạn nội dung cụ thể, hay một chuỗi tool call cụ thể, mà bạn biết rằng khi thấy nó thì agent sẽ gặp vấn đề. Về sau, điều này giúp bạn diagnose vấn đề trong trace mà không cần thực sự đọc hết mọi trace.

Vì sao đọc hết trace lại là vấn đề? Vì nếu bạn có, chẳng hạn, hàng triệu trace của agent, thì việc đọc hết chúng thực ra còn tốn kém hơn cả việc chạy agent. Đó không phải cách hiệu quả nhất để diagnose. Thứ bạn nên nhắm tới là chọn ra một **mẫu đại diện** từ toàn bộ trace, bằng những chiến lược segmentation thông minh, và dùng các indicator đã học như vừa nói.

Lúc đầu diagnose đắt vì phải đọc kỹ trace. Càng về sau, các indicator kiểm bằng code cho từng failure mode và một mẫu đại diện chọn bằng segmentation giúp không phải đọc toàn bộ trace nữa.

## 10. Vòng optimization tự động: chỉ bản thắng mới được ship

Với những mảnh trên, bạn có thể bắt đầu build **autonomous optimization loop**. Vì đã có eval suite, bạn có thể thay đổi feature của mình: cập nhật một số đoạn nhất định, hoặc thậm chí chạy các thử nghiệm kiểu auto-research để xem có đạt được điểm mong muốn, tức điểm target, cho các eval hay không. Chừng nào đạt được, bản đó tự động được ship lên production.

Từ production, bạn có vòng ngoài, outer loop. Mỗi issue tìm thấy ở bước diagnostics lại cho ra một cải tiến hay một remedy, thứ bạn có thể optimize tiếp. Và chừng nào eval suite còn xanh, bản đó lại được deploy lên production.

![Slide Phase 5 Optimize: build, eval, success gate, optimize, chỉ bản qua gate mới ship](https://homus.dev/photos/pSto5YaNGUo-2216.jpg)

Slide "Phase 5, Optimize: Test variants against the evals, only a winner ships.": eval-driven development nghĩa là cứ lặp build, eval, optimize cho tới khi một ứng viên vượt mức và đánh bại version đang live. Ở giữa là success gate ("clears the bar?", điểm lớn hơn hoặc bằng mức và thắng bản live): pass thì ship thành v+1, fail thì sang optimize rồi iterate về eval. Ba ô cuối slide: chỉ bản thắng mới được ship, mỗi lần pass nâng mức lên (v+1 thành baseline mới, mức chỉ đi lên), và loop cộng dồn vì build, eval, optimize tự chạy nên lợi ích chồng lên nhau chứ không reset mỗi cycle.

## 11. Toàn bộ vòng đời chạy như một agentic loop

Bene đi lại toàn bộ vòng đời, giờ đã biết chi tiết từng phần. Mọi thứ bắt đầu bằng spec: bạn định nghĩa và thiết kế. Bạn build agent. Và tất cả những việc này hiển nhiên có thể làm theo kiểu agentic: bạn định nghĩa các agent làm từng việc, và gộp lại, chúng trở thành Agentic AI Engineer.

Bạn đi qua offline loop: khi đã build xong hệ thống evaluation, bạn evaluate, optimize, test, cải thiện độ chính xác trên test dataset. Khi thấy sẵn sàng, bạn deploy lên production, và đó là lúc online loop bắt đầu. Ở đây bạn nhận feedback thật từ user, các test case thật. Bạn monitor chúng liên tục, nhìn vào live trace, và diagnose chúng như vừa học với diagnose agent. Bạn có thể làm root cause analysis, cluster các failure mode, và rút ra eval criteria mới từ chúng.

Những criteria mới này trở thành một phần của spec, trở thành một phần của agent. Chúng lớn lên liên tục cùng bạn khi bạn dùng agent trên production. Đó chính là online loop: càng gom nhiều use case, càng thấy nhiều dữ liệu production, agent càng tốt hơn và điểm của nó càng cao. Tất cả gộp lại thành một loop end-to-end mà bạn có thể chạy theo kiểu agentic.

![Slide The whole lifecycle running as an agentic loop: bảy bước và sơ đồ offline, online quanh agent](https://homus.dev/photos/pSto5YaNGUo-2320.jpg)

Slide "The whole lifecycle, running as an agentic loop.": bảy bước Define + Design (AI Engineer nắm vì sao và thế nào là "tốt", biến nó thành spec), Build (coding agent sinh agent theo spec), Create the eval system (mode 1, cold start: dataset và criteria rút từ spec và trace lịch sử, "tốt" được lấy từ hội thoại thật chứ không viết tay), Offline optimization loop (dataset, evaluate, optimize; mỗi cycle ship một bản tốt hơn, có regression gate trước khi deploy), Deploy (go live với cơ chế feedback), Monitor (live eval chạy trên trace production), Diagnose (mode 2, live drift: mỗi failure được truy root cause và thành case mới). Sơ đồ bên phải: agent ở giữa với ví dụ 99% accuracy và $0.05 cost mỗi task, vòng offline bên trái và vòng online bên phải.

Từ đây, theo Bene, bạn thấy được sự tương đồng với cách phát triển phần mềm bằng coding agent: các khái niệm đó có thể chuyển nguyên sang AI engineering và việc build AI agent.

## 12. Mutagent: một đội agent dưới một orchestrator

Vì [Mutagent](https://mutagent.io/) đang làm đúng việc này, Bene chuyển sang cho thấy nó trông thế nào dưới dạng sản phẩm.

Hiện tại mọi thứ chạy trong môi trường của bạn, cả cloud lẫn local, và về sau họ sẽ có thêm managed service. Sản phẩm là một bộ agent. Có hai agent đang ở dạng research preview, cũng là hai cái họ nói sâu trong talk này:

- **Evaluator agent**: giúp bạn build một eval set, một dataset tốt, vì đây là lõi của optimization, của eval-driven development loop.

- **Diagnostics agent**: giúp bạn diagnose các trace đã có trên production. Họ học được từ user rằng việc đọc qua các trace này chiếm của họ rất nhiều thời gian, và có một agent mà họ có thể bật ra ngay từ coding environment của mình để phân tích trace là điều rất hữu ích với họ.

Cả hai agent được nối với nhau qua một **orchestrator**, chạy trong coding environment của bạn. Thứ bạn cần là các connector tới những nguồn chứa trace, nơi bạn nhận incident. Nguồn đó cũng có thể là một hệ thống ticket, hay Slack, nơi mọi người báo agent của bạn bị lỗi. Bạn nối chúng vào, và như đã nói, có nhiều target platform khác nhau ở đầu ra: có thể là một PR được tự động mở trên GitHub, có thể chỉ là việc chỉnh agent trong các file MD, có thể là các framework khác nhau mà họ nhắm tới, hoặc deploy lên các managed service. Bene tóm lại: platform bật lên các agent khác nhau, tất cả nối vào một orchestrator.

![Slide It runs in your environment: nguồn trace, orchestrator trong coding agent, các agent theo stage và target đầu ra](https://homus.dev/photos/pSto5YaNGUo-2512.jpg)

Slide "It runs in your environment, cloud and local.": Mutagent cài đặt dưới dạng agent bên trong coding agent bạn đang dùng (Claude Code, Codex, Cursor, Pi, Hermes); agent chạy local, slide ghi rằng trace và code không rời khỏi máy, trong khi vẫn đọc và ghi vào các platform của bạn. Nguồn evidence: Langfuse, OpenTelemetry, Datadog, LangSmith, Braintrust, SigNoz. Orchestrator điều phối vòng đời, mỗi stage một agent; chỉ eval (Evaluator) và diagnose (Diagnostics) đang research preview, các stage còn lại ghi WIP. Target đầu ra: code trên GitHub, coding agent dạng .md (Claude Code, Codex, Cursor), framework (Mastra, DeepAgents), cloud-managed (Claude, Vercel). Ô góc phải: tương lai là một cloud platform, Managed Agents-as-a-Service, tự host hoặc fully managed.

Rồi Bene mời Burak cho khán giả xem agent đầu tiên đang ở research preview, trong thực tế.

## 13. Demo: orchestrator trong Claude Code và lệnh diagnose

Burak nhắc lại: bạn có một orchestrator, thứ lo việc dispatch cho mọi sub-agent khác, hay cho các stage mà họ có. Bạn dùng nó được trong bất kỳ coding harness hay coding agent nào bạn muốn. Trong demo này anh dùng [Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview).

Khi khởi động lần đầu, orchestrator hiện ra một kiểu dashboard: bạn có những stage nào, và cả những thứ đã có sẵn trong code base của bạn, các agent của bạn và cấu hình trước đó.

![Dashboard của orchestrator trong terminal: bảng skill theo stage, trạng thái onboarding và danh sách lệnh](https://homus.dev/photos/pSto5YaNGUo-2744.jpg)

Dashboard của orchestrator trong terminal: bảng các thành phần theo stage (build: mutagent-skill-builder, evaluate: mutagent-evaluator, diagnose: mutagent-diagnostics, shared: mutagent-templates, orchestrator), trạng thái onboarding và state hiện tại. Bên dưới là danh sách lệnh bắt đầu bằng dấu sao: *sync để index topology của skill và agent; *evaluate chạy eval trên một skill hay agent và trả verdict; *audit; *diagnose làm RCA và causal chain trên các failure rồi xếp hạng remedy, với ghi chú rằng bước IMPROVE được gate và không bao giờ tự áp dụng; cùng *status, *onboard, *help.

Ở đây anh có một số slash command. Chúng về cơ bản là các lệnh trigger cho workflow hay cho từng stage cụ thể. Nếu gõ diagnose, nó sẽ khởi động stage chẩn đoán để làm root cause analysis.

Bạn có thể trỏ diagnostics vào một phạm vi cụ thể. Phạm vi đó có thể là một agent, cũng có thể là một skill, tức là bạn có thể diagnose mọi lần invoke của một skill nào đó.

Khi bắt đầu diagnostics, nó sẽ lấy trace từ source platform bạn đã cấu hình. Trong trường hợp này, đó có thể là một thứ như [Langfuse](https://langfuse.com), có thể là các transcript Claude local của bạn, hoặc một định dạng khác, ví dụ JSONL export ra từ một observability platform nào đó.

Bản thân một lần chạy diagnostics mất khá lâu mới xong, nên Burak cho xem một bản đã tạo sẵn: nó làm gì và trông ra sao ở cuối.

## 14. Báo cáo HTML: overview, sampling và guided search

"Vậy ta đang thấy gì ở đây?", Bene hỏi.

Burak giải thích: khi chạy diagnostics agent trên các agent của bạn, bạn nhận về một **artifact HTML** được tạo tự động. Nó cho thấy chi tiết agent của bạn, các tool bạn có. Nếu nó có quyền truy cập code, nó còn cho biết agent đang dùng harness hay framework nào. Rồi nhìn chung, nó đi qua các trace và chọn ra các primary signal, hay failure mode, tuỳ theo tần suất chúng xuất hiện trong các mẫu trace.

Như đã nói, phần lớn thời gian bạn không muốn đọc toàn bộ trace vì không hiệu quả về chi phí. Vì thế diagnostics dùng kiểu lọc hay segmentation nhiều tầng để chọn ra một mẫu đại diện. Ban đầu, một vài phần trace, hay một tỉ lệ nhất định, được LLM đọc để xem có vấn đề rõ ràng nào phát hiện được không. Dựa vào đó, diagnostics quyết định tập trung vào một failure mode hay một signal cụ thể.

![Phần Overview của báo cáo: cảnh báo coverage, headline và bảng signal census](https://homus.dev/photos/pSto5YaNGUo-2952.jpg)

Phần Overview trong báo cáo cho một email agent mẫu: các con số tổng (1.946 trace, 102 trace được đọc kỹ, coverage confidence "medium", "evidence sufficient"), một cảnh báo rằng coverage đọc còn thấp nên có thể chạy lại với khung thời gian rộng hơn, một headline (latency chủ yếu do một tool gọi model lồng bên trong, generateDraftReply, nhưng nhóm đối chứng lộ ra một lỗi im lặng nghiêm trọng hơn), và bảng "signal census": latency-spike được chọn làm primary; missing-output, loop, cost-overshoot được thấy trong vài mẫu nhưng chỉ xếp SECONDARY vì chưa có bằng chứng kiểm bằng cơ chế; wrong-output/hallucination và low-score bị loại vì không có tín hiệu.

![Scan coverage và heatmap 24 giờ trong báo cáo diagnostics](https://homus.dev/photos/pSto5YaNGUo-3056.jpg)

Phần "Scan coverage" cho thấy đúng cách lọc nhiều tầng mà Burak mô tả: 1.946 trace trong khung thời gian; cả 1.946 được quét ở mức code (tier 0, không dùng LLM); 102 trace được chọn làm mẫu đại diện (khoảng 5% của khung, theo worst, median, best và ngẫu nhiên); và 102 trace đó được LLM đọc kỹ. Bên dưới là heatmap 24 giờ (màu là latency trung bình, số là lượng trace) và bảng các finding với mức độ nghiêm trọng.

Lựa chọn còn lại: khi trigger diagnostics, bạn cũng có thể chỉ rõ một issue mà bạn tự thấy, hoặc issue bạn đang đi tìm. Đó có thể là thứ user báo lên. Khi đó nó giống một **guided search** hơn: nếu bạn nói với diagnostics agent rằng bạn quan tâm tới một vấn đề cụ thể, nó sẽ cố tìm mọi incident hay mọi lần xảy ra liên quan tới đúng vấn đề đó.

Bene hỏi họ đang nhìn thấy gì trong toàn bộ báo cáo. Burak giải thích: phần đầu là overview tổng, cho biết những issue nào đã được phát hiện và tần suất của chúng trong khung thời gian đã cho.

## 15. Một failure mode: why-chain, assumptions và remedies

Với mỗi tab, bạn có một failure mode và lời giải thích về vấn đề. Ở đó bạn thấy vấn đề đến từ đâu, hay vì sao nó xảy ra. Agent cung cấp một kiểu **why chain** đệ quy để nói với bạn: "Đây là nơi issue bắt nguồn."

![Tab finding F-001: tool soạn nháp là nơi ngốn latency, với Problem, Evidence và Why-chain](https://homus.dev/photos/pSto5YaNGUo-3200.jpg)

Tab finding đầu tiên, mức HIGH: "F-001, The draft tool is the latency sink". Tool generateDraftReply, một lần gọi LLM lồng bên trong chạy nối tiếp sau vòng reasoning chính, là thứ ngốn wall-clock nhiều nhất; ở nhóm chậm nhất nó chiếm 40 tới 87% latency end-to-end trong 28 trên 30 trace. Các thẻ WHAT / WHY / WHERE / APPLY / Confidence phân loại finding. Bên dưới là Problem, Evidence (dẫn tới một trace cụ thể) và Why-chain: trace chậm (p50 54 giây, 41% trên 60 giây), phần lớn thời gian nằm trong một tool, tool đó là một lần gọi LLM lồng chạy nối tiếp, và gốc rễ là thiết kế agent đưa việc soạn tin nhắn qua một lần generate riêng thay vì tạo tin nhắn ngay trong bước reasoning.

Thêm nữa, nó đưa ra các remedy, hay cách sửa, để xử lý vấn đề. Bạn cũng thấy một khối **assumptions**. Burak nói khối này quan trọng, vì khi đọc trace, không phải lúc nào bạn cũng có quyền truy cập code. Khối này giúp họ phát hiện khi LLM, tức diagnostics agent, đưa ra những giả định không đúng, và họ có thể nhìn thấy rồi sửa chúng ở đây.

![Khối Assumptions với nhãn VERIFIED và HYPOTHESIS-PENDING, và remedy xếp hạng 1](https://homus.dev/photos/pSto5YaNGUo-3232.jpg)

Khối Assumptions của finding này: một giả định được đánh dấu VERIFIED (generateDraftReply là một sub-call có LLM phía sau, không phải template deterministic), một giả định khác đánh dấu HYPOTHESIS-PENDING (sub-call gửi lại và decode lại context hội thoại thay vì tái sử dụng), vì prompt nội bộ của tool không có trong bằng chứng. Bên dưới là Remedies, rank 1: giới hạn độ dài bản nháp và stream phần generate bản nháp, kèm lý do chọn ("why this remedy") và lý do nó hiệu quả ("why this works").

Nhưng cuối cùng, bạn sẽ được đưa ra một số cách sửa hay remedy có thể giải quyết vấn đề. Bạn có thể chọn cái được đề xuất, hoặc chọn bao nhiêu tuỳ ý vì đây là multi-choice.

![Remedy rank 2: tạo tin nhắn ngay trong bước reasoning thay vì một lần generate bản nháp riêng](https://homus.dev/photos/pSto5YaNGUo-3312.jpg)

Phía dưới là phần apply instructions của remedy rank 1 (đặt trần max_tokens cho việc generate bản nháp, bật streaming để các bước sau bắt đầu trước khi bản nháp xong) và một ô để ghi feedback cho remedy. Remedy rank 2 là sửa từ gốc kiến trúc: để agent tạo tin nhắn ngay trong bước reasoning, nơi vốn đã có đủ context, thay vì một lần generate bản nháp riêng; theo báo cáo, cách này bỏ đi phần wall-clock lớn nhất và cắt một vòng gọi LLM cho mỗi tin nhắn. Mỗi remedy có checkbox để chọn.

## 16. Trang Decisions, task markdown cho coding agent, và lời kết

Khi đã đi qua hết các vấn đề, cuối cùng bạn tới một **trang decisions**. Ở đây, dành cho những ai đang dùng các tính năng AI text-to-speech hay speech-to-text như [Wispr Flow](https://wisprflow.ai), luôn có một ô feedback chung để bạn có thể nói thẳng vào mic.

Cuối cùng, khi đã hài lòng với mọi quyết định, bạn nhận được một **task definition dạng markdown** cho coding agent của bạn. Nhờ vậy, khi quay lại terminal và coding agent, mọi cách sửa hay remedy đều có thể được áp dụng trực tiếp. Trên giao diện, nút "Copy decisions as markdown" luôn nằm ở góc dưới bên phải trên mọi trang của báo cáo.

Đường đi từ báo cáo diagnostics về lại terminal: chọn remedy, ghi quyết định và feedback, xuất một task markdown để coding agent áp dụng các cách sửa.

"Cảm ơn Burak vì phần demo", Bene nói, rồi dành vài lời cuối cho sản phẩm. Anh cảm ơn mọi người đã lắng nghe, và hy vọng hai người đã cho thấy được một vài insight tốt về cách họ hình dung tương lai của việc build agent với Agentic AI Engineer. Lời nhắn cuối của anh: hãy thôi debugging, để agent làm những việc tẻ nhạt, và liên hệ với họ nếu có câu hỏi thêm. Chúc mọi người một hội nghị tuyệt vời.

![Slide kết Stop debugging. Start evolving.](https://homus.dev/photos/pSto5YaNGUo-3416.jpg)

Slide kết: "Stop debugging. Start evolving." Dòng phụ: agent đáng tin đến từ một thứ duy nhất, một loop không bao giờ dừng, chạy đủ nhanh để cộng dồn. Bên dưới là lại chuỗi conceptualize, build, evaluate, deploy, monitor, diagnose, optimize.

## Nguồn và liên kết

- [Trang talk chính thức trên ai.engineer](https://ai.engineer/talks/pSto5YaNGUo)

- [Mutagent](https://mutagent.io/), platform cho Agentic AI Engineering

- [Tài liệu Mutagent về vòng đời agent (Helix)](https://docs.mutagent.io/helix/what-is-helix)

- [Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview), coding agent dùng trong demo

- [Langfuse](https://langfuse.com), một nguồn trace được nhắc trong demo

- [Deep Agents](https://github.com/langchain-ai/deepagents) và [Hermes Agent](https://github.com/NousResearch/hermes-agent), hai harness được nhắc tới

- [Wispr Flow](https://wisprflow.ai), công cụ speech-to-text được nhắc ở trang Decisions

- LinkedIn của Benedikt Sanftl: linkedin.com/in/benedikt-sanftl-294a6039a