สรุปจากคลิป ดูคลิปต้นฉบับ

Every API Is a Tool for Agents: บทเรียนที่ธุรกิจควรรู้

ปัญหาของการเอา AI agent ไปเชื่อมกับระบบธุรกิจ ไม่ได้อยู่ที่ AI ฉลาดไม่พอเสมอไป แต่อยู่ที่ “มือ” ของมันยังไม่ดีพอต่างหาก ต่อให้ model ตอบเก่งแค่ไหน ถ้ามันเข้าถึง API, เครื่องมือ, หรือระบบงานจริงไม่ได้ มันก็ยังทำงานแทนเราไม่ได้อยู่ดี

นี่คือแกนสำคัญจากคลิป Every API Is a Tool for Agents ของ Matt Carey จาก Cloudflare บนช่อง AI Engineer ซึ่งพูดถึงคำถามใหญ่ของวงการว่า เราจะทำให้ API จำนวนมหาศาล กลายเป็นเครื่องมือที่ AI agent ใช้งานได้จริงอย่างไร โดยไม่ทำให้ context พัง ไม่ทำให้ระบบซับซ้อนเกินจำเป็น และไม่เปิดช่องให้เกิดความเสี่ยงด้านความปลอดภัย

สิ่งที่น่าสนใจคือ ประเด็นนี้ไม่ได้สำคัญแค่กับ developer บริษัทใหญ่ แต่เกี่ยวตรงกับเจ้าของธุรกิจและคนทำงานที่อยากใช้ AI ในงานจริง เพราะถ้าเราเข้าใจทิศทางนี้ เราจะเริ่มเห็นว่าระยะถัดไปของ AI ไม่ได้อยู่ที่ chatbot ตอบคำถามเก่งขึ้นอย่างเดียว แต่อยู่ที่มัน “ลงมือทำงานในระบบต่างๆ แทนเรา” ได้มากขึ้นเรื่อยๆ

สารบัญ

• Step 1: เริ่มจากปัญหาจริงว่า AI agent ใช้ API ทั้งก้อนไม่ไหว
• Step 2: เข้าใจว่าปัญหาไม่ใช่ MCP แต่คือวิธีโหลด tool เข้า context
• Step 3: ใช้แนวคิด Progressive Discovery แทนการโหลดทุกอย่างพร้อมกัน
• Step 4: มองอีกมุมว่า AI อาจไม่ต้องเลือก tool ทีละตัว แต่อาจเขียนโค้ดเอง
• Step 5: อย่ามองข้ามเรื่องสำคัญที่สุด คือการรันโค้ดที่ AI เขียนอย่างปลอดภัย
• Step 6: มองภาพระยะถัดไปว่า agent จะไม่ได้เรียกแค่ tool แต่จะสร้าง mini-script ใช้งานซ้ำ
• Step 7: เตรียมตัวรับโลกที่ API ต้องพร้อมให้ AI ใช้งานหนักขึ้น
• Step 8: จับตาว่า client ฝั่งผู้ใช้จะพัฒนาเร็ว และประสบการณ์ใช้งานจะต่างจากเดิม
• Actionable Insights
• Troubleshooting
• การต่อยอด
• สรุป Checklist ทั้งหมด

Step 1: เริ่มจากปัญหาจริงว่า AI agent ใช้ API ทั้งก้อนไม่ไหว

แนวคิดพื้นฐานของ agent คือให้ AI เรียกใช้ tool หรือ function เพื่อออกไปทำงานภายนอก model เช่น ดึงข้อมูลลูกค้า สร้าง ticket ส่งอีเมล หรือแก้ค่าในระบบหลังบ้าน หลายคนคุ้นกับสิ่งนี้ในชื่อ tool calling หรือ function calling

