GTM บน Claude Code: รันรายชื่อ Verified Lead ด้วยทีม AI Agent

สรุปสั้นๆ (TL;DR): คุณสามารถรันเวิร์กโฟลว์ GTM ใน Claude Code ได้โดยการแบ่งงานบนบอร์ดออกเป็นงานย่อยตามแต่ละสเตจ: ฟิลเตอร์ ICP, ไฟล์กฎระเบียบ (rules file), การคัดกรองคุณสมบัติ (qualification), การค้นหาบุคคล, การค้นหาและตรวจสอบอีเมล, สัญญาณความเคลื่อนไหว (signals) และการติดต่อสื่อสาร (outreach) โดยมีเอเจนต์คอยจัดการงานข้อมูลแต่ละสเตจโดยใช้ Treg เป็นดาต้าเลเยอร์ ในขณะที่มีมนุษย์เป็นเจ้าของไฟล์กฎระเบียบและคอยอนุมัติประโยคเปิดของทุกอีเมลก่อนที่จะกดส่งจริง

การรัน GTM ใน Claude Code อาจฟังดูเหมือนแค่การเขียนพรอมต์ยาวๆ เพียงข้อความเดียว เช่น "หา 50 แอคเคานต์คุณภาพดีแล้วร่างข้อความส่งหาผู้มีอำนาจตัดสินใจซื้อให้หน่อย" ซึ่งวิธีนี้อาจได้ผลดีตอนทำเดโม แต่มันจะพังทันทีเมื่อเครื่องมือค้นหาข้อมูลโควตาเต็ม หรือเมื่อไม่มีใครตอบได้ว่าใครเป็นคนอนุมัติส่งอีเมลฉบับนั้น

GTM engineering playbook ของ Treg ครอบคลุมฝั่งงานข้อมูลไว้ทั้งหมด โดยมี 16 บทตั้งแต่การกำหนด ICP ไปจนถึงการเปิดใช้งานจริง (rollout) ซึ่งสร้างขึ้นจากการรันและบันทึกผล 6 ครั้ง มีการเรียกใช้ API ตามบันทึก 502 ครั้ง และคิดค่าบริการตามการใช้งานจริงอยู่ที่ 5.03 ดอลลาร์ ทั้งนี้ ตัวเลขทั้งหมดในบทความนี้เป็นผลการบันทึกของทาง Treg เอง และยังไม่ได้รับการทดสอบซ้ำจากภายนอก ดังนั้นจึงควรทดสอบกับชุดข้อมูลของคุณเองก่อนนำไปใช้จริง

ส่วนอีกครึ่งหนึ่งคือเรื่องการประสานงาน (coordination): ต้องมีผู้รับผิดชอบที่คอยสั่งหยุด มีคนคอยดูแลขั้นตอน outreach และมีการนับจำนวนแถวข้อมูลในแต่ละสเตจ ซึ่งเซสชันการทำงานเพียงเซสชันเดียวไม่สามารถรองรับเรื่องเหล่านี้ได้ บทความนี้จะแสดงวิธีนำ playbook ดังกล่าวมาจัดโครงสร้างเป็นงานย่อยบน Sharkly โดยให้เอเจนต์รันแต่ละขั้นตอนใน Claude Code หรือ Codex และให้มนุษย์คอยคุมจุดตรวจสอบ (gates) สำคัญ 2 จุดตามที่ playbook ระบุไว้

ทำไมการรัน GTM ใน Claude Code ถึงต้องใช้บอร์ดแทนการใช้เซสชันเดียว

การรันงานเอเจนต์ในเซสชันเดียวยาวๆ มักซ่อนความผิดพลาด 3 ประการที่งาน GTM ไม่ควรปล่อยให้เกิดขึ้น

