Một AI Agent có thể được demo trong vài tuần. Nó có thể đọc email, tìm kiếm tài liệu, truy vấn dữ liệu, tạo báo cáo hoặc thực hiện một chuỗi tác vụ tương đối phức tạp. Trong môi trường demo, mọi thứ có thể hoạt động rất thuyết phục.
Nhưng giữa một Agent “có thể chạy” và một Agent “có thể được sử dụng mỗi ngày trong doanh nghiệp” tồn tại một khoảng cách lớn.
Khi đi vào vận hành thực tế, hàng loạt câu hỏi bắt đầu xuất hiện. Agent lấy dữ liệu từ đâu? Nếu CRM và Excel chứa thông tin khác nhau thì tin nguồn nào? Agent được phép đọc dữ liệu gì? Có được cập nhật hệ thống không? Nếu API lỗi thì workflow tiếp tục thế nào? Nếu AI không chắc chắn thì chuyển cho ai? Ai chịu trách nhiệm khi Agent thực hiện sai? Và quan trọng nhất: sau khi triển khai, doanh nghiệp sẽ đo giá trị bằng chỉ số nào?
Những câu hỏi này cho thấy triển khai AI Agent không chỉ là một bài toán phát triển AI. Nó đồng thời là bài toán về business process, data, integration, permission, operation và measurement.
Đây cũng là lý do cách tiếp cận FDE – Forward Deployed Engineer – trở nên đáng chú ý. Thay vì nhận một requirement đã hoàn thiện rồi quay về phát triển hệ thống, FDE tham gia từ giai đoạn xác định vấn đề, làm việc gần với business team và cùng đưa giải pháp từ ý tưởng đến vận hành thực tế.
Khoảng cách lớn nhất của AI Agent không nằm giữa model này và model khác
Khi bắt đầu một dự án AI, doanh nghiệp dễ dành nhiều thời gian để thảo luận về model. Nên sử dụng model nào? Model nào chính xác hơn? Context window bao nhiêu? Agent framework nào phù hợp? Có cần multi-agent hay không?
Những câu hỏi này có ý nghĩa ở giai đoạn kỹ thuật, nhưng chưa chắc là yếu tố quyết định dự án có tạo ra business value hay không.
Giả sử doanh nghiệp đã có một Agent có thể đọc email khách hàng với độ chính xác đủ tốt. Nếu sau đó nhân viên vẫn phải tự mở CRM, tìm customer record, kiểm tra lịch sử giao dịch, copy dữ liệu sang Agent rồi lấy câu trả lời nhập lại vào CRM, phần khó nhất của workflow vẫn chưa được giải quyết.
Agent có thể thông minh hơn, nhưng nhân viên vẫn đang đóng vai trò kết nối giữa các hệ thống.
Đây chính là vấn đề đã được phân tích trong bài Nhân viên phải mở Email, Excel, CRM và nhiều hệ thống để hoàn thành một việc: AI có thể can thiệp ở đâu?. Giá trị thực tế không chỉ đến từ khả năng AI tạo ra một output tốt, mà từ việc output đó được đặt đúng vị trí trong workflow.
Vì vậy, câu hỏi quan trọng không chỉ là “AI có làm được task này không?”, mà là “Nếu AI làm được task này, toàn bộ quy trình phía trước và phía sau sẽ thay đổi như thế nào?”
Demo thường bắt đầu từ AI, production phải bắt đầu từ workflow
Một demo thường có cấu trúc khá đơn giản: đưa input vào, AI xử lý và tạo output.
Ví dụ:
Email → AI → Response
hoặc:
Document → AI → Extracted Data
hoặc:
Question → AI → Answer
Nhưng trong doanh nghiệp, email không tự nhiên xuất hiện trong prompt. Tài liệu có thể nằm ở SharePoint, hệ thống nội bộ hoặc email. Dữ liệu khách hàng nằm trong CRM. Policy nằm trong knowledge base. Sau khi AI tạo ra kết quả, thông tin có thể phải được kiểm tra, phê duyệt, ghi lại hoặc chuyển sang một hệ thống khác.
Workflow thật có thể giống:
Email → Identify Customer → CRM Lookup → Order System → Knowledge Search → AI Interpretation → Business Rules → Human Approval → Response → CRM Update → Logging.
AI chỉ là một phần của chuỗi này.
Đây cũng là điểm khác biệt giữa việc sử dụng AI như một công cụ và đưa AI vào vận hành doanh nghiệp.
Trong bài AI Agent khác ChatGPT thế nào trong doanh nghiệp?, sự khác biệt cốt lõi không nằm ở giao diện hội thoại mà ở khả năng AI tham gia vào workflow, sử dụng dữ liệu và công cụ trong phạm vi được kiểm soát. Khi đi đến production, những phần “xung quanh AI” thường trở nên quan trọng không kém chính model.
Một AI Agent production thực chất là một hệ thống
Khi nhìn AI Agent như một chatbot nâng cấp, doanh nghiệp rất dễ đánh giá thấp độ phức tạp của production. Một Agent thực tế có thể cần kết hợp nhiều thành phần: AI model để hiểu ngôn ngữ và context; API để truy cập hệ thống; authentication và permission để kiểm soát quyền; business logic cho những quyết định xác định; workflow engine để điều phối; knowledge retrieval để lấy tài liệu; logging để ghi lại hành động; monitoring để phát hiện lỗi; và Human-in-the-loop để xử lý những tình huống cần judgment.
Vì vậy, một kiến trúc AI Agent có thể được nhìn theo chuỗi:
Business Process → Enterprise Data → CRM / ERP / SaaS / Internal Systems → Integration Layer → AI Agent → Business Rules → Human Control → Action → Monitoring → Improvement.
Nếu một mắt xích không đủ tốt, Agent có thể hoạt động tốt trong demo nhưng gặp vấn đề khi vận hành.
Ví dụ, model có thể hiểu yêu cầu chính xác nhưng API trả dữ liệu cũ. Agent có thể tìm đúng policy nhưng người dùng không có quyền truy cập tài liệu đó. AI có thể chuẩn bị hành động đúng nhưng workflow không có cơ chế rollback khi hệ thống đích gặp lỗi.
Do đó, “AI Agent Development” trong môi trường doanh nghiệp không nên được hiểu đơn giản là phát triển prompt hoặc orchestration cho LLM. Nó là system engineering có AI ở bên trong.
Requirement của dự án AI thường không rõ ngay từ đầu
Trong phát triển phần mềm truyền thống, một mô hình quen thuộc là business chuẩn bị requirement, đội phát triển phân tích, estimate rồi xây hệ thống.
Nhưng với AI Agent, requirement thường chưa rõ ở giai đoạn đầu.
Một Sales Director có thể nói: “Tôi muốn AI hỗ trợ Sales.” Một COO có thể nói: “Tôi muốn tự động hóa Back Office.” Customer Service có thể yêu cầu: “Chúng tôi muốn Agent trả lời khách hàng.”
Đây là những nhu cầu hợp lý nhưng chưa phải requirement đủ để development.
Đội dự án còn phải hiểu Sales đang mất thời gian ở đâu, Back Office đang thực hiện những thao tác nào, loại customer request nào xuất hiện nhiều nhất, dữ liệu nằm trong hệ thống nào và bước nào thực sự cần khả năng của AI.
Đó là lý do bài Đừng bắt đầu dự án AI bằng công nghệ: 5 câu hỏi để tìm đúng quy trình cần tự động hóa đặt business workflow trước technology selection.
Với AI, requirement không phải lúc nào cũng là thứ được bàn giao cho engineering. Trong nhiều trường hợp, requirement cần được khám phá cùng business trong quá trình đầu tiên của dự án.
Đây là một trong những khu vực FDE có thể tạo ra khác biệt.
FDE là gì trong bối cảnh triển khai AI?
Forward Deployed Engineer không đơn giản là một kỹ sư được cử đến làm việc onsite. Điểm quan trọng hơn nằm ở cách họ tham gia vào bài toán.
Thay vì bắt đầu bằng câu hỏi:
“Anh muốn chúng tôi xây gì?”
FDE bắt đầu gần hơn với:
“Doanh nghiệp đang muốn giải quyết vấn đề gì, và công việc hiện tại đang diễn ra như thế nào?”
Điều này thay đổi thứ tự của quá trình phát triển.
Mô hình truyền thống có thể là:
Requirement → Proposal → Development → Delivery.
Trong khi cách tiếp cận FDE gần hơn với:
Business Problem → Workflow Discovery → Bottleneck → Use Case → Experiment → KPI → Integration → Production → Iteration.
Engineering vì vậy không chỉ xuất hiện sau khi requirement đã hoàn thiện. Kỹ sư tham gia vào quá trình làm rõ chính requirement đó.
FDE không thay thế business consultant hay software engineer
FDE thường nằm ở giao điểm giữa hai vai trò.
Business consultant có thể giúp doanh nghiệp xác định vấn đề, quy trình và định hướng cải thiện. Software engineer có thể xây hệ thống dựa trên yêu cầu kỹ thuật.
FDE cần có khả năng đi qua cả hai phía: đủ gần business để hiểu workflow thực tế, nhưng cũng đủ sâu về engineering để biết ý tưởng nào có thể triển khai, dữ liệu nào cần truy cập, hệ thống nào cần integration và trade-off kỹ thuật nằm ở đâu.
Ví dụ, business có thể nói:
“Chúng tôi muốn giảm thời gian chuẩn bị trước cuộc họp của Sales.”
Một cách tiếp cận thuần tư vấn có thể dừng ở việc đề xuất một Sales AI Assistant.
Một cách tiếp cận thuần development có thể yêu cầu specification chi tiết trước khi estimate.
FDE sẽ tiếp tục đi sâu: Sales đang chuẩn bị những gì? Thông tin nằm trong CRM hay email? Meeting history được lưu ở đâu? Proposal có version management không? Những dữ liệu nào thực sự cần cho mỗi cuộc họp? Output nào giúp Sales tiết kiệm thời gian?
Từ đó mới hình thành workflow cụ thể. Đây cũng là hướng được phân tích trong bài AI Agent cho Sales: Tự động hóa trước và sau cuộc họp.
Bước 1: Bắt đầu từ công việc thật, không bắt đầu từ danh sách tính năng
Một workshop AI dễ rơi vào tình trạng brainstorming hàng chục ý tưởng: AI chatbot, AI báo cáo, AI tìm kiếm tài liệu, AI Sales, AI Customer Service, AI Agent nội bộ.
Danh sách có thể rất dài nhưng chưa nói được use case nào nên làm trước.
FDE cần đi xuống cấp độ workflow. Thay vì hỏi “Anh muốn AI làm gì?”, có thể hỏi nhân viên mô tả một ngày làm việc, những hệ thống thường xuyên phải mở, những thao tác lặp lại, dữ liệu phải tìm kiếm và những điểm khiến công việc bị dừng lại.
Ví dụ, thay vì use case “AI cho Sales”, vấn đề có thể được thu hẹp thành: Sales mất 30 phút trước mỗi cuộc họp để tìm thông tin khách hàng từ CRM, email và proposal cũ.
Thay vì “AI cho Back Office”, use case có thể trở thành: mỗi tháng bộ phận Operations xử lý 2.000 hồ sơ và mất trung bình tám phút để đọc, phân loại và nhập dữ liệu.
Use case càng cụ thể, khả năng đo giá trị càng cao.
Bước 2: Tách workflow để xác định AI thực sự cần xuất hiện ở đâu
Sau khi hiểu workflow, bước tiếp theo không phải là đặt AI Agent lên toàn bộ quy trình.
Workflow cần được phân tách.
Một số bước chỉ chuyển dữ liệu và phù hợp với API. Một số bước có điều kiện cố định nên dùng business rule. Hệ thống legacy không có API có thể cần RPA. Những bước phải hiểu email, tài liệu hoặc context có thể sử dụng AI. Khi hệ thống cần lựa chọn công cụ hoặc đường xử lý dựa trên context, Agent mới trở nên phù hợp hơn.
Đây chính là nguyên tắc trong bài AI Agent, RPA, API hay Workflow Automation: Doanh nghiệp nên dùng gì cho từng bài toán?.
Một kiến trúc tốt không cần tối đa hóa AI. Nếu workflow hoạt động tốt nhất với 70% API và business logic, 20% AI và 10% Human Decision, đó có thể là thiết kế tốt hơn một hệ thống “100% Agent”.
Bước 3: PoC phải kiểm chứng một business hypothesis
Một PoC dễ bị đánh giá bằng câu hỏi: “AI có chạy được không?”
Nhưng trong môi trường doanh nghiệp, câu hỏi nên là: “Nếu AI được đặt vào workflow này, chỉ số vận hành nào có thể thay đổi?”
Giả sử một nhân viên mất trung bình 15 phút để xử lý một loại hồ sơ. PoC có thể kiểm tra liệu AI + automation có thể giảm phần chuẩn bị xuống còn một khoảng thời gian thấp hơn trong khi vẫn giữ chất lượng ở mức chấp nhận được.
Hoặc Sales mất trung bình 25 phút chuẩn bị cho một cuộc họp. PoC có thể kiểm tra khả năng tự động tổng hợp context từ CRM, email và tài liệu liên quan.
Khi đó, PoC không chỉ có demo output. Nó có baseline và KPI.
Cách tiếp cận này giúp doanh nghiệp tránh một tình trạng phổ biến: PoC được đánh giá là “thành công” vì AI tạo ra kết quả ấn tượng, nhưng không ai biết triển khai nó sẽ cải thiện business metric nào.
Bước 4: Integration phải được nghĩ đến sớm hơn
Nhiều PoC sử dụng dữ liệu được chuẩn bị thủ công. Điều này hợp lý để kiểm tra hypothesis nhanh, nhưng nếu integration chỉ được xem xét sau khi PoC hoàn tất, doanh nghiệp có thể phát hiện quá muộn rằng production khó hơn rất nhiều.
Ví dụ, Agent cần dữ liệu CRM nhưng API bị giới hạn. Tài liệu nằm trong nhiều repository với permission khác nhau. Hệ thống legacy không có API. Customer ID giữa các hệ thống không đồng nhất. Dữ liệu cần thiết không được lưu ở dạng có thể truy xuất.
Những vấn đề này không nhất thiết phải được giải quyết hoàn toàn trước PoC, nhưng cần được nhận diện đủ sớm để biết solution có khả năng production hóa hay không.
FDE vì vậy phải nhìn đồng thời vào business feasibility và technical feasibility.
Một use case có business value rất lớn nhưng không thể tiếp cận dữ liệu cần thiết có thể chưa phải ứng viên tốt cho giai đoạn đầu.
Bước 5: Thiết kế quyền hành động trước khi Agent được đưa vào production
Một Agent có thể hoạt động rất tốt khi chỉ đọc dữ liệu. Nhưng khi được phép thực hiện hành động, risk profile thay đổi.
Agent có được gửi email không? Được cập nhật CRM không? Được tạo task không? Được thay đổi trạng thái đơn hàng không? Trường hợp nào cần approval?
Những câu hỏi này phải trở thành một phần của solution design.
Bài Human-in-the-loop: Vì sao AI Agent vẫn cần con người? đã phân tích cách quyền hành động có thể được mở rộng theo chuỗi Read → Suggest → Prepare → Approve → Execute.
Điểm quan trọng là không cần đi từ demo thẳng đến full autonomy.
Một Agent production đầu tiên có thể chỉ chuẩn bị hành động và yêu cầu con người approve. Khi doanh nghiệp có đủ dữ liệu về chất lượng, những case rủi ro thấp mới dần được chuyển sang tự động.
Đây là cách automation tăng dựa trên evidence thay vì kỳ vọng.
Bước 6: Production phải được thiết kế cho cả failure path
Demo thường tập trung vào trường hợp mọi thứ diễn ra đúng. Production phải quan tâm cả khi mọi thứ diễn ra sai.
Nếu API timeout thì sao? Nếu tài liệu không đọc được? Nếu Agent không tìm thấy customer record? Nếu hai nguồn dữ liệu mâu thuẫn? Nếu policy không bao phủ trường hợp đang xử lý? Nếu AI không đủ confidence?
Một Agent production không thể chỉ có happy path.
Nó cần stop condition, retry logic, fallback, escalation và logging. Trong một số trường hợp, giải pháp đúng là dừng workflow và chuyển cho con người kèm toàn bộ context đã thu thập.
Đây cũng là lý do “AI hoạt động chính xác bao nhiêu phần trăm” không phải câu hỏi duy nhất. Một hệ thống có thể chấp nhận một mức độ không chắc chắn nhất định nếu nó biết khi nào cần dừng và không biến sự không chắc chắn thành hành động có rủi ro.
Bước 7: Sau Go-Live, dự án AI chưa kết thúc
Phần mềm truyền thống cũng cần vận hành và cải tiến, nhưng với AI Agent, vòng lặp này đặc biệt quan trọng vì doanh nghiệp sẽ học được rất nhiều từ dữ liệu sử dụng thực tế.
Những case nào Agent xử lý tốt? Những loại request nào thường xuyên escalation? Người dùng sửa output ở đâu? Dữ liệu nào thường thiếu? Tool nào thường lỗi? Business rule nào chưa bao phủ đủ?
Những thông tin này giúp đội dự án xác định điểm cải thiện tiếp theo.
Một vòng lặp có thể diễn ra như:
Deploy → Observe → Measure → Analyze Exceptions → Improve → Expand.
Những exception ban đầu không chỉ là lỗi. Chúng là dữ liệu để hiểu workflow sâu hơn.
Nếu một loại exception xuất hiện hàng trăm lần, có thể vấn đề không nằm ở model mà ở thiếu integration, thiếu policy hoặc business process chưa được chuẩn hóa.
FDE vì vậy không chỉ giúp đưa Agent đến Go-Live. Giá trị quan trọng nằm ở việc tiếp tục nối feedback từ operation trở lại engineering.
FDE thay đổi cách Business và Engineering làm việc với nhau
Trong nhiều dự án truyền thống, business viết requirement rồi giao cho IT. IT phát triển, bàn giao và chờ feedback.
Với AI Agent, mô hình này dễ tạo ra khoảng cách vì business không phải lúc nào cũng biết chính xác AI có thể làm gì, trong khi engineering không thể hiểu đầy đủ workflow chỉ từ tài liệu requirement.
FDE tạo ra một vòng lặp ngắn hơn:
Business Problem ↔ FDE ↔ Prototype ↔ User Feedback ↔ Engineering ↔ Production Data.
Business không cần mô tả hoàn hảo solution ngay từ đầu. Engineering cũng không cần chờ một specification hoàn chỉnh mới bắt đầu học về vấn đề.
Hai bên cùng khám phá use case thông qua workflow, prototype và dữ liệu thực tế.
Điều này đặc biệt phù hợp với AI, nơi một số câu hỏi chỉ có thể được trả lời sau khi thử nghiệm với dữ liệu và người dùng thật.
Không phải dự án nào cũng cần FDE
Cũng giống AI Agent, FDE không nên được xem như giải pháp cho mọi dự án.
Nếu requirement đã rất rõ, hệ thống tiêu chuẩn, integration đơn giản và phạm vi phát triển ổn định, mô hình software development truyền thống có thể hoàn toàn phù hợp.
FDE trở nên có giá trị hơn khi business problem rõ nhưng solution chưa rõ; workflow cần được khám phá; nhiều hệ thống và dữ liệu phải được kết nối; AI capability cần được kiểm chứng bằng PoC; hoặc requirement có khả năng thay đổi khi người dùng bắt đầu thử nghiệm.
Đây là một điểm quan trọng. Mục tiêu không phải biến mọi kỹ sư thành FDE hoặc gọi mọi dự án AI là FDE project.
FDE là cách tiếp cận phù hợp với những bài toán mà khoảng cách giữa business problem và technical solution chưa thể được giải quyết chỉ bằng một tài liệu requirement ban đầu.
Từ “AI có thể làm được” đến “AI đang tạo ra giá trị”
Có thể nhìn hành trình triển khai AI Agent qua bốn câu hỏi.
Can it work? – AI có thể thực hiện task không?
Can it work with our systems? – Nó có thể hoạt động với dữ liệu và hệ thống của doanh nghiệp không?
Can it work safely in our workflow? – Permission, Human-in-the-loop, exception và monitoring đã đủ chưa?
Does it create measurable value? – Workflow mới có thực sự cải thiện KPI hay không?
Nhiều demo chỉ trả lời câu hỏi đầu tiên.
Một PoC tốt bắt đầu trả lời câu hỏi thứ hai và thứ tư.
Một hệ thống production phải trả lời cả bốn.
Khoảng cách giữa những câu hỏi đó chính là nơi phần lớn công việc thực sự của AI transformation diễn ra.
Synora tiếp cận AI Agent từ workflow đến production
Tại Synora, AI Agent Development được tiếp cận cùng mô hình FDE thay vì bắt đầu bằng việc yêu cầu doanh nghiệp chuẩn bị một requirement AI hoàn chỉnh.
Điểm xuất phát có thể là một vấn đề rất cụ thể: Sales đang mất nhiều thời gian chuẩn bị cuộc họp, Customer Service phải tìm thông tin từ quá nhiều nguồn, Back Office đang xử lý thủ công một lượng lớn tài liệu hoặc Manager mất nhiều thời gian tổng hợp báo cáo.
Từ đó, workflow được phân tích để xác định bottleneck, dữ liệu, hệ thống liên quan và business KPI. Solution có thể kết hợp AI Agent, API, workflow automation, business logic và Human-in-the-loop thay vì mặc định mọi bước đều cần AI.
Mục tiêu cuối cùng không phải tạo ra một Agent có demo ấn tượng. Mục tiêu là đưa được một phần workflow vào vận hành, đo được tác động và tiếp tục cải thiện dựa trên dữ liệu thực tế.
Đã có AI demo? Câu hỏi tiếp theo là làm thế nào để đưa nó vào workflow thật
Nếu doanh nghiệp đã có một AI PoC hoặc ý tưởng AI Agent nhưng chưa rõ cách kết nối dữ liệu, hệ thống, permission, Human-in-the-loop và KPI để tiến tới production, bước tiếp theo không nhất thiết là tiếp tục thêm tính năng cho demo.
Hãy quay lại workflow và xác định khoảng cách giữa “AI có thể làm task” với “doanh nghiệp có thể vận hành task đó bằng AI mỗi ngày”.
Synora có thể cùng doanh nghiệp đi từ Business Problem → Workflow Discovery → PoC → Integration → Production và tiếp tục cải thiện sau Go-Live theo cách tiếp cận FDE.
Trao đổi về AI Agent × FDE
Đã có ý tưởng hoặc PoC AI? Hãy bắt đầu bằng việc xác định những gì còn thiếu để đưa giải pháp vào workflow thực tế.
Bắt đầu trao đổi- AI trả lời đúng trên dữ liệu mẫu
- Kết nối dữ liệu và hệ thống đang dùng
- Phân quyền, approval và xử lý ngoại lệ
- Người dùng thật áp dụng hằng ngày