วางด่านอนุมัติให้ AI agent: ปุ่ม Approve ต้องมาพร้อม checkpoint

หากต้องให้คนตรวจ AI agent ก่อนส่งอีเมล จองบริการ หรือทำรายการที่มีผลจริง ให้วางด่านหลัง agent เสนอ tool call และก่อนเรียกบริการภายนอก บันทึกข้อเสนอพร้อมสถานะงานที่หยุดไว้ใน checkpoint จากนั้นรอคำตัดสินว่าอนุมัติ แก้พารามิเตอร์ หรือปฏิเสธ เมื่อคำตอบมาถึง ระบบจึงโหลดงานเดิมและเดินต่อในทางที่ตรงกับคำตัดสิน ปุ่ม Approve ส่งคำตอบของคน ส่วน checkpoint ทำให้คำตอบนั้นกลับไปถึงงานที่รออยู่ได้แม้โปรเซสเดิมสิ้นสุดแล้ว

ตัวอย่างของ LangGraph.js วาง interrupt() ไว้ต้นเครื่องมือ bookHotel ก่อนตรรกะการจอง แล้วใช้ Command พร้อมค่า resume ส่งการยอมรับหรือชื่อโรงแรมที่แก้ไขกลับเข้า thread เดิม ตัวอย่างใช้ checkpointer ในหน่วยความจำและ thread ID เพื่อสาธิตการกลับมาทำต่อ ส่วนงานที่ต้องอยู่รอดข้ามการปิดโปรเซสต้องเก็บสถานะในฐานข้อมูล ด่านอนุมัติจึงมีทั้งจุดหยุด วิธีจับคู่คำตอบ และที่เก็บสถานะที่เหมาะกับระยะเวลารอ

หยุดตรงข้อเสนอ ไม่ใช่หลังเครื่องมือทำงาน

เริ่มจากแยกช่วงที่ agent เสนอการกระทำออกจากช่วงที่ระบบลงมือทำจริง ข้อเสนอควรระบุชื่อเครื่องมือและพารามิเตอร์ที่ตรวจรูปแบบได้ เช่น ผู้รับ หัวเรื่อง และเนื้อหาอีเมล หรือชื่อบริการ วันเวลา และเงื่อนไขการจอง ตัวดำเนินการภายนอกต้องรอจนกว่าข้อเสนอนั้นจะมีคำตัดสินที่ใช้ได้ การแสดงตัวอย่างอีเมลให้คนเห็นหลังส่งไปแล้วไม่ใช่ด่านอนุมัติก่อนส่ง

กำหนดนโยบายที่ฝั่งเซิร์ฟเวอร์ว่า tool call ใดต้องผ่านคนตรวจ โดยพิจารณาผลที่เกิดขึ้น สิทธิ์ที่ใช้ และขอบเขตข้อมูล เครื่องมืออ่านข้อมูลเพื่อร่างคำตอบอาจเดินต่อได้ ขณะที่เครื่องมือส่งข้อความ สร้างรายการจอง หรือแก้ข้อมูลที่คนอื่นใช้ควรหยุดตามนโยบาย การซ่อนปุ่มในหน้าจอไม่พอ เพราะตัวดำเนินการอาจถูกเรียกผ่านเส้นทางอื่นได้

ลำดับการทำงานที่ตรวจสอบย้อนหลังได้ควรเป็นดังนี้:

1. รับข้อเสนอจาก agent แล้วตรวจชื่อเครื่องมือ ชนิดข้อมูลของพารามิเตอร์ และสิทธิ์ที่ agent มีในการเสนอรายการนั้น หากข้อเสนอไม่ผ่านเงื่อนไขพื้นฐาน ให้ส่งข้อผิดพลาดกลับก่อนสร้างคำขออนุมัติ
2. สร้างตัวระบุเฉพาะของรายการรอ ผูกกับ thread และ tool call ที่เสนอ บันทึกสถานะงานลง checkpoint พร้อมข้อมูลที่ผู้อนุมัติต้องเห็น แล้วหยุดก่อนเรียกเครื่องมือภายนอก
3. แสดงผลที่จะเกิดขึ้นอย่างชัดเจน เช่น ปลายทางและเนื้อหาที่จะส่ง หรือบริการและเงื่อนไขที่จะจอง ให้ผู้มีสิทธิ์เลือกอนุมัติตามเดิม แก้ไข หรือปฏิเสธรายการที่แสดงอยู่
4. รับคำตอบที่เซิร์ฟเวอร์ ตรวจสิทธิ์และสถานะรายการ บันทึกคำตัดสินกับพารามิเตอร์ฉบับสุดท้าย แล้วจึงปลุกงานเดิมให้เดินไปยังขั้นตอนที่เหมาะสม
5. หลังเครื่องมือทำงาน ให้เก็บผลลัพธ์หรือสถานะที่ยังไม่แน่ชัดไว้กับรายการเดียวกัน เพื่อให้การแสดงผลแก่ผู้ใช้และการลองใหม่อ้างอิงการกระทำเดิม