1. ค่าใช้จ่ายที่เกิดขึ้นโดยไม่มีจุดตรวจเช็ก (Spend without a checkpoint) มีการจ่ายเงินเพื่อทำ enrichment ให้กับข้อมูลแถวที่ควรจะถูกตัดทิ้งไปตั้งแต่แรก
2. ระบบพังเงียบๆ โดยไม่รู้ตัว (Silent breakage) Treg ได้ระบุสิ่งที่เกิดข้อผิดพลาดในการรันของตัวเองโดยที่กระบวนการไม่ได้หยุดลง ไม่ว่าจะเป็นเครื่องมือค้นหาโควตาเต็ม, endpoint ของ buying-group โควตาเต็ม, แอคเคานต์ถูกจำกัดอัตราการเรียกใช้ (rate-limited) 3 รายการ และบั๊กใน parser ที่ทำให้ต้องเสียค่าใช้จ่ายรันใหม่ไป 1.08 ดอลลาร์
3. ไม่มีผู้รับผิดชอบการส่ง (No owner for the send) กฎข้อสำคัญสำหรับการ outreach ใน playbook ระบุไว้อย่างตรงไปตรงมาว่า "ห้ามส่งข้อความใดๆ ที่มนุษย์ยังไม่ได้อ่านโดยเด็ดขาด"

ปัญหาแต่ละข้อล้วนเป็นปัญหาเชิงการทำงานร่วมกันในทีม ซึ่งแก้ไขได้ด้วยการกำหนดผู้รับผิดชอบที่ชัดเจน สถานะของงาน และการบันทึกข้อมูลของแต่ละสเตจ นี่คือโมเดลจากแนวคิด การให้มนุษย์เป็นเจ้าของงานของเอเจนต์ (human ownership of agent work) ที่นำมาปรับใช้กับรายชื่อลีด (lead list)

สแตกของระบบ: แต่ละส่วนทำงานที่ไหน

แบ่งออกเป็น 3 เลเยอร์ โดยแต่ละเลเยอร์มีหน้าที่ชัดเจนเพียงอย่างเดียว

ติดตั้ง Treg เพียงครั้งเดียวบน Computer ที่เอเจนต์ของคุณทำงานอยู่ จาก ไฟล์การติดตั้งของ Treg:

# install the CLI and the treg skill for every agent it detects
curl -fsSL https://treg.to/install.sh | sh

# browser sign-in (GitHub, Google, or an emailed code)
treg login

# headless Computer: pass a token instead of a browser
curl -fsSL https://treg.to/install.sh | sh -s -- --token "$TREG_TOKEN"

หรือวางคำสั่งบรรทัดนี้ลงในเอเจนต์ได้เลย: set up treg - https://treg.to/llms.txt โดย Treg ระบุว่าบัญชีใหม่ที่ผ่านการยืนยันตัวตนจะได้รับเครดิตฟรี 1.00 ดอลลาร์ในครั้งแรก ค่าบริการการเรียกใช้จะคิดตามอัตราจริงของผู้ให้บริการโดยไม่มีการบวกเพิ่ม (markup 0%) และหากค้นหาข้อมูลไม่พบจะไม่คิดค่าบริการ (คิด $0.00)

การแปลงไปป์ไลน์ GTM ให้เป็นงานบนบอร์ด

นี่คือการนำ playbook มาแมปให้เป็นงานย่อย โดยคอลัมน์ที่สามคือผลการบันทึกการรันของ Treg ในแต่ละสเตจ

เขียน ICP อย่างไรเพื่อให้เอเจนต์นำไปใช้เป็นฟิลเตอร์ได้?

ให้แยก ICP ออกเป็น 2 ส่วน คือ "ฟิลเตอร์" (filters) และ "การตรวจสอบ" (checks) โดยฟิลเตอร์คือฟิลด์ข้อมูลที่ผู้ให้บริการค้นหาได้ เช่น ประเทศ, จำนวนพนักงาน, หมวดหมู่ธุรกิจ, การระดมทุน ส่วนการตรวจสอบจะเป็นการใช้วิจารณญาณประเมินข้อมูลทีละแถว ซึ่งจะต้องรันก่อนที่จะเข้าสู่ขั้นตอนที่ต้องเสียเงินเสมอ

ในคำอธิบายของงาน (task description) สามารถใส่พรอมต์ของ Treg ลงไปได้ เช่น: "ใช้ treg แปลง ICP ใน icp.md ให้เป็นฟิลเตอร์สำหรับผู้ให้บริการค้นหาบริษัท 2 ราย โดยเรียกใช้เฉพาะ endpoint ตรวจสอบจำนวนแบบฟรีเท่านั้น" ส่วนเกณฑ์การยอมรับงาน (acceptance criteria) ให้นำมาจาก playbook นั่นคือ จะไม่มีการซื้อรายชื่อใดๆ ทั้งสิ้น จนกว่าผลการนับฟรีจากผู้ให้บริการทั้ง 2 รายจะมีจำนวนใกล้เคียงกัน และข้อมูลตัวอย่าง 10 แถวแรกดูถูกต้องเหมาะสม

