Coding agents เปลี่ยนโฉมงานวิศวกรรมที่ Stripe ไปโดยสิ้นเชิง แต่คนที่ไม่ใช่วิศวกรอย่าง sales rep, finance analyst, technical account manager และคนอื่นๆ กลับรู้สึกถูกทิ้งไว้ข้างหลังท่ามกลางคลื่น AI อย่าง Claude Code และ Codex ไม่มีเครื่องมือใดที่มีอยู่เดิมที่ตอบโจทย์ข้อกำหนดด้านความปลอดภัยของข้อมูลและเวิร์กโฟลว์เฉพาะที่ Stripe ต้องการได้: การสอบถามข้อมูลจาก data warehouse การหาข้อมูลลูกค้าก่อนการโทรขาย การคัดแยก incident การจำลองสถานการณ์รายได้ หรือการเตรียม compliance review ทุกอย่างเปลี่ยนไปเมื่อเราส่งมอบ knowledge AI agent ของ Stripe
GIF
ภายในสองสัปดาห์หลังเปิดตัวในเดือนเมษายน Stripe ส่วนใหญ่ก็ใช้งาน Knowledge AI Platform ของ Stripe หรือที่รู้จักกันในชื่อ Kai แล้ว วันนี้ 83% เป็นผู้ใช้ที่ใช้งานเป็นประจำทุกสัปดาห์ ครอบคลุมแทบทั้งทีม GTM (การตลาด ฝ่ายขาย customer success manager และ technical account manager) เซสชันของ Kai ส่วนใหญ่ต้องมีการโต้ตอบหลายเทิร์น เพราะผู้ใช้ต้องค้นคว้าเชิงลึก สร้างชิ้นงานเฉพาะ หรือปรับแต่งผลงานก่อนแชร์ทั้งภายในและภายนอกองค์กร ด้วย Kai ทุกคนที่ Stripe ต่างมีเอเจนต์ที่ถูกสร้างมาเพื่อช่วยงานประจำวันของตัวเองโดยเฉพาะ
ทำไมเราถึงสร้าง Knowledge AI Platform
สำหรับงานเขียนโค้ด รายละเอียดการเปลี่ยนแปลงอาจต่างกันไป แต่เวิร์กโฟลว์และเครื่องมือที่ต้องใช้แทบจะคงเดิมเสมอ คุณแก้ไฟล์ รันเทสต์ คอมมิต ภาษาการเขียนโปรแกรมต่างกัน แต่โครงสร้างโดยรวมของงานค่อนข้างเหมือนกัน นี่คือเหตุผลที่สถาปัตยกรรมเอเจนต์เดียวใช้ได้ผลดี งานความรู้ (knowledge work) กลับอยู่คนละขั้วของสเปกตรัมนี้ งานอย่างการหาข้อมูลลูกค้าหรือเตรียม compliance review ต้องใช้เครื่องมือต่างกัน ข้อมูลต่างกัน ผลลัพธ์ต่างกัน และนิยามของคำว่า "เสร็จ" ก็ต่างกัน
ก่อนมี Kai เรามีตัวเลือก AI สำหรับงานความรู้สองแบบ:
- NoCode Agent Builder: ทุกคนสามารถสร้างและ deploy เอเจนต์เฉพาะเวิร์กโฟลว์ที่ใช้เครื่องมือได้ มีเอเจนต์มากกว่า 4,000 ตัวถูกสร้างขึ้นด้วยระบบนี้ อย่างไรก็ตาม เราสังเกตได้อย่างรวดเร็วว่าทีมต่างๆ เขียนพรอมป์ที่มีแนวคิดคล้ายกัน แต่คุณภาพต่างกันมาก และพบว่าการแพร่หลายของไมโครเอเจนต์เหล่านี้ยากต่อการมอนิเตอร์และดูแลรักษามากขึ้นเรื่อยๆ
- Coding agents: Coding agents ทรงพลัง แต่ก็มาพร้อมความเสี่ยงอีกชุดหนึ่ง เนื่องจากเป้าหมายของเราคือการยกระดับโปรดักติวิตี้ของทั้ง Stripe ผู้ใช้บางรายจึงปรับเวิร์กโฟลว์และเลือกใช้ coding agents แต่ไม่นานปัญหาด้านความปลอดภัยก็ผุดขึ้น พร้อมกับภาระซัพพอร์ตใหม่ของทีมคุณภาพโค้ดที่ไม่เคยต้องซัพพอร์ตคนที่ไม่ใช่วิศวกรมาก่อน
จากประสบการณ์เหล่านี้ เราตระหนักว่าการสร้าง knowledge AI platform ต้องทำให้สามสิ่งนี้ถูกต้อง นั่นคือ การขยายความเชี่ยวชาญโดยไม่รวมศูนย์ไว้ที่จุดเดียว การเข้าหาผู้ใช้ในจุดที่พวกเขาทำงานจริง และการบังคับใช้การ์ดป้องกัน (guardrails) ที่ไม่มีอยู่ในโลกของการเขียนโค้ด
ขยายความเชี่ยวชาญโดยไม่รวมศูนย์
ช่วงความเชี่ยวชาญที่ต้องใช้เพื่อรองรับผู้ใช้ของ Stripe นั้นกว้างใหญ่สุดจะประมาณ คนที่รู้วิธีคัดแยก billing escalation หรือจำลองสถานการณ์รายได้ไม่ได้รวมศูนย์อยู่ที่ใดที่หนึ่ง และแน่นอนว่าพวกเขาไม่อยู่ในทีมที่สร้างโครงสร้างพื้นฐานของเอเจนต์ พวกเขากระจายตัวอยู่ตาม domain เฉพาะทางหลายสิบแห่ง เช่น GTM, Finance, Marketing, Legal, Data Science และอื่นๆ อีกมากมาย ซึ่งแต่ละ domain มีเครื่องมือ แหล่งข้อมูล เวิร์กโฟลว์ และเกณฑ์ตัดสินของตัวเองว่าผลงานที่ "ดี" เป็นแบบไหน ลองคูณความซับซ้อนนี้ด้วยผลิตภัณฑ์และประเทศทั้งหมดที่ Stripe ดำเนินงานอยู่ ผลลัพธ์ที่ได้คือความซับซ้อนที่น่าทึ่ง Kai ต้องจำลองความซับซ้อนนั้นในแบบที่มองไม่เห็น เพื่อให้งาน สำเร็จได้เอง
เอเจนต์ต้องออกไปหาผู้ใช้
จุดที่เอเจนต์ปรากฏตัวสำคัญพอๆ กับสิ่งที่มันรู้ ไม่ใช่ทุกคนทำงานในแท็บเบราว์เซอร์ และน้อยคนนักที่จะทำงานในเทอร์มินัล ดังนั้น knowledge agent จึงไม่ใช่แค่ผลิตภัณฑ์เดี่ยวๆ แต่ต้องเป็นแพลตฟอร์มที่มีความยืดหยุ่นพอจะฝังตัวไปได้ทุกที่ที่งานเกิดขึ้น
ตัวอย่างเช่น แอปพลิเคชันภายในที่ทีม Finance ใช้จำลองการเปลี่ยนแปลงที่ซับซ้อนของงบประมาณดำเนินงานของ Stripe เอเจนต์ต้องอ่านบริบท ค้นคว้าเอกสารที่เกี่ยวข้อง เสนอการเปลี่ยนแปลงที่ถูกต้อง และสรุปความแตกต่าง โดยไม่ต้องดึงผู้ใช้ออกจากแอป
การสร้างผลิตภัณฑ์เอเจนต์แบบสแตนด์อโลนใช้ไม่ได้ผล เพราะมันจะบังคับให้ผู้ใช้ออกจากเวิร์กโฟลว์ธรรมชาติของตัวเองแล้วไปใช้แอปใหม่ การสร้างผลิตภัณฑ์เอเจนต์แยกกันสำหรับแต่ละ surface ก็ใช้ไม่ได้เช่นกัน เพราะดูแลรักษายาก และผู้ใช้ที่ใช้หลายเครื่องมือก็จะเจอประสบการณ์ที่ขาดตอน แพลตฟอร์มต้องเข้าหาผู้ใช้ ในจุดที่พวกเขาอยู่
สร้างการ์ดป้องกันขึ้นมาจากศูนย์
Coding agents ทำงานในสภาพแวดล้อมที่มีการ์ดป้องกันที่รวดเร็วและตรวจสอบได้ซึ่งสั่งสมมานานหลายสิบปี คอมไพเลอร์ปฏิเสธไวยากรณ์ที่ไม่ถูกต้อง เทสต์จับ regression ได้ และ git ทำให้ทุกความผิดพลาดย้อนกลับได้ งานความรู้แทบไม่มีกลไกเหล่านี้คอยหนุน
ลองดู invariant หลักของ Stripe ข้อหนึ่ง: "คุณไม่ควรผสมข้อมูลจากบริบทลูกค้าสองรายที่ไม่เกี่ยวข้องกันในการวิเคราะห์ครั้งเดียว" ผู้ใช้อาจมีสิทธิ์เข้าถึงทั้งสองบริบทอย่างถูกต้องตามกฎหมาย แต่ทั้งสองบริบทจะมาอยู่ในเซสชันเดียวกันไม่ได้ ขอบเขตการแยกไม่ใช่ "คนคนนี้เข้าถึงอะไรได้ตาม authorization token?" แต่เป็น "งานนี้ควรถูกอนุญาตให้เห็นอะไรเมื่ออยู่ในบริบทนี้?" แพลตฟอร์มต้องบังคับใช้การ์ดป้องกันโดยนัยที่ผู้ใช้วางใจเหล่านี้
เราสร้าง Kai ขึ้นมาได้อย่างไร
เอเจนต์แบบโมโนลิธตัวเดียวไม่อาจบรรจุข้อจำกัดทั้งหมดนี้ไว้ได้อย่างมีประสิทธิภาพ และการขอให้ทีม domain แต่ละทีมสร้างโครงสร้างพื้นฐานเอเจนต์ที่ปลอดภัย โฮสต์ได้ และมีประสิทธิภาพด้วยตัวเองก็ไม่สามารถขยายขนาดได้เช่นกัน เพื่อจัดการความท้าทายนี้ เราจึงสร้าง Kai ออกเป็นสามชั้น:
- Surface-agnostic APIs ที่เปิดอินเทอร์เฟซหลายแบบเข้าสู่เอเจนต์เดียวกัน
- AgentStudio ที่เจ้าของ domain ใช้สร้างและกำกับดูแล Kai agent ของตัวเอง และ
- Execution environments ที่ส่งมอบความปลอดภัยในไม่กี่วินาทีโดยไม่มีใครต้องคิดถึงโครงสร้างพื้นฐาน
Surface-agnostic APIs
Kai มาพร้อมเว็บแอปพลิเคชันแบบ opinionated และ Slack integration แต่ primitive หลักคือ API ที่ขับเคลื่อนทั้งสองสิ่งอยู่เบื้องหลัง เอเจนต์คือบริการ ไม่ใช่แอปพลิเคชัน และ surface ต่างๆ เป็นเพียงมุมมองที่ปรับแต่งขึ้นมาจากบริการเดียวกัน
ชาว Stripe ส่วนใหญ่โต้ตอบกับ Kai ผ่านเว็บแอปพลิเคชันที่โฮสต์ภายในองค์กร ไม่ต้องตั้งค่าโครงสร้างพื้นฐานใดๆ เพราะพร้อมให้พนักงานทุกคนใช้ตั้งแต่วันแรก (Day 0)
เครื่องมือภายในใดๆ ก็สามารถฝัง Kai ได้ และหลายเครื่องมือก็เลือกที่จะทำเช่นนั้น ตัวอย่างเช่น พนักงานที่ทำงานบนแพลตฟอร์ม business intelligence ของเราสามารถถามคำถาม Kai ได้จากภายในแอปพลิเคชันเดิม เพราะ Chrome extensions ของเรานำความสามารถของ Kai ไปแสดงภายในเครื่องมือ third-party ที่เป็นเว็บ
แอปพลิเคชันที่กำหนดเองฝัง Kai ผ่าน APIs เพื่อนำประสบการณ์ agentic ไปสู่ทุกเวิร์กโฟลว์
AgentStudio
AgentStudio คือ control plane สำหรับเจ้าของ domain ทีมต่างๆ ใช้มันเพื่อสร้าง ทดสอบ และมอนิเตอร์สกิล Kai agent เฉพาะทาง และการเลือกใช้เครื่องมือของตัวเอง ตัวอย่างเช่น ทีม GTM เป็นเจ้าของ Kai agent ที่ปรับแต่งให้เข้ากับเวิร์กโฟลว์ของพวกเขา โดยเอเจนต์นี้โหลดสกิลของทีมเป็นค่าเริ่มต้น เชื่อมต่อกับแหล่งข้อมูลของทีม และแสดงผลลัพธ์ในรูปแบบที่ผู้ใช้คาดหวัง AgentStudio แสดงข้อมูลการใช้งานและสัญญาณคุณภาพคู่กับแต่ละแอสเซ็ต เพื่อให้เจ้าของ domain เห็นว่าอะไรเวิร์กโดยไม่ต้องถามทีมแพลตฟอร์ม
สกิลต่างๆ ถูกจัดระเบียบเป็นหมวดหมู่ตามพื้นที่ต่างๆ ทั่ว Stripe โดยผู้เชี่ยวชาญประจำ domain
Execution environment
นี่คือชั้นที่ทำให้คำสัญญาของแพลตฟอร์มเป็นจริง primitive หลักทั้งหมด ไม่ว่าจะเป็น agent harness, sandbox, การจัดการเวิร์กโฟลว์ และกรอบงานควบคุมการเข้าถึง ถูกตั้งใจแชร์ร่วมกับเอเจนต์ฝั่งผลิตภัณฑ์ของ Stripe งานความรู้ภายในดำเนินการกับข้อมูลอ่อนไหวชุดเดียวกันและให้บริการผู้ใช้กลุ่มเดียวกับผลิตภัณฑ์ภายนอกของเรา ดังนั้นจึงต้องมีมาตรฐานความปลอดภัยและ compliance ในระดับเดียวกัน การแชร์ substrate ร่วมกันเป็นการบังคับวินัยและสร้างฟลายวีล ยิ่งพัฒนาสภาพแวดล้อมการทำงาน (execution environment) มากเท่าไร ทั้งเอเจนต์ภายในและเอเจนต์ผลิตภัณฑ์ก็ได้ประโยชน์พร้อมกัน
agent harness ซึ่งสร้างด้วย deepagents ของ LangChain รันบน Kubernetes พร้อม sandbox ต่อเซสชันที่ปลอดภัย และ virtual filesystem แบบ multi-tenant ภายในเซสชัน เอเจนต์ทำงานกับ virtual filesystem เพื่อสร้างและปรับแต่งชิ้นงานซ้ำๆ ขณะที่ secure code execution sandbox ใช้สำหรับการวิเคราะห์และประมวลผลข้อมูล
มันถูกออกแบบให้เก็บสถานะข้ามเซสชันที่ยาวและซับซ้อน โดยเพิ่งมีเซสชันหนึ่งที่ยาวถึง 932 เทิร์น ด้วยความสามารถการจัดการงานเชิงลึกของ Kai บทสนทนาเดียวสามารถมีหลายร้อยเทิร์น และมีการเรียกใช้เครื่องมือและ LLM หลายร้อยครั้งโดยไม่หมดเวลา (timeout) หรือทำให้ context window ล้น ซึ่งสำคัญเพราะงานความรู้แทบไม่เคยเป็นคำถามเดียว แต่คือการคิดแบบวนซ้ำที่ต่อยอดจากตัวเอง และเซสชันต้องเก็บสถานะนั้นไว้โดยไม่เสื่อมคุณภาพ
พฤติกรรมผู้ใช้กำลังเปลี่ยนไป และเซสชันถูกใช้สำหรับการทำงานร่วมกันหลายเทิร์นเชิงลึกมากขึ้นเรื่อยๆ
ส่วนที่น่าสนใจที่สุดอย่างหนึ่งของ harness คือวิธีการเลือกสกิลที่ถูกต้องมาใช้ Kai เชื่อมต่อกับสกิลและเครื่องมือมากกว่า 1,000 รายการครอบคลุมระบบภายในต่างๆ ตั้งแต่แดชบอร์ด business intelligence ที่ติดตามตัวชี้วัดสำคัญ ไปจนถึงเครื่องมือจัดการโปรเจกต์ที่ใช้จัดระเบียบการทำงานภายใน และบริการ third-party อย่าง Zoom และ Google Workspace ทุกคนสามารถถามคำถามมันได้และวางใจได้ว่ามันจะโหลดบริบทที่ถูกต้องและใช้เครื่องมือที่เหมาะสมเพื่อให้งานลุล่วง Coding agents มีข้อได้เปรียบโดยธรรมชาติตรงนี้ เพราะโฟลเดอร์ที่พวกเขาทำงานให้การจัดระเบียบสกิลและบริบทตามธรรมชาติ ในโพสต์ถัดไป เราจะลงรายละเอียดว่าเราแก้ปัญหานี้โดยไม่มีโครงสร้างเดิมเหล่านั้นได้อย่างไร ด้วยแนวทางไฮบริดระหว่าง RAG และ LLM รวมถึงเทคนิคอื่นๆ
ผลกระทบ
ผลลัพธ์ที่ได้น่าทึ่งมาก พนักงานใหม่ในทีม GTM เป็นคนยุค Kai โดยกำเนิด (Kai-native) ใช้มันมากกว่า 2.7 เท่า และ power user ปิดมูลค่าได้มากกว่าผู้ใช้งานน้อย (low user) ถึง 80% ภายใน cohort เดียวกัน เมื่อ Account Executive ใช้ Kai พวกเขาสร้างกิจกรรมการขายได้ 2 เท่า สร้างโอกาส (opportunity) ได้เพิ่มขึ้น 17% สร้างโอกาสทางรายได้เพิ่มขึ้น 26% และปิดดีลได้เพิ่มขึ้น 39% เมื่อเทียบกับเซลส์คนเดียวกันในสัปดาห์ที่ไม่ได้ใช้ โดยรวมแล้ว Kai ช่วยเปลี่ยนเวลากว่า 25,000 ชั่วโมงต่อปีจากงานธุรการไปเป็นงานที่สร้างรายได้
ในฝ่ายการเงินและปฏิบัติการ Kai ช่วยชาว Stripe วิเคราะห์ข้อมูลที่ยุ่งเหยิง สร้าง digests ประจำ และเปลี่ยนบริบทที่กระจัดกระจายให้เป็นชิ้นงานที่ใช้งานได้
ในฝ่ายวิศวกรรม Kai กลายเป็นจุดแรกๆ ที่ชาว Stripe จะนึกถึงเมื่อต้องการถามคำถามเกี่ยวกับระบบ ค้นคว้าข้อมูลสำหรับ run request วิเคราะห์ log ร่างแผน และเรียกใช้เอเจนต์และสกิลเฉพาะทางมากขึ้น
และทั่วทั้ง Stripe มีเซสชันมากกว่า 5,000 เซสชันต่อวันที่เกี่ยวข้องกับการวิเคราะห์ข้อมูล ทำให้ Kai เป็นจุดงัด (leverage point) ที่ไม่เหมือนใคร เพราะเมื่อเราต่อบริบทที่ถูกต้องเกี่ยวกับคุณภาพข้อมูลและเลเยอร์ analytics ของเราเข้าไป เราก็มั่นใจได้ว่าคำตอบส่วนใหญ่จะถูกต้องโดยค่าเริ่มต้น
ฟีดแบ็กตรงจากชาว Stripe ยืนยันตัวเลขเหล่านี้ พวกเขารู้สึก “มีพลังที่จะโอบรับ AI” และ “ทึ่งที่ Kai ทำสิ่งที่ถูกต้องแม่นยำได้ขนาดนี้” แต่เรื่องเล่าที่เราชอบที่สุดคือคนที่ไม่ใช่วิศวกรคนหนึ่งที่ออกจากเซสชันแนะนำ Kai แล้วร่วมสร้าง digest ที่ดึงข้อมูลจาก Asana, Slack และ Jira มารวมไว้ในกระบวนการอัตโนมัติเดียวได้ในทันที
เรายังไม่ได้ชนะ
ที่ Stripe วลีเด็ดที่เราชอบที่สุดคือ “เรายังไม่ได้ชนะ” และมันก็เหมาะกับ Kai มาก เราอยู่ในช่วงแรกสุดของการเดินทางนี้ และยังมีอะไรอีกมากที่เราอยากทำ:
- การจัดการสถานะที่ดีขึ้น: เอเจนต์เอนกประสงค์อย่าง Kai สร้างสถานะจำนวนมากระหว่างที่เรียกใช้เครื่องมือแบบวนซ้ำ ดึงเอกสารขนาดใหญ่ลงมา และอื่นๆ เราปรับแต่งทั้งบริบท “active” ที่ส่งให้ LLM และบริบท “extended” ที่เก็บอยู่ใน state store อย่าง S3 หรือ virtual file system อย่างต่อเนื่อง
- การสะท้อนคิดและพัฒนาตัวเอง: เรากำลังทำงานบนวงจรปรับปรุงคุณภาพที่ให้ Kai สะท้อนคิดเกี่ยวกับ traces ที่เกี่ยวข้องกับสกิล เสนอการปรับปรุง ทดสอบ และส่งการเปลี่ยนแปลงให้เจ้าของสกิลตรวจสอบ
- การปรับปรุง primitive สำหรับการทำงานร่วมกัน: ผู้ใช้สร้างบริบทจำนวนมากในเซสชัน Kai ของตัวเองซึ่งตอนนี้ถูก “ขังไว้” แต่นั่นไม่ใช่วิธีที่งานสำเร็จ เราอยากให้ผู้คนแชร์สิ่งที่ Kai แสดงผลข้ามเซสชัน และให้หลายคน (รวมถึงเอเจนต์!) ร่วมมือกันทำงานบนชิ้นงานเดียวกัน
Coding agents ทำให้ AI รู้สึกเป็นรูปธรรมสำหรับวิศวกรซอฟต์แวร์ก่อนใคร Kai ช่วยนำความรู้สึกของการมีพลังแบบเดียวกันมาสู่คนทำงานความรู้ทั่วทั้ง Stripe มันน่าสนใจเพราะแม้เราจะพัฒนาประสิทธิภาพขึ้นอย่างมาก แต่เรายังไม่รู้เพดานของมัน และเราตื่นเต้นที่จะผลักดันขอบเขตนี้ต่อไป ถ้าการสร้างระบบ agentic ที่ขับเคลื่อนประสิทธิภาพภายในองค์กรและเอเจนต์ภายนอกฟังดูเป็นความท้าทายที่ใช่สำหรับคุณ เรากำลังรับสมัครพนักงาน