หน้าตรวจสอบควรแสดงสิ่งที่คนกำลังอนุมัติ ไม่ใช่เพียงชื่อเครื่องมือ ปุ่ม Approve สำหรับการส่งอีเมลต้องอยู่ข้างผู้รับ เนื้อหาที่จะส่ง และบัญชีผู้ส่งที่ใช้ ส่วนงานจองควรเห็นบริการ ช่วงเวลา และข้อผูกพันที่เกิดขึ้น หากข้อมูลบางส่วนยังว่างหรืออธิบายผลไม่ได้ ให้หยุดไว้เพื่อแก้ข้อเสนอ แทนการให้คนรับรองการกระทำที่มองไม่ครบ

คำขออนุมัติหนึ่งรายการควรผูกกับพารามิเตอร์หนึ่งฉบับที่ระบุได้ หาก agent สร้างข้อเสนอใหม่ระหว่างรอ หรือข้อมูลต้นทางเปลี่ยนจนผลการกระทำเปลี่ยน ให้สร้างรุ่นใหม่และทำให้คำตอบต่อรุ่นเก่าใช้ไม่ได้ วิธีนี้ป้องกันสถานการณ์ที่ผู้อนุมัติเห็นอีเมลฉบับหนึ่ง แต่ระบบส่งอีกฉบับเพราะสถานะถูกแก้หลังเปิดหน้าตรวจสอบ

checkpoint ต้องจำทั้งตำแหน่งงานและรายการที่คนเห็น

checkpoint มีหน้าที่ให้ระบบกลับไปทำงานจากจุดพักได้ โดยไม่ต้องขอให้โมเดลสร้างข้อเสนอเดิมขึ้นมาใหม่ นอกจากสถานะของ agent แล้ว ระบบควรมีระเบียนการอนุมัติที่ค้นด้วยตัวระบุเดียวกันได้ ระเบียนนี้ใช้ตอบว่าใครกำลังรอเรื่องใด ใครตัดสินใจ และเครื่องมือได้รับอนุญาตให้ทำอะไร การเก็บเพียงข้อความแชตล่าสุดไม่พอสำหรับจับคู่คำตอบกับการกระทำที่รอ

อย่างน้อยข้อมูลที่เก็บควรครอบคลุมรายการต่อไปนี้:

• ตัวระบุงานหรือ thread ID ตำแหน่งที่หยุด และตัวระบุ tool call เพื่อให้คำตอบกลับไปยังงานที่เสนอรายการนั้นจริง
• ชื่อเครื่องมือ พารามิเตอร์ที่ agent เสนอ และข้อมูลบริบทที่ทำให้คนเข้าใจผล เช่น ผู้รับอีเมลหรือเงื่อนไขการจอง
• สถานะของคำขอ เช่น รอคำตอบ อนุมัติ ปฏิเสธ หมดอายุ หรือดำเนินการแล้ว พร้อมเวลาสร้างและเวลาหมดอายุหากกำหนดไว้
• ตัวตนหรือบทบาทของผู้มีสิทธิ์ตัดสินใจ รวมถึงขอบเขตที่อนุญาตให้แก้ไขพารามิเตอร์
• รุ่นของข้อเสนอหรือค่าแฮชของพารามิเตอร์ เพื่อยืนยันว่าคำตัดสินผูกกับค่าชุดเดียวกับที่หน้าตรวจสอบแสดง
• คำตัดสิน ผู้ตัดสินใจ เวลาที่ตอบ เหตุผลเมื่อปฏิเสธ และพารามิเตอร์ฉบับที่ได้รับอนุมัติ
• ตัวระบุสำหรับป้องกันการทำซ้ำ สถานะการเรียกบริการภายนอก และผลตอบกลับเมื่อทราบผลแล้ว

