ซอฟต์แวร์กำลังมุ่งสู่ความเป็นเฮดเลสหรือไม่?

• การที่ Salesforce เปิดตัวผลิตภัณฑ์แบบเฮดเลสทำให้เกิดคำถามว่า ในยุคของเอเจนต์นั้น ความได้เปรียบเชิงป้องกันของ SaaS ยังเหลืออยู่ตรงไหน เมื่อบริษัทกำลังเดิมพันว่า ชั้นข้อมูล ไม่ใช่ UI คือศูนย์กลางของมูลค่า
• ในยุค SaaS คูเมืองของระบบบันทึกข้อมูล (System of Record) คือ พฤติกรรมการใช้งานที่ก่อตัวผ่าน UI แต่เมื่อเอเจนต์สามารถอ่านและเขียนลง DB ได้โดยตรง ความได้เปรียบนี้ก็อ่อนแรงลง
• ความได้เปรียบเชิงป้องกันกำลังย้ายลงล่างไปสู่ โมเดลข้อมูล สิทธิ์ เวิร์กโฟลว์ลอจิก และคอมพลายแอนซ์ และย้ายขึ้นบนไปสู่ เครือข่าย การสร้างข้อมูลเฉพาะตัว และความสามารถในการลงมือทำในโลกจริง
• ระบบบันทึกข้อมูลแบบ AI-native รุ่นถัดไปจำเป็นต้องมีเกณฑ์ใหม่ ได้แก่ โมเดลข้อมูลที่เป็นมิตรต่อเอเจนต์ การจัดการสิทธิ์ระดับเอเจนต์ และการปิดวงจรการปฏิบัติการ
• ธุรกิจรุ่นถัดไปที่มีแนวโน้มดีที่สุดคือรูปแบบที่ ก้าวข้ามการเก็บข้อมูลอย่างเดียว ไปสู่การปฏิบัติการในโลกจริงและการประสานงานหลายฝ่าย

---

คำถามที่เกิดจากการประกาศเฮดเลสของ Salesforce

• เดือนที่แล้ว Salesforce ประกาศเปิด API และเปิดตัวผลิตภัณฑ์แบบเฮดเลส เป็นการเดิมพันว่าในยุคเอเจนต์ มูลค่าอยู่ที่ ชั้นข้อมูล ไม่ใช่ UI
  • ในเชิงเทคนิคแทบไม่มีอะไรใหม่ — API ที่กำลังทำการตลาดในชื่อผลิตภัณฑ์เฮดเลสนั้นมีอยู่มาหลายปีแล้ว และเป็นการเปิดตัวเชิงการตลาดแบบฉบับ Salesforce
  • แก่นของแนวคิดคือเอเจนต์เข้าถึงข้อมูลของระบบบันทึกข้อมูลได้โดยตรง โดยไม่ต้องผ่าน UI สำหรับมนุษย์
• เมื่อถอด UI ออกและเหลือเพียง DB ก็เกิดคำถามเชิงแก่นแท้ว่า มันต่างจาก Postgres + สคีมาที่ออกแบบดี + API อย่างไร
  • จึงต้องทบทวนว่าองค์ประกอบที่ค้ำจุนระบบบันทึกข้อมูลเดิมยังใช้ได้อยู่หรือไม่ หรือจำเป็นต้องมีเกณฑ์ใหม่

ยุค SaaS ที่ UI คือผลิตภัณฑ์

• ระบบบันทึกข้อมูล (System of Record) คือแหล่งความจริงหนึ่งเดียวที่เชื่อถือได้ในโดเมนใดโดเมนหนึ่ง
  • CRM คือระบบบันทึกข้อมูลของรายได้, HRIS คือระบบบันทึกข้อมูลของงานบุคคล, ERP คือระบบบันทึกข้อมูลของเงินทุน
  • พลังที่แท้จริงไม่ใช่แค่การเก็บข้อมูล แต่คือการสร้าง ความเป็นจริงร่วมกันของทั้งองค์กร
• ตลอด 20 ปีที่ผ่านมา สิ่งที่ Salesforce ขายคือวิธีที่ผู้นำฝ่ายขายใช้บริหารทีม
  • แดชบอร์ด มุมมอง pipeline เครื่องมือพยากรณ์ และ activity feed ต่างหากที่เป็นสินค้าที่ขายจริง และโมเดลธุรกิจก็อิงกับการขาย seat ผู้ใช้
  • DB ด้านล่างนั้นสำคัญ แต่เป็นองค์ประกอบรอง
