Tool, Skill หรือ Subagent: เมื่อ AI agent บวมจนพัง Anthropic ลดมันลงได้อย่างไร

AI agent ที่ใช้งานจริงในองค์กรมักไม่ได้ตายเพราะโมเดลไม่เก่ง แต่ตายเพราะสะสมความสามารถทีละชิ้น มี tool ใหม่ทุกสัปดาห์ subagent ใหม่ทุกเดือน และบรรทัดใน system prompt งอกขึ้นเรื่อยๆ จนวันหนึ่งทุกอย่างพังพร้อมกัน Will จากทีม Applied AI ของ Anthropic นำเคส inventory agent ชื่อ Stock Pilot มาเปิดให้ดูในงาน Code with Claude London ระบบเดิมมี system prompt ยาว 400 บรรทัด มี 12 tools มี 3 subagents และ eval ตกลงเหลือ 62% ทั้งที่เคยทำงานได้ดี

คลิปของ Claude นำเสนอกรอบการตัดสินใจที่ทีม Anthropic ใช้จริงว่าเมื่อไหร่ควรใช้ tool เมื่อไหร่ควรใช้ skill และเมื่อไหร่ควรใช้ subagent พร้อมขั้นตอน refactor agent ที่บวมเกินไปด้วยกระบวนการที่ทีมเรียกว่า hill climbing on evals สุดท้าย eval score กลับขึ้นมาที่ 92% ขณะที่ token usage ลดลงมากและ latency ดีขึ้น เนื้อหานี้สรุปจากคลิปดังกล่าว เพื่อให้นักพัฒนาไทยที่กำลังสร้าง AI agent ของจริงนำกรอบนี้ไปใช้ได้ทันที

1. ปัญหาของ agent ที่โตเกินไป: เคส Stock Pilot

Stock Pilot เป็น inventory management agent ที่ออกแบบสำหรับ retailer ขนาดกลาง ทำงานหลายอย่างพร้อมกัน ได้แก่ flag stock ระดับต่ำ forecast ความต้องการ เลือก supplier ออก PO และเขียน weekly report ให้พนักงาน ในคลิปของ Claude ระบุว่าแต่ละความสามารถไม่ได้ซับซ้อนในตัวเอง ปัญหาอยู่ที่การ bolt-on capability เพิ่มเข้าไปเรื่อยๆ โดยไม่ปรับ architecture เลย

สถาปัตยกรรมเดิมของ Stock Pilot มี orchestrator ตัวเดียวอยู่ด้านบน ใต้นั้นคือ system prompt ยาว 400 บรรทัด ตามด้วย 12 tools โดย 3 ใน 12 เป็น wrapper ที่หุ้ม subagent ซึ่งมี context window แยกของตัวเองอีกชั้น เมื่อต้องเพิ่ม forecasting capability ทีมก็เพิ่ม subagent ใหม่ พอต้องเพิ่ม report writing ก็เพิ่มอีก subagent ส่วนนโยบายต่างๆ ของระบบ inventory ทีม append ลงใน system prompt ไปเรื่อยๆ จนกลายเป็น 400 บรรทัด

Will ชี้ว่ารูปแบบนี้พบบ่อยมากทั้งกับลูกค้าและกับทีม Anthropic เอง อาการที่ตามมาคือ regression ในจุดที่ agent เคยทำได้ดี ส่วน eval ของระบบใหม่เปิดมาที่ 62% ผ่าน 7 จาก 12 task ทั้งที่ก่อนหน้านี้เคยทำได้ราว 83% โดยตัวเลข 17% failure ยอมรับไม่ได้ในงาน manufacturing เพราะต้นทุนแพงมาก

2. Eval methodology: 12 task 5 grader deterministic + non-deterministic

ก่อนจะวิ่งไป refactor อะไร ทีม Anthropic จะ baseline ด้วย eval ก่อน ในคลิปของ Claude อธิบายว่า Stock Pilot ใช้ 12 task แบ่งเป็นสองตระกูล ตระกูลแรกคือ eval ID ที่ขึ้นต้นด้วย R ย่อมาจาก regression task เป็น single-turn ที่ใกล้เคียงการใช้งานจริง ตระกูลที่สองคือ eval ID ขึ้นต้นด้วย F ย่อมาจาก failure mode เป็น multi-turn task ที่ซับซ้อนกว่า

