วิธีหลีกเลี่ยงความตายบนถนนอิฐสีเหลือง - เลเยอร์แอปยังไม่ตาย

• แม้ในหมู่ผู้ก่อตั้งจะมีความกังวลเพิ่มขึ้นว่าเลเยอร์แอป AI จะถูก แล็บขนาดใหญ่ อย่าง OpenAI และ Anthropic กลืนกิน แต่เลเยอร์แอปไม่ได้เป็นโอกาสแบบเดียว หากมีโครงสร้างที่แบ่งออกเป็น "ถนนอิฐสีเหลือง (Yellow Brick Road)" และ "พื้นที่ส่วนที่เหลือของออซ (Rest of Oz)"
• ถนนอิฐสีเหลืองคือพื้นที่แนวนอน เช่น การสร้างโค้ด การเขียน และการสร้างภาพ ที่คุณภาพดีขึ้นได้ด้วยเพียง การพัฒนาสมรรถนะของโมเดลเอง และเป็นเส้นทางที่แล็บทุ่มทรัพยากรมหาศาล
• พื้นที่ส่วนที่เหลือของออซคือพื้นที่ที่ scaffolding บนตัวโมเดลเป็นตัวกำหนดความน่าเชื่อถือและคอมพลายแอนซ์ เช่น เวิร์กโฟลว์แบบ แนวตั้ง หลายขั้นตอน และหลายการอนุมัติ ซึ่งเป็นโอกาสที่สตาร์ตอัพจะเป็นเจ้าของลูกค้าได้
• การที่ OpenAI และ Anthropic ประกาศ บริษัทร่วมทุน forward-deployed ขนาดใหญ่ สำหรับการปรับแต่งระดับองค์กรเอง ก็ชี้ว่าการมี AI coworker แบบทั่วไปเพียงอย่างเดียวไม่อาจแก้ทุกปัญหาได้
• ซอฟต์แวร์องค์กรยุคถัดไปจะถูกสร้างขึ้น "นอกถนน (off the road)" และแนวป้องกันสำคัญคือ แม้โมเดลจะเปลี่ยนทดแทนกันได้ แต่ system of work นั้นไม่ใช่

---

คำถามหลักและสมมติฐานตั้งต้น

• คำถามที่ผู้เขียนได้รับซ้ำๆ จากผู้ก่อตั้งและผู้สมัครงานคือ "OpenAI กับ Anthropic จะฆ่าทุกอย่างหรือไม่ และยังเหลืออะไรให้สร้างในเลเยอร์แอป AI อีกไหม"
• บางคนสรุปว่าที่เดียวที่พอหลีกเลี่ยงการกลายเป็นชนชั้นล่างถาวรได้ คือ ภายในแล็บขนาดใหญ่ หรือไม่ก็แนวหน้าอย่าง หุ่นยนต์และฮาร์ดเทค
• ผู้เขียนในฐานะ AI maximalist มองว่าพวกเขา "ถูกอยู่ครึ่งหนึ่ง" เพราะเป็นความจริงที่แล็บจะดูดซับพื้นผิวของแอปไปไม่น้อย
• แต่ประเด็นสำคัญคือเลเยอร์แอปไม่ใช่โอกาสแบบเดียว — กรอบคิดที่ถูกต้องคือ คุณอยู่บนถนนอิฐสีเหลือง หรืออยู่ที่อื่นในออซ

The Yellow Brick Road — ถนนที่แล็บกำลังเดิน

• รูปแบบการทำงานคือเอา คอนเน็กเตอร์สำเร็จรูป อย่าง G Drive, Slack, Salesforce, Notion, GitHub มาเสียบเข้ากับโมเดลสมรรถนะสูง แล้ววางเลเยอร์ orchestration ของเอเจนต์ทับลงไป
• เหตุผลที่รูปแบบนี้อันตรายคือแล็บกำลังทำสิ่งเดียวกันนี้อยู่แล้วผ่าน Cowork และ Codex
  • เป็นเจ้าของโมเดล → มาร์จินดีกว่า ควบคุมได้มากกว่า และมี อำนาจตั้งราคา ต่อปลายน้ำ
  • มี อิสระในการเลือกสถาปัตยกรรม เพื่อทำให้ผลิตภัณฑ์ออกมาดี — จนถึงตอนนี้ตั้งใจเลือกแพตเทิร์น "model + tool calls" ซึ่งเหมาะตรงตัวกับ งานแนวนอนระดับล่างบนถนน
