# Building Deterministic Infrastructure for Non-Deterministic AI Agents

Nishant Gupta · Meta · AI Engineer World's Fair 2026: Online Track

> Model là stochastic nhưng infrastructure phải deterministic: retry storm, model chỉ đề xuất, agent control plane, trace, memory consistency và safety nhiều lớp.

Topics: Agents, Distributed Systems, Security

Canonical: https://homus.dev/talks/building-deterministic-infrastructure-for-non-deterministic-ai-agents

## 1. Bài toán không còn là trí thông minh, mà là reliability

Nishant Gupta tự giới thiệu: anh là software engineering tech lead ở Meta, làm hạ tầng AI cho cả training lẫn inference. Chủ đề hôm nay là xây dựng deterministic infrastructure (hạ tầng chạy có tính xác định, dự đoán được) cho những AI agent vốn non-deterministic (không xác định: cùng đầu vào có thể ra hành vi khác nhau).

![Slide tiêu đề Building Deterministic Infrastructure for Non-Deterministic AI Agents](https://homus.dev/photos/APh1Vx0oLmQ-0000.jpg)

Slide tiêu đề, dòng tiêu đề phụ "The emerging control plane for autonomous AI systems", ghi tên Nishant Gupta, Tech Lead @ Meta. Hình minh hoạ là một đám mây hỗn loạn bị nhốt trong một khung lập phương cứng: phần lõi bất định được bao bởi một khung xác định, đúng ý cả talk.

Anh mở bằng một nhận xét về hướng của cả ngành. Mấy năm qua, phần lớn các cuộc nói chuyện về AI xoay quanh model: model lớn hơn, nhiều parameter hơn, reasoning tốt hơn. Nhưng khi các tổ chức chuyển từ chatbot sang autonomous agent, một vấn đề khác hẳn xuất hiện. Thách thức không còn là trí thông minh nữa. Thách thức là reliability (độ tin cậy).

Ở Meta và trên toàn ngành, anh thấy agent đã vượt khỏi việc trả lời câu hỏi. Chúng bắt đầu lập kế hoạch (plan), gọi tool, điều phối workflow và đưa ra quyết định có ảnh hưởng tới hệ thống production. Những hệ thống này về bản chất là probabilistic (xác suất). Còn infrastructure thì không được phép như vậy. Đó là mâu thuẫn mà phần còn lại của talk sẽ đi sâu.

## 2. The great mismatch: hạ tầng xây cho microservice dễ đoán

Hạ tầng cloud hiện đại tiến hoá quanh một bộ giả định. Phần lớn request sống rất ngắn. Service thì, ít nhiều, là deterministic. Đường đi của việc thực thi (execution path) đã biết trước. Lỗi thì có giới hạn (bounded): ta biết lỗi có thể lớn tới đâu.

![Bảng The Great Mismatch so sánh traditional microservices với autonomous AI agents](https://homus.dev/photos/APh1Vx0oLmQ-0056.jpg)

"Infrastructure was built for predictable microservices." Bảng "The Great Mismatch" đặt hai cột cạnh nhau: microservice truyền thống là stateless, deterministic (đường đi cố định), request-response đồng bộ, chạy trong mili giây (dưới 100 ms); autonomous AI agent thì stateful, probabilistic (đường đi động), là workflow nhiều bước bất đồng bộ, và chạy dài hàng phút tới hàng giờ. Ở giữa là "friction points": chỗ hai thế giới va nhau.

Autonomous AI agent vi phạm gần như mọi giả định đó. Chúng stateful (giữ trạng thái), chúng chạy lâu (long-running). Chúng ra quyết định một cách động. Và chúng có thể chạy những workflow khác nhau cho cùng một đầu vào. Nishant gọi đây là "the great mismatch", sự lệch pha lớn: ta đang cố chạy hệ thống tự hành trên một hạ tầng được thiết kế cho workflow deterministic.

## 3. Demo tối ưu cho capability, production đòi reliability

Theo anh, đây có lẽ là thay đổi tư duy quan trọng nhất. Phần lớn demo AI phô diễn capability (năng lực): nó có giải được vấn đề không? Nó có dùng được tool không? Nó có hoàn thành được một workflow không?

![Slide Demos optimize for capability, production demands reliability, hình khối Capabilities đặt trên Reliability Core](https://homus.dev/photos/APh1Vx0oLmQ-0128.jpg)

"Demos optimize for capability. Production demands reliability." Phần Capabilities (prompt, LLM) chỉ là khối nhỏ nổi phía trên; bên dưới mặt đất là một Reliability Core lớn gồm nhiều module chịu lực. Phần lớn khối lượng kỹ thuật nằm dưới tầng model.

Hệ thống production có mục tiêu khác. Nó có làm được việc đó một cách đáng tin cậy không? Làm được mười nghìn lần không? Một trăm nghìn lần? Một triệu lần? Nó có tự phục hồi sau lỗi không? Nó có vận hành an toàn không? Nó có làm được với chi phí chấp nhận được, latency chấp nhận được, và kết quả chấp nhận được không?

Vì vậy phần lớn công sức engineering dời xuống dưới tầng model: vào orchestration, monitoring, safety, evaluation và các hệ thống recovery (phục hồi).

## 4. Lỗi thật trong production sinh ra ở infrastructure, không phải ở model

Khi nghe tới "AI failure", người ta lập tức nghĩ tới hallucination. Trong thực tế, theo Nishant, hallucination thường là kiểu lỗi kém thú vị nhất. Thứ anh thấy thay vào đó là các lỗi hạ tầng: recursive reasoning loop (vòng reasoning lặp đệ quy), log bị tràn (overflowed log), retry amplification (retry khuếch đại), context corruption (context bị hỏng), memory poisoning (memory bị đầu độc), và cost explosion (chi phí bùng nổ).

![Diagnostic Failure Tree đi từ Stochastic Model Output tới các hậu quả](https://homus.dev/photos/APh1Vx0oLmQ-0208.jpg)

"Real production failures originate in the infrastructure, not the model." Cây chẩn đoán lỗi (Diagnostic Failure Tree) bắt đầu từ một output bất định của model rồi rẽ ba nhánh: nhánh Logic dẫn tới recursive reasoning loop rồi workflow deadlock; nhánh Action dẫn tới tool hallucination, rồi retry storm, rồi cost explosion; nhánh State dẫn tới context drift rồi memory poisoning.

Câu chốt của phần này: model mắc lỗi, nhưng chính infrastructure mới biến lỗi đó thành một sự cố ngừng dịch vụ (outage). Đó mới là thách thức thật.

## 5. Giải phẫu một retry storm

Slide tiếp theo, theo anh, cho thấy một pattern mà kỹ sư distributed systems có lẽ sẽ nhận ra ngay. Một agent gọi tool sai. Tool trả về lỗi. Thay vì phục hồi, agent sinh ra một request hơi khác đi nhưng vẫn không hợp lệ. Chu trình lặp lại.

![The anatomy of an agent retry storm, chuỗi năm bước và đồ thị GPU compute tăng vọt](https://homus.dev/photos/APh1Vx0oLmQ-0232.jpg)

"The anatomy of an agent retry storm." Năm bước: (1) agent hallucinate tham số API không hợp lệ; (2) tool trả mã lỗi; (3) agent cố sửa lỗi nhưng lại hallucinate một tham số không hợp lệ mới; (4) vòng reasoning đệ quy bị kẹt; (5) hậu quả. Bên phải là đồ thị "Exponential GPU Compute Spike": lượng GPU compute dựng đứng theo thời gian, đi kèm các nhãn resource saturation và cost explosion.

Mỗi lần retry lại tốn thêm compute. Độ sâu reasoning tăng lên. Mức tiêu thụ GPU tăng lên. Cuối cùng ta có tài nguyên tăng theo hàm mũ. Thứ khởi đầu chỉ là một lỗi API nhỏ đã trở thành một sự cố compute. Đây là lý do retry không kiểm soát là một trong những rủi ro lớn nhất của hệ thống agentic.

Với ai từng vận hành distributed system, hình ảnh này rất giống "retry storm" kinh điển: client đồng loạt retry vào một service đang yếu và làm nó sập hẳn. Khác biệt ở đây là mỗi lần retry của agent không rẻ như một HTTP request, mà là thêm một lượt reasoning trên GPU.

## 6. Platform quyết định, model chỉ đề xuất

Đây là nguyên tắc kiến trúc mà Nishant khuyến nghị mạnh nhất: đừng bao giờ để model trực tiếp điều khiển hệ thống production.

![Slide The platform decides, the model merely proposes, lõi stochastic bị bao bởi khung deterministic wrapper](https://homus.dev/photos/APh1Vx0oLmQ-0304.jpg)

"The platform decides. The model merely proposes." Một Stochastic Core nằm giữa, mọi mũi tên đi ra đều phải qua một khung Deterministic Wrapper với các cổng Validate và Filter/Route, rồi mới thành Aligned Output, Safe Execution và System Compliance.

Model nên sinh ra đề xuất (proposal). Infrastructure kiểm tra (validate) đề xuất đó. Một policy engine phê duyệt nó. Một execution gateway thực thi nó, đúng trong giới hạn đã duyệt. Model chỉ gợi ý. Platform mới là bên quyết định.

Sự tách bạch này cho phép xây hệ thống đáng tin cậy ngay cả khi model bên dưới vẫn là probabilistic. Nói cách khác, ta không cần model trở nên deterministic; ta chỉ cần mọi thứ model chạm tới phải đi qua những lớp deterministic.

Bốn vai tách rời: chỉ phần đầu (khung nét đứt) là bất định; ba bước sau là code xác định, nắm quyền thật trên production.

## 7. Agent control plane: lớp hạ tầng mới

Nishant đặt agent vào một chuỗi lịch sử quen thuộc. Container đã sinh ra [Kubernetes](https://kubernetes.io). Microservice đã sinh ra service mesh. AI agent đang sinh ra một thứ mới: agentic control plane.

![Sơ đồ The Agent Control Plane nằm giữa Agent Applications và Foundational LLMs](https://homus.dev/photos/APh1Vx0oLmQ-0328.jpg)

"The Agent Control Plane is the new infrastructure layer." Tầng trên là Agent Applications (research, coding, interaction...), tầng dưới là Foundational LLMs và Data APIs; ở giữa là control plane gồm Memory Coordinator, Orchestration Engine, Safety Policy Node và Compute Scheduler. Chú thích bên phải: agent cần một hệ điều hành; cũng như Kubernetes trở thành control plane điều phối container, một Agent Control Plane chuyên dụng đang hình thành để quản lý runtime execution của AI tự hành.

Lớp này chịu trách nhiệm scheduling, điều phối memory, thực thi policy, evaluation, monitoring và workload routing (định tuyến workload), cái cuối anh nhấn mạnh là rất quan trọng. Hãy nghĩ về nó như một hệ điều hành cho AI tự hành.

Anh dự đoán những tổ chức xây được lớp này sẽ có lợi thế cạnh tranh lớn hơn đáng kể.

## 8. Log là chưa đủ: observability nhiều chiều bằng trace

Log truyền thống cho ta biết điều gì đã xảy ra. Hệ thống agentic đòi hỏi hiểu vì sao nó xảy ra. Ta cần trace ghi lại quyết định lập kế hoạch (planning decision), tool call, memory lookup và chuyển trạng thái (state transition).

![Agent Trace Timeline với năm track LLM decisions, orchestration plans, tool calls, memory access, state transitions](https://homus.dev/photos/APh1Vx0oLmQ-0352.jpg)

"Logs are dead. Autonomous workflows require multidimensional observability." Agent Trace Timeline đặt năm track song song trên cùng một trục thời gian: LLM decisions, orchestration plans, tool calls và execution, memory access, state transitions. Các mũi tên nối giữa track cho thấy một quyết định dẫn tới tool call nào, đọc memory nào, và đổi state ra sao.

Khi debug một workflow tự hành, hiểu được chuỗi quyết định và reasoning thường quan trọng hơn chính output cuối cùng. Observability trở thành nhiều chiều. Thiếu nó, debug trên production gần như là bất khả thi.

## 9. Shared memory và bài toán consistency giữa nhiều agent

Memory, theo Nishant, là một trong những thách thức bị đánh giá thấp nhất trong kiến trúc agentic. Một khi nhiều agent cùng chia sẻ state, các vấn đề quen thuộc của distributed systems xuất hiện: stale read (đọc dữ liệu cũ), conflicting update (cập nhật xung đột), context drift (context trôi lệch), và inconsistent view (mỗi bên thấy một phiên bản khác nhau).

![Shared Memory Architecture với ba agent nối vào một state store, các điểm lỗi context drift, stale memory, conflicting facts](https://homus.dev/photos/APh1Vx0oLmQ-0424.jpg)

"Shared memory coordinates chaotic multi-agent consistency." Ba agent A, B, C cùng nối vào một State Store ở giữa; trên mỗi đường nối có dấu cảnh báo cho một kiểu lỗi: context drift, stale memory, conflicting facts.

Thách thức còn khó hơn khi chính memory cũng có thể mang tính xác suất và dựa trên retrieval: cùng một câu truy vấn chưa chắc lấy về cùng một mẩu ký ức. Kết luận của anh: rất nhiều lỗi trong hệ multi-agent thực ra là lỗi consistency đội lốt lỗi reasoning.

## 10. Safety phải xếp thành nhiều lớp

Safety không thể là một thành phần đơn lẻ. Nó phải được xếp lớp: kiểm soát ở mức prompt, quyền dùng tool (tool permission), kiểm tra bằng policy (policy validation), phê duyệt của con người (human approval), và hệ thống audit.

![Các vòng tròn đồng tâm bao quanh Model Output, một output bị chặn ở vòng ngoài](https://homus.dev/photos/APh1Vx0oLmQ-0448.jpg)

"Autonomous systems demand layered containment boundaries." Model Output nằm ở tâm, bao quanh bởi các vòng: Tool Permissions, Policy Engine, Human Approval, Audit Layer. Trên slide ghi "Ring 2" tới "Ring 5", và nhãn "Ring 5: Audit Layer" xuất hiện hai lần. Một output đỏ đi ra từ tâm và bị chặn (BLOCKED) ở một vòng.

Mỗi lớp bắt một nhóm lỗi khác nhau. Defense in depth (phòng thủ theo chiều sâu) là một nguyên tắc bảo mật đã được hiểu rõ từ lâu, và nó áp dụng tốt y như vậy cho hệ thống AI tự hành: một lớp lọt thì lớp sau vẫn còn cơ hội chặn.

## 11. Con người là đường escalation, không phải nút thắt

Nhiều người nhìn sự tham gia của con người như một thứ cần thiết tạm thời, rồi sẽ bỏ đi khi model đủ giỏi. Nishant không nghĩ vậy là đúng. Theo anh, những hệ thống thành công nhất nhiều khả năng sẽ tiếp tục có con người giám sát (human supervised).

![Workflow Routing Diagram: decision gate tách edge case sang human approval node](https://homus.dev/photos/APh1Vx0oLmQ-0512.jpg)

"Human oversight is an escalation path, not an operational bottleneck." Workflow Routing Diagram: các task tự động của agent chạy thẳng qua một Decision Gate kiểm risk và confidence; chỉ edge case mới bị rẽ xuống Human Approval Node để xem xét thủ công, rồi nhập lại luồng chính khi đã được duyệt.

Con người trở thành người xử lý ngoại lệ (exception handler). Họ xem xét các tình huống mơ hồ. Họ xử lý các kịch bản mới chưa từng gặp. Họ cung cấp tín hiệu hiệu chỉnh (calibration signal) cho hệ thống. Mục tiêu không phải là loại bỏ con người. Mục tiêu là phân bổ sự chú ý của con người vào đúng chỗ nó tạo ra nhiều giá trị nhất.

## 12. Inference ở quy mô lớn thành bài toán cluster scheduling

Một trong những thay đổi hạ tầng lớn nhất là workload AI ngày càng giống bài toán cluster scheduling. Demand đến theo từng đợt (bursty). Độ sâu reasoning không đoán trước được. Workflow có thể chạy hàng phút thay vì vài mili giây. Nhu cầu tài nguyên dao động rất mạnh.

![Elastic Scaling Graph: compute units theo thời gian với bursty demand và long-running workflow](https://homus.dev/photos/APh1Vx0oLmQ-0536.jpg)

"Inference at scale fundamentally becomes a cluster scheduling problem." Elastic Scaling Graph vẽ compute units theo thời gian: các đỉnh nhọn do độ sâu reasoning thay đổi, một khối cao kéo dài do long-running workflow, và các bậc thang capacity chạm vào trần resource contention và GPU limits.

Hệ quả là GPU efficiency, workload placement (đặt workload lên đúng máy), elastic capacity management (co giãn capacity) và scheduling trở nên then chốt. Inference không còn chỉ là chuyện của model; nó trở thành một bài toán điều phối tài nguyên (resource orchestration).

## 13. Reliability Rosetta Stone: pattern cũ cho bài toán mới

Tin tốt là nhiều vấn đề trong số này không hoàn toàn mới. Distributed systems đã giải những bài toán tương tự suốt nhiều thập kỷ. Nishant đưa ra một bảng "dịch" từ pattern quen thuộc sang phiên bản cho agent:

![Bảng The Reliability Rosetta Stone ánh xạ distributed systems pattern sang agent equivalent](https://homus.dev/photos/APh1Vx0oLmQ-0600.jpg)

"The Reliability Rosetta Stone." Cột trái là pattern của distributed systems, cột phải là bản tương đương cho agent: circuit breakers thành tool isolation, rate limiting thành agent limits, retries thành controlled recovery, quotas thành cost governance, observability thành agent tracing.

- **Circuit breaker thành tool isolation**: một tool đang lỗi thì bị cô lập, agent không được gọi nó liên tục (khái niệm circuit breaker: [bài của Martin Fowler](https://martinfowler.com/bliki/CircuitBreaker.html)).

- **Rate limit thành agent limit**: giới hạn số việc một agent được làm.

- **Retry thành controlled recovery**: phục hồi có kiểm soát thay vì retry vô tận như ở phần retry storm.

- **Resource quota thành cost governance**: hạn mức tài nguyên trở thành quản trị chi phí.

- **Observability thành agent tracing**.

Thay vì phát minh ra một hạ tầng hoàn toàn mới, ta có thể chuyển thể những pattern reliability đã được kiểm chứng sang cho hệ thống tự hành. Chương [Handling Overload](https://sre.google/sre-book/handling-overload/) trong sách SRE của Google là một ví dụ tài liệu kinh điển về các pattern quá tải như vậy.

## 14. Lợi thế cạnh tranh dời từ prompt engineering sang systems engineering

Ngành đã đi qua vài giai đoạn. Ban đầu, prompt là yếu tố tạo khác biệt. Rồi model trở thành yếu tố tạo khác biệt. Giờ thì cả hai đang nhanh chóng bị commodity hoá (trở thành hàng phổ thông ai cũng có). Biên giới tiếp theo là infrastructure.

![Đồ thị The Paradigm Shift: đường Prompts và Models lên rồi xuống, đường Infrastructure đi lên](https://homus.dev/photos/APh1Vx0oLmQ-0624.jpg)

"Competitive advantage has shifted from prompt engineering to systems engineering." Đồ thị The Paradigm Shift từ 2023 tới 2025+: đường Prompts lên đỉnh rồi rơi, đường Models lên rồi đi ngang ở "commoditization plateau", còn đường đỏ Infrastructure đi lên theo quỹ đạo tăng trưởng kép.

Tổ chức chiến thắng sẽ không nhất thiết là tổ chức có prompt tốt nhất. Họ sẽ là tổ chức có hệ thống đáng tin cậy nhất. Lợi thế cạnh tranh đang dịch chuyển lên trên stack.

## 15. Kết: AI agent là distributed system, hãy đối xử đúng như vậy

Nếu chỉ nhớ một điều, Nishant muốn đó là: AI agent nên được đối xử như distributed system. Model là stochastic (ngẫu nhiên). Infrastructure phải deterministic. Reliability ngày càng là một bài toán infrastructure. Observability là bắt buộc. Control plane đang nổi lên thành lớp nền móng.

![Slide kết AI agents are distributed systems, treat them accordingly, với Core Takeaways](https://homus.dev/photos/APh1Vx0oLmQ-0648.jpg)

"AI agents are distributed systems. Treat them accordingly." Khung Core Takeaways: model bản chất là stochastic, infrastructure phải chặt chẽ; reliability không còn là bài toán model mà là bài toán infrastructure; observability nhiều chiều là bắt buộc, không phải tuỳ chọn; agent control plane là lớp runtime cần có cho AI trên production. Cột phải là câu kết của talk.

Và cuối cùng, tương lai của AI sẽ không thắng nhờ prompt tốt hơn. Nó sẽ thắng nhờ hệ thống tốt hơn.

## Nguồn và link

- [Trang talk chính thức trên ai.engineer](https://ai.engineer/talks/APh1Vx0oLmQ) · [Video gốc](https://www.youtube.com/watch?v=APh1Vx0oLmQ)

- Kubernetes, control plane cho container mà talk lấy làm phép so sánh: [kubernetes.io](https://kubernetes.io)

- Circuit breaker pattern: [martinfowler.com/bliki/CircuitBreaker.html](https://martinfowler.com/bliki/CircuitBreaker.html)

- Google SRE Book, chương Handling Overload: [sre.google/sre-book/handling-overload](https://sre.google/sre-book/handling-overload/)

- Nishant Gupta trên GitHub: [github.com/nishantgpt-lab](https://github.com/nishantgpt-lab) · LinkedIn: linkedin.com/in/nishantgupta-ai