การแยกสถานะงานออกจากระเบียนการอนุมัติช่วยให้แต่ละส่วนมีหน้าที่ชัดเจน checkpoint บอกว่าโปรแกรมควรกลับไปทำขั้นตอนไหน ระเบียนการอนุมัติบอกว่ารายการใดผ่านเงื่อนไขแล้วและใครเป็นผู้ตอบ ทั้งสองส่วนต้องอ้างถึงข้อเสนอฉบับเดียวกัน มิฉะนั้นคำว่าอนุมัติในหน้าจออาจไม่มีความหมายต่อขั้นตอนที่ agent กำลังจะทำ

ที่เก็บสถานะต้องสอดคล้องกับเวลารอ หากผู้ใช้ตอบได้หลังโปรเซสรีสตาร์ต checkpoint และระเบียนการอนุมัติต้องอยู่ในที่เก็บถาวรที่โปรเซสใหม่เข้าถึงได้ ตัวเก็บข้อมูลในหน่วยความจำช่วยสาธิตลำดับการทำงาน แต่จะหายไปพร้อมโปรเซส จึงไม่รองรับคำขอที่รอคนตอบข้ามการปิดบริการ

เก็บข้อมูลที่จำเป็นต่อการตัดสินใจและการกลับมาทำต่อเท่านั้น หน้าตรวจสอบควรเห็นปลายทางและเนื้อหาที่จะส่ง แต่ไม่ควรได้รับข้อมูลรับรองของบริการภายนอก หากข้อเสนออ้างข้อมูลอ่อนไหว ให้กำหนดสิทธิ์การมองเห็นของผู้ตรวจ และเก็บบันทึกการตัดสินใจในระดับที่ตรวจสอบได้โดยไม่ขยายการเปิดเผยข้อมูลเกินงานนั้น

ควรกำหนดอายุคำขอตามลักษณะการกระทำด้วย ตัวอย่างเช่น การอนุมัติช่วงเวลาจองมีความหมายต่างจากการอนุมัติข้อความอีเมลที่ไม่ขึ้นกับเวลามากนัก หากหมดอายุก่อนคนตอบ ระบบควรปิดรายการและบอกว่าต้องเสนอใหม่ เมื่อเสนอใหม่แล้ว ผู้ตรวจจะได้เห็นข้อมูลปัจจุบันแทนการกดตกลงกับเงื่อนไขเก่า

คำตอบแต่ละแบบต้องเปลี่ยนทางเดินของงาน

เมื่อมีคนกดอนุมัติ เซิร์ฟเวอร์ควรตรวจตัวตน สิทธิ์ สถานะที่ยังรอ และรุ่นของข้อเสนอที่แสดงก่อนรับคำตอบ หากทุกอย่างตรงกัน จึงบันทึกการอนุมัติและให้ตัวดำเนินการอ่านพารามิเตอร์ฉบับนั้น การตรวจเช่นนี้ต้องเกิดที่จุดรับคำตอบ ไม่ฝากไว้กับหน้าจอ เพราะลิงก์เก่าหรือคำขอที่ส่งซ้ำอาจมาถึงหลังสถานะเปลี่ยนแล้ว

การเปลี่ยนสถานะจากรอเป็นอนุมัติควรเป็นการเปลี่ยนที่มีผู้ชนะเพียงรายเดียว หากผู้มีสิทธิ์สองคนตอบเกือบพร้อมกัน คำตอบแรกที่ผ่านเงื่อนไขควรล็อกผล ส่วนคำตอบที่ตามมาควรได้รับสถานะล่าสุดกลับไป การปล่อยให้ทั้งสองคำตอบปลุกงานได้ อาจทำให้เกิดการเรียกเครื่องมือซ้ำ แม้หน้าจอของแต่ละคนจะแสดงการกดสำเร็จ

คำสั่งแก้ไขต้องผ่านการตรวจรูปแบบและกฎธุรกิจอีกครั้ง เช่น ช่องผู้รับต้องเป็นปลายทางที่อนุญาต วันที่จองต้องยังใช้ได้ และค่าที่แก้ต้องอยู่ในขอบเขตสิทธิ์ของผู้อนุมัติ เก็บทั้งข้อเสนอเดิมและฉบับที่แก้ เพื่อบอกได้ว่า agent เสนออะไรและคนเปลี่ยนอะไร หากการแก้ไขเปลี่ยนสาระสำคัญ ควรให้ผู้อนุมัติเห็นค่าฉบับสุดท้ายก่อนยืนยัน