• UI คือสิ่งที่สร้างความเหนียวแน่น (stickiness)
  • มันบังคับสุขอนามัยข้อมูล สร้างคำศัพท์ร่วม (Lead, Opportunity, Account) และทำให้พนักงานขายกรอกข้อมูลที่ปกติจะไม่กรอก
  • เหตุผลที่หัวหน้าฝ่ายขายจำนวนมากพา Salesforce ติดตัวไปเมื่อย้ายงาน ไม่ใช่เพราะ UI ดี แต่เพราะ ความคุ้นมือจากการใช้งาน (muscle memory)
• เอเจนต์กำลังเริ่มพลิกโมเดลนี้
  • มันสามารถ read/write ข้อมูลได้โดยตรงโดยไม่ผ่าน UI
  • รอบ ๆ SAP ก็มีระบบนิเวศที่เป็นมิตรกับ AI ขยายตัวอย่างรวดเร็วเช่นกัน
  • เอเจนต์ที่ใช้งานคอมพิวเตอร์จะค่อย ๆ ทำให้ปัจจัยแบบมนุษย์เป็นศูนย์ เช่น ความชอบ การฝึกฝน และบริบทที่ไม่ได้เขียนไว้

เกณฑ์เดิมในการประเมินความเหนียวแน่นของระบบบันทึกข้อมูล

• ปัจจัยที่อิงจากวิธีที่มนุษย์โต้ตอบกับซอฟต์แวร์และความชอบของมนุษย์

• ถูกใช้งานบ่อยแค่ไหน

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

• เป็นแบบ Write-only หรือ Read-write

  • ระบบบันทึกข้อมูลที่เหนียวแน่นมักเป็นแบบ read-write
  • CRM ถูกอ่านตลอดเวลา — บันทึกการโทรทุกครั้ง การอัปเดตขั้นตอน การสร้างงาน ล้วนเป็นกระแสข้อมูลสองทาง
  • เพราะต้องจัดการข้อมูลปฏิบัติการสด จึงไม่มีจังหวะเปลี่ยนผ่านที่ปลอดภัย → เมื่อนำมาใช้แล้วจึงออกได้ยาก
  • ตรงกันข้าม ATS (ระบบติดตามผู้สมัคร) ใกล้เคียงกับ write-only มากกว่า — หลังจบการจ้างงาน แทบไม่มีเหตุผลต้องย้อนกลับไปดูข้อมูลอีก

• มี SOP ที่ไม่ได้ถูกเขียนไว้มากแค่ไหน

  • บริบทแกนกลางของธุรกิจไม่ได้ถูกเก็บไว้ในวิกิ แต่ถูกเข้ารหัสไว้ในกฎของเวิร์กโฟลว์
  • ตัวอย่างฝ่ายขาย: ดีล enterprise ที่เกิน 100,000 ดอลลาร์ต้องได้รับอนุมัติจาก VP, ดีลใน EMEA ต้องผ่านการตรวจสอบความเป็นส่วนตัว, ส่วนลดสำหรับ strategic logo สามารถข้ามฝ่ายการเงินได้เฉพาะช่วงปลายไตรมาส
  • บริบทเหล่านี้ทำให้เกิดความต่างระหว่างการจัดการทันเวลาและการพลาดตกหล่น
  • การย้ายระบบหมายถึงการ reverse engineer ระบบอัตโนมัติทั้งหมด หรือไม่ก็สูญเสียความทรงจำขององค์กรไปทั้งก้อน

• ขนาดของการพึ่งพาทั้งภายในและภายนอก

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

• ความสำคัญด้านคอมพลายแอนซ์

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

• เปรียบเทียบต้นทุนการเปลี่ยนระบบตามประเภทของระบบบันทึกข้อมูล

  • ATS เป็นเครื่องมือเวิร์กโฟลว์ที่มีขอบเขตชัดเจนคือการจ้างงาน มีการเชื่อมต่อแคบและผู้ใช้น้อย
  • ERP อยู่คนละขั้ว — บัญชีแยกประเภทคือตัว audit trail เอง และนักบัญชี ผู้ตรวจสอบบัญชี และหน่วยงานกำกับดูแลล้วนเป็นผู้มีส่วนได้ส่วนเสียโดยตรง
  • การเปลี่ยน ATS นั้นเจ็บปวดแต่ยังพอทนได้, การเปลี่ยน CRM คือการผ่าตัดหัวใจแบบเปิด, และ การเปลี่ยน ERP คือการผ่าตัดหัวใจแบบเปิดให้กับคนไข้ที่กำลังวิ่งมาราธอนอยู่

