กล่องแชตว่าง ๆ เป็นที่ที่ไม่ดีสำหรับรัน consequential work มันยุบคำถามที่ต่างกันมากห้าข้อ คุณต้องการอะไร กำลังดูอะไร มันอิงอะไร คุณได้รับอนุญาตให้ทำอะไร และเกิดอะไรขึ้นแล้ว ให้กลายเป็นสตรีมเดียวที่ไม่แยกแยะ สำหรับงานทั่วไปสิ่งนี้พอได้ แต่สำหรับ governed operations ที่ actions แตะ systems of record และ decisions ต้องปกป้องได้ การยุบแบบนั้นคือสิ่งที่รับไม่ได้
workspace ของ Threada จึงถูกแยกออกเป็นห้า surfaces อย่างตั้งใจ แต่ละ surface ตอบคำถามหนึ่งข้อ และการแยกให้ชัดคือสิ่งที่ทำให้งาน review ได้
1. Intent bar: คุณต้องการอะไร?
งานใน Threada เริ่มจาก intent bar ที่คงอยู่ แทนการนำทางลึก ๆ คุณระบุผลลัพธ์ที่ต้องการด้วยภาษาธรรมชาติ อาจใช้คำสั่งมีโครงสร้างร่วมด้วย แล้ว runtime แปลงสิ่งนั้นเป็น artifact ที่มีโครงสร้างและ execute ได้: WorkItem พร้อม entities ที่ extract, confidence score และ risk flags
นี่คือ interaction แบบ intent-first แทนที่จะบังคับให้ operator รู้ว่าต้องใช้ฟอร์มใด คิวใด และ workflow ใดก่อนเริ่ม ระบบจับเป้าหมายและประกอบเส้นทางให้ เมื่อข้อมูลขาด ระบบถามเฉพาะสิ่งที่ต้องการ แทนที่จะเสนอ wizard ยาว ๆ คงที่ตั้งแต่ต้น
2. Adaptive canvas: คุณกำลังทำอะไร?
Canvas คือที่ที่ WorkItem อยู่และถูกหล่อรูป มัน adaptive: UI สามารถประกอบฟอร์มชั่วคราว การเปรียบเทียบ และแผงตัดสินใจ เพื่อเก็บบริบทที่ขาดและทำงานให้เสร็จ แทนที่จะ render layout เดียวสำหรับงานทุกชนิด
ผลลัพธ์ที่สร้างขึ้นเริ่มเป็น draft ที่แก้ไขได้ ไม่ใช่การเปลี่ยนแปลงที่ commit แล้ว Operator review, edit และ decide controls ที่ใช้ควบคุมต้องชัดเจน เช่น lock และ no-change zones, side-by-side compare, undo และ version rollback ที่รวดเร็ว เพื่อให้ canvas เป็นที่สำหรับพิจารณา ไม่ใช่ที่ที่คำเดาแรกของโมเดลกลายเป็นความจริง
3. Evidence drawer: มันอิงอะไร?
output ที่มีผลตามมาทุกชิ้นควรแสดงที่มาของตนได้ Evidence drawer เก็บ citations, retrieval traces และ source attribution ที่ ground WorkItem เมื่อระบบ ground คำตอบไม่ได้ มันจะบอกอย่างชัดเจนด้วย fallback reason แทนที่จะสร้างความมั่นใจขึ้นมา
นี่คือ surface ที่ทำให้ “trust the AI” กลายเป็น claim ที่ตรวจดูได้ ไม่ใช่การกระโดดด้วยศรัทธา Operator ไม่จำเป็นต้องเชื่อ draft; เขาเปิด drawer แล้วตรวจได้ว่ามันยืนบนอะไร แหล่งข้อมูลสดแค่ไหน และแต่ละ claim มาจากที่ใด
4. Action controls: คุณทำอะไรได้?
การอ่านและการร่างปลอดภัย แต่การลงมือกับโลกจริงไม่ปลอดภัย ดังนั้น controls surface จึงต้องมี governance นี่คือที่ที่ proposals กลายเป็น approvals และ approvals กลายเป็น executed actions ต่อระบบภายนอก: refund, ticket, record update หรือ access grant
Governance ที่นี่แสดงเป็น policy, permissions, thresholds, approval gates และ redlines ไม่ใช่ settings toggles ที่กระจายไปทั่ว Actions ความเสี่ยงสูงผ่าน progression ที่ชัดเจนแบบ proposed, approved, executing และ auto-execute เฉพาะเมื่อ policy อนุญาตเท่านั้น kill switch ระดับ service สามารถหยุด execution ก่อนเรียก connector ใด ๆ พร้อมคง state ไว้สำหรับ review Controls surface คือที่ที่ความระมัดระวังของระบบกลายเป็นรูปธรรม
5. Run log: เกิดอะไรขึ้นแล้ว?
Run log คือ timeline ของ WorkItem: ทุก transition, ทุก approval, ทุก action, ทุก AI participant event ตามลำดับ นี่คือ surface ที่ receipts สะสมเป็นประวัติ
สิ่งสำคัญคือ actions ของ AI ปรากฏเป็น actor events แยก ไม่ถูกพับรวมกับกิจกรรมของมนุษย์ เมื่ออ่าน run log คุณจะบอกได้ว่าใครเสนอ ใครอนุมัติ และอะไรถูก execute เป็นมนุษย์หรือ agent โดยไม่ต้องเดา Run log คือสิ่งที่ auditor อ่านตอนสิ้นไตรมาส และสิ่งที่ operator อ่านเพื่อเข้าใจ case ที่อยู่ตรงหน้าวันนี้
ทำไมการแบ่งนี้คือหัวใจ
จะง่ายกว่าถ้าสร้าง surface เดียวแล้วปล่อยให้ทุกอย่างปนกัน เหตุผลที่ไม่ควรทำคือ consequential work ต้องการให้คำถามเหล่านี้แยกจากกัน
ถ้า intent, evidence และ action อยู่ร่วม surface เดียวกัน จะง่ายที่จะลงมือกับสิ่งที่ไม่เคย ground หรืออนุมัติสิ่งที่ไม่เคยเห็นฐานรองรับ การให้แต่ละส่วนมี surface ของตนเองทำให้ Threada ทำเส้นทางที่รอบคอบให้เป็นเส้นทางตามธรรมชาติ: ระบุ intent, ปั้น draft บน canvas, ตรวจ evidence แล้วจึง action ผ่าน governed controls โดยมี run log บันทึกทั้งหมด
ห้า surfaces คงที่ข้าม packs และ roles; สิ่งที่เติมเข้าไปจะปรับตามงาน ความเสถียรนี้ตั้งใจออกแบบ Operator ที่เรียนรู้รูปแบบ workspace หนึ่งแบบ ก็เรียนรู้รูปแบบทั้งหมดแล้ว ไม่ว่าจะทำ IT access provisioning, vendor security review หรือ procurement approval งานเปลี่ยน แต่วิธี reasoning เกี่ยวกับงานนั้นไม่เปลี่ยน