Harness Engineering: कैसे बनाएं ऐसे AI Agents जो वास्तव में काम करते हैं

ज़्यादातर लोग AI agents को गलत लेयर पर ठीक करने की कोशिश कर रहे हैं।

जब कोई agent फेल होता है, तो वे prompt बदल देते हैं। जब वह फिर फेल होता है, तो वे और ज़्यादा instructions जोड़ देते हैं, model बदल देते हैं, context window बढ़ा देते हैं, या कोई दूसरा tool कनेक्ट कर देते हैं।

और फिर वही पुरानी समस्याएँ लौट आती हैं।

Agent कोई ज़रूरी फैसला भूल जाता है। वह गलत tool इस्तेमाल करता है। उसे याद नहीं रहता कि तीन स्टेप पहले क्या हुआ था। बिना रिज़ल्ट चेक किए वह कह देता है कि काम पूरा हो गया। वह उसी फेल हुए एक्शन को तब तक दोहराता रहता है जब तक बजट खत्म न हो जाए।

समस्या हमेशा model में नहीं होती।

समस्या उसके आस-पास के environment में होती है।

वह environment ही harness है।

Harness Engineering का मतलब है model के चारों तरफ ऐसा system बनाना जो यह तय करे कि वह क्या देख सकता है, क्या कर सकता है, उसे क्या याद रहता है, सफलता किसे माना जाएगा, और कुछ फेल होने पर क्या होगा।

एक बेहतर prompt सिर्फ एक response को सुधार सकता है।

लेकिन एक बेहतर harness हर run को सुधार देता है।

AI agents, automation और production systems पर ऐसे ही प्रैक्टिकल विश्लेषण पढ़ने के लिए मेरे Substack को फॉलो करें:

substack.com/@lunarresearcher

1. Model ही Agent नहीं होता

एक model सोच सकता है, generate कर सकता है, तुलना कर सकता है और चुनाव कर सकता है।

लेकिन इससे वह एक भरोसेमंद agent नहीं बन जाता।

एक असली agent को सही context ढूँढना, tools इस्तेमाल करना, state बनाए रखना, permissions का ध्यान रखना, अपना काम खुद verify करना, और जब environment उम्मीद से अलग बर्ताव करे तो खुद को संभालना भी आना चाहिए।

Model सिर्फ एक reasoning engine है।

Harness वह सब कुछ है जो उस reasoning को असल execution में बदलता है।

1USER REQUEST
2      |
3      v
4+-----------------------------+
5|           HARNESS           |
6|                             |
7| contract      context       |
8| tools         state         |
9| policy        verification  |
10| traces        recovery      |
11+-----------------------------+
12      |
13      v
14    MODEL
15      |
16      v
17REAL ENVIRONMENT

उसी model को एक chat box में डाल दीजिए, तो वह सवालों के जवाब देगा।

उसे terminal access, tests, browser tools, project memory, controlled permissions और review loop वाले repository में डाल दीजिए, तो वह असली काम पूरा कर सकता है।

Model नहीं बदला।

Harness बदला।

2. हर Request को Contract में बदलें

Natural language लचीली होती है।

Autonomous execution को नहीं होना चाहिए।

इस तरह की request:

ऑनबोर्डिंग फ्लो को बेहतर बनाओ।

ठीक है, जब कोई इंसान model के साथ बैठा हो।

लेकिन production instruction के तौर पर यह बहुत खराब है।

Agent के काम शुरू करने से पहले, request को एक सीमित task contract में बदल दें।

1objective: ऑनबोर्डिंग ड्रॉप-ऑफ कम करना
2
3inputs:
4  - प्रोडक्ट ब्रीफ
5  - एनालिटिक्स डेटा
6  - रिपॉजिटरी
7
8constraints:
9  - ऑथेंटिकेशन बरकरार रखें
10  - डेटाबेस स्कीमा न बदलें
11  - मौजूदा मोबाइल व्यवहार बरकरार रखें
12
13deliverable:
14  - रिव्यू करने योग्य pull request
15
16done_when:
17  - टेस्ट पास हों
18  - एनालिटिक्स इवेंट सही तरीके से ट्रिगर हो
19  - डेस्कटॉप फ्लो रिव्यू पास करे
20  - मोबाइल फ्लो रिव्यू पास करे
21
22approval_required:
23  - प्रोडक्शन डिप्लॉयमेंट

सबसे अहम हिस्सा done_when है।

इसके बिना, agent समस्या का थोड़ा आसान वर्ज़न हल कर सकता है और फिर भी पूरे भरोसे से कह सकता है कि काम पूरा हो गया।