การแก้พารามิเตอร์อาจเปลี่ยนผู้มีสิทธิ์อนุมัติด้วย สมมติว่าผู้ตรวจมีสิทธิ์อนุมัติอีเมลไปยังกลุ่มภายใน แต่แก้ปลายทางเป็นผู้รับภายนอก ระบบต้องใช้นโยบายของปลายทางใหม่ ไม่ถือว่าการเปิดหน้าตรวจสอบเดิมให้สิทธิ์กับรายการที่ถูกเปลี่ยนแล้ว หลักเดียวกันใช้กับวงเงิน เงื่อนไขบริการ หรือบัญชีที่ agent จะใช้ทำรายการ

คำสั่งปฏิเสธควรปิดทางเดินที่เรียกเครื่องมือจริง บันทึกเหตุผลสั้น ๆ ที่อ่านได้ แล้วส่งผลกลับให้ส่วนที่ควบคุมงานตัดสินว่าจะยุติหรือให้ agent เสนอทางเลือกใหม่ หากให้เสนอใหม่ คำขอใหม่ต้องมีตัวระบุและพารามิเตอร์ของตนเอง คำอนุมัติที่ผูกกับรายการเก่าจะไม่ถูกนำไปใช้กับข้อเสนอถัดไป

การปฏิเสธกับการขอแก้ไขมีผลต่างกัน การปฏิเสธบอกว่ารายการที่เสนอไม่ควรเกิดขึ้น ส่วนการแก้ไขยังอนุญาตให้เกิดการกระทำภายใต้ค่าที่คนกำหนด หากหน้าใช้งานมีเพียงปุ่ม Approve และ Reject ผู้ใช้ที่ต้องการแก้ชื่อโรงแรมหรือผู้รับอีเมลอาจต้องปฏิเสธแล้วรอ agent เสนอใหม่ การมีทางแก้พารามิเตอร์ช่วยรักษาความตั้งใจของงานโดยยังบันทึกได้ว่าค่าฉบับใดได้รับอนุญาต

หลังรับคำตัดสิน อย่าให้ agent เลือกเองว่าจะตีความคำตอบว่าเป็นการอนุมัติหรือไม่ คำตอบจากคนควรเป็นข้อมูลแบบมีชนิดชัดเจน เช่น approve, edit หรือ reject แล้วให้โค้ดกำหนดทางเดินของแต่ละชนิด ข้อความอิสระของผู้ตรวจอาจแนบเป็นเหตุผลหรือคำแนะนำได้ แต่ไม่ควรเป็นสัญญาณเดียวที่ปลดล็อกการเรียกเครื่องมือสำคัญ

รอคำตอบทันทีและรอข้ามชั่วโมงใช้วงจรต่างกัน

ถ้าผู้ใช้กำลังอยู่ในหน้าสนทนาและตอบได้ทันที ระบบอาจรอคำตอบระหว่างรอบที่ agent ยังทำงานอยู่ วิธีนี้เรียบง่ายสำหรับการกดยืนยันสั้น ๆ แต่จะผูกความคืบหน้ากับรอบการทำงานที่กำลังเปิดอยู่ หากผู้ตรวจกลับมาตอบภายหลัง ระบบควรจบรอบ บันทึกสถานะ แล้วเปิดรอบใหม่จากข้อมูลที่เก็บไว้

คู่มือ human-in-the-loop ของ AutoGen ระบุว่า UserProxyAgent ที่รอคำตอบระหว่างการทำงานจะบล็อกทีมและอยู่ในสถานะที่บันทึกเพื่อกลับมาทำต่อไม่ได้ จึงเหมาะกับการตอบสั้นที่ต้องเกิดทันที สำหรับการสื่อสารแบบ asynchronous คู่มือเสนอให้ทีมจบรอบ แอปพลิเคชันบันทึก state ลงที่เก็บถาวร แล้วเริ่มรอบถัดไปเมื่อ feedback มาถึง ความแตกต่างนี้เป็นเรื่องวงจรการทำงาน ไม่ใช่เพียงการเปลี่ยนหน้าจากแชตเป็นกล่องแจ้งเตือน

ในงานที่รอนาน หน้าอนุมัติควรอ่านรายการจากที่เก็บถาวรโดยใช้ตัวระบุคำขอ ไม่อาศัยการเชื่อมต่อของหน้าแชตเดิม ลิงก์แจ้งเตือนอาจพาผู้ตรวจไปยังรายการที่รอได้ แต่ลิงก์นั้นยังต้องผ่านการตรวจตัวตนและสิทธิ์ ผู้ตรวจที่เปิดหลายแท็บควรเห็นสถานะล่าสุดเมื่อกลับมาที่หน้าเดิม