• ต่อให้สตาร์ตอัพจะเหนือกว่า Codex หรือ Claude Code ในด้านประสิทธิภาพ แล็บก็ยังมี เครือข่ายการจัดจำหน่าย ขนาดมหึมา และ ออร่าของแบรนด์ ที่ใหญ่ที่สุดในวงการ AI
• บริษัทแอป AI ที่เดินตามเพลย์บุ๊กนี้ด้วยชุดคอนเน็กเตอร์แบบเดียวกัน ไม่มีซับเอเจนต์ ไม่มีการจัดองค์ประกอบ และไม่มีการจัดจำหน่าย ก็คือการเดินบน "ถนนที่พาไปไม่ถึงไหน"

The Rest of Oz — โอกาสของสตาร์ตอัพ

• คือพื้นที่ที่สร้างประสบการณ์เอเจนต์โดยร้อยเรียงโมเดลผ่าน เครือข่ายที่ซับซ้อนของเครื่องมือ อัตโนมัติ และการเชื่อมต่อระบบ ซึ่งโดยธรรมชาติมักลงเอยเป็น แนวตั้ง
• สามารถโฟกัสงาน หลายขั้นตอน หลายผู้มีส่วนร่วม ที่แพลตฟอร์มแนวนอนไปไม่ถึง
  • รวบรวมคอนเท็กซ์จากทั่วทั้งระบบ แล้วส่งต่อไปยัง คนจำนวนมากที่ต้องอนุมัติเป็นลำดับขั้น
  • เชื่อมกับ ระบบ legacy อย่างน้อยหนึ่งระบบ ต้องการ ผลลัพธ์แบบกำหนดได้แน่นอน และไม่ยอมรับความกำกวม
  • มักเชื่อมโยงกับ ผลลัพธ์ทางธุรกิจที่มีมูลค่า
• แล็บเองก็รับรู้ถึงคุณค่าของปัญหานี้ จึงถึงขั้นทำ องค์กรรับจ้างตั้งค่าระบบ (outsourced configuration shops) เอง และนี่คือเหตุผลที่มี ชั้นลูกค้าระดับบนของธุรกิจ reinforcement learning

ทำไมพื้นที่ส่วนที่เหลือของออซจะไม่ถูกพ่อมดกลืนกิน

• Data and learning flywheels (วงล้อข้อมูลและการเรียนรู้)

  • บรรทัดฐานอุตสาหกรรมโดยนัย ที่ไม่อยู่ในชุดฝึก มาตรฐานที่ไม่ได้เขียนไว้ และ องค์ความรู้ฝังองค์กร (tribal knowledge) ในหัวคนทำงานจริงนั้น ไม่มีอยู่บนเว็บสาธารณะ
  • มีวงล้อสองชุดที่ทำงานทับซ้อนกัน
    • across-customer: แพตเทิร์นที่สะสมจากการเห็นรูปแบบย่อยของปัญหาเดียวกันในลูกค้าหลายราย
    • within-customer: เหตุผลของการตัดสินใจเฉพาะ ข้อยกเว้นโดยนัย และกฎประสบการณ์เฉพาะของบริษัทนั้น
  • บริษัทที่ผ่านการทำ legal redline 100 ครั้ง, insurance underwriting 1,000 ครั้ง, และ SDR campaign 10,000 ครั้ง จะซึมซับ รูปร่างของปัญหา ที่ผู้เล่นใหม่ไม่อาจลอกเลียนได้ด้วยเอเจนต์ที่เพิ่งเปิดตัว
  • เหตุผลสำคัญที่เอเจนต์แนวนอนไม่อาจสร้างโครงสร้างการเรียนรู้แบบเดียวกันได้คือ UX — มีแต่ผู้เล่นแนวตั้งเท่านั้นที่ออกแบบพื้นผิวเวิร์กโฟลว์ได้อย่างแม่นยำ
  • ชุด eval, เอาต์พุตที่ติดป้ายกำกับ, และอนุกรมวิธานของ edge case จะสะสมเป็น วงล้อข้อมูลเฉพาะแนวตั้ง และกลายเป็นเชื้อเพลิงสำหรับการ fine-tune