इसके साथ, काम पूरा होना मापने योग्य बन जाता है।

Agent को यह नहीं पूछना चाहिए:

मुझे आगे क्या करना चाहिए?

उसे यह पूछना चाहिए:

कौन सा एक्शन मौजूदा environment को contract में तय नतीजे के करीब ले जाएगा?

यह एक बहुत मज़बूत loop है।

3. Agent को Giant Context Window नहीं, Map दें

Agent की गलतियों पर लोगों का आम रिएक्शन होता है — model को और ज़्यादा context दे दो।

और ज़्यादा documentation।

और ज़्यादा conversation history।

और ज़्यादा files।

और ज़्यादा tool output।

आखिरकार agent को सब कुछ मिल जाता है और वह कम समझ पाता है।

Context स्टोरेज नहीं है।

यह एक attention budget है।

हर run में पूरा प्रोजेक्ट डंप करने के बजाय, agent को एक छोटा map दें जिससे उसे पता चले कि काम की जानकारी कहाँ मिलेगी।

1PROJECT MAP
2
3product rules     -> docs/product/
4architecture      -> docs/architecture.md
5frontend          -> apps/web/
6backend           -> services/api/
7tests             -> tests/
8commands          -> docs/commands.md
9security          -> docs/security.md

फिर ज़रूरत पड़ने पर ही इसे बढ़ाएँ।

1TASK
2  |
3  v
4PROJECT MAP
5  |
6  v
7RELEVANT SYSTEM
8  |
9  v
10EXACT FILES
11  |
12  v
13LOCAL INSTRUCTIONS

सोर्स मटेरियल इसे progressive disclosure बताता है: harness को ज़्यादा जानकारी इसलिए लोड करनी चाहिए क्योंकि task को उसकी ज़रूरत है, न कि सिर्फ इसलिए कि वह जानकारी मौजूद है।

मकसद maximum context नहीं है।

मकसद maximum useful signal है।

4. Model और उसके Tools के बीच Gateway लगाएँ

बीस tools वाला model अपने आप बीस गुना ज़्यादा सक्षम नहीं हो जाता।

हो सकता है उसके पास फेल होने के बीस और रास्ते आ गए हों।

हर tool का एक contract होना चाहिए।

1TOOL: edit_file
2
3INPUTS
4path
5patch
6
7PRECONDITIONS
8path मौजूद है
9path workspace के अंदर है
10
11SUCCESS
12patch लागू हुआ
13diff वापस मिला
14
15FAILURE
16structured error
17कोई partial overwrite नहीं
18
19RISK
20reversible

फिर execution path कुछ ऐसा बनता है:

1MODEL PROPOSES
2      |
3      v
4GATEWAY VALIDATES
5      |
6      v
7POLICY AUTHORIZES
8      |
9      v
10TOOL EXECUTES
11      |
12      v
13HARNESS RECORDS RESULT

Model तय करता है कि उसे कौन सा एक्शन चाहिए।

Harness तय करता है कि वह एक्शन valid है, allowed है और सुरक्षित है या नहीं।

यह फर्क तब बहुत अहम हो जाता है जब tools मैसेज भेज सकें, production में बदलाव कर सकें, पैसा खर्च कर सकें या डेटा डिलीट कर सकें।

एक अच्छा tool gateway timeouts जोड़ सकता है, arguments validate कर सकता है, file paths पर पाबंदी लगा सकता है, errors को normalize कर सकता है और retries को सुरक्षित बना सकता है।

अच्छे tools उन चीज़ों की तादाद कम कर देते हैं जो model को अनुमान से तय करनी पड़ती हैं।

5. Memory को Conversation से बाहर रखें

Conversation को system of record नहीं होना चाहिए।

लंबे समय तक चलने वाले agents आखिरकार context limits से टकराते हैं, crash होते हैं, restart होते हैं, या काम किसी दूसरे session को सौंप देते हैं।

अगर हर अहम फैसला सिर्फ transcript के अंदर मौजूद है, तो workflow नाज़ुक है।

Durable state को अलग से स्टोर करें।

1{
2  "task_id": "feature_042",
3  "status": "verifying",
4  "current_step": "mobile_check",
5
6  "completed": [
7    "implementation",
8    "unit_tests",
9    "desktop_check"
10  ],
11
12  "decisions": [
13    "reuse existing export endpoint",
14    "preserve current date format"
15  ],
16
17  "artifacts": [
18    "export.csv",
19    "desktop-after.png"
20  ],
21
22  "open_risks": [
23    "mobile toolbar may overflow"
24  ],
25
26  "next_action": "render mobile viewport"
27}

एक काम का system memory को चार हिस्सों में बाँटता है:

