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

ಈ ಫಾರ್ಮ್ಯಾಟ್ ಸ್ಪಷ್ಟತೆಯನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸುತ್ತದೆ. ಇದು ಮಾರ್ಕೆಟಿಂಗ್ ವಾದಗಳನ್ನು ಪುರಾವೆಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಇದು ಮಾಲೀಕತ್ವವನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಏಜೆಂಟ್ ತನ್ನ ಪರಿಷ್ಕರಣೆಯ ಪ್ರಯತ್ನದ ಸಮಯದಲ್ಲಿ ಅನುಮೋದಿತ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹಾಳುಮಾಡಿದಾಗ, ಯಾವ ತಂಡಕ್ಕೆ ಮಾಹಿತಿ ನೀಡಬೇಕೆಂದು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿಯುತ್ತದೆ. ಮಾಲೀಕನಿಲ್ಲದಿದ್ದರೆ, ಜವಾಬ್ದಾರಿ ಇರುವುದಿಲ್ಲ. ನಿಲ್ಲಿಸುವ ಷರತ್ತುಗಳಿಲ್ಲದಿದ್ದರೆ, ಸುರಕ್ಷತಾ ತಡೆಗೋಡೆಯಿರುವುದಿಲ್ಲ.

ನೀವು ಯಾವುದೇ ಪೈಲಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ಮೂರು ವಿಷಯಗಳನ್ನು ಲಿಖಿತ ರೂಪದಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಿ. ಮೊದಲನೆಯದಾಗಿ, ನಿಮ್ಮ ಕಾರ್ಯಗಳು (tasks). ಇವು ಸಿಂಥೆಟಿಕ್ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳಿಂದಲ್ಲದೆ, ನೈಜ ವ್ಯವಹಾರದ ತರ್ಕದಿಂದ (business logic) ಹೊರಬಂದಿರಬೇಕು. ಎರಡನೆಯದಾಗಿ, ನಿಮ್ಮ ವೈಫಲ್ಯ ಪರೀಕ್ಷೆಗಳು (failure tests). ಕಾರ್ಯವು ನಡೆಯುತ್ತಿರುವ ಮಧ್ಯದಲ್ಲಿ API ಕೀಯನ್ನು ರದ್ದುಗೊಳಿಸಿ, ತಪ್ಪಾದ JSON ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು (malformed JSON response) ಸೇರಿಸಿ ಅಥವಾ ನಿರೀಕ್ಷಿತ ಲ್ಯಾಟೆನ್ಸಿಯನ್ನು (latency) ದ್ವಿಗುಣಗೊಳಿಸಿ. ಮೂರನೆಯದಾಗಿ, ನಿಮ್ಮ ನಿಲ್ಲಿಸುವ ಷರತ್ತುಗಳು (stop conditions). ಇವು ಸ್ವಯಂಚಾಲಿತವಾಗಿರಬೇಕು, ಯಾರಾದರೂ ಗಮನಿಸುತ್ತಾರೆ ಎಂದು ನೀವು ಭಾವಿಸುವ ಮ್ಯಾನುಯಲ್ ಪ್ಯಾನಿಕ್ ಬಟನ್ ಆಗಿರಬಾರದು.

ವೆಂಡರ್ ವಾದಗಳನ್ನು ಹೇಗೆ ಪ್ರಶ್ನಿಸುವುದು ಹೇಗೆ

ಏಜೆಂಟ್‌ಗಳಿಗೆ ಐದು ಘಟಕಗಳು ಬೇಕು ಎಂದು OpenAI ಪ್ರಸ್ತಾಪಿಸುತ್ತದೆ: ಮಾಡೆಲ್‌ಗಳು, ಪರಿಕರಗಳು, ಸೂಚನೆಗಳು, ಗಾರ್ಡ್‌ರೈಲ್ಸ್ ಮತ್ತು ಮಾನವ ಹಸ್ತಕ್ಷೇಪ. ನೀವು ಅವರ ನಿರ್ದಿಷ್ಟ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳದೆ, ವೆಂಡರ್‌ಗಳನ್ನು ಪ್ರಶ್ನಿಸಲು ಈ ಪಟ್ಟಿಯನ್ನು ಒಂದು ಶಬ್ದಕೋಶವಾಗಿ ಬಳಸಬಹುದು.

