Generative UI: เมื่อ AI Agent ต้องเลิกอธิบาย แล้วเริ่มวาดหน้าจอ

มีประโยคหนึ่งจาก X Article ของ Shubham Saboo ที่ผมคิดว่าเป็นสัญญาณใหญ่ของตลาด AI Agent:

Ask for a table, get a table. Not a paragraph describing one.

ขอ table ก็ควรได้ table ไม่ใช่ได้ข้อความยาว ๆ ที่บอกว่า “นี่คือตารางที่คุณต้องการ”

ฟังดูเหมือนเรื่อง UX เล็ก ๆ แต่จริง ๆ แล้วมันคือเส้นแบ่งระหว่าง AI chatbot กับ AI Agent ที่ทำงานในธุรกิจจริง

เพราะในงานจริง คนไม่ได้ต้องการคำตอบอย่างเดียว คนต้องการหน้าจอที่ทำให้ตัดสินใจได้ แก้ไขได้ approve ได้ ส่งต่อได้ และตรวจ proof ได้

นี่คือที่มาของคำว่า Generative UI

1) เกิดอะไรขึ้น

Shubham Saboo เขียน X Article ชื่อ “Generative UI Is the New Frontend” โดยสรุปว่า frontend กำลังเปลี่ยนจากสิ่งที่ fixed ล่วงหน้า ไปเป็นสิ่งที่ agent มีส่วนสร้างขึ้นตามคำขอของผู้ใช้แบบ real time

เขาวาง stack ไว้สามชั้น:

• MCP เชื่อม agent กับ tool และ data
• A2A เชื่อม agent กับ agent
• AG-UI เชื่อม agent กับ user ผ่าน event stream, state sync, tool call, UI schema และ action feedback

ส่วน A2UI คือแนวทาง declarative UI ที่ให้ agent ส่ง schema เพื่อให้ frontend render เป็นหน้าจอจริง เช่น card, list, badge, form หรือ dashboard

ในเอกสารของ Google ADK และ CopilotKit ก็เห็นทิศทางเดียวกัน: agent app ไม่ได้จบที่ chat message แล้ว แต่เริ่มมี protocol สำหรับ streaming UI, state, action และ human-in-the-loop กลับไปกลับมาระหว่าง agent กับ user

พูดง่าย ๆ:

AI Agent กำลังมี frontend ของตัวเอง

ไม่ใช่ frontend แยกจาก agent แต่เป็น frontend ที่ถูกขับเคลื่อนด้วย goal, context, tool และ state ของ agent

2) Generative UI มี 3 pattern

Saboo แบ่ง pattern ออกเป็น 3 แบบ ซึ่งผมคิดว่าเป็นกรอบที่ทีม product ควรใช้ก่อนเขียน code

Pattern 1: Controlled UI

แบบแรกคือ controlled

ทีม frontend สร้าง component ไว้ก่อน เช่น expense chart, quote card, approval card, customer timeline, payment slip review card

agent มีหน้าที่เลือก component ที่ถูกต้อง แล้วส่ง argument เข้าไป render

ข้อดีคือ control สูงมาก brand ไม่เพี้ยน layout เป๊ะ ใช้กับ workflow สำคัญได้ดี

เช่นใน CustomerOS ถ้า agent สรุปลูกค้ารายหนึ่งแล้วพบว่าควรส่งใบเสนอราคา สิ่งที่ควรขึ้นมาไม่ใช่ข้อความว่า “ควรส่ง quote”

แต่ควรเป็น quote card ที่มี:

• ชื่อลูกค้า
• package ที่เสนอ
• ราคา
• เงื่อนไข
• risk note
• ปุ่มให้ owner approve ก่อนส่งจริง

นี่คือ controlled UI ที่เหมาะกับงานที่ธุรกิจต้องการความชัด

แต่ข้อเสียคือ ยิ่งมี component เยอะ agent ยิ่งต้องรู้จัก tool เยอะ Saboo ยกตัวอย่างว่า component description กับ JSON schema อาจกิน token หลายร้อย token ต่อ component ถ้ามี 25 component ก็กลายเป็น token tax ก้อนใหญ่ทุก turn

และพอ component เยอะเกินไป agent อาจเลือกผิด เช่น pie chart กับ donut chart ดูเหมือนกันในคำอธิบาย

ดังนั้น controlled เหมาะกับ top flow ที่สำคัญจริง ๆ ไม่ใช่ทุกอย่างในระบบ

3) Declarative / A2UI คือทางของ long tail

แบบที่สองคือ declarative หรือ A2UI

agent ไม่ได้เลือก component ที่ hard-code ไว้หนึ่งตัว แต่ส่ง schema ว่าอยากได้ UI แบบไหน จาก catalog ที่ frontend อนุญาตไว้