ทำไมไฟล์กฎระเบียบถึงต้องมีมนุษย์เป็นผู้รับผิดชอบ?

เพราะเกณฑ์คะแนน (threshold) ส่งผลต่อรายชื่อที่จะได้โดยตรง ในการรันของ Treg หากตั้งเกณฑ์ความตรงกับ ICP ไว้ที่ 50% จะมีบริษัทผ่าน 27 จาก 48 แห่ง แต่ถ้าขยับเป็น 60% จะมีบริษัทผ่านเพียง 14 แห่งเท่านั้น นี่คือการตัดสินใจเชิงธุรกิจ จึงต้องมีมนุษย์เป็นเจ้าของงานที่เขียนกำหนดกฎเหล่านี้ขึ้นมา

ควรเก็บกฎเหล่านี้ไว้ในจุดที่ทุกสเตจสามารถเข้ามาอ่านได้ ซึ่ง Skill ของ Sharkly จะช่วยรวมชุดคำสั่งที่นำกลับมาใช้ซ้ำได้สำหรับการทำงานของเอเจนต์ ทำให้ไฟล์กฎระเบียบนี้กลายเป็น Skill เดียวที่ผูกไว้กับทุกเอเจนต์ในไปป์ไลน์ GTM แทนที่จะต้องคอยคัดลอกข้อความยาวๆ ไปแปะลงใน 9 พรอมต์แยกกัน

# gtm-rules.md (owner: the person who can stop the run)
icp_threshold: 0.50
max_spend_per_run_usd: 3.00
drop_if: [no_usable_domain, headcount_outside_51_200]
send_only: verifier_verdict == "deliverable"
stop_owner: "growth lead"
every_stage_reports: [rows_in, rows_out, metered_cost]

สเตจ 3 ถึง 7: คัดกรองคุณสมบัติก่อนยอมจ่ายเงิน

นี่คืองานจัดการข้อมูลที่ควรเริ่มจากขั้นตอนที่มีค่าใช้จ่ายต่ำที่สุดก่อน โดยเชื่อมโยงงานเหล่านี้ด้วยความสัมพันธ์แบบ blocks / is blocked by เพื่อให้การคัดกรองคุณสมบัติเสร็จสิ้นก่อนที่การค้นหาบุคคลจะเริ่มต้นขึ้น ลำดับขั้นตอนมีความสำคัญอย่างยิ่งต่อเรื่องค่าใช้จ่าย: Treg คัดกรองบริษัท 50 แห่งด้วยเงินเพียง $2.33 ในขณะที่ประเมินว่าต้องใช้เงินถึง $4.12 หากทำ enrichment กับทั้ง 48 บริษัทที่มีโดเมนที่ใช้งานได้โดยไม่คัดกรองก่อน

กฎสองข้อจาก playbook จะถูกนำมาใช้เป็นเกณฑ์การยอมรับงาน ข้อแรกคือ รายชื่อ lookalike จะต้องผ่านฟิลเตอร์ขนาดบริษัทและการตรวจสอบ ICP เหมือนกับข้อมูลแถวอื่นๆ ทั่วไป ข้อที่สองคือ เฉพาะอีเมลที่ผ่านการตรวจสอบยืนยันแล้วว่าส่งถึงได้จริง (verified-deliverable) เท่านั้นที่จะถูกนำเข้าสู่กระบวนการส่งอีเมล: ในการศึกษาข้อมูล 60 คนของ Treg เครื่องมือค้นหาพบ 60 อีเมล แต่เครื่องมือตรวจสอบยืนยันให้ผ่านเพียง 32 อีเมลเท่านั้น

งานข้อมูลแต่ละสเตจจะจบลงด้วยคอมเมนต์จากเอเจนต์ที่ระบุ: จำนวนแถวข้อมูลขาเข้า (rows in), จำนวนแถวข้อมูลขาออก (rows out) และค่าบริการตามการใช้งานของ Treg ซึ่งเมื่อรวมกับบันทึกประวัติการรันแล้ว สิ่งนี้จะทำหน้าที่เป็นเหมือนใบเสร็จของแต่ละสเตจ

ทำอย่างไรให้มนุษย์ยังคงเป็นผู้ควบคุมปุ่มส่ง?

