Stop running fresh model benchmarks and start watching your agent try to cancel a subscription. The gap between those two activities is where production systems die. A single-turn test can tell you if a response sounds pleasant. It cannot tell you whether the agent just refunded the wrong customer, looped fourteen times against a calendar API, or decided to skip the fraud check entirely. Text is the least dangerous thing an agent produces. The real risks hide in the tools it touches, the data it mutates, and the moments when it should have asked for help but kept going.

Why Text Benchmarks Fail in Production

High scores on standard benchmarks have become a misleading form of comfort. An agent that writes elegant prose might still be an operational hazard. When your system books appointments, edits database records, or files support tickets, the generated text is only the visible surface of the workflow. Underneath, the agent is making concrete decisions about which endpoint to hit, what payload to send, and when to stop. It can top a reading-comprehension leaderboard while costing you money by double-booking resources, mutating the wrong row, or leaking sensitive state into a log file. You need to verify the mechanics of the work, not just the polish of the output. If an agent can score well on an offline QA test and still fail your workflow by looping or misusing a tool, your evaluation is looking at the wrong signals.

Mapping the Five Dependencies

The team at Van Data Team starts every evaluation by mapping five specific control points. This changes the question entirely. You stop asking if one model is smarter than another. You start asking if the agent can actually finish a production task under your real constraints.

Business outcomes. Define what "done" means in dollars and customer impact. A task is not complete because the agent emitted a summary. It is complete when the inventory record is accurate, the appointment is confirmed, and the customer received a valid tracking number.

Mutable state. Know exactly what the agent is allowed to change. Which tables, which statuses, which account flags? If the agent can issue refunds, reschedule jobs, or update billing addresses, you need to inventory every field it touches.

Tool permissions. Be explicit about which API endpoints and functions are in scope. An agent with access to a search tool, a write tool, and a notification tool will mix them up if the boundaries are fuzzy. Map each permission to a specific operational need.

Failure recovery. Decide what happens when the calendar API times out, returns a 500, or hands back malformed JSON. The agent should not panic, hallucinate a success message, or retry forever. It needs a clear fallback path.

Human review gates. Identify the moments where a person must sign off before the agent proceeds. This is not a sign of weakness in the automation. It is a safety valve for high-impact changes and a source of ground-truth labels for your rubrics.

What a Real Evaluation Plan Looks Like

Once the dependencies are mapped, you need an evaluation plan that matches the messiness of production. Slide-deck metrics will not help you here.

Build test sets from real production failures, not from synthetic question banks. If your agent failed last Tuesday by confusing two similar SKUs, that exact confusion should be a permanent test case. Your evaluation suite should grow every time an incident teaches you something new.

Write rubrics that define successful completion in operational terms. Vague criteria like "helpful" or "accurate" are useless. A useful rubric states that a refund task is only successful if the original payment ID was referenced, the amount matched the request, a confirmation email was queued, and the transaction ID was logged.

Define trace specs for tool calls and retries. You need observability into what the agent planned, what it actually called, how many times it retried, and whether the retry strategy was appropriate. A trace without tool-level granularity is just a pretty story.

Set policies for when to alert a human. The agent should know its own boundaries. If a request exceeds a dollar threshold, references a VIP account, or encounters a state it has never seen before, it should escalate rather than guess.

वाईट मॉडेल अपग्रेड्स रोखण्यासाठी रिलीज गेट्स (release gates) स्थापित करा. एखादे नवीन मॉडेल तेव्हाच अपग्रेड मानले जाते जेव्हा ते तुमच्या विशिष्ट निकालांमध्ये सुधारणा करते. जर ते वारंवार टूल आर्ग्युमेंट्समध्ये चुका (hallucinate) करत असेल, लॅटन्सी (latency) वाढवत असेल किंवा नवीन सुरक्षेचे धोके निर्माण करत असेल, तर ते रिलीज करू नका. बेस मॉडेल विक्रेता नवीन व्हर्जन पाठवत असतानाही हे गेट प्रोडक्शनला स्थिर ठेवते.

रनटाइम ग्रेडिंग (Runtime Grading): एजंटचे काम पाहताना

Anthropic उद्योगाला ऑफलाइन टेस्ट्सच्या पलीकडे जाऊन रनटाइम ग्रेडिंगकडे (runtime grading) वळण्यासाठी प्रवृत्त करत आहे. एखादा संवाद (transcript) पूर्ण झाल्यानंतर त्याचे मूल्यमापन करण्याऐवजी, रनटाइम ग्रेडिंगमुळे एखादे कार्य प्रक्रियेत असतानाच (in flight) सिस्टिमला एजंटच्या कामाचे मूल्यमापन करता येते. यामुळे चुका वास्तविक समस्यांमध्ये रूपांतरित होण्यापूर्वीच त्या पकडण्याची संधी मिळते.