frontend มี catalog ของ component เช่น card, row, list, metric, button, badge, table แล้ว map schema เหล่านั้นเป็น React หรือ framework อื่น

ข้อดีคือ agent เห็น function น้อยลง แต่สร้าง UI ได้หลากหลายขึ้น

เอกสาร CopilotKit A2UI อธิบายว่ามีทั้ง fixed schema และ dynamic schema:

• fixed schema: developer เขียน component tree ล่วงหน้า agent เติม data
• dynamic schema: LLM สร้าง schema และ data จาก context ของ conversation

สำหรับธุรกิจ นี่สำคัญมาก เพราะ UI ของงานจริงมี long tail

เจ้าของกิจการอาจถาม:

• วันนี้ทีมตอบแชทช้าเพราะอะไร
• ลูกค้าที่น่าตามต่อคือใครบ้าง
• lead จาก Facebook Ads อันไหน convert ดี
• สินค้าไหนถูกถามเยอะแต่ปิดไม่ได้
• admin คนไหนมี conversation ค้าง
• สาขาไหนต้อง follow-up

ถ้าเราสร้าง component แยกทุกคำถาม ระบบจะบวมเร็วมาก

แต่ถ้าใช้ declarative UI เราสามารถมี catalog ที่ออกแบบดี แล้วให้ agent render surface ตามบริบทได้

เช่น owner report อาจไม่ได้มีหน้าตาเดียวตลอด บางวันควรเป็น table บางวันควรเป็น funnel บางวันควรเป็น customer list บางวันควรเป็น risk alert card

ทั้งหมดนี้ไม่ควรเป็นข้อความยาวใน chat ควรเป็น work surface ที่ดูแล้วตัดสินใจได้

4) Open-ended UI ดูเท่ แต่ไม่ควรเป็น default

แบบที่สามคือ open-ended

agent เขียน raw HTML หรือควบคุม canvas / MCP App เอง แล้ว app render ใน sandbox

ตัวอย่างเช่น agent วาด diagram ใน Excalidraw, สร้าง HTML dashboard ชั่วคราว, หรือสร้าง visualization จาก API response ที่ผู้ใช้แค่ต้องการดูครั้งเดียว

ข้อดีคือ flexible มาก แต่ข้อเสียคือ brand และ behavior คุมยาก

วันนี้หน้าตาแบบหนึ่ง พรุ่งนี้หน้าตาอีกแบบ บางครั้งปุ่มกดไม่ได้ บางครั้ง form submit ไม่ทำงาน บางครั้งมี text แปลก ๆ หลุดมา

สำหรับ demo มันดู wow แต่สำหรับ product ที่ลูกค้าใช้ทุกวัน มันอาจทำให้ระบบดูไม่น่าเชื่อถือ

ผมเห็นด้วยกับข้อสรุปของ Saboo ตรงนี้:

Open-ended เหมาะกับ disposable UI ไม่เหมาะเป็น primary product surface

ถ้าธุรกิจจะใช้ AI Agent กับงานจริง เช่น CRM, sales, finance, support, content ops หรือ HR เราไม่ควรฝากหน้าจอหลักไว้กับ raw HTML ที่ model แต่งเองทุกครั้ง

ใช้มันเป็น sandbox ได้ แต่อย่าให้มันเป็นระบบหลัก

5) มุม Business OS: UI คือ proof layer

ผมคิดว่า Generative UI ไม่ใช่แค่เรื่อง frontend แต่มันคือ proof layer ของ Business OS

ใน Business OS เรามักพูดถึง loop นี้:

Goal → Context → Plan → Tools → Approval → Proof → Memory

ปัญหาคือหลายระบบหยุดแค่ chat agent ตอบว่า “ทำแล้ว” แต่ user ยังต้องไปเปิดระบบอื่นเพื่อตรวจเอง

ถ้า agent บอกว่า:

“ผมเจอลูกค้า 12 รายที่ควร follow-up”

คำถามคือ แล้ว user เห็นอะไรต่อ?

ถ้าเห็นแค่ข้อความยาว ๆ ใน chat งานยังไม่จบ

แต่ถ้าเห็น customer cards ที่มีชื่อ, stage, last message, reason, suggested reply, ปุ่ม approve, ปุ่ม assign admin และ proof link ไปยัง conversation เดิม

อันนี้เริ่มเป็น operating surface แล้ว

Generative UI จึงเป็นชั้นที่ทำให้ agent ทำงานกับคนได้จริง

ไม่ใช่เพราะมันสวยขึ้น แต่เพราะมันทำให้ human approval และ business decision เกิดขึ้นบนหน้าจอเดียวกับ proof