งานในขั้นตอนการติดต่อสื่อสาร (outreach) เป็นจุดที่เอเจนต์จะทำการค้นคว้าและร่างข้อความ แล้วหยุดรอ โดยในการรันของ Treg มีประโยคเปิดที่อิงจากข่าวเพียง 4 จาก 19 ประโยคที่ได้คะแนนอยู่ในเกณฑ์พอใช้ขึ้นไป ดังนั้น เอเจนต์จึงเปลี่ยนสถานะของงานให้อยู่ในสถานะ รอการตรวจสอบจากมนุษย์ (waiting for human review) เพื่อให้ผู้ตรวจสอบเป็นคนอนุมัติ แก้ไข หรือเขียนใหม่ เราเคยอธิบายแพตเทิร์นนี้ไว้ในบทความ human-in-the-loop coding agents ซึ่งสามารถนำมาปรับใช้กับการส่งอีเมลได้โดยตรงโดยไม่ต้องเปลี่ยนแปลงอะไร

Sharkly ช่วยควบคุมกฎเกณฑ์ของ playbook ให้อยู่กับร่องกับรอยได้อย่างไร

• หนึ่งงานต่อหนึ่งสเตจ (One task per stage) ช่วยให้แต่ละขั้นตอนมีสถานะที่ชัดเจน มีผู้รับผิดชอบหรือ Assignee (ไม่ว่าจะเป็น Agent, Crew หรือบุคคล) และมีเกณฑ์การยอมรับงานที่ชัดเจน
• สถานะการตรวจสอบ (Review states) ช่วยจัดลำดับความสนใจของทีม เอเจนต์สามารถตั้งสถานะงานให้รอการตอบกลับจากมนุษย์หรือรอการตรวจสอบจากมนุษย์ได้ และการแจ้งเตือนเหล่านี้จะถูกส่งไปยัง Inbox ของผู้รับผิดชอบโดยตรง
• บันทึกประวัติการรัน (The run record) แสดงเวลาเริ่มต้นและสิ้นสุดของการรัน ประวัติการเรียกใช้เครื่องมือ (tool calls) และเหตุการณ์ใน Runtime รวมถึงรายละเอียดความล้มเหลวต่างๆ ซึ่งเป็นบันทึกการตรวจสอบ (audit trail) ตามที่บทการเปิดใช้งานจริงกำหนดไว้
• งานหลัก (Parent tasks) ใช้สำหรับควบคุมผลลัพธ์ภาพรวม เช่น "รายชื่อผู้มีอำนาจซื้อฝ่ายการตลาด Q4" จะทำหน้าที่เป็นงานหลัก ส่วนขั้นตอนทั้ง 9 สเตจจะเป็นงานย่อย (sub-tasks)

หากคุณไม่อยากสร้างและมอบหมายงานทั้ง 9 สเตจด้วยตัวเอง หัวหน้า Crew ก็สามารถช่วยแตกงานหลักและกระจายงานย่อยในแต่ละสเตจให้ได้ตามที่อธิบายไว้ใน Sharkly Crews โดย Sharkly สามารถเริ่มต้นใช้งานได้ฟรี และการใช้งานโมเดลจะคิดตามแพ็กเกจของ Claude Code หรือ Codex ที่เชื่อมต่อกับ Runtime ของคุณอยู่แล้ว

สัญญาณความเคลื่อนไหว: ไม่มีลิงก์ต้นทาง ถือว่าไม่มีสัญญาณ

งานในขั้นตอนตรวจจับสัญญาณ (signals) จำเป็นต้องมีเกณฑ์การยอมรับงานที่เข้มงวดที่สุด โดย Treg พบว่า 16 จาก 27 แอคเคานต์มีการเปิดรับสมัครตำแหน่งงานสาย GTM ในช่วง 60 วันที่ผ่านมา แต่ประกาศรับสมัครงาน 355 จาก 675 รายการที่ดึงมาได้นั้นถูกปิดรับไปแล้ว