• Managing model variability and complexity (การจัดการความหลากหลายและความซับซ้อนของโมเดล)

  • แล็บมีการทำ model routing และ ensemble ภายในตามประเภทคำขออยู่แล้ว แต่ไม่สามารถทำ การส่งต่อข้ามผู้ขาย, การประเมินโมเดลของคู่แข่ง หรือการใช้ โมเดลโอเพนซอร์สที่ fine-tune แล้ว ในโดเมนแคบๆ ได้
  • บริษัทใน Rest of Oz สามารถเลือกโมเดลที่เหมาะที่สุดสำหรับแต่ละซับแทสก์จาก ทั้งตลาดโมเดล ไม่ใช่แค่ของที่แล็บแม่ปล่อยออกมา
  • ทุกครั้งที่อัปเกรดก็รับงาน "ไม่มีใครอยากทำ" ไว้เอง เช่น รัน eval ใหม่, ปรับเทียบพรอมป์ต์ให้เข้ากับ edge case ของลูกค้า, และค่อยๆ ปล่อยใช้งานโดยไม่ทำให้โปรดักชันพัง
  • แล็บเพียงขายโมเดลตัวถัดไปแล้วบอกให้ "ย้ายระบบ" แต่บริษัท Rest of Oz จะ รับภาระการย้ายระบบแทน เพื่อมอบทั้งความฉลาดที่ดีที่สุดในตลาดและความต่อเนื่องของการอัปเกรดให้ลูกค้า

• Cost optimization (การเพิ่มประสิทธิภาพต้นทุน)

  • การรันทุกคิวรีด้วย Opus 4.7 คือทางลัดที่สุดสู่กำไรขั้นต้นติดลบ
  • บริษัท Rest of Oz ที่เก่งที่สุดจะทำ การส่งต่อโมเดลตามระดับชั้น
    • งานที่ยากที่สุดใช้โมเดล frontier
    • งานส่วนใหญ่ใช้ mid-tier
    • ส่วนที่มีคุณสมบัติเหมาะสมใช้ โมเดลขนาดเล็กแบบคัสตอมและ fine-tune
  • บางบริษัททำ post-training ของตัวเองบนชั้นนี้อีกที เพื่อปรับให้เหมาะกับส่วนแคบๆ ที่ลูกค้าสนใจ และให้บริการได้ด้วยต้นทุนเพียงบางส่วนของ frontier API
  • หากแล็บตั้ง ราคาพื้น ว่าเป็น "ความฉลาดขั้นต่ำที่ X ดอลลาร์" บริษัท Rest of Oz ก็ขายสิ่งตรงข้าม คือ ต้นทุนต่อดอลลาร์ต่ำที่สุด สำหรับระดับความฉลาดที่เวิร์กโฟลว์นั้นต้องการจริง

• Governance (การกำกับดูแล)

  • การเป็น control plane ของวิธีที่ลูกค้ารัน AI ในแนวตั้งนั้นมีคุณค่ามาก — สิทธิ์การเข้าถึง การตรวจสอบ สิ่งที่เอเจนต์ทำได้ และสิ่งที่มันทำจริง ล้วนมารวมกันที่นี่
  • control plane ประกอบด้วย guardrail ตาม use case ที่แตกต่างกันโดยสิ้นเชิงตามอุตสาหกรรมและหน้าที่งาน
  • เพราะเป็นเจ้าของเครื่องมือ เวิร์กโฟลว์ และข้อมูลแบบ end-to-end จึงสามารถให้ ผลลัพธ์แบบกำหนดได้แน่นอน ที่เครื่องมือแนวนอนทำได้ยาก
  • เป็นผู้รับภาระความซับซ้อนด้านกฎระเบียบแทนผู้ซื้อปลายทาง
    • กฎหมาย: FRCP และข้อบังคับจริยธรรมทนายความ
    • การแพทย์: HIPAA
    • การเงิน: SEC และ FINRA
    • ประกันภัย: กฎกำกับประกันภัยระดับรัฐ เป็นต้น
  • CIO ต้องการพาร์ตเนอร์ที่ รับผิดชอบตามสัญญา ต่อคอมพลายแอนซ์ของเอเจนต์ที่ตนนำมาใช้