6) ใช้กับ Data-Espresso ยังไง

ถ้ามองจาก product ของ Data-Espresso ผมจะแบ่งแบบนี้

CustomerOS

ใช้ controlled UI กับ flow ที่เสี่ยงหรือสำคัญ:

• quote approval
• customer handoff
• payment slip review
• escalation card
• product recommendation ก่อนส่งให้ลูกค้า
• owner approval ก่อน broadcast หรือ campaign

ใช้ declarative UI กับ long-tail report:

• daily owner report
• customer list ตาม risk
• product FAQ gap
• lead source performance
• admin response summary
• pipeline snapshot

open-ended ใช้เฉพาะ demo หรือ exploration เช่น visualizing conversation pattern แบบครั้งเดียว

OPB Stack

OPB Stack ไม่ควรขายแค่ “มี agent ให้ใช้”

แต่ควรขายว่า agent มีบ้าน มี tool มี memory และมี work surface ที่เจ้าของธุรกิจเห็น proof ได้

Generative UI ช่วยให้ OPB Stack กลายเป็น AI coworker workspace มากกว่า chat bot sandbox

เจ้าของไม่ควรต้องอ่าน log ยาว ๆ เพื่อรู้ว่า agent ทำอะไร เขาควรเห็น card, checklist, report, diff, approval gate และ next action

TimeFlow

TimeFlow มีงานที่เหมาะกับ controlled UI มาก เช่น leave approval, timesheet reminder, missing entry card, manager summary

แต่ analytics และ team performance dashboard เหมาะกับ declarative UI มากกว่า เพราะคำถามผู้บริหารเปลี่ยนไปเรื่อย ๆ

Learn / AI Mentor

AI Mentor ไม่ควรตอบแค่ paragraph เสมอไป

บางคำถามควรกลายเป็น:

• checklist
• quiz card
• flashcard
• lab step
• code explanation panel
• comparison table

นี่คือ Generative UI ในบริบทการเรียน ถามเรื่อง lesson ก็ได้ learning surface ไม่ใช่แค่ text answer

7) คำถามที่ทีมควรถามก่อนเลือก pattern

ก่อนทำ agent UI ผมจะไม่เริ่มจากถามว่าใช้ framework ไหน

ผมจะถามก่อนว่า:

1. Flow นี้ต้อง pixel-perfect ไหม
2. Flow นี้เสี่ยงไหม ถ้าปุ่มหรือข้อมูลผิดจะเกิดอะไร
3. มี UI แบบนี้กี่แบบในระบบ
4. ต้องให้ user แก้ state แล้ว agent รับรู้ต่อไหม
5. ต้องเก็บ proof ว่า agent เลือก schema/component อะไรไหม
6. เป็นหน้าจอที่จะใช้ซ้ำ หรือแค่ visualization ครั้งเดียว

ถ้าต้องเป๊ะและใช้บ่อย ให้ controlled ถ้ามี long tail เยอะ ให้ declarative ถ้าเป็นของชั่วคราว ให้ open-ended

ถ้ายังไม่แน่ใจ ให้เริ่ม declarative แล้วเลือก top 3 flow ที่สำคัญที่สุดไปทำ controlled

อย่าเริ่ม open-ended เป็น default เพราะมันดูเร็วใน demo แต่ช้าใน production ตอนต้องตามแก้ consistency, security และ brand trust

8) สรุป

Generative UI ไม่ได้แปลว่า agent วาดหน้าเว็บสวย ๆ ได้

มันแปลว่า agent เริ่มมีความสามารถในการสร้าง work surface ที่เหมาะกับงานตรงหน้า

สำหรับธุรกิจไทย นี่สำคัญกว่าที่คิด

เพราะหลายธุรกิจไม่ได้ติดปัญหาว่า AI ตอบไม่ได้ แต่ติดปัญหาว่า AI ตอบแล้ว งานยังไม่จบ

ตอบแล้วต้อง copy ไป Sheet ตอบแล้วต้องเปิด CRM ตอบแล้วต้องไปถาม owner ตอบแล้วต้องไปหา proof ตอบแล้วต้องกลับมาเขียนข้อความส่งลูกค้าเอง

Generative UI คือชั้นที่ช่วยปิดช่องว่างนี้

AI ไม่ควรเป็นแค่คนพูดเก่งใน chat

AI ควรเป็นคนทำงานที่เปิดหน้าจอที่ถูกต้องให้เราเห็น แล้วให้เราตัดสินใจต่อได้ทันที

นี่คือ frontend ใหม่ของ AI Agent และเป็นชิ้นสำคัญของ Business OS ที่หลายทีมยังไม่ได้ออกแบบจริงจัง