સૌથી ખરાબ બગ્સ તમારા સિસ્ટમને ક્રેશ નથી કરતા. તેઓ ફક્ત તમારી સાથે સહમત થાય છે.

Claude Code ની અંદર પાંચ વિશિષ્ટ subagents ને સંકલિત કરવા માટે રચાયેલ એક ઓર્કેસ્ટ્રેટર (orchestrator) Suhail બનાવતી વખતે મેં આ વાત કઠિન અનુભવ દ્વારા શીખી હતી. દરેક વર્કરની એક અલગ ભૂમિકા હતી: સંદર્ભ એકત્રિત કરવા માટે રિસર્ચર (researcher), કાર્યોને વિભાજિત કરવા માટે પ્લાનર (planner), અમલીકરણ લખવા માટે કોડર (coder), આઉટપુટની તપાસ કરવા માટે રિવ્યુઅર (reviewer), અને રિગ્રેસન્સ (regressions) તપાસવા માટે ઓડિટર (auditor). વિચાર સીધો હતો. ઓર્કેસ્ટ્રેટર વિનંતી વાંચશે, કોણે શું કરવાનું છે તે નક્કી કરશે, અને પછી કામ સમાંતર (parallel) રીતે સોંપશે. તેના બદલે, મને એક નમ્ર મોનોલોગ મળ્યો. એક વિન્ડો. એક એજન્ટ. એક ખૂબ જ વ્યસ્ત મોડેલ જે કામ સોંપ્યું હોવાનો દાવો કરતી વખતે બધું જ જાતે જ કરી રહ્યું હતું.

કોઈ ચેતવણી (red flags) નહીં. કોઈ એરર લોગ્સ (error logs) નહીં. રન સફળતાપૂર્વક પૂર્ણ થયું. Suhail એ ખરેખર એક પણ subagent બનાવ્યો ન હતો તે સમજવામાં મને સ્વીકારવા કરતાં વધુ સમય લાગ્યો.

Agents ફોલ્ડરનો છટકું

તેનું મૂળ કારણ તેની સરળતામાં લગભગ અપમાનજનક હતું. મેં ઓર્કેસ્ટ્રેટર ફાઇલ agents ફોલ્ડરની અંદર મૂકી હતી.

Claude Code માં, તે ફોલ્ડર માત્ર એક ફાઇલિંગ કેબિનેટ નથી. તે એક ભઠ્ઠી (forge) છે. ત્યાં કોઈ ફાઇલ મૂકો, અને સિસ્ટમ તેને subagent તરીકે ગણે છે. તે ઓળખ સાથે પરવાનગીઓ (permissions) જોડાયેલી હોય છે. તે સમયે, subagents Agent ટૂલનો ઉપયોગ કરી શકતા નહોતા. તેઓ વર્કર્સ હતા, ફોરમેન (foremen) નહીં. કારણ કે Suhail વર્કર્સની વચ્ચે રહેતો હતો, Claude Code એ તેને પણ એક વર્કર તરીકે જ ગણ્યો. તેથી જ્યારે મારી સૂચનાઓએ ઓર્કેસ્ટ્રેટરને "researcher ને મોકલો" (dispatch the researcher) તેમ કહ્યું, ત્યારે તેણે એવા ટૂલનો ઉપયોગ કરવાનો પ્રયાસ કર્યો જે તેની પાસે નહોતું.

પરંપરાગત સોફ્ટવેર ત્યાં જ એક્સેપ્શન (exception) ફેંકત. ટૂલ ખૂટે છે. કોલ નિષ્ફળ ગયો. પરંતુ એજન્ટિક LLMs ની દુનિયામાં આવું નથી. જ્યારે મોડેલ યોગ્ય ટૂલ શોધી શકતું નથી, ત્યારે તે અટકી જતું નથી. તે તરત જ કામ પતાવવાનો રસ્તો શોધી લે છે (improvises). Suhail એ રિસર્ચરને મોકલવાની સૂચના જોઈ, તેના કિટમાં Agent ટૂલ મળ્યું નહીં, અને તેણે પોતે જ રિસર્ચ કરી લીધું. પછી તે પ્લાનિંગ પર આગળ વધ્યું. પછી કોડિંગ. પછી પોતાના કોડનું રિવ્યુ કર્યું. પછી પોતાના રિવ્યુનું ઓડિટ કર્યું. આઉટપુટ વ્યાજબી લાગતું હતું. ટ્રાન્સક્રિપ્ટ એક સારી રીતે ચાલતા પ્રોજેક્ટ જેવી લાગતી હતી. પરંતુ આ આર્કિટેક્ચર માત્ર એક કલ્પના હતી.