ಯಾವ ಮಾಡೆಲ್ ಕೇವಲ ಜನರೇಷನ್ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಪ್ಲಾನಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಕೇಳಿ. ಯಾವ ಪರಿಕರದ ಅನುಮತಿಗಳು (tool permissions) ಹಾರ್ಡ್‌ಕೋಡೆಡ್ ಆಗಿವೆ ಮತ್ತು ಯಾವುವು ಡೈನಾಮಿಕ್ ಆಗಿವೆ ಎಂದು ಕೇಳಿ. ಗಾರ್ಡ್‌ರೈಲ್ಸ್‌ಗಳನ್ನು ಎಲ್ಲಿ ಜಾರಿಗೆ ತರಲಾಗಿದೆ, ಪ್ರಾಂಪ್ಟ್ ಲೇಯರ್‌ನಲ್ಲಿ ಅಥವಾ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಇಂಜಿನ್‌ನಲ್ಲಿ ಎಂದು ಕೇಳಿ. ಮಾನವ ಹಸ್ತಕ್ಷೇಪವು ಅಂತರ್ಗತ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಆಗಿದೆಯೇ ಅಥವಾ ಏಜೆಂಟ್ ಈಗಾಗಲೇ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹಾಳುಮಾಡಿದ ನಂತರ ಕಳುಹಿಸಲಾದ ಪೋಸ್ಟ್-ಮೋರ್ಟಮ್ ಇಮೇಲ್ ಆಗಿದೆಯೇ ಎಂದು ಕೇಳಿ. ನೀವು OpenAI ನ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಖರೀದಿಸುತ್ತಿಲ್ಲ. ನೀವು ಬೇರೆಯವರಲ್ಲಿನ ಕೊರತೆಗಳನ್ನು ಎತ್ತಿ ತೋರಿಸಲು ಅವರ ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೀರಿ.

MonkeyCode ಓಪನ್-ಸೋರ್ಸ್ ಮಾರ್ಗ ಮತ್ತು ಉಚಿತ ಕ್ಲೌಡ್ ವರ್ಷನ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ಆ ಸಂಯೋಜನೆಯು ಪೈಲಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವುದನ್ನು ಅಗ್ಗವಾಗಿಸುತ್ತದೆ. ಆದರೆ ಅಗ್ಗದ ಪ್ರವೇಶವು ದೃಢೀಕರಿಸಲ್ಪಟ್ಟ ಯಶಸ್ಸಿನಂತಲ್ಲ. ನಿಮ್ಮ ಸ್ವಂತ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ (infrastructure) ನಿಮ್ಮ ಸ್ವಂತ ಕಾರ್ಯಗಳನ್ನು ನಡೆಸುವವರೆಗೆ ಸಿಸ್ಟಮ್‌ನ ಅಜ್ಞಾತ ಭಾಗಗಳು ಅಜ್ಞಾತವಾಗಿಯೇ ಉಳಿಯುತ್ತವೆ. ಕಠಿಣ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರ ಸಿಕ್ಕಿದೆ ಎಂದು ಭಾವಿಸಲು ಶೂನ್ಯ ಡಾಲರ್ ಟಿಕೆಟ್‌ನನ್ನು ನಂಬಬೇಡಿ.

ಬಜೆಟ್ ಉಳಿಸುವ ಖರೀದಿ ನಿಯಮ

ಏಜೆಂಟಿಕ್ ಪೈಲಟ್ ಅನ್ನು ಪ್ರೊಡಕ್ಷನ್ ಕಮಿಟ್‌ಮೆಂಟ್ ಆಗಿ ವಿಸ್ತರಿಸಲು ನನ್ನ ನಿಯಮ ಸರಳವಾಗಿದೆ. ನಿರ್ಣಾಯಕ ಸಾಮರ್ಥ್ಯಗಳಿಗೆ ಪುರಾವೆ ಮತ್ತು ವೈಫಲ್ಯಗಳಿಗೆ ಸ್ಪಷ್ಟ ಮಾಲೀಕನಿದ್ದಾಗ ಮಾತ್ರ ನಾನು ವ್ಯಾಪ್ತಿ (scope) ಮತ್ತು ಬಜೆಟ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತೇನೆ. ರೋಡ್‌ಮ್ಯಾಪ್ ಸ್ಲೈಡ್ ಅಲ್ಲ. ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ ಕ್ಯೂ ಅಲ್ಲ. ಪುರಾವೆ ಎಂದರೆ ನಿಮ್ಮ ಎನ್ವಿರಾನ್ಮೆಂಟ್‌ನ ಲಾಗ್‌ಗಳು (logs). ಮಾಲೀಕ ಎಂದರೆ ಆ ನಿರ್ದಿಷ್ಟ ವೈಫಲ್ಯದ ವಿಧಾನಕ್ಕಾಗಿ ಪೇಜರ್ (pager) ಹೊರುವ ಹೆಸರಿಸಲ್ಪಟ್ಟ ಮನುಷ್ಯ.

ವೆಂಡರ್ ನಿಮಗೆ ಪುರಾವೆಯನ್ನು ತೋರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಅಥವಾ ನಿಮ್ಮ ಆಂತರಿಕ ತಂಡವು ಮಾಲೀಕನನ್ನು ನೇಮಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನೀವು ವಿಸ್ತರಿಸಲು ಸಿದ್ಧರಾಗಿಲ್ಲ ಎಂದರ್ಥ. ನೀವು ಪರೀಕ್ಷ