สองตัวอย่างจาก Sarah Simionescu ตั้งแต่ตามปัญหาจาก Slack ไปจนถึงวิเคราะห์ผู้ใช้ด้วย PostHog, Metabase และ Remote Workbench
Sarah Simionescu จาก Composio เล่าว่าเธอใช้ Datadog ทุกวันมาหกเดือน จนเมื่อเพื่อนร่วมงานขอให้เปิดดูการแจ้งเตือนบน Dashboard เธอกลับหาทางไปไม่ถูก ประสบการณ์นี้เป็นจุดตั้งต้นของทอล์ก “Dashboards Are Dead” บนช่อง AI Engineer
ชื่อทอล์กเป็นข้อเสนอของ Sarah เกี่ยวกับวิธีใช้ซอฟต์แวร์ ส่วนที่นำมาพิจารณาได้ชัดกว่าคือการสาธิตว่า agent จะค้นเครื่องมือที่ต้องใช้ รู้ข้อมูลที่ต้องเตรียม และนำผลจากหลายแอปมาตอบคำถามเดียวกันได้อย่างไร ตัวอย่างแรกเป็นสถานการณ์จำลองการตามแก้บั๊ก ส่วนตัวอย่างที่สองไล่จากประเภทธุรกิจของผู้ใช้ไปถึงชุดเครื่องมือที่กลุ่มนั้นนิยมใช้
ค้นเครื่องมือพร้อมสิ่งที่ต้องทำก่อน
Sarah เริ่มจากงานที่หลายทีมคุ้นเคย มีคนแจ้งปัญหาใน Slack แล้วผู้รับงานต้องไปค้นข้อมูลใน Datadog เปิดดู session ใน PostHog แก้โค้ด และสร้าง pull request เพื่อให้ทีมตรวจ ระหว่างทางยังต้องเปลี่ยนภาษาค้นหาตามบริการที่เปิดใช้
เธอมองว่าปุ่ม AI ภายในแต่ละแอปช่วยเขียนคำค้นได้บางส่วน แต่คนยังต้องย้ายผลลัพธ์ข้ามแอปเอง ส่วน MCP เปิดช่องให้ agent ติดต่อเครื่องมือได้ ทว่าโจทย์การเลือกเครื่องมือและลำดับการเรียกใช้ยังต้องได้รับการออกแบบด้วย
ปัญหาที่ Sarah ชี้คือเมื่อส่งคำอธิบายเครื่องมือจากหลายบริการเข้า context พร้อมกัน agent ต้องเลือกจากรายการจำนวนมาก และบางครั้งยังไม่รู้ว่าต้องหาข้อมูลชิ้นไหนก่อนจึงจะเรียกเครื่องมือถัดไปได้ ตัวอย่างเล็ก ๆ คือการอ่านข้อความใน Slack ที่ต้องรู้รหัสช่องสนทนาก่อน
แนวทางที่เธอสาธิตเริ่มจากให้ Claude แจ้งงานที่ต้องการทำกับระบบค้นเครื่องมือของ Composio แล้วจึงรับเครื่องมือและข้อมูลที่เกี่ยวข้องกลับมา เรียกวิธีนี้ได้ว่า tool discovery หรือการค้นหาเครื่องมือตามงาน การพบเครื่องมืออ่านข้อความจึงมาพร้อมความเข้าใจว่าต้องหารหัสช่องก่อน ไม่ใช่หยุดอยู่แค่ชื่อฟังก์ชันที่น่าจะใช้ได้
อีกข้อที่เธอยกขึ้นมาคือข้อผิดพลาดที่กลับมาเมื่อเริ่มบทสนทนาใหม่ และการเพิ่ม skills จน context หนาแน่น ประเด็นในกรอบนี้คือการเชื่อม MCP อย่างเดียวไม่ได้จัดการความรู้จากงานก่อนหน้าหรือการเลือกคำแนะนำให้พอดีกับงานใหม่ไว้ให้ครบ
สถานการณ์จำลองจากข้อความ Slack ไปสู่ร่าง PR
Sarah ระบุชัดว่าตัวอย่างแรกเป็นการสาธิตแบบจำลอง โดยมี Claude เชื่อมกับ MCP ของ Composio ผู้ใช้วางลิงก์ข้อความ Slack แล้วขอให้ใช้ Sentry และ Datadog หาสาเหตุ พร้อมสร้างร่าง PR สำหรับตรวจ
จุดเริ่มต้นของ agent คือค้นเครื่องมือที่เกี่ยวกับโจทย์ จากนั้นเตรียมข้อมูลสำหรับอ่าน Slack รวมถึงรหัสช่อง เมื่ออ่านข้อความและเข้าใจอาการที่มีคนแจ้ง จึงดึงข้อมูลจากแหล่งที่เกี่ยวข้องมาประกอบกัน โดยบางส่วนทำคู่ขนาน
วิธีเล่านี้ทำให้เห็นว่าการแก้ปัญหาข้ามแอปมีงานย่อยซ่อนอยู่หลายชั้น ลิงก์ข้อความเป็นเพียงจุดเริ่ม ต้องระบุให้ได้ว่าข้อร้องเรียนกล่าวถึงอะไร แล้วค่อยใช้ข้อมูลจากระบบติดตามข้อผิดพลาดและระบบตรวจการทำงานเพื่อหาคำอธิบาย
Sarah กล่าวว่าในตัวอย่างนี้ได้แนวทางแก้ภายในไม่ถึงห้านาที โดยเธอไม่ได้เขียน workflow หรือ skill เฉพาะเพื่อสอนลำดับงานดังกล่าว ตัวเลขนี้เป็นคำบรรยายของการสาธิตแบบจำลอง ไม่ใช่ผลทดสอบอิสระหรือเวลาที่ใช้รับประกันการแก้เหตุขัดข้องจริง
ขอบเขตของคำขอหยุดที่ร่าง PR จึงยังต้องมีการตรวจโค้ดและผลทดสอบก่อนนำไปใช้ การพิมพ์กำชับว่าอย่าทำผิดในโจทย์ไม่ได้ทดแทนขั้นตรวจเหล่านี้ และคลิปไม่ได้แสดงว่ามีการนำการแก้ไขขึ้นระบบจริงแล้ว
ตามคำถามจาก PostHog ไปยัง Metabase
ตัวอย่างที่สองเปลี่ยนจากงานแก้บั๊กมาเป็นการวิเคราะห์ผู้ใช้ Sarah อยากรู้ว่าคนเลือกประเภทธุรกิจอะไรในช่วงเริ่มใช้งาน จากนั้นจึงเจาะกลุ่มอีคอมเมิร์ซเพื่อดูว่าคนกลุ่มนี้ใช้ชุดเครื่องมือใดบ่อย
Claude เริ่มด้วยการค้นเครื่องมือผ่าน Composio แล้วสร้างคำค้นใน PostHog เพื่อดูการกระจายตามประเภทธุรกิจ เมื่อเลือกกลุ่มอีคอมเมิร์ซได้ คำถามถัดไปต้องใช้ข้อมูลอีกชุดใน Metabase จึงเปลี่ยนจากการดูภาพรวมไปสู่การตามพฤติกรรมของกลุ่มที่สนใจ
แทนที่จะดึงข้อมูลทุกแถวออกมาทันที การสาธิตให้ Claude สำรวจ schema หรือโครงสร้างฐานข้อมูล และอ่านข้อมูลตัวอย่างก่อน เพื่อเข้าใจว่าข้อมูลถูกจัดไว้อย่างไร แล้วจึงทำงานต่อกับข้อมูลที่ต้องใช้ตอบคำถาม
สิ่งที่ต่อเนื่องกันในตัวอย่างนี้คือคำถามของผู้ใช้ ขั้นแรกระบุว่ากำลังสนใจลูกค้ากลุ่มไหน ขั้นต่อมาถามว่ากลุ่มนั้นใช้เครื่องมืออะไร ขณะที่แหล่งข้อมูลเปลี่ยนจาก PostHog ไปเป็น Metabase คนถามไม่ต้องเริ่มอธิบายโจทย์ใหม่จากศูนย์ทุกครั้งที่เปลี่ยนบริการ
Remote Workbench กับข้อมูลที่ไม่ต้องเข้า context ทั้งหมด
หลังสำรวจโครงสร้างและข้อมูลตัวอย่าง Sarah อธิบายว่า Claude ใช้ Composio Remote Workbench ทำงานกับข้อมูลต่อ โดยไม่โหลดผลลัพธ์ทั้งหมดเข้า context ของโมเดล แล้วจึงแสดงชุดเครื่องมือที่นิยมในกลุ่มผู้ใช้อีคอมเมิร์ซ ซึ่งอาศัยข้อมูลจากทั้งสองแหล่ง
ตัวอย่างนี้แยกบทบาทของการเข้าใจคำถามออกจากการประมวลผลข้อมูลจำนวนมาก โมเดลใช้ข้อมูลเรื่องโครงสร้างและตัวอย่างเพื่อวางวิธีทำงาน ส่วนข้อมูลทั้งหมดไม่จำเป็นต้องกลายเป็นข้อความยาวให้โมเดลอ่านก่อนตอบ
อย่างไรก็ตาม คลิปและสไลด์ที่มีอยู่ไม่ได้เปิดรายละเอียดการเชื่อมข้อมูลให้ตรวจซ้ำครบทุกขั้น จึงไม่ควรเติมเองว่าใช้รหัสใดจับคู่ผู้ใช้ หรือสรุปว่าตัวเลขในผลลัพธ์ผ่านการตรวจความถูกต้องแล้ว
เมื่อลองคำถามแบบนี้กับข้อมูลของตัวเอง จุดที่ต้องถามให้ชัดคือ “นับจากอะไร” เช่น นับจำนวนผู้ใช้ที่เคยเรียกเครื่องมือ หรือนับจำนวนครั้งที่เครื่องมือถูกเรียก รวมถึงเลือกช่วงเวลาใด คำว่า “นิยมที่สุด” อาจให้คำตอบต่างกันตามนิยาม วิธีตรวจที่ต่อยอดจากตัวอย่างนี้คือขอดูเงื่อนไขและวิธีนับก่อนใช้ผลไปตัดสินใจ
ออกแบบเครื่องมือให้ agent ใช้งานต่อได้
ช่วงท้าย Sarah เสนอให้มอง agent เป็นผู้ใช้ของผลิตภัณฑ์อีกประเภทหนึ่ง เธออธิบายว่า Composio ทำหน้าที่แปลง API ของหลายบริการให้เป็นเครื่องมือสำหรับเรียกผ่าน MCP, CLI หรือช่องทางเรียกเครื่องมือโดยตรง เป้าหมายที่เธอเสนอคือทำให้ agent ทำงานข้ามบริการได้ต่อเนื่องขึ้น
เมื่ออ่านข้อเสนอนี้ควบคู่กับสองตัวอย่าง คำว่า agent experience มีรายละเอียดที่จับต้องได้ขึ้น เครื่องมือต้องค้นเจอตามโจทย์ อธิบายข้อมูลที่จำเป็นก่อนเรียกใช้ และเปิดทางให้นำผลไปทำงานขั้นถัดไปได้ ในตัวอย่าง Slack รายละเอียดนั้นคือรหัสช่อง ส่วนตัวอย่างวิเคราะห์ผู้ใช้คือโครงสร้างข้อมูลและวิธีประมวลผลข้ามแหล่ง
ทอล์กไม่ได้พิสูจน์ว่าทุกคนจะเลิกใช้ Dashboard แต่แสดงแนวทางที่คนเริ่มงานด้วยคำถาม แล้วให้ agent จัดเส้นทางผ่านเครื่องมือต่าง ๆ แทน หากจะทดลองแนวทางนี้ งานที่เหมาะเป็นจุดเริ่มคือคำถามข้ามแอปที่รู้วิธีตรวจคำตอบอยู่แล้ว จะได้แยกออกว่าระบบช่วยลดงานช่วงไหน และช่วงไหนยังต้องเข้าไปตรวจด้วยตัวเอง
วิดีโอต้นทาง
เรียบเรียงจาก Dashboards Are Dead โดย Sarah Simionescu จาก Composio ช่อง AI Engineer ข้อเสนอและเวลาทำงานที่กล่าวถึงเป็นคำอธิบายของผู้พูดในการนำเสนอ