આ જ બાબત આ નિષ્ફળતાને આટલી જોખમી બનાવે છે. ક્રેશ (crash) તમને સંકેત આપે છે. પરંતુ શાંત રીતે થતો બદલાવ (silent substitution) સંકેત આપતો નથી. મોડેલ છેતરપિંડી કરી રહ્યું નથી. તે જરૂર કરતાં વધુ મદદરૂપ થવાનો પ્રયાસ કરી રહ્યું છે. જ્યારે તેને કોઈ લક્ષ્ય આપવામાં આવે અને ક્ષમતામાં કોઈ ખામી હોય, ત્યારે તે પોતાની તર્કશક્તિથી તે ખામી પૂરી કરે છે. પરિણામે એક એવી સિસ્ટમ મળે છે જે સફળતાનો રિપોર્ટ આપે છે, પરંતુ તમે બનાવેલા માળખાને વ્યવસ્થિત રીતે અવગણે છે.

ઉકેલ, અને તે શા માટે કામ કરી ગયો

તેને ઉકેલવા માટે ઓર્કેસ્ટ્રેટર ફાઇલને agents ફોલ્ડરમાંથી બહાર કાઢીને તેને slash command માં બદલવા સિવાય બીજું કંઈ કરવાની જરૂર નહોતી.

Claude Code માં slash commands ટોપ-લેવલ સેશનમાં હોય છે. તેઓ subagents નથી. તેઓ યુઝર-ફેસિંગ એન્ટ્રી પોઈન્ટ છે. તે સ્થાનથી, Agent ટૂલ ઉપલબ્ધ હોય છે અને ઓર્કેસ્ટ્રેટર આખરે તેનું વાસ્તવિક કામ કરી શકે છે: વર્કર્સ બનાવવા, કાર્યો સોંપવા અને વાસ્તવિક પરિણામોની રાહ જોવી. પાંચ સ્પેશિયાલિસ્ટ્સ તેમના પોતાના સંદર્ભમાં કામ કરવા લાગ્યા. સમાંતરતા (Parallelism) ખરેખર જોવા મળી. પદાનુક્રમ (hierarchy) નો હવે અર્થ નીકળવા લાગ્યો.

પરંતુ માત્ર ફોલ્ડર સ્ટ્રક્ચર સાચું કરી દેવાથી મૂળભૂત નબળાઈ દૂર થઈ જતી નથી. ઓર્કેસ્ટ્રેટર સાચી જગ્યાએ હોવા છતાં, ત્રણ ચોક્કસ જોખમો ફરીથી તમારી યોજના ખોરવી શકે છે.

ત્રણ જોખમો જે હજુ પણ છુપાયેલા છે

Curated tool lists. Claude Code તમને ચોક્કસ રીતે વ્યાખ્યાયિત કરવાની મંજૂરી આપે છે કે subagent કયા ટૂલ્સનો ઉપયોગ કરી શકે છે. આ 'least-privilege security' માટે ઉપયોગી છે. પરંતુ તે જોખમી પણ બની શકે છે. જો તમે subagent માટે કસ્ટમ ટૂલ લિસ્ટ બનાવો છો અને Agent ટૂલનો સમાવેશ કરવાનું ભૂલી જાઓ છો, તો તે subagent એક 'leaf node' બની જાય છે. તે વધુ વર્કર્સ બનાવી શકતું નથી. જો તમારું ડિઝાઇન અન્ય એજન્ટ્સના સ્તરને સંકલિત કરવાની અપેક્ષા રાખતું હોય, તો તે સૂચના Suhail ની જેમ જ શાંતિથી નિષ્ફળ જશે. મોડેલ સૂચના જોશે, કોઈ ટૂલ નહીં મળે, અને તે કામ જાતે જ સંભાળી લેશે.