1FACTS
2स्थिर जानकारी
3
4DECISIONS
5क्या चुना गया और क्यों
6
7STATE
8मौजूदा run कहाँ पहुँचा है
9
10LESSONS
11ऐसी गलतियाँ जिनका असर आने वाले runs पर पड़ना चाहिए

अगले agent session को पिछली बातचीत की सिकुड़ी हुई कहानी नहीं, बल्कि काम की state विरासत में मिलनी चाहिए।

6. काम पूरा होने का पैमाना Evidence को बनाएँ

Agent का "हो गया" कहना इस बात का सबूत नहीं है कि काम सच में हो गया।

यह भी model का एक और output भर है।

Harness को observable evidence चाहिए।

1CLAIM                     EVIDENCE
2
3"bug is fixed"            फेल होने वाला टेस्ट अब पास हो रहा है
4
5"page works"              browser flow पूरा हुआ
6
7"data is correct"         वैल्यूज़ source से मैच कर रही हैं
8
9"migration is safe"       dry run + rollback पास हुआ
10
11"task is complete"        हर acceptance check पास हुआ

पहले deterministic checks इस्तेमाल करें।

1syntax
2  |
3  v
4types
5  |
6  v
7focused tests
8  |
9  v
10integration tests
11  |
12  v
13visual / semantic review
14  |
15  v
16human approval

जो बात compiler, test, schema या database query साबित कर सकता है, उसके लिए किसी दूसरे model से जवाब मत माँगिए।

Models का इस्तेमाल judgment के लिए करें।

Deterministic systems का इस्तेमाल facts के लिए करें।

Model artifact बनाता है।

Environment उस artifact के बारे में evidence बनाता है।

Harness तय करता है कि evidence काफी है या नहीं।

7. Builder को Verifier से अलग करें

Self-review में एक और समस्या है।

जिस agent ने गलती की, वह अक्सर वही assumptions लेकर review में भी आता है।

एक मज़बूत architecture worker और verifier को अलग रखती है।

1BUILDER
2   |
3   v
4candidate बनाता है
5   |
6   v
7VERIFIER
8   |
9   +-- contract चेक करता है
10   +-- छूटे हुए cases ढूँढता है
11   +-- बिना सबूत वाले दावों को टेस्ट करता है
12   +-- रिज़ल्ट को तोड़ने की कोशिश करता है
13   |
14   +------ PASS ------> ACCEPT
15   |
16   +------ FAIL ------> RETURN EVIDENCE

Verifier को यह नहीं पूछना चाहिए:

क्या यह ठीक लग रहा है?

उसे यह पूछना चाहिए:

ऐसा क्या है जो इसे अस्वीकार्य बना देगा?

इससे review महज़ पुष्टि करने से बदलकर गलत साबित करने की कोशिश बन जाता है।

सोर्स मटेरियल स्पष्ट रूप से सलाह देता है कि verification को अपने rejection criteria और इतनी आज़ादी दें कि वह उन assumptions को चुनौती दे सके जिन्होंने पहला रिज़ल्ट तैयार किया था।

8. Permissions को Model से बाहर रखें

कुछ नियमों को कभी भी model की याददाश्त पर निर्भर नहीं रहना चाहिए।

1बिना approval के कभी publish मत करो
2secrets कभी expose मत करो
3spend limit कभी पार मत करो
4workspace के बाहर कभी write मत करो
5जब तक टेस्ट न चले हों, कभी यह मत कहो कि वे पास हो गए

ये prompt suggestions नहीं हैं।

ये policy हैं।

एक साधारण permission ladder:

1LOW RISK
2
3read
4search
5inspect
6
7-> automatic
8
9REVERSIBLE
10
11edit workspace
12run tests
13create draft
14
15-> automatic + trace
16
17EXTERNAL EFFECT
18
19send
20deploy
21purchase
22
23-> approval required
24
25IRREVERSIBLE / SENSITIVE
26
27delete data
28rotate credentials
29publish globally
30
31-> hard gate or prohibited

नतीजा जितना गंभीर, control उतना सख्त।

Model एक्शन suggest कर सकता है।

Harness उसे authorize करता है।

Tool उसे execute करता है।

Autonomy का मतलब control का न होना नहीं है।

इसका मतलब है एक तय सीमा के अंदर आज़ादी।

9. आँख बंद करके Retry करना बंद करें

सबसे खराब recovery policies में से एक है:

कुछ फेल हो गया। दोबारा कोशिश करो।

अगर कुछ नहीं बदलता, तो system सिर्फ उसी गलती को दोहराने के पैसे दे रहा है।

पहले failures को categorize करना चाहिए।