ช่วงแรก วิธีที่คนนิยมทำกันคือแต่ละ agent จะมีชุดเครื่องมือที่ฝังมาด้วย ถ้าจะเชื่อม Gmail ก็เขียน tool ของ Gmail ถ้าจะเชื่อม CRM ก็เขียน tool ของ CRM ปัญหาคือทุกทีมต้องทำซ้ำ และเครื่องมือเหล่านี้มักกระจัดกระจาย

พอ MCP หรือ Model Context Protocol เริ่มถูกใช้มากขึ้น หลายบริษัทก็ขยับมาอีกขั้น คือสร้าง MCP server เพื่อเปิด API ของตัวเองให้ agent ใช้ผ่านมาตรฐานเดียวกัน ฟังดูดีมาก เพราะเหมือนมี “ประตูมาตรฐาน” ให้ AI เข้าใช้ระบบต่างๆ ได้

แต่เมื่อ API ขององค์กรใหญ่มีจำนวน endpoint เยอะมาก ปัญหาก็โผล่ทันที Cloudflare ยกตัวอย่างตรงๆ ว่า OpenAPI spec ของทั้งองค์กรมีขนาดใหญ่มหาศาล ระดับหลายล้าน token ถ้าพยายามแปลง endpoint ทั้งหมดให้กลายเป็น tool แล้วโยนเข้า context ของ agent ทีเดียว ก็แทบใช้งานไม่ได้

มุมนี้สำคัญกับธุรกิจมาก เพราะหลายองค์กรชอบคิดว่า “ถ้ามี API ครบ เดี๋ยว AI ก็ใช้ได้เอง” แต่ความจริงไม่ใช่ AI ไม่ได้แค่ต้องเข้าถึง API มันต้อง “เข้าใจว่าจะใช้อะไร เมื่อไร และอย่างไร” ด้วย ถ้าให้ข้อมูลเยอะเกินไป มันไม่ต่างจากการยื่นคู่มือบริษัท 3,000 หน้าให้พนักงานใหม่ แล้วหวังให้เขาทำงานถูกตั้งแต่นาทีแรก

สำหรับธุรกิจไทย ภาพนี้อาจเทียบได้กับระบบที่มีหลายส่วนมาก เช่น ERP, POS, CRM, ระบบบัญชี, ระบบแชต, และระบบคลัง ถ้าเราอยากให้ AI ช่วยทำงานข้ามระบบ เราไม่ควรเริ่มจากการยัดทุกอย่างใส่มันพร้อมกัน แต่ต้องออกแบบให้มัน “ค่อยๆ เจอเครื่องมือที่ต้องใช้” ตามโจทย์จริง

Step 2: เข้าใจว่าปัญหาไม่ใช่ MCP แต่คือวิธีโหลด tool เข้า context

ข้อถกเถียงหนึ่งที่เกิดขึ้นบ่อยคือ MCP ยังเวิร์กอยู่ไหม หรือมันกลายเป็น “Mega Context Problem” ไปแล้วเพราะกิน token เยอะมาก คำตอบจาก Matt ค่อนข้างชัดว่า ปัญหาไม่ใช่ตัว protocol แต่เป็นวิธีที่คนเอา tool เข้า context แบบทุ่มทีเดียว

นี่เป็นจุดที่ควรแยกให้ออกระหว่าง “มาตรฐานการเชื่อมต่อ” กับ “วิธีการใช้งาน” MCP อาจยังเป็นมาตรฐานที่ดีสำหรับการ expose ความสามารถของระบบให้ agent เห็น แต่เราไม่ควรใช้มันแบบเอาทุกอย่างมาวางต่อหน้า agent ตั้งแต่ต้น

Cloudflare เจอปัญหานี้จริงจนต้องแยก API ออกเป็น MCP server ย่อยตาม product หลายตัว วิธีนี้ช่วยลด token ในแต่ละ server ก็จริง แต่สร้างภาระใหม่ให้ผู้ใช้ต้องเลือกเองว่าจะต่อกับ server ไหน และบาง server ก็ครอบคลุม API ได้ไม่ครบ

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