ส่วน grader มีทั้งหมด 5 ประเภท แบ่งเป็นสองกลุ่ม กลุ่มแรกคือ deterministic grader ที่วัดสิ่งที่นับได้ตรงๆ ได้แก่ จำนวน token ที่ใช้ latency และ turn count ตลอดการทำ task กลุ่มที่สองคือ non-deterministic grader ใช้แนวคิด LLM-as-a-judge เพื่อประเมินคุณภาพที่นับเป็นตัวเลขตรงๆ ไม่ได้ เช่น personality tone style และ output quality

Note: การมีทั้ง deterministic และ non-deterministic grader คู่กันคือกุญแจสำคัญ เพราะถ้าวัดเฉพาะ accuracy อย่างเดียว ระบบที่ตอบถูกแต่เดินอ้อมแบบ winding path จะถูกมองว่า "ผ่าน" ทั้งที่จริงๆ แล้วมีปัญหา

Will เน้นว่า eval แบบนี้ไม่ใช่เครื่องมือตรวจครั้งเดียว แต่เป็นเครื่องมือสำหรับ hill climb ระบบไปเรื่อยๆ คือรัน baseline → ปรับ architecture → รันใหม่ → ดูว่าตัวเลขขยับขึ้นหรือลง → ปรับต่อ การที่ทีม Applied AI เริ่มจาก eval ก่อนเสมอ ทำให้ทุกการตัดสินใจ refactor มีตัวเลขรองรับ ไม่ใช่ feeling

3. Failure mode analysis: F1 F2 R8 คืออะไรและพังเพราะอะไร

ในคลิปของ Claude เจาะ failure mode สามตัวที่สะท้อนปัญหาคนละแบบกัน ซึ่งจะกลายเป็นกรณีศึกษาสำคัญสำหรับการตัดสินใจเลือก primitives ในขั้นต่อไป

F1: daily low-stock sweep — ปัญหา efficiency

F1 จำลองการสแกน inventory ทั้งหมดเพื่อหาสินค้าที่ stock ต่ำ ซึ่งเป็นงานพื้นฐานมากของ inventory agent ในคลิประบุว่า task นี้ fail ไม่ใช่เพราะ agent ตอบผิด แต่เพราะ agent เดินอ้อมแบบ winding path คือไปถึงคำตอบที่ถูกต้องด้วยวิธีที่ไม่มีประสิทธิภาพ deterministic grader จับตัวเลข token และ latency แล้วตัดสินว่า fail

F2: ordering ภายใต้ promotion — ปัญหา communication ระหว่าง subagent กับ orchestrator

F2 ประเมินกระบวนการสั่งซื้อในช่วง promotion package พิเศษ Will ชี้ว่า subagent ที่รับ task นี้ทำงานถูกในส่วนของมันเอง แต่ปัญหาเกิดที่ communication breakdown ระหว่าง subagent กับ orchestrator ข้อมูลถูกแปลหรือสรุปเพี้ยนตอนส่งกลับ Will บอกว่าจุดนี้เป็น failure point ที่พบบ่อยมากในระบบของลูกค้าที่มี subagent หลายตัว และ communication contract ระหว่าง orchestrator กับ subagent ต้องแม่นมาก ไม่อย่างนั้นข้อมูลจะหายกลางทาง

R8: forecasting ในช่วง promotion month — context problem ไม่ใช่ model problem

R8 คือกรณีที่ลึกที่สุดและเป็นบทเรียนสำคัญที่สุดของคลิป task นี้ให้ agent คำนวณ forecast ในเดือนที่มี promotion ในคลิปแสดงให้เห็นจาก simulated terminal ว่า agent ดึง forecasting baseline ถูก คือ 12 units/day และดึง promotion multiplier ถูก คือ 3.1x แต่พอเข้าสู่ขั้นตอนคำนวณจริง agent กลับเอา 1.35 มาคูณแทน ทั้งที่ตัวเลขนี้ไม่ได้อยู่ในข้อมูลตั้งต้นเลย

Will ระบุชัดว่า "this isn't a model problem. It's a context problem" เพราะ system prompt ยาว 400 บรรทัดมี policy สองชุดอยู่คนละมุมของ prompt และขัดแย้งกันเอง โมเดลจึงสับสนและ hallucinate ตัวเลขขึ้นมาเอง ตามที่ Will ชี้ การเอาความรู้ทั้งหมดอัดลงใน system prompt ไม่ใช่การช่วยโมเดล แต่เป็นการสร้างกับดักให้โมเดลขัดแย้งกับตัวเอง

