Every few months, the industry mints a new term for software that supposedly thinks on its own. Right now that word is "Agentic AI." Vendors are quick to paste it across landing pages and pitch decks. But a label is only marketing copy until the system survives contact with your environment, your data, and your failure modes. The word itself tells you nothing about safety, reliability, or fit.
It is time to stop reading feature lists and start measuring capabilities.
The Label Problem
Sales engineers will show you dashboards, multi-model dropdown menus, and mobile access as proof of an "agentic" architecture. Those are interface choices, not behavioral guarantees. A product can look cutting-edge and still crumble the moment it needs to revise a plan after an API timeout.
What matters is whether the system actually behaves like an autonomous agent. Does it break work into steps? Does it touch real systems within strict boundaries? When something breaks, does it adapt, or does it simply fail and wait? Until you answer these questions with evidence specific to your stack, you are buying a concept, not a product.
Five Capability Tests That Actually Matter
I evaluate every agentic claim against five specific capabilities. For each one, I ask a simple triage question: is the behavior documented, verified in a pilot, or still unknown? Unknown is the default. The burden is on the product to prove otherwise.
Planning. Does the system decompose an ambiguous goal into ordered, verifiable steps? Anyone can generate a to-do list. The real test is handling a messy objective like "reduce our cloud spend by fifteen percent this quarter." A genuine agent maps out an audit of current usage, identifies idle resources, drafts rightsizing recommendations, and schedules change requests in the proper sequence. If it hands you a generic five-bullet essay and calls the job done, it is not planning. It is summarizing.
Tools. Does it act on real systems within a set scope? Calling a mock API in a polished demo is easy. Authenticating to your production CRM with least-privilege credentials, writing a record, and logging the transaction is hard. You need to know exactly which systems it touches, what keys it carries, and where the blast radius ends. Scope must be bounded. If the agent has write access to production by default, you do not have an agent. You have a liability.
Correction. Does it change its next move after a failure? This is where most prototypes die. When the third step returns a 503 error or a schema mismatch, does the agent loop forever, hallucinate a success message, or adjust its path? True correction means observing the failure, re-planning the remainder of the workflow, and executing a new path without dropping constraints. A retry loop wrapped in optimism is not correction.
Context. Does it keep constraints active across every step? Memory is not enough. If step one establishes a hard rule such as "do not exceed a five-hundred-dollar budget" or "exclude EU customer data," step seven cannot ignore that ceiling because the prompt context shifted. This applies to compliance rules, brand voice, approval hierarchies, and access controls. Context preservation is where long-context models and classical state management must meet.
Oversight. Can a human stop or resume the process? You need circuit breakers that are granular, not just a kill switch on the virtual machine. Can someone inspect the plan after step two and approve step three? If an external dependency fails, can a human fix it and resume the workflow without losing state? Oversight is not an audit log you read after disaster strikes. It is a live mechanism for intervention.
Evidence Beats Checkboxes
A demo is not a reliability rate. A checkbox on a vendor comparison sheet is not proof. When an account executive says the product "revises after test failure," your next move is to ask for the evidence card.
An evidence card replaces the checkbox with specificity. It looks like this:
- Capability: Correction
- Claim: Revises after a test failure
- Evidence: Pending controlled fixture
- Owner: Developer-experience team
- Stop if: Revision changes an approved interface
รูปแบบนี้ช่วยบังคับให้เกิดความชัดเจน มันแยกคำกล่าวอ้างทางการตลาดออกจากหลักฐานการพิสูจน์ มันกำหนดผู้รับผิดชอบ เพื่อที่ว่าเมื่อ agent ทำอินเทอร์เฟซที่ได้รับอนุมัติพังระหว่างพยายามแก้ไข คุณจะรู้ได้ทันทีว่าทีมไหนต้องถูกเรียกตัว หากไม่มีผู้รับผิดชอบ ก็จะไม่มีความรับผิดชอบ หากไม่มีเงื่อนไขการหยุด (stop conditions) ก็จะไม่มีราวกั้นความปลอดภัย
ก่อนที่คุณจะเริ่มโครงการนำร่อง (pilot) ใดๆ ให้กำหนดสามสิ่งนี้เป็นลายลักษณ์อักษร อย่างแรกคือ งานของคุณ (tasks) ซึ่งควรมาจากตรรกะทางธุรกิจจริง ไม่ใช่จากเกณฑ์มาตรฐานแบบสังเคราะห์ (synthetic benchmarks) อย่างที่สองคือ การทดสอบความล้มเหลว (failure tests) เช่น การยกเลิก API key ระหว่างการทำงาน, การฉีด JSON response ที่ผิดรูปแบบ หรือการเพิ่มค่า latency ที่คาดหวังเป็นสองเท่า อย่างที่สามคือ เงื่อนไขการหยุด (stop conditions) ซึ่งต้องเป็นแบบอัตโนมัติ ไม่ใช่ปุ่มกดฉุกเฉินแบบแมนนวลที่คุณได้แต่หวังว่าจะมีใครสักคนสังเกตเห็น
วิธีการซักถามคำกล่าวอ้างของผู้ให้บริการ (Vendor)
OpenAI เสนอว่า agent จำเป็นต้องมีองค์ประกอบ 5 อย่าง ได้แก่ models, tools, instructions, guardrails และ human intervention คุณสามารถใช้รายการนี้เป็นชุดคำศัพท์ในการตั้งคำถามกับผู้ให้บริการ โดยไม่จำเป็นต้องยอมรับสถาปัตยกรรมเฉพาะของพวกเขา
ถามว่า model ไหนทำหน้าที่วางแผน (planning) เทียบกับการสร้างข้อมูล (generation) เพียงอย่างเดียว ถามว่าสิทธิ์การใช้งาน tool ตัวไหนที่ถูกกำหนดไว้ตายตัว (hardcoded) และตัวไหนที่เป็นแบบไดนามิก ถามว่า guardrails ถูกบังคับใช้ที่ไหน ระหว่างในชั้น prompt หรือใน orchestration engine ถามว่า human intervention เป็นจุดตรวจสอบ (checkpoint) ที่ติดตั้งมาในตัว หรือเป็นเพียงอีเมลแจ้งเตือนหลังเกิดเรื่อง (post-mortem) ที่ส่งมาหลังจาก agent ทำฐานข้อมูลของคุณพังไปแล้ว คุณไม่ได้กำลังเลือกซื้อ stack ของ OpenAI แต่คุณกำลังใช้ framework ของพวกเขาเพื่อเปิดโปงช่องโหว่ของเจ้าอื่น
MonkeyCode มีทางเลือกแบบ open-source และเวอร์ชัน cloud ฟรี การผสมผสานนี้ทำให้การเริ่มโครงการนำร่องมีราคาถูก แต่การเริ่มต้นที่ราคาถูกไม่ได้หมายถึงความสำเร็จที่ได้รับการพิสูจน์แล้ว ส่วนที่ไม่รู้จักของระบบจะยังคงเป็นสิ่งที่ไม่รู้จัก จนกว่าคุณจะรันงานของคุณเองบนโครงสร้างพื้นฐาน (infrastructure) ของคุณเอง อย่าปล่อยให้ตั๋วราคาศูนย์ดอลลาร์หลอกให้คุณคิดว่าคำถามที่ยากๆ ได้รับคำตอบแล้ว
กฎการซื้อที่ช่วยประหยัดงบประมาณ
กฎของผมในการขยายโครงการนำร่องแบบ agentic ไปสู่การใช้งานจริง (production) นั้นง่ายมาก ผมจะเพิ่มขอบเขตและงบประมาณก็ต่อเมื่อความสามารถที่สำคัญได้รับการพิสูจน์แล้ว และมีผู้รับผิดชอบที่ชัดเจนเมื่อเกิดความล้มเหลว ไม่ใช่แค่สไลด์ใน roadmap ไม่ใช่แค่คิวในระบบ support ticket คำว่า "หลักฐาน" หมายถึง logs จากสภาพแวดล้อมของคุณ ส่วน "ผู้รับผิดชอบ" หมายถึงบุคคลที่มีชื่อระบุไว้ชัดเจนและพร้อมรับผิดชอบต่อรูปแบบความล้มเหลวนั้นๆ
หากผู้ให้บริการไม่สามารถแสดงหลักฐานให้คุณเห็น หรือหากทีมภายในของคุณไม่สามารถระบุผู้รับผิดชอบได้ แสดงว่าคุณยังไม่พร้อมที่จะขยายโครงการ คุณแค่พร้อมที่จะทดสอบต่อไป
สิ่งที่ควรจำ: คำว่า "Agentic" คือเสียงปืนปล่อยตัวสำหรับการประเมินของคุณ มันไม่ใช่เส้นชัย จงใช้มันเป็นสิ่งกระตุ้นให้ตั้งคำถามที่ยากขึ้น รันโครงการนำร่องที่เข้มงวดขึ้น และเรียกร้องหลักฐานที่มีความหมายต่อองค์กรของคุณ หากผลิตภัณฑ์ไม่สามารถผ่านการทดสอบความสามารถทั้งห้าในพื้นที่ของคุณ ด้วยความล้มเหลวในแบบของคุณ มันก็ไม่ใช่ agentic ที่แท้จริง มันเป็นเพียงแค่เดโมอีกตัวหนึ่งเท่านั้น
Source: https://dev.to/bestbee/is-it-really-agentic-ai-use-a-five-capability-product-gate-1c0h
Optional learning community: https://t.me/GyaanSetuAi