บทเรียนที่เอาไปใช้ได้คือ อย่าออกแบบ AI workflow โดยโยนความซับซ้อนกลับไปให้คนใช้ ถ้าพนักงานต้องมานั่งเลือกตลอดว่าเคสนี้ต้องใช้ API ไหน ต้องใช้ server ไหน หรือเปิดสิทธิ์อะไรบ้าง เท่ากับเรายังไม่ได้ลดงานจริง

Step 3: ใช้แนวคิด Progressive Discovery แทนการโหลดทุกอย่างพร้อมกัน

คำสำคัญของคลิปนี้คือ progressive discovery หรือการให้ agent ค่อยๆ ค้นพบ tool ตามความจำเป็น แนวคิดนี้สำคัญมาก เพราะช่วยให้ AI เห็นเฉพาะสิ่งที่เกี่ยวข้องกับงาน ณ ตอนนั้น

Matt อธิบายทางเลือกหลักๆ ไว้ 3 ทาง

• CLI ที่ agent อ่านคำสั่ง help แล้วค่อยสำรวจคำสั่งย่อยต่อ
• Tool search ที่ให้ agent ค้นหาเครื่องมือที่เกี่ยวข้องจากคำถาม
• Code mode หรือการให้ model เขียนโค้ดเรียก API จาก type ที่กระชับ

แต่ละแบบมีข้อดีต่างกัน และไม่มีแบบไหนเหมาะกับทุกสถานการณ์

CLI ดีเพราะค้นพบตัวเองได้

CLI มีข้อดีตรงที่คำสั่งและ help ถูกออกแบบมาให้สำรวจได้อยู่แล้ว agent สามารถค่อยๆ อ่าน command tree และหาคำสั่งที่ตรงกับโจทย์ เช่น อยากดูฐานข้อมูล ก็ไล่จากคำสั่งหลักไปคำสั่งย่อยได้

ข้อดีของวิธีนี้คือไม่ต้องใส่ทุก endpoint เข้า context ตั้งแต่แรก แต่ข้อเสียชัดมากคือ agent ต้องมี shell access ซึ่งไม่ใช่ทุกองค์กรจะยอม โดยเฉพาะในองค์กรที่มีข้อกำกับด้าน security สูง

Tool search ช่วยลดของใน context

อีกแนวทางคือมี search tool กลาง ให้ agent ใช้ค้นหา tool ที่เกี่ยวข้องกับคำถาม จากนั้นโหลดมาแค่บางส่วน เช่น ถ้าผู้ใช้ต้องการสร้าง worker ระบบก็อาจดึงเครื่องมือที่น่าจะเกี่ยวข้อง 6-8 ตัวเข้ามา แล้วค่อยให้ model เลือกใช้อีกที

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

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

Step 4: มองอีกมุมว่า AI อาจไม่ต้องเลือก tool ทีละตัว แต่อาจเขียนโค้ดเอง

ส่วนที่น่าสนใจที่สุดของคลิปคือแนวคิด code mode แทนที่จะให้ model เลือก tool จากรายการยาวๆ Cloudflare ทดลองให้ model เขียนโค้ดโดยอิงจาก typed SDK ที่ generate จาก OpenAPI spec

แกนคิดคือ type มีความกระชับกว่าคำอธิบาย tool ยาวๆ มาก และยังบอก input กับ output ได้ชัดเจน ถ้า model เข้าใจ type เหล่านี้ มันก็สามารถเขียนโค้ดเพื่อเรียก API ที่ต้องใช้ได้เลย

ผลลัพธ์คือ agent สามารถทำงานที่ซับซ้อนได้ เช่น

• ดึงรายการ worker
• deploy worker ใหม่
• ผูกระบบเข้ากับ Cloudflare Access
• จัดการโครงสร้างพื้นฐานผ่าน API ทั้งชุด

ประโยคที่ควรจำคือ “code is a very compact plan” หรือโค้ดคือแผนงานที่กระชับมาก แทนที่จะต้องมี tool เป็นร้อยตัว บางครั้งเราอาจมี tool หลักแค่ตัวเดียวคือ “run code” แล้วให้ model สร้างวิธีการเอง