Tip: เวลา agent ตอบผิดอย่างมั่นใจในงานที่ data ตั้งต้นถูก ปัญหาส่วนใหญ่ไม่ใช่ที่โมเดล แต่อยู่ที่ context ที่ห่อโมเดลไว้ การแยก policy ออกจาก system prompt ไปอยู่ใน skill หรือ tool ที่เรียกเฉพาะตอนต้องใช้ มักแก้ปัญหานี้ได้ตรงจุดกว่า

4. Decision framework: เมื่อไหร่ใช้ Tool, Skill, Subagent

นี่คือแก่นของ workshop ในคลิป ซึ่ง Will นำเสนอเป็นกรอบการตัดสินใจสามเสาในการเลือก primitives ของ agent โดยแต่ละเสามีจังหวะใช้งานและ anti-pattern ของตัวเอง

4.1 Tool — ลำดับการเลือกที่ทีม Anthropic ใช้

Will บอกว่าทีม Anthropic มี mental model ที่ใช้ร่วมกันเสมอ คือ เริ่มจาก humanlike primitives ก่อน เหมือนที่มนุษย์ใช้ทำงานทุกวัน ได้แก่ การเปิดไฟล์ใน file system การเปิด browser การทำ web search การเขียนและรันโค้ด การจดบันทึก to-do list Claude Code เป็น coding agent ที่ทำงานได้ดีไม่ใช่เพราะมี tool พิเศษมหัศจรรย์ แต่เพราะ Claude เข้าถึง primitives เหล่านี้ทั้งหมดได้เหมือนคน

ในคลิปยกตัวอย่าง document analysis ซึ่งเป็นงานที่ทีมหลายแห่งสร้างเป็น tool พิเศษกัน Will ชี้ว่าถ้าต้องวิเคราะห์ CSV หรือ Excel sheet หลายไฟล์ การให้ bash tool แล้วให้โมเดลเขียน Python script สั้นๆ มาวิเคราะห์ ดีกว่าการอัด CSV ทั้งไฟล์เข้าไปใน context window มาก เพราะ token usage ลดลงมาก และโมเดลใช้ collective brain power ไปกับการตัดสินใจ ไม่ใช่การจำตัวเลขทุกแถว

ลำดับการเลือก tool ที่ทีม Anthropic ใช้คือ

1. เริ่มจาก Claude Code humanlike primitives ก่อน ได้แก่ bash code execution, file system, web search, to-do list ใน Claude Managed Agents สิ่งเหล่านี้ติดมาให้ default ไม่ต้องสร้างเอง
2. เพิ่ม custom local tools เฉพาะตอนที่ primitives ไม่พอจริงๆ เช่น tool ที่เรียก API ภายในขององค์กรที่ไม่มีทางใช้ bash ทำได้
3. MCP เป็นทางเลือกสุดท้าย ไม่ใช่ทางเลือกแรก ใช้เฉพาะเมื่อมี tool ที่ต้องแชร์ระหว่างหลาย client หรือหลาย agent และต้องมี governance ส่วนกลาง

ในคลิปย้ำหลายครั้งว่าลูกค้าจำนวนมากวิ่งไปหา MCP เป็นทางเลือกแรก แล้วจบลงด้วย MCP server หลายตัวที่ทับซ้อนกันและสร้าง context pollution Will ระบุว่าข้อเสียอย่างหนึ่งของ MCP คือกินที่ใน context window ไปเยอะมาก ทำให้หลายเคสการใช้ code execution ผ่าน CLI หรือเรียก API ผ่านโค้ดโดยตรงยืดหยุ่นกว่า และไม่ต้อง commit กับ MCP ตั้งแต่ต้น

Anti-pattern ที่พบบ่อย: สร้าง custom tool ใหม่ทุกครั้งที่ต้องการ capability ใหม่ ทั้งที่ความสามารถนั้น Claude ทำได้ด้วย bash + code execution อยู่แล้ว ผลลัพธ์คือ tool list ยาวขึ้นเรื่อยๆ จนโมเดลสับสนเองว่าจะใช้ tool ไหน