ข้อมูลการเปลี่ยนงานยิ่งแย่กว่านั้น จากการศึกษาของ Treg กับบุคคล 148 คนที่เพิ่งประกาศรับตำแหน่งใหม่ ฐานข้อมูลรายชื่อติดต่อเฉลี่ยแล้วระบุชื่อนายจ้างใหม่ผิดหรือไม่พบข้อมูลถึง 68% ของเวลาทั้งหมด ในขณะที่การอ่านข้อมูลโปรไฟล์แบบสดๆ (live profile read) สามารถค้นพบข้อมูลเพียง 49 จาก 148 คน แต่มีความถูกต้องแม่นยำถึง 47 คน ดังนั้นกฎจึงต้องเป็นไปตาม playbook อย่างเคร่งครัด นั่นคือ: หากไม่มีลิงก์ต้นทางที่พิสูจน์ได้ ห้ามส่งอีเมลติดต่อโดยเด็ดขาด

การทดสอบของ Treg ในเรื่องการตรวจจับการจ้างงานก่อนการระดมทุนไม่สามารถแยกกลุ่มเป้าหมายได้อย่างชัดเจน ดังนั้นจึงควรตรวจสอบสัญญาณเรื่องจังหวะเวลา (timing signal) กับสถิติการปิดการขายได้และไม่ได้ (wins and losses) ของคุณเองก่อนที่จะให้น้ำหนักกับสัญญาณนั้น

สิ่งที่ตัวเลขของ Treg บอก และสิ่งที่ตัวเลขไม่ได้บอก

Treg ได้เผยแพร่การเปรียบเทียบ 2 จุดที่น่าอ่านอย่างละเอียดไว้บนหน้า ค้นหาบุคคล (people-search) ของตนเอง

• ต้นทุนต่ออีเมลที่ถูกต้อง (Cost per correct email): จากลีด 100 รายในเดือนตุลาคม 2026 Treg ระบุว่าได้อีเมลสำหรับทำงานที่ถูกต้อง 92 อีเมล ด้วยต้นทุน $0.58 ต่อ 100 อีเมลที่ถูกต้อง เมื่อเทียบกับ Clay ที่ได้ 84 อีเมล ในราคา $3.77
• ความแม่นยำของเอเจนต์ (Agent accuracy): ในโจทย์การค้นหาลูกค้ามุ่งหวังแบบ B2B จากการทดสอบ People Search Bench จำนวน 119 งานของ LessieAI ทาง Treg ระบุว่า Claude Code ลำพังทำได้ 43% ในขณะที่ Claude Code ร่วมกับ Treg ทำได้ 78.2% โดยจัดทำรายชื่อเสร็จสิ้นในเวลาเพียง 1.4 นาที เทียบกับ 2.8 นาที

ตัวเลขเหล่านี้เป็นผลการทดสอบที่จัดทำโดยตัวผู้ให้บริการเองตามราคาทางการ ณ วันที่ทดสอบ และ Treg ยังระบุด้วยว่าความแตกต่างเพียงไม่กี่แถวนั้นถือว่าสูสีกัน ดังนั้นควรใช้ข้อมูลเหล่านี้เป็นแนวทางในการเลือกสิ่งที่จะนำไปทดสอบกับข้อมูล 50 แถวของคุณเอง

เปิดใช้งานอย่างเป็นระบบเหมือนการปล่อยซอฟต์แวร์

กฎสำคัญในบทสุดท้ายคือ: ห้ามปล่อยให้ระบบทำงานแบบอัตโนมัติอย่างสมบูรณ์ (autonomous) จนกว่าจะผ่านการรันแบบประกบคู่ขนาน (shadow mode) มาก่อน ซึ่งบนบอร์ดการทำงานจะแบ่งออกเป็น 3 เฟส

1. Shadow: ให้เอเจนต์รันงานข้อมูลทุกสเตจ แต่งานในขั้นตอน outreach จะต้องอยู่ในสถานะรอตรวจสอบเสมอและยังไม่มีการส่งอีเมลใดๆ
2. กลุ่มเป้าหมายขนาดเล็ก (Small segment): ทดสอบกับกลุ่มเป้าหมายระดับเดียว (one tier) เป็นเวลาหนึ่งสัปดาห์ คอยติดตามจำนวนแถวข้อมูลและต้นทุนต่อลีดที่ส่งถึงได้จริงเทียบกับไฟล์กฎระเบียบ
3. อัตโนมัติเฉพาะงานข้อมูล แต่ไม่ใช่การส่งอีเมล (Autonomy for data, never for sending): งานด้านข้อมูลสามารถรันตามตารางเวลาที่กำหนดผ่านระบบ Automation ได้ แต่การกดส่งจะต้องเป็นการตัดสินใจของมนุษย์เสมอ