• องค์ประกอบคูเมืองที่อ่อนแอมาแต่เดิม

  • ข้อมูลเฉพาะตัว — CRM มีข้อมูลที่อุดมสมบูรณ์ แต่แทบไม่เคยสร้างอินไซต์ข้ามลูกค้าอย่างจริงจัง (มีเพียงความพยายามบางส่วน เช่น Salesforce Einstein)
  • network effects — เป็นเสมือนจอกศักดิ์สิทธิ์ แต่ในระบบบันทึกข้อมูลนั้นอ่อนแอมาโดยตลอดในเชิงประวัติศาสตร์

เมื่อ UI หายไปและเอเจนต์มาถึง จะเหลืออะไร

• เอเจนต์ไม่ต้องการเบราว์เซอร์ — ขอแค่มี API บริบท คำสั่ง และความสามารถในการลงมือทำก็พอ

• มีการเปลี่ยนแปลงสองอย่างที่ทำให้สิ่งนี้เป็นไปได้

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

• สามเส้นทางของผู้ซื้อซอฟต์แวร์

  • ระบบเดิม + เอเจนต์: ใช้ CLI/API ของเจ้าตลาด SaaS เดิม ใช้ผลิตภัณฑ์เอเจนต์เนทีฟ (Salesforce Agentforce, SAP Joule) หรือสร้างเอเจนต์เอง — แต่ทั้งหมดนี้ตั้งอยู่บนสมมติฐานว่า API นั้นครบ ใช้งานได้จริง และการเปลี่ยนสู่เฮดเลสทำได้ง่ายในเชิงปฏิบัติการ
  • สร้างระบบบันทึกข้อมูลเอง (DIY): สร้างโมเดลข้อมูล ลอจิกการปฏิบัติการ สิทธิ์/การตรวจสอบ/การเชื่อมต่อ และเอเจนต์ของตัวเองตั้งแต่ต้น (อาจใช้เครื่องมือ third-party ได้)
  • ซื้อทางเลือกแบบ AI-native: ซื้อซอฟต์แวร์รุ่นใหม่ที่ถูกสร้างขึ้นใหม่ทั้งหมดบนฐานของ machine-readability มีการ orchestration เอเจนต์เป็นฟีเจอร์ระดับแกน และรองรับเฮดเลส

• อะไรที่ยังรอดจากเกณฑ์ประเมินเดิม

  • ปัจจัยที่อิงพฤติกรรมมนุษย์ (ความถี่ในการใช้, read vs read-write) → หายไปพร้อมกับนิสัยการใช้งาน
  • เอเจนต์ทำลายคูเมืองจากนิสัยการใช้งาน แต่ ไม่ได้ทำลายคูเมืองจากลอจิกการปฏิบัติการและบริบท
  • อันที่จริงมันยิ่งสำคัญขึ้น เพราะถ้าเอเจนต์จะลงมือได้อย่างปลอดภัย ก็ต้องมีการกำหนดกฎ สิทธิ์ และกระบวนการอย่างชัดเจน

• ในระยะสั้น SOP ที่ไม่ได้เขียนไว้ยังสำคัญ

  • ลอจิกองค์กรที่เข้ารหัสในกฎเวิร์กโฟลว์ยังเป็นหัวใจให้เอเจนต์ทำงานได้ถูกต้อง
  • มันไม่สามารถส่งออกออกมาอย่างสะอาดได้ง่าย ๆ (โดยเฉพาะเมื่อยังมีมนุษย์อยู่ในบางขั้นตอนของกระบวนการ)
  • อย่างไรก็ดี เมื่อการเก็บบริบททำได้ง่ายขึ้นและเอเจนต์เข้ามาแทนแรงงานมากขึ้น ความสำคัญส่วนนี้ก็จะค่อย ๆ ลดลง