ग्रेडर जोडल्यामुळे टोकन्स आणि लॅटन्सीचा खर्च वाढतो. तुम्ही प्रत्येक लहान पायरीचे मूल्यमापन करू शकत नाही. प्रत्येक ग्रेडरचे स्थान ठरवणे हा एक डिझाइन निर्णय आहे. जिथे चुका महाग पडू शकतात, तिथे ते ठेवा. सर्वात मौल्यवान चेकपॉइंट्स डेटाबेसमध्ये स्टेट चेंज (state change) करण्यापूर्वी, पेमेंट घेण्यापूर्वी आणि ग्राहकाला संदेश पाठवण्यापूर्वी असतात. हे असे क्षण आहेत जिथे चुकीचा निर्णय ही एक अपरिवर्तनीय कृती बनते.

एका विशिष्ट 'ब्लाईंड स्पॉट'बद्दल सावध राहा. जर तेच मॉडेल काम करत असेल आणि त्याच वेळी त्याचे मूल्यमापनही करत असेल, तर ते त्याच चुकांकडे दुर्लक्ष करू शकते. ज्या तर्कामुळे चूक झाली, तोच तर्क पुनरावलोकनादरम्यान त्या चुकीचे समर्थन करू शकतो. उच्च-प्रभाव असलेल्या कामांसाठी, मानवी पुनरावलोकन (human review) प्रक्रियेत ठेवा. विशेषतः जेव्हा पैसा किंवा ग्राहकाचा विश्वास पणाला लागलेला असतो, तेव्हा लोकांनी ग्रेडरच्या निर्णयाची पडताळणी करू द्या.

याचे उद्दिष्ट ऑपरेशनल कंट्रोल (operational control) मिळवणे हे आहे. तुमचा इन्सिडेंट डेटा, टास्क रुब्रिक्स आणि रनटाइम ट्रेसेस एकाच फीडबॅक सायकलमध्ये जोडा. संपूर्ण मार्गाचे मूल्यमापन करा: योजना, टूलचा वापर, रिकव्हरी बिहेवियर आणि अंतिम निकाल. रिलीज करण्यापूर्वी ज्ञात आणि पुन्हा उद्भवू शकणाऱ्या चुका पकडण्यासाठी ऑफलाइन टेस्ट्स वापरा. तुम्ही अपेक्षित न केलेल्या नवीन त्रुटी शोधण्यासाठी रनटाइम ट्रेसेस वापरा. तुमचे रुब्रिक्स कुठे अपरिपक्व आहेत आणि त्यांना अधिक कडक करण्याची गरज आहे, हे शोधण्यासाठी मानवी पुनरावलोकनाचा वापर करा.

म्हणून स्वतःला विचारा: तुम्ही तुमच्या वर्कफ्लोमध्ये रनटाइम ग्रेडर कुठे ठेवाल? टूल कॉलच्या आधी, टूल कॉलच्या नंतर, की फक्त जोखमीच्या बदलापूर्वी? बहुतेक टीम्स खूप व्यापक सुरुवात करतात, सर्व गोष्टींचे मूल्यमापन करतात आणि नंतर खर्चाच्या ओझ्याखाली अडखळतात. मर्यादित सुरुवात करा. अशी एक कृती निवडा जी चुकल्यास सर्वाधिक नुकसान होईल. तिथे प्रथम ग्रेडर ठेवा.

एका महागड्या चुकीपासून सुरुवात करा

ऑपरेशनल इव्हॅल्युएशन (Operational evaluation) ही केवळ एक संशोधन प्रक्रिया नाही. एजंट लाईव्ह झाल्यानंतर शांतपणे झोपण्यासाठी ती एक पद्धत आहे. तुम्हाला पहिल्या दिवसापासून परिपूर्ण फ्रेमवर्कची गरज नाही. तुम्हाला फक्त एक स्पष्ट वर्कफ्लो, साध्या व्यावसायिक भाषेत लिहिलेले रुब्रिक आणि ज्या क्षणी चूक महाग पडू शकते, तिथे ठेवलेला ग्रेडर हवा आहे. हे योग्य केल्यास, तुम्हाला खरोखर विश्वास ठेवता येईल असा पाया मिळेल.

जर तुम्हाला तज्ज्ञांच्या समुदायासोबत एजंट इव्हॅल्युएशन आणि रनटाइम ग्रेडिंगबद्दल अधिक जाणून घ्यायचे असेल, तर तुम्ही GyaanSetu लर्निंग कम्युनिटी https://t.me/GyaanSetuAi येथे शोधू शकता.