• ข้อสรุปร่วม: โฟกัส

  • ไม่ว่าจะเป็นแนวตั้งอย่างประกันภัย กฎหมาย บัญชี หรือฟังก์ชันที่ทำอย่างลึกอย่างการขาย ฝ่ายสนับสนุนลูกค้า หรือการเงิน ก็ต้องการทีมที่อุทิศให้กับเวิร์กโฟลว์ edge case และกฎระเบียบของกลุ่มลูกค้าชุดเดียว
  • แล็บทำแบบนี้ไม่ได้ เพราะโครงสร้างของมันต้องอยู่ได้ทุกที่เพื่อทุกคน — เลือกได้ว่าจะ "อยู่ทุกที่" หรือ "เก่งเรื่องเดียว"

กรณีศึกษา Sales — เคล็ดลับภาคสนามจาก Prabhav Jain ซีอีโอของ 11x

• Focus on outcomes (โฟกัสที่ผลลัพธ์)

  • เส้นทางเชิงยุทธวิธีในการสร้างบริษัทที่ทนต่อแรงกดดันจากแล็บได้ คือเริ่มจาก ผลลัพธ์เฉพาะ ที่ลูกค้าแคร์จริง — สำหรับ 11x คือ การสร้าง pipeline
  • แยกแต่ละกิจกรรมออกเป็นแทสก์ → แยกว่าส่วนไหนเป็น agentic และไม่เป็น agentic ส่วนไหนต้องอาศัย insight เชิงโดเมนอย่างละเอียดและส่วนไหนไม่ต้อง
  • ในเวิร์กโฟลว์ที่มีหลายขั้นตอน อินพุตสกปรก สถานะตีความยาก และข้อจำกัดจากโลกจริง โมเดลที่ดีกว่าอย่างเดียวไม่พอ ต้องใช้ วิศวกรรมซอฟต์แวร์แบบดั้งเดิม และในพื้นผิวนี้แล็บไม่ได้เหนือกว่า
  • ตัวอย่างแทสก์ที่ 11x จัดการ
    • การหา lead prospecting จากสัญญาณคัสตอม, lead enrichment, deep account research
    • ตัวดึงคอนเท็กซ์จาก CRM, ตัวเขียนข้อความตามช่องทาง, เอเจนต์ตรวจสอบคุณสมบัติ lead, ระบบ email deliverability
  • งานของบริษัทแอปคือการฉีดความรู้โดเมนที่ไม่มีในข้อมูลฝึกทั่วไปเข้าไปในโมเดล ณ จุดที่เหมาะสมของเวิร์กโฟลว์ และสิ่งนี้ สะสมได้
  • ทักษะจะล้าสมัยอยู่เสมอตามวิวัฒนาการของธุรกิจ ดังนั้นความสามารถในการทำให้เวิร์กโฟลว์และคอนเท็กซ์วิวัฒน์ตามได้จึงเป็นข้อได้เปรียบในการแข่งขัน
    • เช่น ตั้งแต่ช่วงที่อีเมลเขียนโดย AI เริ่มแพร่หลาย เซนส์ของผู้ใช้ก็เปลี่ยนทุกไม่กี่เดือน เอเจนต์จึงต้องปรับตัวต่อเนื่องตามพลวัตของตลาด
    • ในช่วงไม่กี่เดือนที่ผ่านมา positive reply rate เพิ่มขึ้น 4 เท่า และสร้าง pipeline มูลค่าหลายร้อยล้านดอลลาร์ให้ลูกค้า