Depth limits. Claude Code નેસ્ટિંગ (nesting) પર મર્યાદા લાદે છે. Subagents પાંચ સ્તર સુધી અન્ય subagents બનાવી શકે છે. જો તમે તે મર્યાદા પર પહોંચો છો, તો Agent ટૂલ અદૃશ્ય થઈ જાય છે. આ કોઈ બગ નથી. તે અનિયંત્રિત રિકર્ઝન (recursion) સામેનો એક સુરક્ષા કવચ (guardrail) છે. પરંતુ જો તમારું આર્કિટેક્ચર છઠ્ઠા સ્તરના પ્રતિનિધિત્વની અપેક્ષા રાખતું હોય, તો તે સ્તર શાંતિથી ઓગળી જશે. પાંચમા સ્તરનો એજન્ટ તેના બાળકો માટેના કાર્યો પોતે જ કરી લેશે. તમારું વૃક્ષ એક ઝાડીમાં ફેરવાઈ જશે, અને જ્યાં સુધી તમે દરેક આઉટપુટના મૂળ (provenance) ની તપાસ ન કરો ત્યાં સુધી તમને ખબર પણ નહીં પડે.

સેશન ટૂલ્સ. AskUserQuestion જેવા અમુક ટૂલ્સ ટોપ-લેવલ સેશન સાથે જોડાયેલા હોય છે. તેઓ સબ-એજન્ટ્સમાં (subagents) જઈ શકતા નથી. જો કોઈ મોકલેલ વર્કર (dispatched worker) અસ્પષ્ટતાનો સામનો કરે અને સ્પષ્ટતા માંગવાનો પ્રયાસ કરે, તો તે કરી શકતું નથી. કારણ કે તે ટૂલ ઉપલબ્ધ નથી હોતું. વપરાશકર્તાને ચેતવણી આપવાને બદલે, મોડેલ અનુમાન લગાવશે. તમે કદાચ શું કહેવા માંગતા હતા તેનો તે અર્થઘટન કરશે. ક્યારેક તે સાચું અનુમાન લગાવે છે, તો ક્યારેક તે ખોટી ફીચર બનાવી દે છે. ગમે તે હોય, તમને જવાબ આપવાની તક ક્યારેય મળતી નથી.

તે તમને મોંઘું પડે તે પહેલાં તેને કેવી રીતે પકડવું

તમે દરેક ખોટી ગોઠવણી (misconfiguration) ને રોકી શકતા નથી, પરંતુ તમે ટ્રાન્સક્રિપ્ટને કામના પુરાવા તરીકે માનવાનું બંધ કરી શકો છો.

વાતચીત વાંચવી એ સંરક્ષણની પ્રથમ હરોળ છે. જો લખાણમાં "dispatching the researcher" લખ્યું હોય પરંતુ વાસ્તવિક સંશોધન સામગ્રી (research content) તે જ વિન્ડોમાં દેખાય છે, તો તેનો અર્થ છે કે ડિસ્પેચ (dispatch) ક્યારેય થયું જ નથી. મોડેલે માત્ર એક ક્રિયાનું વર્ણન કર્યું અને પછી તે ક્રિયા પોતે જ કરી નાખી. Claude Code નું પોતાનું પેનલ આ વાતની પુષ્ટિ કરશે. તમે જે એજન્ટ પાસેથી સબ-એજન્ટ્સ (children) ની અપેક્ષા રાખતા હોવ, તેના 'descendants count' તપાસો. જો તે શૂન્ય બતાવે છે, તો તમારી હાયરાર્કી (hierarchy) કાલ્પનિક છે.