เมื่อคำตอบมาถึง เซิร์ฟเวอร์ต้องตรวจว่ารายการยังรออยู่และพารามิเตอร์ยังเป็นรุ่นที่แสดง จากนั้นบันทึกคำตอบก่อนสั่งให้ตัวทำงานโหลด checkpoint ด้วยตัวระบุงานเดิม หากปลุกงานไม่สำเร็จ คำตอบยังคงอยู่ในที่เก็บถาวรเพื่อให้ระบบลองปลุกใหม่ได้โดยไม่ขอให้คนกดซ้ำ การตอบรับจากหน้าจอจึงควรแยกได้ว่ารับคำตัดสินแล้วหรือเครื่องมือภายนอกทำงานเสร็จแล้ว

ถ้าคำขอหมดอายุ ถูกยกเลิก หรือมีคนอื่นตัดสินไปแล้ว ให้คืนสถานะจริงแก่ผู้ที่ตอบช้าและไม่ปลุกงานอีก การกดซ้ำหลังอนุมัติไม่ควรสร้างคำตัดสินใหม่ ส่วนการเปิดลิงก์เก่าหลัง agent เสนอรายการฉบับใหม่ต้องพาไปดูรายการที่ถูกต้อง ไม่ใช้คำตอบเดิมกับข้อเสนอใหม่โดยอัตโนมัติ

ระบบที่มีงานรอจำนวนมากควรให้ผู้ตรวจเห็นว่าแต่ละรายการรอเรื่องใด ใครเสนอ และการตัดสินใจมีผลเมื่อใด หากผู้ตรวจออกจากระบบหรือสิทธิ์ถูกถอนระหว่างรอ การตรวจสิทธิ์ตอนรับคำตอบต้องใช้สิทธิ์ปัจจุบัน การเคยได้รับแจ้งเตือนไม่ใช่สิทธิ์ถาวรในการอนุมัติรายการนั้น

checkpoint ไม่แทนการกันรายการซ้ำ

การกลับมาถึงขั้นตอนเดิมได้ไม่ได้แปลว่าผลภายนอกจะเกิดเพียงครั้งเดียว สมมติว่า agent ส่งคำสั่งจองแล้วบริการปลายทางรับคำขอ แต่โปรเซสหยุดก่อนบันทึกผลสำเร็จ เมื่อระบบฟื้นขึ้นมา สถานะในเครื่องของเราอาจยังบอกว่าไม่เสร็จ หากเรียกบริการอีกครั้งโดยไม่มีวิธีกันซ้ำ ก็อาจเกิดการจองอีกหนึ่งรายการ

ให้กำหนดตัวระบุการกระทำที่อนุมัติแล้วแยกจากตัวระบุการพยายามเรียกบริการ ตัวระบุการกระทำคงเดิมเมื่อเครือข่ายขาดหรือโปรเซสลองใหม่ ส่วนบันทึกการพยายามแต่ละครั้งช่วยสืบได้ว่าเกิดอะไรขึ้น การออกคีย์ใหม่ทุกครั้งที่ลองส่ง จะทำให้ปลายทางมองว่าเป็นคำขอใหม่และลดประโยชน์ของการป้องกันซ้ำ

หากบริการปลายทางรองรับ idempotency key ให้ส่งคีย์เดียวกันกับคำขอฉบับที่ได้รับอนุมัติทุกครั้งที่ลองทำซ้ำ เอกสาร idempotent requests ของ Stripe อธิบายการใช้คีย์กับคำขอสร้างหรือแก้ข้อมูล เพื่อให้ลองส่งอีกครั้งหลังการเชื่อมต่อผิดพลาดโดยไม่สร้างการดำเนินการเดิมซ้ำ หลักนี้ใช้ได้เฉพาะเมื่อบริการปลายทางรองรับและใช้คีย์ตามเงื่อนไขของบริการนั้น

คีย์ต้องผูกกับพารามิเตอร์ฉบับสุดท้าย ไม่ใช่ข้อเสนอแรกที่ agent สร้าง หากคนแก้ชื่อโรงแรมก่อนอนุมัติ ให้บันทึกฉบับที่แก้เป็นการกระทำที่จะดำเนินการ แล้วใช้คีย์ของการกระทำนั้นกับการลองซ้ำทุกครั้ง อย่านำคีย์ของคำขอเดิมไปใช้กับพารามิเตอร์ชุดใหม่ การแก้ไขก่อนลงมือทำกับการลองส่งรายการเดิมซ้ำเป็นคนละเหตุการณ์