1TOOL TIMEOUT
2-> backoff के साथ retry करें
3
4INVALID ARGUMENTS
5-> tool call ठीक करें
6
7MISSING CONTEXT
8-> छूटा हुआ source लाएँ
9
10FAILED TEST
11-> फेल होने वाले behavior को जाँचें
12
13PERMISSION DENIED
14-> approval माँगें
15
16CONFLICTING REQUIREMENTS
17-> escalate करें
18
19UNCHANGED REPEATED FAILURE
20-> रुक जाएँ

एक काम का agent loop कुछ ऐसा दिखता है:

1OBSERVE
2   |
3   v
4DECIDE
5   |
6   v
7ACT
8   |
9   v
10MEASURE
11   |
12   +---- ACCEPT
13   |
14   +---- REPAIR
15   |
16   +---- ESCALATE
17   |
18   +---- STOP

हर loop में attempts, time, spend और destructive scope की सीमाएँ होनी चाहिए।

एक भरोसेमंद agent को पता होना चाहिए कि आगे कैसे बढ़ना है।

उसे यह भी पता होना चाहिए कि कब एक और कोशिश करना बेकार है।

10. बार-बार दिए जाने वाले Instructions को Infrastructure बना दें

मान लीजिए prompt में लिखा है:

हमेशा formatter चलाओ।

यह नियम तब ज़्यादा मज़बूत होता है जब formatter अपने आप चल जाए।

मान लीजिए instructions कहते हैं:

UI code सीधे database तक नहीं पहुँच सकता।

यह तब ज़्यादा मज़बूत होता है जब यह एक architecture test बन जाए जो नियम टूटने पर फेल हो जाए।

यह progression कुछ ऐसा दिखता है:

1EXPLANATION
2      |
3      v
4CHECKLIST
5      |
6      v
7TEMPLATE
8      |
9      v
10AUTOMATED CHECK
11      |
12      v
13ENFORCED POLICY

Prompt को judgment समझाना चाहिए।

Harness को invariants लागू करने चाहिए।

हर बार होने वाली गलती को इस ladder में थोड़ा और नीचे ले जाना चाहिए।

आखिरकार model को वह सीख याद रखने की ज़रूरत नहीं रहती।

Environment उसे model के लिए याद रखता है।

11. Run को Record करें

एक बेहतरीन final artifact एक खराब execution path को छिपा सकता है।

शायद agent ने गलत source access किया हो।

शायद उसने किसी फेल हुए command को नज़रअंदाज़ कर दिया हो।

शायद उसने कोई external action दो बार कर दिया हो।

शायद उसने उम्मीद से दस गुना ज़्यादा बजट खर्च कर दिया हो।

शायद उसे सही जवाब गलत वजह से मिला हो।

इतनी जानकारी record करें कि आप दोबारा पता लगा सकें कि क्या हुआ था।

109:14  task contract बनाया गया
209:15  architecture.md लोड हुआ
309:17  checkout.ts एडिट किया गया
409:18  focused test फेल हुआ
509:21  implementation ठीक किया गया
609:22  focused test पास हुआ
709:24  integration test पास हुआ
809:25  deployment रोका गया: approval ज़रूरी है

काम के traces में context sources, tool calls, state changes, verification results, retry reasons, approval decisions, cost और latency शामिल होते हैं।

मकसद शौक के लिए logs जमा करना नहीं है।

मकसद failure को local बनाना है।

अगर step 18 टूटता है, तो आपको step 18 को ठीक कर पाना चाहिए।

आपको पूरा run दोबारा चलाने की ज़रूरत नहीं पड़नी चाहिए।

12. हर Run को Receipt दें

इंसान को चालीस मैसेज वाला transcript पढ़ने के लिए मजबूर मत कीजिए।

रिज़ल्ट को एक छोटी receipt में समेट दीजिए।

1OBJECTIVE
2
3डुप्लीकेट कूपन अप्लाई होने की समस्या ठीक करें।
4
5CHANGED
6
7checkout validation
8regression test
9
10VERIFIED
11
12lint passed
13unit tests passed
14integration test passed
15
16NOT VERIFIED
17
18production payment provider
19
20RISKS
21
22legacy mobile client उपलब्ध नहीं है
23
24APPROVAL NEEDED
25
26staging पर deploy करें

यह model के दावे का summary नहीं है कि क्या हुआ।

यह उस बात का summary है जिसे harness साबित कर सकता है कि हुआ।

यही फर्क receipt को review, handoffs और आने वाले agent sessions के लिए काम का बनाता है।

13. हर Failure से Harness को बेहतर बनाएँ

ज़्यादातर टीमें फेल हुए output को ठीक करती हैं।