• Work on problems where complexity is high (ทำงานกับปัญหาที่ซับซ้อนสูง)

  • มูลค่าทางธุรกิจที่แท้จริงจะถูกปลดล็อกในปัญหาที่ซับซ้อน ไม่เช่นนั้นก็จะกลายเป็นเพียง thin wrapper
  • ตัวอย่าง GTM: กฎง่ายๆ อย่าง "ห้ามติดต่อคอนแท็กต์ของบริษัทที่เป็นลูกค้าอยู่แล้ว" แท้จริงซับซ้อนมาก
    • อาจมีการแมปโดเมนใน CRM, บริษัทที่มีบริษัทย่อยหลายสิบแห่ง, กรณีที่บันทึกไว้แค่โดเมนของบริษัทแม่, และฟิลด์ matching ใน Salesforce ที่ล้าสมัยจนเผลอ ส่ง cold pitch ไปหา CRO ของลูกค้าปัจจุบัน
  • ข้อมูลโลกจริงนั้นสกปรก และทั้งคนทั้งโมเดลก็แก้ให้หายวิเศษๆ ไม่ได้ — ต้องมี เอเจนต์เฉพาะวัตถุประสงค์ ที่ถูกวิศวกรรมให้เข้ากับรูปร่างเฉพาะของปัญหา
  • จากข้อมูลของ 11x คุณภาพและความสดใหม่ของข้อมูลบริษัทตนเองสูงกว่าของลูกค้า จึงยึด ข้อมูลของตนเองเป็นหลัก โดยปริยาย

• Guardrails — ไม่ใช่แค่กันเรื่องแย่ๆ แต่คือแก่นที่ลูกค้ายอมจ่ายเงิน

  • guardrail ถูกประเมินค่าต่ำเกินไปอย่างมาก และแม้อยู่ในผลิตภัณฑ์เดียวกันก็ยังต้องแยกตาม use case
  • สิ่งรับประกันที่ลูกค้าเป้าหมายในบริการการเงินที่ถูกกำกับดูแลต้องการ ย่อมไม่เหมือนลูกค้า mid-market SaaS และความต่างนี้ไหลลงไปถึงวิธีที่เอเจนต์เขียน วิธีเลือกคนที่จะติดต่อ ข้อมูลที่เข้าถึง สิ่งที่พูดในการโทร และวิธีบันทึกการตัดสินใจ
  • ระบบแบบ one-size-fits-all จะพังทลาย จำเป็นต้องมีการออกแบบตาม use case การตั้งค่าตามลูกค้า และการตรวจสอบอย่างต่อเนื่อง
  • เพื่อสิ่งนี้ จึงมีการใช้ FDE (Forward Deployed Engineer) และนักกลยุทธ์การติดตั้งเทคโนโลยีที่ปรับแต่งให้ตรงความต้องการลูกค้า
  • กรณีขององค์กร F1000
    • ทำ outbound voice แบบอิงความยินยอมกับลูกค้า SMB จำนวนมาก
    • ในรอบแรกๆ อัตรารับสายต่ำ → จึงเรียนรู้อย่างรวดเร็วว่าจะดึงความสนใจเจ้าของธุรกิจ SMB ภายใน 10 วินาทีแรกของสายอย่างไร
    • เจ้าของธุรกิจ SMB มีพฤติกรรมต่างจากผู้ซื้อ B2B รายใหญ่หรือผู้บริโภค และตอนนี้ระบบสามารถสร้าง โอกาสทางการขายได้มากกว่าใน 1 วัน เมื่อเทียบกับทีมขายของลูกค้าตลอด 1 เดือนสำหรับเซ็กเมนต์นี้

กรณีศึกษา Insurance — Aman Gour ซีอีโอของ FurtherAI

