แผงสวิตช์ทำงานได้ตรงตามที่เดินสายไว้เท่านั้น กดสวิตช์ก็ได้ผลลัพธ์ตายตัวแบบเดิมทุกครั้ง ถ้าขอให้ทำอะไรนอกวงจรนั้นก็ทำไม่ได้ เพราะมันรับมือกับความแปรผันไม่ได้ มีแค่สายไฟที่เดินไว้
แต่พนักงานรับสายต่างออกไป เมื่อได้รับคำขอ เช่น ช่วยต่อสายไปที่แผนกต้อนรับ เขาจะหาวิธีทำเอง ว่าจะใช้สายไหน ถ้าสายไม่ว่างจะทำอย่างไร หรือถ้าคำขอไม่ชัดเจนจะทำอย่างไร เขาไม่ได้แค่ส่งสัญญาณผ่านไป แต่ตีความและลงมือทำตามนั้น
Maven Apps คือพนักงานรับสาย ไม่ใช่แผงสวิตช์ ตอนที่เราเริ่มสร้างเฟรมเวิร์กที่ขับเคลื่อนโครงสร้างพื้นฐาน App ของเรา เราตัดสินใจอย่างตั้งใจว่า จะไม่สร้างเลเยอร์ integration อีกชั้น แต่จะสร้างแพลตฟอร์มแอปพลิเคชันของจริง และให้เอเจนต์ AI เป็นพลเมืองชั้นหนึ่งบนแพลตฟอร์มนั้น
วันนี้มีแอปหลายพันแอปบนเฟรมเวิร์กของเรา ซึ่งรวมถึงแอปสำหรับระบบภายนอกหลักๆ อย่าง Salesforce, Zendesk และ Notion แต่ยังมีแอปที่สร้างขึ้นเฉพาะอีกหลายร้อยแอปที่ทำงานอยู่ใน production บนเอเจนต์ที่ใช้งานจริง
ทำไม integration พื้นฐานจึงไม่เพียงพอ
ถามผู้ให้บริการ 10 รายว่า "integrate กับ Salesforce ได้" หมายถึงอะไรสำหรับผลิตภัณฑ์ของเขา คุณจะได้คำตอบ 10 แบบ เพราะระบบอย่าง Salesforce, Zendesk หรือ Front ไม่เคยเป็นแค่สิ่งเดียว ระบบเหล่านี้อาจเป็น:
- ที่ที่เอเจนต์ต้องเข้าไปค้นหาข้อมูล (ฐานความรู้ ประวัติเคส)
- ที่ที่เอเจนต์ต้องเข้าไปลงมือทำ (สร้างทิกเก็ต อัปเดตเรคคอร์ด คืนเงิน)
- พื้นที่ที่เอเจนต์ต้องไปปรากฏตัว (co-pilot สำหรับ agent assist ภายในคอนโซลที่ทีมซัพพอร์ตใช้งานอยู่ทุกวัน)
"Salesforce integration" ที่รู้จักแค่บทความ ไม่ใช่ผลิตภัณฑ์เดียวกับที่สามารถเปิดเคสได้ด้วย และก็ไม่ใช่ผลิตภัณฑ์เดียวกับที่อยู่ในคอนโซลของเอเจนต์ในฐานะ co-pilot ได้ แต่ทั้งหมดนี้มักถูกเหมารวมอยู่ใต้คำทางการตลาดคำเดียว แล้วปล่อยให้คุณไปเจอช่องโหว่เอาเองระหว่างการติดตั้งใช้งาน
นี่คือปัญหาแบบตู้หยอดเหรียญ เมนูตายตัวที่ทำงานได้ตามที่โฆษณาไว้ทุกอย่าง จนกระทั่งสิ่งที่คุณต้องการไม่อยู่ในรายการ และถึงตอนนั้นคุณก็ตัดสินใจไปแล้ว เราไม่อยากให้ Maven Apps ทำงานแบบนั้น จึงออกแบบเฟรมเวิร์กโดยยึดคำถามที่แท้จริง (ความรู้ ความสามารถ หรือช่องทาง) แทนที่จะยึด "connector" แบบทั่วไป
Maven Apps: มากกว่า integration
Maven Apps มีได้หลายรูปแบบ แต่ส่วนใหญ่สร้างขึ้นจากรูปแบบทั่วไปไม่กี่แบบ ตัวอย่างสิ่งที่แอปทำได้:
- Knowledge apps อ่านและทำดัชนีเนื้อหาจากระบบภายนอก เพื่อให้เอเจนต์ตอบคำถามจากเนื้อหานั้นได้ แบบอ่านอย่างเดียว มีการจัดเวอร์ชัน และติดแท็กตามกลุ่มผู้ใช้ได้
- Capability apps ทำให้เอเจนต์ลงมือทำบางอย่างในระบบนั้นได้จริง ผ่านการเรียก API จริง ที่เชื่อมต่อกันเป็นเวิร์กโฟลว์หลายขั้นตอน (ค้นหาคำสั่งซื้อ ตรวจสอบนโยบายการคืนสินค้า คืนเงิน แล้วยืนยันกลับไปยังลูกค้า) ทั้งหมดภายในบทสนทนาเดียว ขณะที่ตู้ ATM ทำธุรกรรมตามสคริปต์จากเมนูตายตัวทีละรายการ capability app ทำงานคล้ายพนักงานธนาคารส่วนตัวมากกว่า คือรับผลลัพธ์ที่ต้องการ ไม่ใช่รายการในเมนู แล้วทำทุกอย่างเพื่อไปให้ถึง รวมถึงจัดการกรณียกเว้นด้วย
- Channel apps นำเอเจนต์ไปอยู่ในที่ที่ลูกค้าหรือทีมซัพพอร์ตของคุณอยู่แล้ว ไม่ว่าจะเป็นวิดเจ็ตแบบฝัง การโทรศัพท์ inbox หรือแผง co-pilot ในคอนโซลที่เอเจนต์ของคุณใช้ทุกวัน
แอปสำเร็จรูปในไดเรกทอรีของเรามักติดตั้งได้ภายในไม่กี่นาที และเมื่อระบบของลูกค้าไม่มีอยู่ในแคตตาล็อก นักพัฒนาก็ใช้เฟรมเวิร์กเดียวกัน SDK เดียวกัน lifecycle hooks เดียวกัน และโมเดลความปลอดภัยเดียวกันในการสร้างแอปเฉพาะขึ้นมาเอง
ไม่มีเฟรมเวิร์กระดับ "enterprise-grade" แยกต่างหากที่มีแต่วิศวกรของเราใช้ App Studio ซึ่งเป็นแพลตฟอร์มนักพัฒนาสำหรับสร้างแอปของเรา ทำงานบนสถาปัตยกรรมเดียวกันทุกประการ เป็น TypeScript จริง SDK จริง (@mavenagi/mavenagi) และ deploy pipeline จริง ไม่ใช่ภาษาสคริปต์เฉพาะที่คุณต้องเรียนรู้เพื่อใช้กับเราเท่านั้น
หากคุณเคยพัฒนาบน MCP มาก่อน Maven App ให้แนวคิดคล้ายกันในรูปแบบ fully managed เซิร์ฟเวอร์ MCP มาตรฐานยังหมายความว่าคุณต้องตั้งค่า ลงทะเบียน ดูแลให้ทำงานต่อเนื่อง และขยายขนาดเอง ส่วน Maven App ใกล้เคียงกับ MCP endpoint ที่ลงทะเบียนและขยายขนาดได้อัตโนมัติ โดยไม่มีโครงสร้างพื้นฐานเหลือให้คุณต้องดูแล คุณเขียนแค่ลอจิก ส่วน endpoint การยืนยันตัวตน และโฮสติ้ง เราจัดการให้
Apps ถูกออกแบบให้ทรงพลังอย่างไร
Maven App คือแอปพลิเคชันแบบ serverless ที่ทำงานในสภาพแวดล้อมที่ปลอดภัยและแยกส่วน และสื่อสารกับแพลตฟอร์ม Maven ผ่าน SDK ที่กำหนดไว้ กล่าวอย่างเป็นรูปธรรม:
รองรับ multi-tenant แอปหนึ่งสร้างครั้งเดียวแต่ติดตั้งได้หลายครั้ง ข้ามองค์กรและเอเจนต์ต่างๆ แต่ละการติดตั้งมีบริบทเฉพาะของตัวเอง (organization ID, agent ID และการกำหนดค่ารันไทม์ของตัวเอง) แต่ใช้โค้ดพื้นฐานชุดเดียวกัน หมายความว่าเมื่อเราปรับปรุงแอป Salesforce ลูกค้าทุกรายที่ใช้งานอยู่จะได้ประโยชน์ทันที และไม่มีใครต้องติดอยู่กับ integration เวอร์ชันเก่าที่ทำขึ้นเองเฉพาะ "ของตัวเอง"
แยกส่วนอย่างแท้จริง ไม่ใช่ของต่อเติม แต่ละแอปทำงานเป็นฟังก์ชันของตัวเองในสภาพแวดล้อมที่ปลอดภัย แยกจาก backend หลักของ Maven และแยกจากแอปของลูกค้ารายอื่น ลอจิกเฉพาะของคุณจะไม่ทำงานอยู่ใน monolith ที่ใช้ร่วมกับคนอื่น การเชื่อมต่อออกไปยังระบบหลักของคุณทำได้ผ่าน VPN, VPC peering, OIDC หรือ HTTPS ทั่วไปพร้อม IP allowlisting ตามที่คุณเลือก ไม่ใช่ที่เรากำหนด
ตอบสนองต่อเหตุการณ์จริง ไม่ใช่ตารางการ polling แทนที่จะใช้งาน sync ทุกคืน แอปสามารถใช้ event hooks ที่เรียกว่า triggers ได้ เช่น มีการสร้างบทสนทนา มีฟีดแบ็กเข้ามา หรือฐานความรู้ถูกรีเฟรช แล้วแพลตฟอร์มจะแจ้งแอปทันทีที่เหตุการณ์นั้นเกิดขึ้น ซึ่งต่างจากเครื่องมือ automation ที่คุณอาจรู้จัก trigger ของ Maven เป็นแบบ passive คือตัวแพลตฟอร์มเองคอยฟังการเปลี่ยนแปลงสถานะแล้วส่งต่อไปยังทุกแอปที่เกี่ยวข้อง โดยแอปที่ทำให้เกิดเหตุการณ์กับแอปที่ตอบสนองไม่ต้องผูกติดกัน ในทางปฏิบัติ แอปตอบอีเมลกับแอป sync กับ Salesforce ที่แยกกันโดยสิ้นเชิง สามารถตอบสนองต่อเหตุการณ์ "conversation updated" เดียวกันได้อย่างอิสระ ต่างคนต่างทำหน้าที่ของตัวเอง โดยไม่ต้องรู้ด้วยซ้ำว่าอีกแอปมีอยู่
นี่คือกลไกการประสานงานแบบเดียวกับที่อาณาจักรมดใช้ ไม่มีมดตัวไหนวางแผนพฤติกรรมของทั้งอาณาจักร และไม่มีมดตัวไหนส่งข้อความหาอีกตัวโดยตรง มดตัวหนึ่งเปลี่ยนแปลงบางอย่างในสภาพแวดล้อมที่ใช้ร่วมกัน (รอยฟีโรโมน) แล้วมดตัวอื่นๆ ก็ตอบสนองต่อการเปลี่ยนแปลงนั้นอย่างอิสระ ตามกฎง่ายๆ ของตัวเอง ความฉลาดระดับอาณาจักร (เส้นทางหาอาหารที่เหมาะที่สุด การกระจายภาระงาน หรือแม้แต่การตัดสินใจร่วมกันอย่างการย้ายรัง) เกิดขึ้นจากสิ่งนั้น โดยไม่มีผู้ประสานงานส่วนกลาง และไม่มีมดตัวไหนรู้แผนทั้งหมด Maven Apps ประสานงานกันแบบเดียวกัน เหตุการณ์หนึ่งเปลี่ยนสถานะที่ใช้ร่วมกัน แล้วทุกแอปที่เกี่ยวข้องก็ตอบสนองด้วยตัวเอง
มี lifecycle จริง ทุกแอปใช้ lifecycle hooks ชุดเล็กๆ ดังนี้:
preInstall: ตรวจสอบ credentials และการกำหนดค่าก่อนเริ่มใช้งานจริง หาก API key ผิด การติดตั้งจะล้มเหลวอย่างชัดเจนตรงนี้ แทนที่จะล้มเหลวเงียบๆ ในอีก 3 สัปดาห์ต่อมาpostInstall: ลงทะเบียน actions ของแอปและจัดเตรียมทรัพยากรที่จำเป็นเมื่อการติดตั้งสำเร็จexecuteAction: ทำงานจริงตามที่เอเจนต์ร้องขอ โดยเปิดให้ลูกค้าใช้ในรูปแบบ capability เช่น ค้นหาคำสั่งซื้อ สร้างเคส คืนเงิน หรือตรวจสอบยอดคงเหลือในบัญชี
integration ส่วนใหญ่เป็นเหมือนสวิตช์ไฟ เปิดหรือปิด ไม่มีอะไรตรงกลาง แต่ของเราทำงานตาม lifecycle เต็มรูปแบบ ทั้งติดตั้ง ตรวจสอบ รัน และ teardown ใกล้เคียงกับกิจวัตรที่อ่านบริบทและปรับตัว (ตรวจสอบว่ามีอะไรเปิดอยู่ ยืนยันว่าอะไรปลอดภัย แล้วจึงลงมือ) มากกว่าสวิตช์ที่มีแค่ 2 สถานะ นี่คือวินัยที่คุณคาดหวังได้จากซอฟต์แวร์ระดับ production เพราะมันคือซอฟต์แวร์ระดับ production จริงๆ
Apps กับ Integrations
integration ทั่วไปตอบคำถามแคบๆ เพียงข้อเดียว ซึ่งมักเป็น "ข้อมูลไปจาก A ถึง B ได้หรือไม่" แล้วถือว่านั่นคือเส้นชัย แต่ Maven App ถูกสร้างมาเพื่อตอบคำถามที่ยากและมีประโยชน์กว่า คือเอเจนต์ AI รู้ได้อย่างน่าเชื่อถือหรือไม่ว่าอะไรเป็นจริงในระบบของคุณ ณ ตอนนี้ และไว้วางใจให้ลงมือทำแทนคุณได้หรือไม่เมื่อจำเป็น
แพลตฟอร์มองค์กรส่วนใหญ่มีตัวเลือกประมาณว่า "สร้างเองได้ ถ้าเราไม่มีให้สำเร็จรูป" สิ่งที่มักไม่บอกคือ การสร้างเองหมายถึงต้องดูแลเซิร์ฟเวอร์เอง ขยายขนาดเอง ตรวจสอบความปลอดภัยเอง บนโครงสร้างพื้นฐานของคุณเอง ช่องว่างเล็กๆ ในแคตตาล็อก connector จึงกลายเป็นการตัดสินใจเรื่องกำลังคน ว่าจะขอบประมาณด้านวิศวกรรมและโครงสร้างพื้นฐาน หรือจะยอมจำกัดอยู่กับสิ่งที่มีสำเร็จรูป ด้วย Maven Apps ลูกค้าของเราไม่ต้องถูกบังคับให้เลือกทางที่แย่น้อยที่สุด แอปเฉพาะที่คุณหรือนักพัฒนาของคุณสร้างขึ้นจะทำงานบนโครงสร้างพื้นฐานของเรา ด้วยการมอนิเตอร์ การขยายขนาด และมาตรฐานความปลอดภัยเดียวกับแอปสำเร็จรูปทุกตัวในไดเรกทอรีของเรา คุณเขียนโค้ด เรารันให้
นี่จึงเป็นเหตุผลที่สถาปัตยกรรมนี้ให้ความสำคัญกับเรื่องที่ webhook ธรรมดาไม่เคยต้องกังวล:
- Response ที่มีโครงสร้างและจำกัดขนาด ทุก action ที่แอปทำจะส่งคืน response ที่ชัดเจนพร้อมข้อมูลแบบมีโครงสร้างที่เอเจนต์นำไปใช้ให้เหตุผลต่อได้ ไม่ใช่ข้อมูลดิบไร้ขอบเขตที่ต้องเดาเอาเอง
- การยืนยันตัวตนแบบลงนามและสองทาง แพลตฟอร์มลงนามทุกคำขอที่ส่งไปยังแอป เพื่อให้แอปตรวจสอบได้ว่าเป็น Maven ที่เรียกมาจริง และแอปก็ยืนยันตัวตนกลับไปยังแพลตฟอร์มด้วย credentials ของตัวเอง ไม่มีฝ่ายไหนต้องพึ่งความไว้วางใจในเครือข่ายเพียงอย่างเดียว
- ตรวจสอบการกำหนดค่าก่อนถึง production เนื่องจาก
preInstallทำงานก่อนแอปเริ่มใช้งานจริง credentials ที่ผิดหรือการตั้งค่าที่ขาดหายจะถูกตรวจพบตั้งแต่ตอนติดตั้ง ไม่ใช่ครั้งแรกที่ลูกค้าต้องพึ่งพามัน - มีโครงสร้างพื้นฐานจริงรองรับ ไม่ใช่แค่การเรียกฟังก์ชัน เนื่องจากแอปเป็นแอปพลิเคชันเต็มรูปแบบ จึงเก็บ state ได้จริง ทั้ง cache ตัวนับ rate หรือฐานข้อมูลขนาดเล็ก ไม่ใช่แค่ request และ response แบบ stateless ซึ่งทำให้ทำสิ่งต่างๆ ได้ เช่น ติดตามว่าอัตราการแก้ปัญหาของโดเมนหนึ่งลดลงเกิน 10% ในช่วง 24 ชั่วโมงที่ผ่านมาหรือไม่ และแจ้งเตือนทีมของคุณเมื่อเกิดขึ้น การเรียก API เปล่าๆ เก็บความจำแบบนั้นไม่ได้ แต่แอปพลิเคชันจริงทำได้ เช่นเดียวกับที่อาณาจักรมดจำได้ว่าอาหารอยู่ที่ไหน แม้ไม่มีมดตัวไหนจำได้เลย
- กันข้อมูลอ่อนไหวออกจากโมเดล บางขั้นตอนไม่ควรผ่าน AI เลย เมื่อลูกค้าพร้อมซื้อสินค้าในตะกร้า เอเจนต์จะเรียกขั้นตอน checkout ของแอป และแอปจะเก็บข้อมูลการชำระเงินและข้อมูลส่วนบุคคลจากลูกค้าโดยตรงผ่านอินเทอร์เฟซที่ปลอดภัยของตัวเอง เอเจนต์ควบคุมลำดับการทำงาน แต่หมายเลขบัตรและข้อมูลอ่อนไหวอื่นๆ จะไม่เข้าไปอยู่ในบทสนทนากับ AI เลย
- โค้ดเบสเดียว ลูกค้าทุกราย ผลกระทบถูกจำกัดวง multi-tenancy ทำให้การแก้ไขและปรับปรุงปล่อยครั้งเดียวแล้วถึงทุกคน ขณะที่การแยกส่วนทำให้ลอจิกเฉพาะของลูกค้ารายหนึ่งไม่มีทางกระทบลูกค้ารายอื่น
สิ่งนี้มีความหมายอย่างไรสำหรับคุณ
หากคุณกำลังประเมิน Maven ข้อสรุปในทางปฏิบัติคือ เมื่อเราบอกว่าเอเจนต์ตอบคำถามและลงมือทำตามนั้นได้ เราหมายความว่ามีแอปพลิเคชันจริงอยู่เบื้องหลัง action นั้น มีการจัดเวอร์ชัน ยืนยันตัวตน แยกส่วน และสร้างบนเฟรมเวิร์กเดียวกัน ไม่ว่าจะมาจากทีมของเราหรือทีมของคุณ นี่คือความต่างระหว่างเอเจนต์ที่พูดถึงระบบของคุณได้ กับเอเจนต์ที่เชื่อมเข้ากับระบบของคุณได้จริง
เราสร้าง Maven Apps เพราะเราเชื่อว่านี่คือสิ่งที่ "integration" ควรจะหมายถึงมาตั้งแต่แรก
ทดลองกับบทสนทนาของคุณเอง
ขอรับเดโมเฉพาะสำหรับคุณฟรี