• การเชื่อมต่อ (connectivity) ยังยากและจะยิ่งขยายตัว

  • แกนกลางไม่ใช่การตามพฤติกรรมมนุษย์อีกต่อไป แต่คือ การรักษาการเชื่อมต่อระหว่างฟังก์ชันและซอฟต์แวร์ที่กระจัดกระจาย
  • เอเจนต์ CRM ต้องเชื่อมร้อยข้อมูลและบริบทระหว่างฝ่ายขาย การวางบิล และ customer success
  • หากมันกลายเป็นโหนดที่เอเจนต์ของหลายองค์กรภายนอกมาทำธุรกรรมร่วมกัน การพึ่งพาก็จะยิ่งลึกขึ้น
  • ทั้งแนวทางเจ้าตลาดเดิม + เอเจนต์ และแนวทาง DIY DB + เอเจนต์ ต่างก็ยังข้ามผ่านซอฟต์แวร์ย่อยจำนวนมากได้ยาก

• ข้อมูลด้านคอมพลายแอนซ์ยังสำคัญ

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

องค์ประกอบความได้เปรียบเชิงป้องกันใหม่ของสตาร์ตอัป AI-native

• ความยากในการทำซ้ำระบบบันทึกข้อมูล

  • ในระยะสั้น ประเด็นสำคัญคือการดึงและทำซ้ำข้อมูลที่อยู่บนฐานของระบบบันทึกข้อมูลได้ง่ายแค่ไหน
  • เจ้าตลาด SaaS เดิมมักทำให้ API ใช้งานลำบาก หรือวางข้อจำกัด ทำให้ไม่ครบ หรือไม่คุ้มทางเศรษฐกิจ
  • แต่เมื่อเครื่องมือดึงข้อมูล โดยเฉพาะเอเจนต์ที่ใช้คอมพิวเตอร์ พัฒนาขึ้น สิ่งนี้ก็เริ่มง่ายขึ้นเรื่อย ๆ
  • ขณะเดียวกันก็มีบริษัทใหม่เกิดขึ้นที่สร้างข้อมูลได้สมบูรณ์ขึ้นจากอีเมล โทรศัพท์ voice agent และเอกสารภายใน
  • AI ลดต้นทุนของการทำซ้ำ 80% แรกของระบบบันทึกข้อมูล แต่ 20% ที่เหลือ — การจัดการข้อยกเว้น การอนุมัติ คอมพลายแอนซ์ และเวิร์กโฟลว์ edge case — คือจุดที่แบ่งตัวแทนทดแทนจริงออกจาก wedge

• มีข้อมูลเฉพาะตัวที่มีความหมายหรือไม่

  • ข้อมูลที่ป้องกันการแข่งขันได้ไม่ใช่ข้อมูลที่ import เข้ามา แต่คือ ข้อมูลที่ผลิตภัณฑ์สร้างขึ้นมาอย่างเฉพาะตัว
  • สวนล้อมข้อมูล (walled garden) — ข้อมูลที่เป็นกรรมสิทธิ์ อยู่ภายใต้กฎระเบียบ หรือจำเป็นต้องอัปเดตต่อเนื่อง
  • ผู้ให้บริการซอฟต์แวร์ที่ลงทุนกับข้อมูลที่มีอำนาจอ้างอิงและสมบูรณ์ จะได้เปรียบเหนือผู้ให้บริการแบบทั่วไป
  • ข้อมูลพฤติกรรมที่สร้างขึ้นภายใน: พฤติกรรมที่สังเกตได้ อัตราการตอบกลับ รูปแบบจังหวะเวลา ผลลัพธ์ของกระบวนการ benchmark รูปแบบข้อยกเว้น และการติดตามประสิทธิภาพของเอเจนต์
  • ข้อมูลก็คือบริบท (data is the context)

• เป็นเจ้าของชั้นการลงมือทำหรือไม่

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

• องค์ประกอบการปฏิบัติการในโลกจริง

  • โมเดลธุรกิจที่มีการเชื่อมต่อกับงานปฏิบัติการในโลกจริงซึ่งจะไม่ถูกทำให้เป็นอัตโนมัติทั้งหมด
  • กรณีของเครือข่ายปฏิบัติการอย่าง DoorDash — แม้ในอดีตจะไม่ใช่ระบบบันทึกข้อมูล แต่ก็ให้บทเรียนสำคัญ
  • ซอฟต์แวร์ที่ปิดลูปได้ผ่านบริการ ฟูลฟิลเมนต์ โลจิสติกส์ งานภาคสนาม และการชำระเงิน มีความได้เปรียบเชิงป้องกันคนละแบบกับ SaaS บริสุทธิ์
  • ไม่ใช่แค่เก็บบันทึกหรือให้คำแนะนำ แต่คือ ส่งคนออกไป เคลื่อนย้ายของ และทำบริการให้เสร็จสิ้น
  • สำหรับผู้สร้าง โอกาสอยู่ในตลาดที่ซอฟต์แวร์ตัดสินใจมากขึ้นและเอเจนต์ประสานงานมากขึ้น แต่ last mile ยังต้องอาศัยการลงมือทำในโลกจริง — เช่น vertical software ที่ผสานงานบริการภาคสนาม