หากต้องการติดตามการรันหลายๆ รายการพร้อมกัน สามารถดูเพิ่มเติมได้ที่ วิธีมอนิเตอร์ coding agents ที่ทำงานแบบขนานกัน

เริ่มต้นทีละสเตจ

การรัน GTM ใน Claude Code จะมีประสิทธิภาพเมื่อแต่ละสเตจมีขนาดเล็ก มีการควบคุมค่าใช้จ่าย มีผู้รับผิดชอบชัดเจน และบอร์ดระบุไว้อย่างชัดเจนว่าใครมีสิทธิ์สั่งหยุดการรันและใครเป็นผู้อนุมัติการส่ง เริ่มต้นจากจุดเล็กๆ: สร้างงานกำหนด ICP และงานไฟล์กฎระเบียบใน Sharkly รันการตรวจสอบจำนวนแบบฟรีก่อน แล้วจึงค่อยเริ่มเปิดสเตจที่มีค่าใช้จ่าย

คำถามที่พบบ่อย (FAQ)

GTM engineering คืออะไร?

Playbook ของ Treg ให้นิยามไว้ว่า คือการออกแบบ สร้าง และดูแลรักษาระบบที่แปลงกลยุทธ์ Go-to-Market ให้กลายเป็นเวิร์กโฟลว์ที่ทำซ้ำได้ ตั้งแต่การกำหนดกลุ่มเป้าหมาย (account targeting), การเพิ่มคุณค่าข้อมูลลีด (lead enrichment), การให้คะแนน (scoring), การติดตามสัญญาณความเคลื่อนไหว (signal monitoring), การค้นคว้าหาข้อมูล (research) ไปจนถึงการส่งต่อลีดขาเข้า (inbound routing) โดยมีการตรวจสอบโดยมนุษย์ก่อนที่จะส่งข้อความติดต่อภายนอก (outbound messages)

Treg มีค่าใช้จ่ายต่อลีดเท่าไร?

ในการรันของ Treg เองเมื่อวันที่ 23 กันยายน 2026 ลีดที่ผ่านการคัดกรองคุณสมบัติมีค่าใช้จ่ายอยู่ที่ $0.12 ต่อลีดที่ส่งอีเมลถึงได้จริง และคิดเป็นเงิน $2.33 สำหรับรายชื่อทั้งหมด โดยการเรียกใช้งานจะคิดค่าบริการตามปริมาณการใช้งานจริง และหากค้นหาไม่พบจะคิดค่าบริการ $0.00

AI Agent ควรส่ง Cold Email โดยไม่มีการตรวจสอบหรือไม่?

ไม่ควรอย่างยิ่ง Playbook ของ Treg ระบุไว้ชัดเจนว่าห้ามส่งข้อความใดๆ ที่มนุษย์ยังไม่ได้อ่าน และในการรันจริง มีประโยคเปิดที่ค้นคว้าโดยเอเจนต์เพียง 4 จาก 19 ประโยคเท่านั้นที่ได้คะแนนอยู่ในเกณฑ์พอใช้หรือดีขึ้นไป

กฎเกณฑ์สำหรับ GTM Agent ถูกเก็บไว้ที่ไหน?

เก็บไว้ในไฟล์กฎระเบียบ (rules file) ที่มีเกณฑ์ตัวเลขที่ชัดเจน เงื่อนไขการตัดทิ้ง เพดานค่าใช้จ่าย และระบุชื่อบุคคลผู้มีอำนาจสั่งหยุดการรันไว้อย่างชัดเจน โดยใน Sharkly คุณสามารถรวมสิ่งเหล่านี้เป็น Skill เพื่อให้เอเจนต์ทุกตัวอ่านกฎชุดเดียวกันได้

สามารถใช้งานร่วมกับ Codex แทน Claude Code ได้หรือไม่?

ได้ การตั้งค่าของ Treg รองรับทั้ง Claude Code, Codex และ Cursor และ Agent ของ Sharkly ก็สามารถรันบน Runtime ตัวใดก็ได้จากบนบอร์ดเดียวกัน สามารถดูขั้นตอนการตั้งค่าทั่วไปได้ที่ เครื่องมือจัดการงาน AI: มอบหมาย ติดตาม และตรวจสอบการทำงานของเอเจนต์ (AI task manager: assign, track, and review agent work)