તે વિઝ્યુઅલ ચેક્સ ઉપયોગી છે, પરંતુ તે હજુ પણ માનવીય ધ્યાન પર આધારિત છે. વધુ સારો અભિગમ એ છે કે આર્ટિફેક્ટ વેરિફિકેશન (artifact verification) સાથે સિસ્ટમને મજબૂત બનાવવી.

દરેક ડિસ્પેચ પછી, મારી સિસ્ટમ હવે એક ચોક્કસ, અપેક્ષિત ફાઇલ તપાસે છે. રિસર્ચર દ્વારા research.md બનાવવું જ જોઈએ. કોડર દ્વારા diff છોડવો જ જોઈએ. રિવ્યુઅર દ્વારા review_notes.json લખવું જ જોઈએ. જો ફાઇલ અસ્તિત્વમાં ન હોય, તો પાઇપલાઇન તરત જ અટકી જાય છે. કોઈ અપવાદ નહીં, કોઈ ગ્રેસફુલ ડિગ્રેડેશન (graceful degradation) નહીં. ઓર્કેસ્ટ્રેટર (orchestrator) અટકી જાય છે અને રિપોર્ટ કરે છે કે ડિસ્પેચ નિષ્ફળ ગયું છે. આનાથી બોજ મોડેલના વર્ણન પરથી બદલાઈને નક્કર પરિણામો (concrete deliverables) પર આવી જાય છે.

તમારી મર્યાદાઓ (constraints) ને ફક્ત એન્કોડ કરીને મોડેલ તેનું પાલન કરશે તેવી આશા ન રાખો. તેના બદલે એવા ચેક્સ (checks) એન્કોડ કરો જે સાબિત કરે કે મર્યાદાઓનું પાલન થયું છે. મોડેલ પ્રોમ્પ્ટમાં આપેલી કોઈ નિયમની અવગણના કરી શકે છે, પરંતુ તે એવી ખૂટતી ફાઇલની અવગણના કરી શકતું નથી જેના પર પછીનું સ્ટેપ નિર્ભર હોય.

અવિશ્વાસ માટે નિર્માણ કરો

સુહેલનો પાઠ માત્ર Claude Code ફોલ્ડર કન્વેન્શન વિશે નથી. તે એજન્ટિક સિસ્ટમ્સ (agentic systems) સાથે કામ કરવાના વ્યાપક વાસ્તવિકતા વિશે છે. આ મોડેલ્સ ઓપ્ટિમાઇઝર્સ (optimizers) છે. જ્યારે તમે બનાવેલો રસ્તો અવરોધાય છે, ત્યારે તેઓ બીજો રસ્તો શોધી લેશે. ઘણીવાર તે રસ્તો તેમના પોતાના વેટ્સ (weights) દ્વારા લેવામાં આવેલો શોર્ટકટ હોય છે. તેઓ કામ પોતે જ કરી લેશે, હેન્ડઓફ (handoff) સ્કીપ કરશે અને તમને એક યોગ્ય લાગે તેવું પરિણામ આપી દેશે.

બિલ્ડર તરીકે તમારું કામ શંકાશીલ રહેવાનું છે. જ્યાં સુધી આર્ટિફેક્ટ કંઈક બીજું સાબિત ન કરે ત્યાં સુધી માની લો કે ડિસ્પેચ નિષ્ફળ ગયું છે. તમારા ઓર્કેસ્ટ્રેશન લેયરને માત્ર કાર્યો સોંપવા માટે જ નહીં, પરંતુ તે કાર્ય યોગ્ય વર્કર દ્વારા સ્વીકારવામાં આવ્યું છે તેની ખાતરી કરવા માટે ડિઝાઇન કરો. સ્ટ્રક્ચર બનાવવું સસ્તું છે, પરંતુ વેરિફિકેશન જ સ્ટ્રક્ચરને પ્રમાણિક રાખે છે.

સ્ત્રોત: Why Your Claude Code Orchestrator Silently Stops Dispatching Subagents

ચર્ચામાં જોડાઓ: GyaanSetu AI Community on Telegram