• network effects

  • ในอดีต ระบบบันทึกข้อมูลมี network effects อ่อน เพราะซอฟต์แวร์ส่วนใหญ่ใช้ภายในองค์กร
  • แต่เมื่อมันถูกฝังลงในเวิร์กโฟลว์หลายฝ่าย network effects อาจสำคัญขึ้นมาก
  • เมื่อตัวกลางของปฏิสัมพันธ์ซ้ำ ๆ ระหว่าง ผู้ซื้อ-ผู้ขาย นายจ้าง-ลูกจ้าง บริษัท-ผู้ตรวจสอบบัญชี ผู้ขายสินค้า-ลูกค้า ผู้จ่ายเงิน-ผู้ให้บริการ จำนวนผู้เข้าร่วมที่เพิ่มขึ้นจะเพิ่มมูลค่าของเครือข่าย
  • วิธีที่สิ่งนี้เกิดขึ้น
    • การประสานเวิร์กโฟลว์ร่วม — กลายเป็นสถานที่ที่ทั้งสองฝ่ายเข้ามาทำธุรกรรม แลกเปลี่ยนบริบท และแก้ข้อยกเว้น
    • benchmark และ intelligence — ให้บรรทัดฐาน ความผิดปกติ และคำแนะนำจากรูปแบบในเครือข่าย
    • ความเชื่อถือและการทำให้เป็นมาตรฐาน — หากกลายเป็นรางร่วมของการอนุมัติ การส่งต่องาน คอมพลายแอนซ์ และการชำระเงิน มันจะไม่ใช่แค่ DB แต่เป็นส่วนหนึ่งของ โครงสร้างพื้นฐานการประสานตลาด

• ความสามารถทางเทคนิคของผู้ซื้อ

  • แม้โดยทฤษฎีทุกคนจะสร้างเอเจนต์ได้ แต่ในทางปฏิบัติความสามารถยังแตกต่างกันมาก
  • ในตลาดปลายทางแบบ vertical และในฟังก์ชันที่ทีมวิศวกรรมภายในอ่อนแอ ผู้ซื้อมีโอกาสต่ำที่จะสร้าง ดูแล และพัฒนาฐานข้อมูล ลอจิกเวิร์กโฟลว์ สแตกเอเจนต์ และ governance เอง
  • ต้นทุนก็สำคัญ — DIY อาจลดค่าลิขสิทธิ์ แต่ย้ายต้นทุนไปอยู่ที่การพัฒนา การดูแล และความซับซ้อนภายใน
  • โอกาสจึงอยู่ในหมวดที่การปฏิบัติการซับซ้อนแต่ยังขาดการรองรับทางเทคนิค — การผลิต แบ็กออฟฟิศงานก่อสร้าง เวิร์กโฟลว์งานอุตสาหกรรมและภาคสนาม และบัญชี

องค์ประกอบจำเป็นอื่น ๆ (table stakes)

• โมเดลข้อมูลใหม่ (ontology)

  • วิธีคิดแบบ "DIY DB" มักประเมินค่าของโมเดลอ็อบเจกต์ต่ำเกินไป
  • ซอฟต์แวร์เดิมถูกสร้างมาเพื่อจับแดชบอร์ด รายงาน และเวิร์กโฟลว์ของมนุษย์ → เช่น Opportunity, Ticket, Candidate
  • สคีมาสำหรับเอเจนต์ต้องจับ การให้เหตุผล การกระทำ การติดตามสถานะ การจัดการข้อยกเว้น การมอบหมาย และการประสานงานข้ามระบบ
  • โมเดลอ็อบเจกต์แบบเนทีฟจึงเปลี่ยนไปเป็นสิ่งอย่าง task, intent, thread, policy, outcome

• การจัดการสิทธิ์ของเอเจนต์

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

• บริบทด้านต้นทุน

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

บทสรุป — ทิศทางวิวัฒนาการของระบบบันทึกข้อมูล

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