Agentic Company OS สำหรับทุกทีม ไม่ใช่แค่ทีม engineering

ซอฟต์แวร์องค์กรส่วนใหญ่ถูกซื้อเป็น seat — หนึ่ง licence ต่อหนึ่งคน หนึ่ง instance ที่ใช้ร่วมกันทั้งบริษัท และ backlog ของ internal tool ที่ไม่เคยสั้นลง Enterprise Agentic Company OS พลิกโมเดลนั้น ซอฟต์แวร์ถูกสร้างขึ้นตอนที่มีคนขอ รันแบบส่วนตัวให้คนที่ขอ และถูกทิ้งเมื่องานจบ ขณะที่ระบบซึ่งมันไปแตะยังอยู่ภายใต้การควบคุมจากส่วนกลางอย่างเข้มงวด

อะไรเปลี่ยนไป เมื่อซอฟต์แวร์ภายในกลายเป็นของใช้แล้วทิ้ง?

อุปสรรคของ internal tool มาจากเรื่องความคุ้มค่ามาตลอด นักวิเคราะห์การเงินที่อยากได้หน้าจอ reconciliation ใช้ครั้งเดียว จะไม่มีทางได้คิวก่อนงานที่ผูกกับรายได้ สุดท้ายงานนั้นก็อยู่บน spreadsheet ต่อไปอีกสามปี แต่เมื่อ agent สร้างแอปที่ต่อกับข้อมูลจริงได้ในไม่กี่นาที สมการก็เปลี่ยน — แอปแค่ต้องคุ้มกับสิบนาทีที่ใช้อธิบายเท่านั้น ส่วนใหญ่ถูกใช้อาทิตย์เดียวแล้วลบทิ้ง มีไม่กี่ตัวที่กลายเป็นของสำคัญ และตัวเหล่านั้นจะถูกยกขึ้นเป็น Blueprint ให้คนทั้งองค์กรหยิบไปใช้ต่อ

Agent-Built Internal Apps กับโมเดลหนึ่ง instance ต่อหนึ่งคน

ทุกแอปที่แพลตฟอร์มสร้างขึ้นจะรันเป็น instance ส่วนตัวของคนที่ขอ ไม่ใช่ tenant หนึ่งใน service ที่ใช้ร่วมกัน นี่เป็นคุณสมบัติด้าน security ก่อนจะเป็นเรื่อง product ด้วยซ้ำ — เพราะไม่มี shared instance ก็ไม่มีเส้นทางข้อมูลข้ามผู้ใช้ให้พลาด นอกจากนั้นแต่ละแอปยังเปิด method ของตัวเองกลับไปให้ agent เรียกได้ agent ที่สร้าง supplier scorecard จึงขับมันต่อได้ ทั้งเติมข้อมูล query และต่อยอดตามที่สั่ง

สิ่งที่ทีมมักสร้างกันในเดือนแรก:

• หน้าจอ Reconciliation และ Exception ที่อ่านจาก ERP แล้วดันขึ้นมาเฉพาะแถวที่ต้องใช้คนตัดสิน
• แอป Document Extraction ที่เปลี่ยนโฟลเดอร์สัญญา supplier หรือ policy PDF ให้เป็นตารางที่ query ได้
• Approval Tracker ที่วางทับระบบ workflow เดิม แล้วตามคนที่ติดจริง ๆ ให้ขยับ
• Report ระดับแผนกที่สร้างใหม่ทีละทีม เพราะแต่ละโรงงาน ภูมิภาค และโต๊ะงาน อยากได้ตัวเลขชุดเดียวกันในมุมที่ต่างกัน

Capability Broker คุม agent ให้อยู่ในเลนได้อย่างไร?

แอปเริ่มต้นจากศูนย์ — ไม่มี network ไม่มี credential ไม่มีข้อมูล สิทธิ์ถูกให้ทีละ capability และทุก external call ต้องวิ่งผ่าน Capability Broker ที่ถือ credential ไว้เอง บีบ scope ให้แคบเหลือเฉพาะ resource ที่ถูกส่งให้ และเขียน audit record ไปพร้อมกัน แอปที่ได้สิทธิ์อ่าน CRM report เพียงตัวเดียว จะขยายไปถึง account object ไม่ได้ ไม่ว่า agent จะพยายามแค่ไหน เพราะแอปไม่เคยถือ token ที่จะขยายได้ตั้งแต่แรก

เราไม่ได้ไว้ใจ agent ก่อนแล้วค่อยไปคุมทีหลัง แต่ให้มันเริ่มจากศูนย์ แล้วส่งสิ่งที่งานต้องใช้ให้ทีละ capability

Deferred Human Approval — ทำไม agent ไม่ควรหยุดรอคน

Human-in-the-loop ตามปกติแปลว่า agent หยุดแล้วรอ ซึ่งเป็นเหตุผลที่ทีมส่วนใหญ่แอบปิดมันทิ้งภายในไตรมาสเดียว ที่นี่การเขียนที่ต้องขออนุมัติจะถูกคิวไว้เป็น proposed action และ agent เดินงานต่อบนผลลัพธ์ที่คาดไว้ workflow ห้าขั้นจึงไม่ค้างทั้งวันอยู่ที่ขั้นสอง ฝั่งคนรีวิวเห็นชัดว่าจะเขียนอะไร ลงระบบไหน ในนามใคร และการกด Approve หรือ Deny จะไปปิดคิวนั้น โดยการ Deny ถูกบันทึกคู่กับการ Approve เสมอ ซึ่งมักเป็นสิ่งที่ auditor อยากเห็นจริง ๆ

มันวางตัวอยู่ตรงไหนใน estate เดิมของคุณ

แพลตฟอร์มนี้เป็นชั้นหนึ่ง ไม่ใช่ของมาแทนที่ ERP, CRM, HRIS, Data Warehouse และระบบ Ticketing ของคุณยังเป็น system of record เหมือนเดิม ส่วน Capability Broker เข้าถึงระบบเหล่านั้นผ่าน service account, SSO และ SCIM Provisioning ชุดเดียวกับที่ทีม security ของคุณกำกับอยู่แล้ว ส่วน Blueprint ทำให้แอปที่ใช้ได้จริงของแผนกหนึ่งถูกเผยแพร่เป็น template ให้อีกแผนกหยิบไปสร้าง instance ด้วยข้อมูลและ approval policy ของตัวเอง — reuse ได้โดยไม่ต้องใช้ instance ร่วมกัน และไม่ต้องมี fork ที่ไม่มีใครดูแล

ถ้ากำลังชั่งใจระหว่าง agentic operating model กับการรอคิว internal tool ไปอีกหนึ่งปี — คุยกับทีมวิศวกรของ HarmonyX เรา scope ได้ตั้งแต่ pilot แผนกเดียว ไปจนถึง rollout ทั้งองค์กร และรับงาน integration กับ governance กับระบบที่คุณใช้อยู่ให้ทั้งหมด