หากปลายทางไม่มีระบบรับคีย์กันซ้ำ ให้เก็บสถานะการดำเนินการในระบบของตนและใช้ตัวระบุรายการเดียวกันตลอดวงจร ก่อนลองใหม่หลังผลไม่ชัดเจน ควรตรวจว่าปลายทางสร้างรายการไปแล้วหรือไม่ผ่านวิธีที่บริการนั้นมี เช่น ค้นด้วยตัวอ้างอิงของคำขอ การบันทึกว่าเริ่มส่งแล้วในฐานข้อมูลของเราเพียงอย่างเดียวบอกไม่ได้ว่าปลายทางรับคำขอสำเร็จหรือยัง

สถานะผลลัพธ์จึงควรแยกอย่างน้อยระหว่างยังไม่ส่ง ส่งแล้วและทราบผล กับส่งแล้วแต่ผลไม่แน่ชัด งานที่ผลไม่แน่ชัดต้องเข้าสู่ขั้นตรวจสอบก่อนลองส่งใหม่ การเหมารวมทุกข้อผิดพลาดเป็นความล้มเหลวแล้วส่งซ้ำทันทีเสี่ยงที่สุดเมื่อบริการปลายทางทำงานสำเร็จแต่คำตอบกลับมาไม่ถึงเรา

ทดสอบจุดที่คำตอบและสถานะอาจสวนกัน

ก่อนเปิดใช้กับเครื่องมือที่มีผลจริง ให้ทดสอบเส้นทางอนุมัติด้วยบริการจำลองหรือสภาพแวดล้อมทดสอบที่สังเกตจำนวนการเรียกได้ จุดสำคัญไม่ใช่เพียงว่าปุ่มกดได้ แต่คือหลังสถานะเปลี่ยนแล้วมีคำสั่งภายนอกเกิดขึ้นกี่ครั้ง และเกิดจากพารามิเตอร์ฉบับใด การทดสอบควรครอบคลุมทั้งหน้าตรวจสอบ ตัวเก็บสถานะ และตัวดำเนินการ

• ให้คนกด Approve ซ้ำ เปิดคำขอเดียวกันหลายแท็บ หรือให้ผู้มีสิทธิ์หลายคนตอบพร้อมกัน แล้วตรวจว่ามีคำตัดสินที่ชนะเพียงรายการเดียว
• แก้พารามิเตอร์ก่อนอนุมัติ แล้วตรวจว่าตัวดำเนินการใช้ค่าฉบับสุดท้าย พร้อมตรวจสิทธิ์และกฎธุรกิจของค่าที่แก้ใหม่
• ปฏิเสธหรือปล่อยให้หมดอายุ แล้วลองส่งคำตอบเดิมอีกครั้ง ตรวจว่าเครื่องมือภายนอกไม่ถูกเรียก
• หยุดโปรเซสขณะรอหลายชั่วโมง เปิดโปรเซสใหม่ และส่งคำตอบผ่านช่องทางอื่น ตรวจว่าระบบโหลดงานที่ถูกต้องจาก checkpoint
• หยุดโปรเซสหลังส่งคำขอภายนอกแต่ก่อนบันทึกผล แล้วจำลองการลองใหม่ ตรวจว่าระบบตรวจผลเดิมหรือใช้คีย์กันซ้ำตามความสามารถของปลายทาง

เมื่อผ่านกรณีเหล่านี้แล้ว ควรติดตามสถานะของรายการรอและรายการที่ผลไม่แน่ชัดระหว่างใช้งานจริง รายการที่ค้างผิดปกติต้องมีเจ้าของงานและวิธีปิดสถานะโดยไม่กด Approve แทนผู้ใช้ ส่วนรายการที่ปลายทางรับไปแล้วแต่ระบบยังไม่ทราบผลต้องได้รับการตรวจสอบก่อนปลุก agent ให้ทำขั้นตอนถัดไป วงจรอนุมัติจะครบก็ต่อเมื่อคำตอบของคนผูกกับข้อเสนอที่เห็น งานกลับมาทำต่อได้ และผลภายนอกไม่ถูกทำซ้ำเพราะการลองใหม่