ถ้าแปลเป็นภาษาธุรกิจ นี่หมายความว่า AI อาจไม่ต้องมี integration แบบ custom สำหรับทุก task เสมอไป แต่ใช้ความสามารถในการ “ประกอบวิธีทำงานชั่วคราว” จาก API ที่มีอยู่แล้ว

ตัวอย่างในธุรกิจไทย เช่น

• ให้ AI รวบรวมยอดขายจากหลายสาขาแล้วสรุปเป็นรายงานเช้า
• ดึงข้อมูลจากระบบ order, inventory และขนส่ง เพื่อเช็กสินค้าค้างส่ง
• สร้าง workflow ตอบคำถามลูกค้าโดยอิงข้อมูลจริงจากหลายระบบ

ทั้งหมดนี้ไม่จำเป็นต้องเขียน automation แยกทีละชิ้นตั้งแต่วันแรก ถ้ามี typed API ที่ดี AI สามารถประกอบงานเองได้มากขึ้น

Step 5: อย่ามองข้ามเรื่องสำคัญที่สุด คือการรันโค้ดที่ AI เขียนอย่างปลอดภัย

จุดที่ Matt พูดตรงและควรเอามาคิดต่อคือ แนวคิดให้ AI เขียนโค้ดแล้วเอาไปรันนั้น “น่ากลัว” มาก ถ้าฟังแบบไม่คิดเงื่อนไข มันคือการปล่อยให้ระบบรันโค้ดที่เราไม่ได้ตรวจด้วยตา อาจเข้าถึง secrets, อ่านไฟล์, ยิง network request ออกไป หรือกินทรัพยากรจนพังได้

นี่คือจุดที่หลายทีมติดอยู่ ไม่ใช่เพราะแนวคิดไม่ดี แต่เพราะ ความเสี่ยงสูงเกินกว่าจะ deploy แบบตรงๆ

ทางออกของ Cloudflare คือใช้ sandbox แบบ lightweight ที่รันโค้ดใน isolated environment และใส่ guardrails แบบโปรแกรมได้ เช่น

• ปิดการเข้าถึง environment variables
• ปิดหรือจำกัด network access
• กำหนดได้ว่าเรียกออกได้เฉพาะบาง domain
• กำหนด behavior ของ runtime ได้ตามนโยบาย

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

มุมที่เห็นต่างนิดหนึ่งคือ แม้แนวคิดนี้จะทรงพลัง แต่ธุรกิจทั่วไปไม่ควรรีบตีความว่า “ให้ AI เขียนโค้ดแล้วรันเลย” คือคำตอบสำหรับทุกอย่าง สำหรับหลายองค์กร คำตอบที่ปลอดภัยกว่ายังอาจเป็น workflow แบบจำกัดขอบเขต เช่นให้ AI เลือก action จากรายการที่อนุมัติไว้แล้วก่อน แล้วค่อยขยับไปสู่ code execution ในบาง use case ที่ควบคุมได้จริง

Step 6: มองภาพระยะถัดไปว่า agent จะไม่ได้เรียกแค่ tool แต่จะสร้าง mini-script ใช้งานซ้ำ

อีกภาพระยะถัดไปที่คลิปนี้ชี้ไว้ชัดคือ เมื่อ model เขียนโค้ดได้ดีขึ้น โค้ดที่มันเขียนจะไม่ใช่ของชั่วคราวเสมอไป แต่น่าจะถูกเก็บเป็น mini-script เพื่อเอากลับมาใช้ซ้ำ

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

นี่เป็นภาพที่ธุรกิจควรให้ความสนใจมาก เพราะมันหมายถึง AI จะค่อยๆ กลายเป็นชั้นกลางระหว่าง “คำสั่งภาษาคน” กับ “workflow ที่รันจริง”