बेहतर तरीका है उस system को ठीक करना जिसने उस गलती की इजाज़त दी।

1MISSING CONTEXT
2-> project map बेहतर करें
3
4WRONG TOOL
5-> routing या tool contract बेहतर करें
6
7BAD OUTPUT
8-> validator जोड़ें
9
10REPEATED LOOP
11-> retry cap जोड़ें
12
13UNSAFE ACTION
14-> permission gate जोड़ें
15
16LOST DECISION
17-> state persist करें
18
19UNKNOWN FAILURE
20-> tracing बेहतर करें

यहीं से harness engineering का असली फायदा जुड़ना शुरू होता है।

एक ठीक किया गया output सिर्फ एक run की मदद करता है।

एक ठीक किया गया harness उसके बाद हर run को बेहतर बनाता है।

सबसे बेहतरीन agent systems इसलिए ज़्यादा भरोसेमंद बनते हैं क्योंकि गलतियाँ अपने पीछे infrastructure छोड़ जाती हैं।

14. सबसे छोटे काम के Harness से शुरुआत करें

शुरू करने के लिए आपको किसी विशाल orchestration platform की ज़रूरत नहीं है।

Layers में बनाएँ।

1LEVEL 0
2
3prompt
4model
5
6LEVEL 1
7
8task contract
9project map
10tools
11
12LEVEL 2
13
14structured state
15verification
16bounded loop
17
18LEVEL 3
19
20permissions
21traces
22recovery
23human gates

एक छोटे research task को शायद सिर्फ एक prompt और एक review की ज़रूरत हो।

File access, network access और deployment capability वाले छह घंटे के coding task को बहुत ज़्यादा चीज़ों की ज़रूरत होगी।

Complexity तब जोड़ें जब failure surface इसके लायक हो।

सिर्फ इसलिए नहीं कि agent architecture cool लगता है।

Harness Engineering Checklist

किसी agent को असली autonomy देने से पहले पूछें:

1[ ] क्या execution से पहले success define किया गया है?
2
3[ ] क्या agent सब कुछ लोड किए बिना
4    सही context ढूँढ सकता है?
5
6[ ] क्या हर tool का एक साफ मकसद,
7    schema और failure state है?
8
9[ ] क्या अहम फैसले conversation
10    से बाहर स्टोर किए जा रहे हैं?
11
12[ ] क्या काम पूरा होने के लिए evidence ज़रूरी है?
13
14[ ] क्या risky actions policy से सुरक्षित हैं?
15
16[ ] क्या हर loop में retry limit है?
17
18[ ] क्या interruption के बाद run फिर शुरू हो सकता है?
19
20[ ] क्या आप हर अहम action को दोबारा reconstruct कर सकते हैं?
21
22[ ] क्या failure किसी rule, tool,
23    test, map या permission को बेहतर बनाता है?
24
25[ ] क्या आखिरी change rollback किया जा सकता है?

अगर कई जवाब 'नहीं' हैं, तो एक मज़बूत model अपने आप agent को भरोसेमंद नहीं बना देगा।

हो सकता है वह बस failure को तेज़ और महँगा बना दे।

असली बदलाव

Prompt engineering पूछता है:

मुझे model को क्या बताना चाहिए?

Context engineering पूछता है:

इस वक्त model को क्या पता होना चाहिए?

Harness engineering पूछता है:

कौन सा system model को काम करने, अपना काम verify करने, failure से उबरने और सुरक्षित तरीके से चलने देता है?

1PROMPT
2-> instruction
3
4CONTEXT
5-> working view
6
7HARNESS
8-> operating environment
9
10LOOP
11-> local correction
12
13GRAPH
14-> coordination

Models बदलते रहेंगे।

असली, टिकाऊ फायदा उनके आस-पास बनता है।

आपके contracts बेहतर होते हैं।

आपके tools बेहतर होते हैं।

आपके tests बेहतर होते हैं।

आपकी state साफ होती है।

आपकी permissions सुरक्षित होती हैं।

आपकी recovery logic स्मार्ट होती है।

आपकी failures infrastructure में बदल जाती हैं।

यही तरीका है जिससे सक्षम models भरोसेमंद agents बनते हैं।

यही Harness Engineering है।

अगर आप यहाँ तक पहुँचे हैं

इस गाइड को Bookmark करें।

मुझे X पर फॉलो करें: x.com/0xjmori

मेरे Substack को Subscribe करें: substack.com/@lunarresearcher

यह आर्टिकल उस इंसान को भेजें जो अभी भी हर agent failure को लंबे prompt से ठीक करने की कोशिश कर रहा है।