4.2 Skill — progressive disclosure ของข้อมูล

ในคลิปของ Claude นิยาม skill ว่าเป็น packaged composable information ที่ Claude ดึงเข้ามาใน context เฉพาะตอนที่ต้องใช้ ไม่ใช่ข้อมูลที่ Claude ต้องถือไว้ใน mind ตลอดเวลา หลักการนี้เรียกว่า progressive disclosure

ความแตกต่างระหว่าง system prompt กับ skill มีกฎที่ Will วางไว้ชัด: system prompt ใส่เฉพาะข้อมูลที่ Claude ต้องรู้ทุก task ที่ได้รับ ส่วน skill ใส่ข้อมูลที่ Claude จะต้องใช้บางครั้ง ไม่ใช่ทุกครั้ง ตัวอย่างเช่น forecasting guideline ไม่จำเป็นต้องอยู่ใน system prompt เพราะ Claude ไม่ได้ทำ forecast ทุก task แต่เมื่อ user ขอ forecast Claude จะรู้เองว่าต้องใช้ skill ตัวไหนและดึงเข้ามา

ในเคส Stock Pilot ทีมย้าย business logic จำนวนมากออกจาก system prompt 400 บรรทัด แล้วแพ็คเป็น skill ไว้ ผลลัพธ์คือ system prompt เหลือเพียง 15 บรรทัด และ context window ไม่ต้องแบก policy ที่ไม่ได้ใช้ จุดนี้สำคัญเป็นพิเศษ เพราะ R8 fail จาก policy สองชุดใน system prompt ที่ขัดแย้งกันเอง เมื่อย้ายไปเป็น skill Claude จึงดึงเฉพาะ policy ที่เกี่ยวกับ task นั้นๆ และไม่มีโอกาส conflict อีก

Anti-pattern ที่พบบ่อย: เห็น requirement ใหม่จากธุรกิจแล้ว append ลงท้าย system prompt ไปเรื่อยๆ ซึ่งเป็นการสะสม technical debt แบบเงียบๆ จนวันหนึ่ง system prompt ยาวจน performance ตก แต่ไม่มีใครรู้ว่าเกิดอะไรขึ้น

4.3 Subagent — สำหรับ parallelize หรือ fresh-mind review

Will นำเสนอจังหวะที่เหมาะกับการใช้ subagent มีเพียงสองกรณีเท่านั้น

กรณีแรก: ต้องการ throw a lot of Claude ใส่ปัญหาเดียวกัน เช่น deep research, web search หลายมุม, หรือ code base exploration ที่ต้องการให้ Claude หลาย instance วิ่งคู่ขนานกัน เพื่อให้ครอบคลุมและเร็วขึ้น

กรณีที่สอง: ต้องการ fresh mind มาดูปัญหา Will ใช้ตัวอย่างของตัวเองในฐานะ developer ว่าไม่อยากเป็นทั้งคนเขียนโค้ดและคนรีวิวโค้ดของตัวเองในเวลาเดียวกัน ในกรณีของ Claude Code การให้ Claude หนึ่ง instance เขียน code แล้วให้ Claude อีก instance ที่ไม่มี context ของคนเขียนมา review เป็น use case ที่เหมาะกับ subagent อย่างยิ่ง

ในเคส Stock Pilot ทีมเก็บ subagent ไว้เฉพาะตัวเดียวคือ forecasting subagent เพราะต้องการแยก mind ของ Claude ที่ทำงาน forecast ออกจาก Claude ที่คุยกับ customer เพื่อไม่ให้ context ฝั่ง customer มา distort กระบวนการ forecast ส่วน subagent อื่นที่เคยมี ทีมแทนด้วย primitive tools และ skill ทั้งหมด

อีกประเด็นสำคัญในคลิปคือ Claude Managed Agents มี native capability ที่เรียกว่า callable agents ต่างจากการห่อ subagent เป็น tool เพราะ callable agents ทำให้ logging และ observability ครบใน session เดียว ทีม Anthropic จึงเปลี่ยนจาก wrapper-as-tool ไปเป็น native callable agents เพื่อแก้ปัญหา F2 ที่เกี่ยวกับ communication breakdown ระหว่าง subagent กับ orchestrator