ลองนึกถึงเคสในไทย เช่น

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

แทนที่จะต้องให้ทีมเขียน automation ใหม่ทุกครั้ง เราอาจเริ่มจาก AI ทำให้ก่อน แล้วค่อยเก็บสิ่งที่เวิร์กเป็น workflow ถาวร

Step 7: เตรียมตัวรับโลกที่ API ต้องพร้อมให้ AI ใช้งานหนักขึ้น

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

นั่นหมายความว่า platform ต้องพร้อมเรื่องต่อไปนี้

• rate limiting ที่ดีพอ
• permissions ที่แยกตามงานและตามระดับความเสี่ยง
• observability เพื่อรู้ว่า agent กำลังทำอะไรอยู่
• fallback เมื่อมีการเรียกผิดพลาดหรือเรียกมากเกินไป

สำหรับเจ้าของธุรกิจ นี่แปลว่าเวลาถาม vendor หรือทีมเทคว่า “ระบบเราพร้อมใช้ AI agent หรือยัง” คำตอบไม่ควรหยุดที่มี API หรือไม่มี API แต่ควรถามต่อว่า API ของเรารับการใช้งานแบบ autonomous ได้แค่ไหน ควบคุมสิทธิ์ได้หรือยัง และตามรอยการกระทำของ agent ได้หรือเปล่า

Step 8: จับตาว่า client ฝั่งผู้ใช้จะพัฒนาเร็ว และประสบการณ์ใช้งานจะต่างจากเดิม

อีกจุดที่คลิปนี้พูดไว้ดีคือ การสร้าง MCP client ที่ใช้งานจริงเคยยากมาก ต้องจัดการ connection, state, resumability และรายละเอียดอีกหลายอย่าง ทำให้ที่ผ่านมาเครื่องมือฝั่งผู้ใช้ยังไม่หลากหลายเท่าที่ควร

แต่เมื่อเครื่องมือเหล่านี้ง่ายขึ้น เราจะเห็น client รูปแบบใหม่ๆ เพิ่มขึ้นมาก ทั้งแบบ local และแบบ cloud native และเมื่อ client เก่งขึ้น มันก็จะไม่ใช่แค่หน้าต่างแชต แต่เป็นระบบที่เรียก tool แบบโปรแกรมได้ เก็บสคริปต์ได้ และรันงานเบื้องหลังได้

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

Actionable Insights

• อย่าเริ่มจากเชื่อมทุกระบบพร้อมกัน เริ่มจาก use case ที่ชัด 1-2 งานก่อน เช่นสรุปรายงาน หรือดึงข้อมูลข้ามระบบ
• ถามทีมเทคเรื่องสิทธิ์และ sandbox ก่อนถามเรื่องความฉลาดของ AI ถ้าคุมขอบเขตไม่ได้ ใช้งานจริงยาก
• มอง API เป็นสินทรัพย์สำหรับ agent ไม่ใช่แค่ของสำหรับนักพัฒนา ถ้า API อ่านยาก AI ก็ใช้ยาก
• สร้าง workflow ที่ค้นพบเครื่องมือทีละขั้น แทนการยัดทุก action ให้ AI ตั้งแต่แรก
• เก็บงานที่ AI ทำได้ดีเป็นสคริปต์ใช้งานซ้ำ เพื่อเปลี่ยนงาน ad hoc ให้กลายเป็นระบบ

Troubleshooting

ปัญหา: AI ตอบได้แต่ทำงานจริงไม่ได้

สาเหตุ: มี model แต่ไม่มีการเชื่อม API หรือเชื่อมแบบจำกัดเกินไป

วิธีแก้: เริ่มจากนิยาม 1 งานจริงที่ต้องการให้ AI ทำ จากนั้นเปิด API หรือ tool เท่าที่จำเป็นสำหรับงานนั้นก่อน

ปัญหา: พอเพิ่มเครื่องมือเยอะแล้ว AI สับสน