• สมมติฐานที่ได้พบซ้ำๆ ระหว่างนำ AI ไปใช้ในงานประกันภัยจริง — ว่า "โมเดลคือความฉลาด และเวิร์กโฟลว์เป็นเพียง scaffolding" — ยิ่งทำงานกับบริษัทประกันมากเท่าไร ก็ยิ่งมั่นใจว่าเป็น ตรงกันข้าม
• ในประกันภัย ความฉลาดส่วนใหญ่อยู่ ในตัวเวิร์กโฟลว์เอง
  • แม้บริษัทประกันสองแห่งจะใช้เส้นทางเดียวกัน (submission → review → quote → bind) ความแตกต่างก็อยู่ในทุกสิ่งภายในนั้น
    • ความเสี่ยงแบบใดจะถูก escalation
    • สัญญาณความเสียหายแบบใดสำคัญ
    • เมื่อกฎ appetite ขัดกัน ข้อใดเป็นฝ่ายชนะ
    • จุดไหนที่มนุษย์ต้องอนุมัติ ต้องเรียกข้อมูลภายนอกเมื่อไร และจะบันทึกการตัดสินใจสุดท้ายอย่างไร
  • ลอจิกนี้ไม่ได้อยู่ในกฎเอนจินสะอาดๆ จุดเดียว แต่กระจายอยู่ใน SOP, การรีวิวของผู้จัดการ, ปรัชญาการรับประกันภัย, appetite เฉพาะของแต่ละบริษัทประกัน, และประสบการณ์ปฏิบัติงานหลายปี ซึ่งจำนวนมากไม่ได้ถูกเอกสารให้อยู่ในรูปที่โมเดลอ่านได้
• ข้อสรุปที่ได้ทุกครั้งจึงไม่ใช่ทั้ง pure agent ที่ต้องอนุมานใหม่จากศูนย์ทุกครั้ง และไม่ใช่ เวิร์กโฟลว์แข็งทื่อ ที่พังเมื่อโลกจริงเริ่มยุ่งเหยิง แต่คือ agentic workflows
  • เวิร์กโฟลว์ → ความทำซ้ำได้ ความสามารถในการตรวจสอบ และการควบคุมต้นทุน
  • เอเจนต์ → รับมือความผันผวน และกู้สถานการณ์เมื่อ happy path พัง
  • human-in-the-loop → สำหรับการตัดสินใจที่ความรับผิดชอบมีความสำคัญ
• ใน Day 1 คือการทำงานด้วยมือให้เป็นอัตโนมัติ แต่เมื่อเวลาผ่านไป ทุก escalation จะกลายเป็นสัญญาณ ทุกข้อยกเว้นเป็น feedback และทุกการแก้ไขของมนุษย์คือสัญญาณบอกจุดที่ runbook ยังขาด ทำให้เวิร์กโฟลว์ค่อยๆ วิวัฒน์เป็น operating memory ของบริษัทประกัน
• แล็บจะยังปล่อยทั้งโมเดลที่ดีขึ้นและเอเจนต์ทั่วไปที่ดีขึ้นต่อไป แต่เรื่องว่าบัญชีไหนถูก escalation ความเสี่ยงใดถูกปฏิเสธ และทำไม underwriter ถึงกลับคำแนะนำ appetite แล้วถูกต้องนั้น จะเรียนรู้ไม่ได้เลยหากไม่ได้อยู่ในโปรดักชันของบริษัทประกันนานพอ
• "สิ่งที่เป็นคูเมืองป้องกันไม่ใช่เวิร์กโฟลว์ที่เปิดตัวใน Day 1 แต่เป็น ลูป ที่การใช้งานจริงในโปรดักชันสร้างขึ้นเมื่อเวลาผ่านไป"

3 บททดสอบเพื่อดูว่าคุณอยู่ใน Rest of Oz หรือไม่

• The tools-and-steps test (บททดสอบเครื่องมือและขั้นตอน)

  • งานนั้นมีทั้งหมดกี่ขั้นตอน และมีความซับซ้อนของเครื่องมือสนับสนุนมากแค่ไหน
  • เปรียบเทียบ
    • การค้นหา AI แนวนอน (ค้นข้าม Google Drive): 1 ขั้นตอน 1 เครื่องมือ ผลลัพธ์ยืดหยุ่น — ถ้าผิดก็ถามใหม่
    • legal redline (เทียบกับบรรทัดฐานของสำนักงานกฎหมายย้อนหลัง 3 ปี): หลายสิบขั้นตอน หลายเครื่องมือ และเอาต์พุตต้องผ่านการตรวจของพาร์ตเนอร์ แถมอาจถูกโต้แย้งในศาลได้
  • ทั้งสองอย่างดูเหมือน "เอเจนต์กำลังทำงาน" เหมือนกัน แต่มีเพียงฝั่งเดียวที่ต้องการ ซอฟต์แวร์ลึกๆ ที่ทีมโฟกัสสร้างกันหลายปี

