ทำไม App Layer ถึงยังไม่ตาย
คำถามที่ผมได้รับจากผู้ก่อตั้งและพนักงานที่มีศักยภาพอยู่เรื่อยๆ คือ: ยังมี AI application layer ให้สร้างอีกไหม หรือ OpenAI กับ Anthropic จะมาทำลายทุกอย่างหมด?
มีอาการของ AI psychosis แบบเฉพาะอยู่เบื้องหลังคำถามนี้ บางคนสรุปว่าที่เดียวที่ปลอดภัยจากการเป็นชนชั้นรองถาวรคือการอยู่ในแล็บใหญ่ หรือออกไปสร้างสิ่งใหม่ในสาย robotics, hardtech หรืออะไรทำนองนั้น – ในทางทฤษฎีคืออะไรก็ตามที่ "แล็บแตะต้องไม่ได้" ถ้าซอฟต์แวร์ทุกชิ้นกำลังจะถูกกิน ไม่ว่าจะโดย Codex หรือ Claude ที่ดูดซับงานโดยตรง หรือโดยโมเดลในอนาคตที่จะทำให้สิ่งที่คุณสร้างขึ้นมาไร้ความจำเป็น งั้นก็หนีสิ!
ฟังนะ ผมเป็น AI maximalist พอๆ กับใครๆ และผมคิดว่าพวกเขาพูดถูกครึ่งหนึ่ง แล็บต่างๆ กำลังจะเข้ามาแทนที่ application surface ส่วนใหญ่จริงๆ แต่ "application layer" ไม่ใช่แค่โอกาสแบบเดียวกันทั้งหมด กรอบความคิดที่ถูกต้องคือการดูว่าคุณอยู่บน Yellow Brick Road หรืออยู่ที่อื่นใน Oz
Yellow Brick Road คือคำเรียกสั้นๆ ของเราสำหรับเส้นทางที่แล็บต่างๆ กำลังเดินอยู่ ซึ่งพวกเขาทุ่มเททรัพยากรมหาศาล เหตุผลที่แล็บเหมาะที่สุดกับปัญหาเช่นการเขียนโค้ด การเขียนเนื้อหา หรือการสร้างภาพ ก็เพราะปัญหาพวกนี้ดีขึ้นเมื่อความสามารถดิบของโมเดลดีขึ้น: ทุกดอลลาร์ที่ใช้ไปกับการ pre-training และ post-training จะช่วยปรับปรุงคุณภาพของผลิตภัณฑ์ ในขณะเดียวกัน ส่วนอื่นๆ ของ Oz ก็เต็มไปด้วยปัญหาที่ซับซ้อนกว่า มักเป็นแนวตั้ง ซึ่งไม่ง่ายเหมือนกับการให้เครื่องมือแนวนอนแก่ผู้ใช้ทางธุรกิจที่เข้าถึงเครื่องมือมาตรฐานและการใช้งานคอมพิวเตอร์ได้ คุณค่ามาจากความสามารถดิบของโมเดลพื้นฐานน้อยกว่า (ถึงแม้จะยังสำคัญ!) มากกว่ามาจากโครงสร้างรอบๆ ที่ทำให้ผลลัพธ์น่าเชื่อถือ เป็นไปตามข้อกำหนด และทำงานได้ในอุตสาหกรรมเฉพาะ
เรากำลังเห็นสิ่งนี้เกิดขึ้นจริงในขณะที่ OpenAI และ Anthropic กำลังบอกตลาดอย่างมีประสิทธิภาพว่าพวกเขาไม่สามารถแก้ปัญหาทุกอย่างได้ด้วยเพื่อนร่วมงาน AI ทั่วไป พวกเขาได้ประกาศ กิจการร่วมค้าขนาดใหญ่ที่เน้นการปรับใช้ล่วงหน้า เพื่อสร้างทั้งบริษัทที่เน้นการกำหนดค่าและปรับแต่งโมเดลของพวกเขาสำหรับองค์กร คุณจะไม่ทุ่มเงินหลายพันล้านลงในโปรแกรมเหล่านั้นถ้าคุณคิดว่าโมเดลรุ่นถัดไปจะจัดการทุกอย่างได้เอง
ดังนั้นถ้าคุณอยากรวยจากการสร้างแอป AI – จงหลีกเลี่ยง yellow brick road และไปสร้างที่อื่นใน Oz นี่คือสิ่งที่เราได้เรียนรู้ และสิ่งที่ผู้ก่อตั้งในพอร์ตของเราบางคนได้เรียนรู้ เกี่ยวกับสิ่งที่ได้ผล
Yellow Brick Road
ถ้าคุณกำลังเริ่มต้นบริษัท Yellow Brick Road คือเส้นทางที่ชัดเจนที่สุด แต่ก็อันตรายที่สุด ใช้โมเดลประสิทธิภาพสูง เสียบปลั๊กคอนเนคเตอร์สำเร็จรูป (เช่น G Drive, Slack, Salesforce, Notion, GitHub) แล้ววาง orchestration layer แบบ agentic ไว้ด้านบน ก็เสร็จ! วิเศษ!
ปัญหาคือว่านี่คือสิ่งที่แล็บต่างๆ กำลังทำกับ Cowork และ Codex แน่นอนว่าพวกเขาเป็นเจ้าของโมเดล ซึ่งทำให้พวกเขามีมาร์จิ้นที่ดีกว่า การควบคุม และความสามารถในการใช้อำนาจกำหนดราคากับใครก็ตามที่อยู่ downstream จากพวกเขา แต่ที่สำคัญที่สุดคือพวกเขายังเป็นเจ้าของตัวเลือกทางสถาปัตยกรรมที่กำหนดว่าผลิตภัณฑ์ของพวกเขาถูกสร้างขึ้นมาเพื่อแก้ปัญหาอะไรได้ดี พวกเขาจงใจใช้รูปแบบ model plus tool calls มาจนถึงตอนนี้ และนี่คือสิ่งที่งานแนวนอนที่มีขั้นตอนน้อยบนถนนเส้นนี้ต้องการ ถึงแม้สตาร์ทอัพจะทำได้ดีกว่า Codex หรือ Claude Code ได้ somehow แต่แล็บต่างๆ ก็มีช่องทางการจัดจำหน่ายมหาศาลและรัศมีแบรนด์ที่ใหญ่ที่สุดใน AI
ถ้าคุณเป็นบริษัทแอป AI ที่ใช้แผนการเล่นนั้นกับคอนเนคเตอร์เดียวกัน ไม่มี sub-agents หรือการกำหนดค่าข้างใต้ และไม่มีการจัดจำหน่าย คุณกำลังเดินไปบนถนนที่ไปไม่ถึงไหน
ส่วนอื่นๆ ของ Oz
ไม่ใช่ทุกอย่างจะมืดมนสำหรับสตาร์ทอัพ มีโอกาสมหาศาลอยู่นอก Yellow Brick Road ที่ซึ่งสตาร์ทอัพมีเส้นทางที่ชัดเจนในการเป็นเจ้าของลูกค้าและแก้ปัญหาที่ซับซ้อน
ธุรกิจเหล่านี้กำลังสร้างประสบการณ์แบบ agentic ที่โมเดลถูกถักทอผ่านเครือข่ายที่ซับซ้อนของเครื่องมือ ระบบอัตโนมัติ และการบูรณาการ (อ่านว่า: ซอฟต์แวร์) ทำให้สตาร์ทอัพส่วนใหญ่กลายเป็นแนวตั้งโดยปริยาย พวกเขาสามารถมุ่งเน้นไปที่งานที่มีหลายขั้นตอนและหลายฝ่าย โดยมี sub-agents สำหรับงานเฉพาะบทบาทและแนวตั้ง ที่ Anthropic และ OpenAI ไม่สามารถเข้าถึงได้ด้วยแพลตฟอร์มแนวนอน: การรวบรวมบริบทจากหลายระบบ จากนั้นส่งต่อไปยังมนุษย์หลายคนที่ต้องอนุมัติในขั้นตอนต่างๆ มันมักเกี่ยวข้องกับระบบเดิมหนึ่งระบบขึ้นไป มักจะต้องการผลลัพธ์ที่แน่นอนซึ่งความคลุมเครือไม่สามารถยอมรับได้ และบางครั้งก็เชื่อมโยงกับผลลัพธ์ทางธุรกิจที่มีคุณค่า แล็บต่างๆ เข้าใจว่าปัญหาเหล่านี้มีคุณค่าแค่ไหน: นั่นคือเหตุผลที่พวกเขาสร้างร้านค้ากำหนดค่าภายนอกของตัวเอง และเหตุผลที่มีธุรกิจ reinforcement learning ระดับบนทั้งคลาส
ทำไมส่วนอื่นๆ ของ Oz จะไม่ถูกครอบครองโดยพ่อมด
การตอบสนองต่อสิ่งที่กล่าวมาข้างต้นก็คือ จนถึงตอนนี้ การเดิมพันต่อต้านการปรับปรุงของโมเดล/แล็บนั้นเป็นการเดิมพันที่แย่มาก พวกเขามักจะดีขึ้นเรื่อยๆ และในที่สุดก็จะกินตลาดที่ธุรกิจ application layer เหล่านี้ให้บริการ
แล็บต่างๆ จะดีขึ้นอย่างแน่นอน แต่ผมอยากโต้แย้งว่ามีสองสามวิธีที่ส่วนอื่นๆ ของ Oz สามารถป้องกันตัวเองได้เมื่อเวลาผ่านไป:
Data และ Learning Flywheels:
สิ่งต่างๆ มากมายที่คุณซึมซับไม่ได้อยู่ใน training set ใดๆ — บรรทัดฐานอุตสาหกรรมที่ไม่ได้เขียนไว้ มาตรฐานที่ไม่ได้บันทึก ความรู้ของชนเผ่าที่อยู่ในหัวของผู้ปฏิบัติงาน ไม่มีสิ่งใดเลยที่อยู่บนเว็บสาธารณะ ไม่มีปริมาณ training compute ใดมาแทนที่การอยู่ภายใน workflows ที่ซึ่งความรู้นี้มีอยู่จริง มี flywheels สองอันที่ซ้อนทับกันอยู่ที่นี่: อันที่ข้ามลูกค้า — รูปแบบที่ทวีคูณเมื่อคุณเห็นตัวแปรต่างๆ ของปัญหาเดียวกันมากขึ้น — และอันที่ภายในลูกค้า — เหตุผลเบื้องหลังการตัดสินใจเฉพาะ ข้อยกเว้นที่ไม่ได้พูดออกมา กฎประจำบริษัทที่ปรากฏผ่านการโต้ตอบจริงกับระบบเท่านั้น
ถึงแม้ข้อมูลลูกค้าจะไม่สามารถใช้ข้ามลูกค้าได้ บริษัทแอปพลิเคชันก็จะสามารถใช้ประโยชน์จากการจดจำรูปแบบข้ามประเภทปัญหาของลูกค้า และใช้สิ่งนั้นเพื่อแจ้งสถาปัตยกรรมที่เหมาะสมสำหรับปัญหาในอนาคต บริษัทที่รัน agents ของมันผ่าน legal redlines หลายร้อยครั้ง วงจรการรับประกันภัยหลายพันรอบ หรือแคมเปญ SDR หลายหมื่นแคมเปญ ได้ซึมซับรูปร่างของปัญหาในแบบที่ผู้เข้ามาใหม่ไม่สามารถเลียนแบบได้ด้วยการเปิด agent ใหม่เป็นครั้งแรก
agent แนวนอนสามารถสร้างโครงสร้างพื้นฐานการเรียนรู้แบบเดียวกันได้ในหลักการ เหตุผลที่มันไม่ทำ นอกเหนือจากเรื่องโฟกัสล้วนๆ ก็คือ UX: การจับความรู้ประเภทนี้ขึ้นอยู่กับพื้นผิว workflow ที่คุณให้ผู้ใช้ และผู้เล่นแนวตั้งสามารถปรับพื้นผิวเหล่านั้นให้ตรงกับสิ่งที่ workflow ของพวกเขาจำเป็นต้องแสดงผล เครื่องมือแนวนอนทำไม่ได้ ชุดประเมินผล ผลลัพธ์ที่ติดป้ายกำกับ และอนุกรมวิธานกรณีขอบ สามารถทวีคูณเป็น data flywheel เฉพาะแนวตั้ง ซึ่งสามารถเป็นเชื้อเพลิงให้กับการ fine-tuning ที่ผู้เข้ามาใหม่ไม่สามารถสร้างได้หากไม่มีการเปิดรับการผลิตที่เทียบเคียงได้ สิ่งนี้เป็นไปได้หรือไม่ขึ้นอยู่กับสิทธิ์ในข้อมูล ปริมาณการเปิดรับการผลิตที่สะสม และโครงสร้างของสัญญาลูกค้า แต่การจดจำรูปแบบจะสะสมไม่ว่าจะอย่างไรก็ตาม
การจัดการความแปรปรวนและความซับซ้อนของโมเดล: แล็บต่างๆ กำลังทำการ routing ภายในอยู่แล้ว — โมเดลคลาสต่างๆ สำหรับคำขอที่แตกต่างกัน, ensembles ภายใต้ฝาครอบ สิ่งที่พวกเขาทำไม่ได้คือ routing ข้ามผู้จำหน่าย หรือประเมินโมเดลของคู่แข่งสำหรับงานย่อยเฉพาะ หรือใช้ open-source fine-tune สำหรับส่วนแคบๆ ที่มันดีที่สุดจริงๆ บริษัทในส่วนอื่นๆ ของ Oz เลือกโมเดลที่เหมาะสมสำหรับแต่ละงานย่อยจากตลาดโมเดลทั้งหมด ไม่ใช่แค่สิ่งที่แล็บแม่จัดส่งมา มันยังทำงานที่ไม่มีใครอยากทำ — การรัน eval ซ้ำในการอัปเกรด การปรับเทียบ prompt ใหม่สำหรับกรณีขอบของลูกค้า การเปิดตัวโดยไม่ทำให้ระบบผลิตเสียหาย — ทุกครั้งที่มีโมเดลใหม่เกิดขึ้น แล็บต่างๆ ไม่ได้ทำสิ่งนี้ในนามของลูกค้า พวกเขาขายโมเดลถัดไปให้คุณและบอกให้คุณย้ายข้อมูล บริษัทในส่วนอื่นๆ ของ Oz ดูดซับการย้ายข้อมูลนั้น สิ่งที่ลูกค้าได้รับคือความฉลาดที่ดีที่สุดที่มีอยู่ในตลาดทั้งหมด บวกกับความต่อเนื่องผ่านการอัปเกรดทุกครั้ง
การเพิ่มประสิทธิภาพต้นทุน: การรันทุก query ผ่าน Opus 4.7 คือเส้นทางที่เร็วที่สุดสู่ gross margin ติดลบ บริษัทที่ดีที่สุดในส่วนอื่นๆ ของ Oz ทำการ routing ข้ามระดับของโมเดล — โมเดล frontier สำหรับงานที่ยากที่สุด ระดับกลางสำหรับงานส่วนใหญ่ โมเดลขนาดเล็กที่กำหนดเองหรือ fine-tuned ในที่ที่พวกเขาได้รับสิทธิ์ในการใช้มัน บางแห่งกำลัง post-training โมเดลของตัวเองบนนั้น เพิ่มประสิทธิภาพสำหรับงานส่วนแคบๆ ที่ลูกค้าสนใจ และให้บริการในราคาเพียงเศษเสี้ยวของการเรียก API frontier แล็บต่างๆ กำหนดราคาพื้น: ความฉลาดน้อยที่สุดในราคา $X บริษัทในส่วนอื่นๆ ของ Oz ขายสิ่งที่ตรงกันข้าม — ต้นทุนดอลลาร์ต่ำที่สุดสำหรับระดับความฉลาดเฉพาะที่ workflow ต้องการจริงๆ สิ่งนั้นเป็นไปได้ก็ต่อเมื่อคุณรู้แน่ชัดว่างานย่อยแต่ละงานต้องการระดับไหน ซึ่งแล็บต่างๆ ไม่สามารถรู้ได้ในทุกแนวตั้ง มันแปลโดยตรงไปยังราคาที่ต่ำกว่าและควบคุมได้สำหรับผลลัพธ์
การกำกับดูแล: มีคุณค่ามหาศาลในการเป็น control plane สำหรับวิธีที่ลูกค้าของคุณรัน AI ในแนวตั้งนั้น — สถานที่ที่การอนุญาต การตรวจสอบ สิ่งที่ agent ได้รับอนุญาตให้ทำ และสิ่งที่ agent ทำจริง มาบรรจบกัน control plane นั้นสร้างขึ้นจาก guardrails เฉพาะกรณีการใช้งานที่ดูแตกต่างกันอย่างสิ้นเชิงในแต่ละอุตสาหกรรมและประเภทงาน เนื่องจากพวกเขาเป็นเจ้าของเครื่องมือ workflows และข้อมูลที่ agent สัมผัสแบบ end-to-end พวกเขาสามารถให้ผลลัพธ์ที่แน่นอนในแบบที่เครื่องมือแนวนอนจะดิ้นรนทำ พวกเขายังเป็นหน่วยงานที่ดูดซับความซับซ้อนด้านกฎระเบียบสำหรับผู้ซื้อปลายทาง — FRCP และกฎบาร์ในกฎหมาย HIPAA ใน healthcare SEC และ FINRA ในด้านการเงิน กฎระเบียบประกันของรัฐ และอื่นๆ ผู้เล่นแนวนอนไม่สามารถทำสิ่งนั้นได้อย่างน่าเชื่อถือโดยไม่กลายเป็นแนวตั้งร้อยแบบพร้อมกัน CIOs ต้องการมีพันธมิตรที่ระบุตามสัญญาว่าพวกเขากำลังจัดการการปฏิบัติตามข้อกำหนดสำหรับ agents ที่พวกเขาจัดหาให้
ทั้งหมดนี้กลับมาที่สิ่งเดียวกัน: โฟกัส สิ่งนั้นอาจเป็นแนวตั้ง (ประกันภัย กฎหมาย บัญชี) หรือฟังก์ชันที่ทำอย่างลึกซึ้ง (การขาย การสนับสนุนลูกค้า การเงิน) ไม่ว่าจะด้วยวิธีใด งานต้องการทีมที่มุ่งมั่นกับลูกค้าหนึ่งกลุ่ม — workflows ของมัน กรณีขอบของมัน กฎระเบียบของมัน แล็บต่างๆ ไม่ได้ถูกสร้างขึ้นมาเพื่อสิ่งนั้น พวกเขาต้องอยู่ทุกที่ สำหรับทุกคน ซึ่งเป็นวิธีที่พวกเขาสร้าง Yellow Brick Road ตั้งแต่แรก ข้อแลกเปลี่ยนเดียวกันนี้ทำให้พวกเขาอยู่นอกส่วนอื่นๆ ของ Oz — คุณสามารถอยู่ทุกที่ในคราวเดียว หรือคุณสามารถเก่งในสิ่งเดียว ไม่ใช่ทั้งสองอย่าง
การขายเป็นตัวอย่าง – เคล็ดลับเชิงปฏิบัติจาก CEO ด้านเทคนิคของ 11x
คุณควรคิดอย่างไรเกี่ยวกับเรื่องนี้ในทางปฏิบัติ? นี่คือเคล็ดลับเชิงปฏิบัติจาก Prabhav Jain CEO ของ 11x
มุ่งเน้นไปที่ผลลัพธ์
เส้นทางเชิงกลยุทธ์ในการสร้างบริษัทที่ทนทานต่อแล็บคือการเริ่มต้นจากผลลัพธ์เฉพาะที่ลูกค้าของคุณใส่ใจจริงๆ สำหรับเราแล้ว นั่นคือการช่วยให้บริษัทต่างๆ สร้าง pipeline ได้มากขึ้น จากนั้นคำถามก็จะกลายเป็นเชิงกลยุทธ์ กิจกรรมใดที่เราต้องการเป็นเจ้าของแบบ end-to-end ที่ขับเคลื่อน pipeline จริงๆ? แยกย่อยแต่ละกิจกรรมเป็นงาน งานใดเป็น agentic และงานใดไม่ใช่ งานใดต้องการข้อมูลเชิงลึกเฉพาะโดเมนที่ซับซ้อนและงานใดไม่ต้องการ แล็บต่างๆ จะจัดส่ง workflows เช่นกัน แต่เมื่อ workflow มีหลายขั้นตอน อินพุตที่ยุ่งเหยิง สถานะที่ตีความยาก หรือข้อจำกัดในโลกแห่งความจริง โมเดลที่ดีกว่าเพียงอย่างเดียวจะไม่พาคุณไปถึงจุดนั้น งานตกเป็นของวิศวกรรมซอฟต์แวร์แบบเก่าที่ดี และแล็บต่างๆ ไม่มีความได้เปรียบเหนือบริษัทแอปพลิเคชันที่มุ่งเน้นบนพื้นผิวนั้น ตัวอย่างเช่น นี่คืองานบางส่วนที่เราจัดการ บางส่วนเป็น agentic และบางส่วนไม่ใช่: การหาโอกาสในการขายตามสัญญาณที่กำหนดเอง การเพิ่มคุณค่าให้กับโอกาสในการขาย การวิจัยบัญชีเชิงลึก ตัวดึงข้อมูลบริบทจาก CRM นักเขียนข้อความเฉพาะช่องทาง agent การคัดเลือกโอกาสในการขาย และระบบการจัดส่งอีเมล สิ่งเหล่านี้ไม่ใช่งานที่คุณสามารถทำได้ในครั้งเดียวและต้องใช้วิศวกรรมเชิงลึก
ข้อมูลเชิงลึกที่สำคัญในการเปรียบเทียบ Oz คือประมาณครึ่งหนึ่งของ workflow จริงใดๆ ที่ไม่ใช่ agentic ไม่มีความได้เปรียบจากแล็บ พวกเขาไม่ได้ดีไปกว่าคุณในการเขียนซอฟต์แวร์ที่กำหนดได้ภายใต้ layer ของโมเดล และครึ่งหนึ่งที่เป็น agentic ก็ยังต้องการให้คุณปรับแต่ง ฝึกฝน และจำกัดโมเดลให้สอดคล้องกับผลลัพธ์ที่คุณต้องการจริงๆ ความรู้เฉพาะโดเมนมักจะไม่อยู่ในข้อมูลการฝึกทั่วไป ทักษะเหล่านั้นถูกสร้างขึ้นจากพื้นฐานสำหรับแนวตั้งหรือฟังก์ชันนั้น และป้อนเข้าสู่โมเดลในช่วงเวลาที่เหมาะสมใน workflow เมื่อ agents ของเรากำลังคัดเลือกโอกาสในการขายขาเข้าทางโทรศัพท์ ผมต้องได้รับการฝึกฝนว่าการสนทนาการขายที่ดีสำหรับอุตสาหกรรมเฉพาะและบุคลิกนั้นคืออะไร นั่นคืองานของบริษัทแอปพลิเคชัน และมันทวีคูณ
ที่สำคัญกว่านั้น ทักษะเหล่านั้นล้าสมัยตลอดเวลาเพราะธุรกิจมีการพัฒนา ดังนั้นความสามารถของคุณในการพัฒนา workflows และบริบทเหล่านั้นจึงกลายเป็นความได้เปรียบทางการแข่งขัน ตัวอย่างเช่น เมื่อเราเริ่มต้นผลิตภัณฑ์การส่งอีเมลขาออกแบบปรับขนาดได้ อีเมลที่เขียนโดย "AI" เพิ่งเริ่มมีบทบาท มาถึงวันนี้ ผู้คนมีประสาทสัมผัสที่ปรับแต่งแล้วสำหรับอีเมลที่เขียนโดย AI เทียบกับมนุษย์ และที่สำคัญ สิ่งนี้เปลี่ยนแปลงทุกสองสามเดือน agents ของเราต้องปรับตัวอย่างต่อเนื่องตามพลวัตของตลาด แต่นี่คือที่มาของการสร้าง moat อันที่จริง แม้จะมีพลวัตนี้ อัตราการตอบกลับเชิงบวกของเราก็เพิ่มขึ้น 4 เท่าในช่วงสองสามเดือนที่ผ่านมา และเราสร้าง pipeline มูลค่าหลายร้อยล้านให้กับลูกค้าของเรา
ทำงานกับปัญหาที่มีความซับซ้อนสูง
ปัญหาที่ซับซ้อนคือที่ซึ่งคุณค่าทางธุรกิจที่แท้จริงถูกปลดล็อก มิฉะนั้นคุณจะพบว่าตัวเองกำลังสร้าง wrapper บางๆ
แยกย่อยปัญหาทางธุรกิจที่ซับซ้อนพอสมควรใดๆ และความยุ่งเหยิงจะปรากฏขึ้นอย่างรวดเร็ว นี่คือตัวอย่างจากโลก GTM ที่ฟังดูเล็กน้อย: คุณไม่ควรติดต่อผู้ติดต่อที่บริษัทถ้าบริษัทนั้นเป็นลูกค้าอยู่แล้ว มันไม่ใช่เรื่องง่ายเลย บางทีคุณมีโดเมนที่เกี่ยวข้องกับบริษัทใน CRM ของคุณ แล้วบริษัทที่มีบริษัทย่อยหลายสิบแห่งล่ะ? จะเกิดอะไรขึ้นถ้าเรกคอร์ด CRM มีโดเมนของบริษัทแม่? จะเกิดอะไรขึ้นถ้าฟิลด์การจับคู่ที่ล้าสมัยใน Salesforce ส่งข้อเสนอเย็นไปยัง CRO ของลูกค้าปัจจุบัน? ข้อมูลในโลกแห่งความจริงนั้นยุ่งเหยิง มนุษย์ก็ลำบากกับมัน โมเดลไม่ได้เคลียร์บาร์นั้นอย่างน่าอัศจรรย์ การสร้างระเบียบจากความยุ่งเหยิงนั้นต้องการ agents ที่สร้างขึ้นโดยเฉพาะซึ่งออกแบบมาสำหรับรูปร่างเฉพาะของปัญหา ไม่ใช่ copilot ทั่วไปที่ชี้ไปที่ CRM อันที่จริง จากข้อมูลที่เรามี เราตระหนักว่าคุณภาพและความสดใหม่ของข้อมูลของเราสูงกว่าของลูกค้ามาก ดังนั้นโดยค่าเริ่มต้น เรายึดมั่นในข้อมูลของเราเอง
Guardrails ไม่ได้มีไว้เพื่อป้องกันสิ่งเลวร้ายเท่านั้น นั่นคือสิ่งที่ลูกค้าของคุณจ่ายเงินให้คุณ
Guardrails ถูกประเมินค่าต่ำเกินไปอย่างรุนแรง แม้แต่ภายในผลิตภัณฑ์เดียวกัน ทุกกรณีการใช้งานก็ต้องการของตัวเอง สำหรับเรา ลูกค้าที่เป็นสถาบันการเงินที่มีการควบคุมต้องการการรับประกันที่แตกต่างจากลูกค้า SaaS ระดับกลาง และการรับประกันเหล่านั้นส่งผลต่อวิธีที่ agent ได้รับอนุญาตให้เขียน ใครที่มันสามารถติดต่อได้ ข้อมูลใดที่มันสามารถแตะต้องได้ สิ่งที่มันสามารถพูดในการโทร และวิธีการบันทึกทุกการตัดสินใจ
ระบบแบบเดียวที่เหมาะกับทุกคนจะพังทลายลงภายใต้ความแปรปรวนนั้น Guardrails ต้องถูกสร้างขึ้นต่อกรณีการใช้งาน กำหนดค่าต่อลูกค้า และตรวจสอบอย่างต่อเนื่อง และงานนั้นอยู่กับบริษัทแอปพลิเคชันอย่างชัดเจน นี่คือเหตุผลที่เรามี FDEs และนักวางกลยุทธ์การปรับใช้ทางเทคนิคที่ต้องปรับแต่งตามความต้องการของลูกค้าแต่ละราย ตัวอย่างเช่น เราทำงานกับสถาบัน F1000 เพื่อทำ outbound ที่ได้รับความยินยอมผ่านเสียงไปยังฐานลูกค้า SMB ขนาดใหญ่ของพวกเขา การทำซ้ำสองสามครั้งแรกมีอัตราการรับสายต่ำ — เราต้องทำซ้ำอย่างรวดเร็วและเรียนรู้วิธีทำให้ผู้ชมประเภทเฉพาะนี้มีส่วนร่วมใน 10 วินาทีแรกของการโทร เจ้าของธุรกิจ SMB มีพฤติกรรมแตกต่างจากผู้ซื้อ B2B หรือผู้บริโภครายใหญ่มาก ตอนนี้เราสร้างโอกาสในการขายให้พวกเขาในหนึ่งวันมากกว่าทีมขายทั้งหมดของพวกเขาสำหรับกลุ่มนั้นในหนึ่งเดือน
การประกันภัยเป็นตัวอย่าง – เคล็ดลับเชิงปฏิบัติจาก CEO ของ FurtherAI
การขายเป็นตัวอย่างหนึ่ง การประกันภัยเป็นอีกตัวอย่างหนึ่ง และมันชี้ให้เห็นประเด็นเดียวกันจากมุมที่แตกต่าง นี่คือวิธีที่ Aman Gour CEO ของ FurtherAI คิดเกี่ยวกับการสร้างนอกถนน:
เมื่อเราเริ่มปรับใช้ AI ในการดำเนินงานประกันภัยจริง เราได้ยินสมมติฐานเฉพาะอยู่เรื่อยๆ: โมเดลคือความฉลาด และ workflow เป็นเพียงโครงสร้างรอบๆ
ยิ่งเราทำงานกับผู้ให้บริการประกันมากเท่าไหร่ เราก็ยิ่งเชื่อว่าสิ่งนี้กลับหัวกลับหาง
ในการประกันภัย ความฉลาดส่วนใหญ่อยู่ภายใน workflow เอง ผู้ให้บริการสองรายสามารถรัน submission ผ่านสิ่งที่ดูเหมือนเส้นทางเดียวกัน: submission, review, quote, bind แต่เส้นทางเป็นส่วนที่ง่าย สิ่งที่แยกผู้ให้บริการทั้งสองออกจากกันคือทุกอย่างภายในนั้น: ความเสี่ยงใดที่ถูกยกระดับ สัญญาณการสูญเสียใดที่สำคัญ กฎความอยากรับความเสี่ยงใดชนะเมื่อสองข้อขัดแย้งกัน เมื่อใดที่มนุษย์ต้องลงนาม ข้อมูลภายนอกใดที่ถูกดึงเข้ามา และวิธีการบันทึกการตัดสินใจขั้นสุดท้าย
ตรรกะนั้นไม่ได้อยู่ใน rules engine ที่สะอาดเพียงเครื่องเดียว มันกระจายอยู่ทั่ว SOPs การตรวจสอบของผู้จัดการ ปรัชญาการรับประกันภัย ความอยากรับความเสี่ยงเฉพาะผู้ให้บริการ และประสบการณ์การดำเนินงานหลายปี ส่วนใหญ่ไม่ได้ถูกเขียนลงในรูปแบบที่โมเดลสามารถอ่านได้ง่าย
นี่คือเหตุผลที่เราไม่เชื่อใน agent บริสุทธิ์ที่ใช้เหตุผลตั้งแต่ต้นทุกครั้ง และเราไม่เชื่อใน workflow ที่แข็งทื่อที่พังทันทีที่ความเป็นจริงยุ่งเหยิง และเรากำลังสร้าง agentic workflows แทน workflow ให้ความสามารถในการทำซ้ำ ความสามารถในการตรวจสอบ และการควบคุมต้นทุนแก่คุณ agent จัดการกับความแปรปรวนและกู้คืนเมื่อเส้นทางที่มีความสุขพัง มนุษย์ยังคงอยู่ในวงจรสำหรับการตัดสินใจที่ความรับผิดชอบมีความสำคัญ
ในวันแรก สิ่งนี้ทำให้งานที่ต้องทำด้วยตนเองเป็นอัตโนมัติ แต่เมื่อเวลาผ่านไป ทุกการยกระดับกลายเป็นสัญญาณ ทุกข้อยกเว้นคือข้อเสนอแนะ และทุกการแก้ไขของมนุษย์แสดงให้เห็นว่า runbook ไม่สมบูรณ์ตรงไหน เมื่อเวลาผ่านไป workflow จะหยุดเป็นสคริปต์และเริ่มกลายเป็นความทรงจำในการดำเนินงานของผู้ให้บริการ นี่คือส่วนที่แล็บต่างๆ จะพบว่ายากที่จะเข้าถึง พวกเขาจะยังคงจัดส่งโมเดลที่ดีขึ้นและ agents ทั่วไปที่ดีขึ้น และพวกเขาควรทำ แต่พวกเขาไม่ได้นั่งอยู่ใน workflows การผลิตของผู้ให้บริการนานพอที่จะเรียนรู้ว่าทำไมบัญชีหนึ่งถึงถูกยกระดับ ทำไมความเสี่ยงหนึ่งถึงถูกปฏิเสธ หรือทำไมผู้รับประกันภัยถึงแทนที่คู่มือความอยากรับความเสี่ยงและทำถูกต้องแล้ว
ความเข้าใจนั้นมาจากการรัน workflow ในการผลิต หลายพันครั้งเท่านั้น workflow ที่คุณจัดส่งในวันแรกไม่ใช่ moat วงจรที่การใช้งานในการผลิตสร้างขึ้นเมื่อเวลาผ่านไปต่างหากที่เป็น moat
สำหรับเรา นั่นคือความหมายของการสร้างนอกถนน
คุณจะตัดสินใจได้อย่างไรว่าคุณอยู่ในส่วนอื่นๆ ของ Oz หรือไม่?
การทดสอบเครื่องมือและขั้นตอน: งานใช้เวลากี่ขั้นตอน และเครื่องมือที่คุณต้องสร้างเพื่อรองรับมันซับซ้อนแค่ไหน? เปรียบเทียบการค้นหา AI แนวนอนใน Google Drive — หนึ่งขั้นตอนกับเครื่องมือเดียวที่มีผลลัพธ์ที่ให้อภัย ผู้ใช้อ่านสรุปและถามใหม่ถ้ามันผิด — กับการตรวจสอบสัญญาทางกฎหมายหลายขั้นตอนกับแบบอย่างของบริษัทสามปี: หลายสิบขั้นตอนข้ามเครื่องมือมากมาย ผลลัพธ์ที่ต้องผ่านการตรวจสอบของหุ้นส่วนและอาจต้องถูกโต้แย้งในศาล ทั้งสองอย่างดูเหมือน "agent ที่ทำงาน" แต่มีเพียงหนึ่งเดียวเท่านั้นที่ต้องการซอฟต์แวร์เชิงลึกแบบที่ทีมที่มุ่งเน้นใช้เวลาหลายปีในการสร้าง
การทดสอบระบบ: คุณกำลังสร้างระบบที่ลูกค้ารันงานผ่าน หรือเครื่องมือที่วางอยู่บนระบบที่พวกเขามีอยู่แล้ว? ระบบเป็นเจ้าของ workflow แบบ end-to-end — การจับข้อมูล การกำกับดูแล บันทึกของสิ่งที่ทำเสร็จ — และมันคือสิ่งที่ลูกค้าชี้ไปเมื่ออธิบายว่างานจริงเกิดขึ้นได้อย่างไร ในทางกลับกัน เครื่องมือเพียงเพิ่มความฉลาดให้กับ workflow ที่ลูกค้ารันอยู่แล้ว กรณีเครื่องมือสร้างรายได้จริงและแล็บสามารถเอามันไปได้เพราะลูกค้าไม่ได้พึ่งพาคุณในฐานะ orchestration layer ACV สูงมักเป็นสัญญาณของระบบ เนื่องจากระบบแทนที่จำนวนพนักงานจริงและได้รับค่าตอบแทนตามนั้น แต่มันไม่ใช่การรับประกัน ถามตัวเองว่าลูกค้าจะยังต้องการเครื่องมือของคุณหรือไม่ถ้าแล็บจัดส่งสิ่งที่ supposedly แข่งขันกับคุณโดยตรง ถ้าใช่ คุณกำลังสร้างระบบ ถ้าไม่ใช่ คุณคือเครื่องมือ — ถึงแม้ ACV ของคุณจะสูงก็ตาม
การทดสอบกองทุนป้องกันความเสี่ยง / P&L: ในขณะที่ประสิทธิภาพของแล็บถูกตัดสินจาก benchmark ประสิทธิภาพของส่วนอื่นๆ ของ Oz ถูกตัดสินจาก P&L ของลูกค้าของคุณ ลูกค้าของคุณไม่สนใจว่าโมเดลของคุณได้คะแนนดีบน SWE-Bench หรือ MMLU — พวกเขาสนใจว่า agent ของคุณปิดการขายได้หรือไม่ ตรวจสอบสัญญาถูกต้องหรือไม่ หรือผูกนโยบายที่ถูกต้องหรือไม่ ถ้าพวกเขายึดติดกับผลลัพธ์เฉพาะ workflow ของพวกเขา ไม่ใช่คะแนนความสามารถทั่วไป แสดงว่าคุณอยู่ในส่วนอื่นๆ ของ Oz ถ้าพวกเขาจ่ายเงินเพื่อความสามารถทั่วไป แสดงว่าคุณกำลังขายสิ่งที่พวกเขาสามารถได้รับจากที่นั่ง Claude หรือ Codex ธุรกิจ agent ที่ดีที่สุดจะต้องดำเนินการเหมือนกองทุนป้องกันความเสี่ยง — ชนะด้วย alpha ที่วัดจาก P&L ของลูกค้า ไม่ใช่คะแนน benchmark
ทั้งสองอย่างสามารถ (และจะ) ชนะ
เราจะได้เห็นผู้ชนะรายใหญ่ทั้งบนและนอก Yellow Brick Road โมเดลจะยังคงชนะต่อไปเพราะพวกเขาเป็นเจ้าของโมเดลและพวกเขาเป็นเจ้าของการจัดจำหน่ายสำหรับเครื่องมือแนวนอนที่พวกเขาออกแบบ
ส่วนอื่นๆ ของ Oz สามารถชนะได้ถ้าพวกเขาเป็นเจ้าของ system of work — พื้นผิวที่งานของบริษัทดำเนินการจริงและข้อมูลที่ไหลจากมันถูกจับ บริษัทเหล่านี้เป็นเจ้าของการจับข้อมูล ระบบการดำเนินการของ workflow และการกำกับดูแล เมื่อ workflows ที่ซับซ้อนมากขึ้นเติบโตเต็มที่ในแนวตั้ง พวกมันจะทวีคูณเป็นประสบการณ์หลักหนึ่งเดียวที่ลูกค้าพึ่งพา เมื่อโมเดลรุ่นใหม่จัดส่งจากผู้เล่นปัจจุบันและผู้เข้ามาใหม่ บริษัทจะกลายเป็นเลเยอร์ที่บูรณาการและส่งมอบให้กับลูกค้า โมเดลสามารถทดแทนได้ภายใต้; system of work ไม่สามารถ
ซอฟต์แวร์องค์กรรุ่นต่อไปจะถูกสร้างขึ้นนอกถนน
ถ้าคุณกำลังสร้างมัน ติดต่อมาได้ที่: [email protected].