สาเหตุ: โหลด tool เข้า context มากเกินไปจน model เลือกไม่แม่น

วิธีแก้: ใช้แนวคิด progressive discovery เช่น search tool หรือจัดกลุ่มความสามารถตามโจทย์งาน

ปัญหา: กังวลว่า AI จะเข้าถึงข้อมูลสำคัญเกินจำเป็น

สาเหตุ: ไม่มี sandbox และไม่มี policy จำกัดสิทธิ์ที่ชัดเจน

วิธีแก้: แยก environment สำหรับ agent ออกจากระบบหลัก จำกัด network, secrets และสิทธิ์ตามหน้าที่

ปัญหา: ระบบเริ่มช้า หรือ API ถูกเรียกถี่ผิดปกติ

สาเหตุ: agent สามารถวนลูปเรียก API ได้เร็วกว่าคนมาก

วิธีแก้: ตั้ง rate limit, monitoring และ alert สำหรับ traffic ที่มาจาก agent โดยเฉพาะ

ปัญหา: ทีมธุรกิจคุยกับทีมเทคไม่รู้เรื่องเรื่อง agent

สาเหตุ: คุยกันคนละชั้น ฝั่งหนึ่งพูดเรื่อง model อีกฝั่งพูดเรื่อง infra

วิธีแก้: เปลี่ยนบทสนทนาเป็นภาษางาน เช่น “AI ต้องทำอะไรได้บ้าง” “ใช้อะไรได้บ้าง” และ “อะไรห้ามทำ”

การต่อยอด

• ทำ AI operations assistant สำหรับทีมภายใน เช่น สรุปยอด ตรวจสถานะงาน และเรียกข้อมูลจากหลายระบบในคำสั่งเดียว
• สร้าง catalog ของ API สำหรับ agent ให้ทีมเริ่มมอง API เป็นความสามารถทางธุรกิจ ไม่ใช่แค่เอกสารของนักพัฒนา
• ทดลอง mini-script library เก็บ workflow ที่ AI สร้างแล้วเวิร์กไว้เป็นชุดคำสั่งใช้งานซ้ำในองค์กร

สรุป Checklist ทั้งหมด

ใช้รายการนี้เป็นเช็กลิสต์ก่อนเริ่มเอา AI agent ไปทำงานกับระบบจริง

• ☐ ระบุ use case ธุรกิจที่ AI ต้อง “ทำ” ไม่ใช่แค่ “ตอบ”
• ☐ แยกให้ออกว่า use case นั้นต้องเข้าถึงระบบหรือ API อะไรบ้าง
• ☐ หลีกเลี่ยงการโยน tool ทั้งหมดเข้า context ตั้งแต่ต้น
• ☐ ออกแบบการค้นพบเครื่องมือแบบ progressive discovery
• ☐ พิจารณาว่าโจทย์ไหนเหมาะกับ CLI, tool search หรือ code mode
• ☐ ตั้ง sandbox และ guardrails สำหรับโค้ดที่ AI สร้าง
• ☐ จำกัดสิทธิ์การเข้าถึงข้อมูล, secrets และ network
• ☐ วาง rate limit และระบบติดตามการใช้งาน API ของ agent
• ☐ เก็บ workflow ที่ทำงานได้ดีเป็น mini-script หรือ automation ใช้งานซ้ำ
• ☐ ประเมินความพร้อมของ platform จากมุมการใช้งานโดย agent ไม่ใช่แค่การมี API

สรุปแล้ว แก่นของ Every API Is a Tool for Agents ไม่ได้อยู่ที่ MCP เพียงอย่างเดียว แต่อยู่ที่วิธีคิดใหม่เกี่ยวกับการให้ AI เข้าถึงระบบงานจริง โลกที่กำลังมาไม่ใช่โลกที่ AI รู้ทุกอย่าง แต่เป็นโลกที่ AI “ลงมือทำ” ผ่าน API, tool, CLI และโค้ดที่มันสร้างขึ้นเองได้

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