Anti-pattern ที่พบบ่อย: ใช้ subagent ทันทีที่งานเริ่มซับซ้อน ทั้งที่ frontier model ในปัจจุบันจัดการ context ขนาดใหญ่ได้ดีขึ้นมาก Will ระบุว่าทีมเห็นลูกค้าจำนวนมาก consolidate subagent กลับเข้า main agent เพราะโมเดลเก่งพอที่จะ reason cross-context โดยตรง จึงลด overhead ของ communication contract ระหว่าง agent ลงได้

5. Refactor steps: hill climbing ด้วย eval

หลังได้กรอบตัดสินใจ 3 primitive แล้ว ทีมเริ่ม refactor Stock Pilot เป็นลำดับขั้น โดยทุกขั้นมี eval ตามท้ายเพื่อยืนยันว่าการเปลี่ยนแปลงนั้นดัน metric ไปทางที่ต้องการจริง ในคลิประบุว่าทีมใช้ Claude Code ที่รันด้วย Opus 4.7 effort level extra high เป็นเครื่องมือช่วย refactor และ triage eval results

ขั้น 1: migrate จาก Messages API ไป Claude Managed Agents

ทีมสร้าง Stock Pilot version แรกบน Messages API โดยตรง จึงต้องจัดการ agent harness, scaling, security, memory เอง การ migrate ไป Claude Managed Agents ทำให้ทีมโยน infrastructure overhead เหล่านี้ออกไป แล้วโฟกัสกับ architecture decision เพียงอย่างเดียว Will บอกว่านี่คือเหตุผลที่เขาเลือก CMA คือ "I just wanted to worry about building the best thing possible and not all the messiness that comes with it"

ขั้น 2: ตัด system prompt 400 บรรทัดเหลือ 15 บรรทัดด้วย skill

ทีมขอให้ Claude วิเคราะห์ system prompt แล้วระบุว่าส่วนไหนเป็น "policy เฉพาะ task" ที่ควรย้ายไปเป็น skill ผลคือทีมย้าย business logic ออกจาก prompt เกือบทั้งหมด เหลือไว้ใน prompt เฉพาะข้อมูลที่ Claude ต้องรู้ทุก task เช่น identity และ guard rails พื้นฐาน

ขั้น 3: ลด 12 tools เหลือ 3 tools (bash, read, write) ด้วย code execution primitive

ในคลิประบุว่าทีมตัด tool เกือบทั้งหมดออก แล้วเปลี่ยนเป็น bash + read + write ที่ติดมากับ Claude Managed Agents เป็น default เมื่อ agent เริ่มทำงาน ระบบจะ sync ข้อมูลเข้ามาใน CMA environment แล้วให้ Claude ใช้ bash เขียน Python script วิเคราะห์เอง

ผลลัพธ์ที่จับได้จาก eval หลังขั้นนี้คือ token usage ลดจาก 200,000+ ลงไปมาก cost ลดตาม และ latency ก็ลดเช่นกัน เพราะแทนที่จะอัด CSV ทั้งไฟล์เข้า context Claude เขียนสคริปต์อ่านเฉพาะส่วนที่ต้องใช้

ขั้น 4: เหลือ subagent เฉพาะ forecasting และย้ายเป็น CMA callable agents

ทีมตัด 3 subagents เดิมออกไป 2 ตัว เพราะงานนั้นทำผ่าน primitive tools และ skill ได้แล้ว เหลือ forecasting subagent เพียงตัวเดียว แล้วเปลี่ยนจาก wrapper-as-tool ไปเป็น CMA native callable agents เพื่อแก้ communication breakdown ที่ F2 จับได้

6. ผลลัพธ์: eval 62% → 92% และ architecture ที่เบาลงทั้งหมด

หลัง refactor ครบทั้ง 4 ขั้น Will สรุปตัวเลข before/after ของ Stock Pilot ไว้ดังนี้

• System prompt: 400 บรรทัด → 15 บรรทัด
• Tools: 12 ตัว → 3 ตัว (bash, read, write)
• Subagents: 3 ตัว → 1 ตัว (forecasting) บน CMA callable agents
• Eval score: 62% → 92%
• Token usage: ลดลงดราม่า (จาก 200,000+ ลงไปมาก)
• Cost: ลดลงตาม token
• Latency: ลดลง แม้ turn count จะใกล้เคียงเดิม