• The system test (บททดสอบระบบ)

  • คุณกำลังสร้าง ระบบที่ลูกค้าใช้ให้งานไหลผ่าน หรือเป็นเพียงเครื่องมือที่วางอยู่บนระบบเดิม
  • ระบบจะเป็นเจ้าของการเก็บข้อมูล การกำกับดูแล และบันทึกการปฏิบัติงานแบบ end-to-end และเป็นสิ่งที่ลูกค้าชี้ว่าเป็น "ที่ที่งานจริงเกิดขึ้น"
  • เครื่องมือเพียงเติมความฉลาดให้เวิร์กโฟลว์ที่ลูกค้ารันอยู่แล้ว ซึ่งแม้ทำรายได้ได้ แต่ก็เป็นพื้นที่ที่ แล็บเอาไปได้
  • High ACV มักเป็นสัญญาณของการเป็นระบบ แต่ไม่ใช่หลักประกัน — เกณฑ์วัดจริงคือ หากแล็บออกผลิตภัณฑ์คู่แข่งเอง ลูกค้ายังต้องการเครื่องมือของคุณอยู่หรือไม่

• The hedge fund / P&L test (บททดสอบเฮดจ์ฟันด์ / P&L)

  • ผลงานของแล็บวัดด้วย benchmark ส่วนผลงานของ Rest of Oz วัดด้วย P&L ของลูกค้า
  • ลูกค้าไม่สนใจคะแนน SWE-Bench หรือ MMLU — เขาสนใจว่าเอเจนต์ปิดดีลได้หรือไม่ redline สัญญาได้ถูกต้องหรือไม่ และ bind policy ได้เหมาะสมหรือไม่
  • ลูกค้าที่หมกมุ่นกับผลลัพธ์เฉพาะเวิร์กโฟลว์ → Rest of Oz ส่วนลูกค้าที่จ่ายเงินเพื่อความสามารถทั่วไป → ใช้ที่นั่ง Claude หรือ Codex ก็พอ
  • ธุรกิจเอเจนต์ที่ดีที่สุดควรแข่งขันด้วยอัลฟ่าที่วัดจาก P&L ของลูกค้า เหมือนเฮดจ์ฟันด์

ทั้งสองฝั่งชนะได้

• จะมีผู้ชนะมหาศาลเกิดขึ้นบนถนนอิฐสีเหลืองด้วยเช่นกัน — แล็บเป็นเจ้าของโมเดล และยังเป็นเจ้าของการจัดจำหน่ายของเครื่องมือแนวนอนที่ตนออกแบบเอง
• เงื่อนไขแห่งชัยชนะของ Rest of Oz คือการเป็นเจ้าของ system of work — พื้นผิวที่งานจริงของบริษัทถูกดำเนินการและมีการเก็บข้อมูล
  • เป็นเจ้าของการเก็บข้อมูล ระบบแอ็กชันของเวิร์กโฟลว์ และการกำกับดูแล
  • ยิ่งเวิร์กโฟลว์ที่ซับซ้อนในแนวตั้งเติบโตเต็มที่มากเท่าไร ก็ยิ่งควบแน่นเป็น ประสบการณ์หลักหนึ่งเดียว ที่ลูกค้าพึ่งพา
  • เมื่อโมเดลรุ่นใหม่และรุ่นเก่าถูกปล่อยออกมา บริษัทจะกลายเป็นเลเยอร์ที่รวมและส่งมอบสิ่งเหล่านั้น
  • โมเดลด้านล่างนั้น ทดแทนกันได้ (fungible) แต่ system of work ไม่ใช่
• ซอฟต์แวร์องค์กรยุคถัดไปจะถูกสร้างขึ้น "นอกถนน"