Note: Will ระบุว่า turn count ที่ใกล้เคียงเดิมเป็นเรื่องปกติ เพราะการให้โมเดลเขียนโค้ดและรันโค้ดทำให้มี turn สำหรับ reason เพิ่มขึ้น แต่ token ต่อ turn ลดลงมหาศาล ทำให้ cost รวมยังลด

ในคลิปย้ำว่ามีข้อดีสำคัญอีกข้อที่ไม่ค่อยมีคนพูดถึง เมื่อ architecture ตั้งอยู่บน primitives ที่นิ่ง (file system, code execution, ฯลฯ) ทีมสามารถ "drop in better Claude" ได้ทุกครั้งที่ Anthropic ปล่อยโมเดลใหม่ โดยไม่ต้องเขียน tool ใหม่หรือออกแบบ agent ใหม่ Will เปรียบเทียบว่าเหมือนคนคนหนึ่งกลับจากงาน conference โต๊ะทำงานและ tool ยังเหมือนเดิม แต่สมองใหญ่ขึ้น ทำงานเก่งขึ้น ส่วน agent ก็ยังทำงานในรูปแบบเดิม

7. สามบทเรียนหลักจาก Will สำหรับนักพัฒนา agent

Will สรุปประเด็นที่ต้องการให้ผู้ฟังกลับไปลองเอง 3 ข้อที่อยู่ในแนวทางของทีม Applied AI ของ Anthropic

1. เริ่มจาก single loop ที่มี simple primitives ก่อนเสมอ ได้แก่ file system, code execution, web search, to-do list หลักการคือคิดว่า agent เป็นเหมือนคนที่นั่งทำงานหน้าคอมหนึ่งเครื่อง มี tool พื้นฐานเท่ากับมนุษย์ ก่อนจะ add custom tool ใดๆ ต้องตอบให้ได้ก่อนว่า primitives เดิมทำไม่ได้จริงๆ ใช่ไหม

2. ใช้ progressive disclosure ผ่าน skill แทนการอัดข้อมูลใน system prompt ถ้าข้อมูลไม่ต้องใช้ทุก task ที่โมเดลรับมา ข้อมูลนั้นควรเป็น skill ไม่ใช่ส่วนของ system prompt การแยกแบบนี้ลดทั้ง token usage และความเสี่ยงที่ policy จะขัดแย้งกันเอง

3. Hill climb ด้วย eval ที่ครอบคลุมสิ่งที่แคร์จริง ทุกครั้งที่ขยาย capability ของ agent ต้องเช็กว่า eval suite ครอบคลุม metric ที่ต้องการให้ดีขึ้น (deterministic เช่น token, latency, turn count + non-deterministic เช่น tone, output quality) แล้วใช้ eval เป็นเข็มทิศนำทาง refactor ไม่ใช่ตัดสินด้วย gut feeling

Tip: สำหรับทีมไทยที่กำลังขึ้น agent ตัวแรกกับลูกค้าจริง ลำดับงานที่นำมาประยุกต์ได้ทันทีคือ (1) ตั้ง eval suite ที่มี deterministic + non-deterministic grader ก่อนเขียน feature ใหม่ทุกตัว, (2) ใช้ CMA หรือ Claude Code primitives เป็นจุดตั้งต้น, (3) ทุก requirement ใหม่ให้ถามตัวเองว่ามันคือ tool, skill หรือ subagent อย่าเหมารวมเป็น system prompt

เคส Stock Pilot สะท้อนว่า agent ที่บวมจนพังไม่ใช่เพราะคนสร้างไม่เก่ง แต่เพราะทีมไม่ได้ stop-the-line เพื่อ refactor ตามจังหวะที่ requirement เพิ่ม การมี framework การตัดสินใจที่ชัดเจนเรื่อง tool/skill/subagent บวกกับ eval ที่ run ทุกครั้งหลังการเปลี่ยนแปลง ทำให้การขยาย agent ในระยะยาวยั่งยืนขึ้น ไม่ใช่การสะสมหนี้ที่จะระเบิดในวันใดวันหนึ่ง

เนื้อหานี้สรุปจากคลิป Tool, skill, or subagent? Decomposing an agent that outgrew its prompt ของช่อง Claude (Anthropic) ใน workshop Code with Claude London โดย Will จากทีม Applied AI

ที่มา: Claude — Tool, skill, or subagent? Decomposing an agent that outgrew its prompt