એજન્ટનું પ્રદર્શન સુધારવા મથતી મોટાભાગની AI ટીમો એ જ ઉપાયો અજમાવે છે: મોટી સંદર્ભ વિન્ડો, વધુ દસ્તાવેજો અને વધુ ચતુર પ્રોમ્પ્ટ. આ લેખ દલીલ કરે છે કે આ વૃત્તિ જ સંપૂર્ણપણે ખોટી છે. ખૂટતું ઘટક વધુ માહિતી નથી. તે નિયંત્રણ છે. સારી રીતે રચાયેલું નિયંત્રણ સ્તર જ ડેમોમાં ચાલતા એજન્ટને પ્રોડક્શનમાં ચાલતા એજન્ટથી અલગ પાડે છે.
AI એજન્ટને મોટી સ્મૃતિ, વધુ દસ્તાવેજો અથવા લાંબી સંદર્ભ વિન્ડો આપવાથી તે વધુ બુદ્ધિશાળી બનતો નથી, માત્ર ધીમો અને ખર્ચાળ બને છે. ખરો લાભ એજન્ટને એકસાથે બધું વાપરવાને બદલે તેને શું અને ક્યારે જોઈએ તે પસંદ કરતાં શીખવવાથી મળે છે.
વિશ્વસનીયતા મોડલમાંથી નહીં, લૂપમાંથી આવે છે. ડેમોમાં પ્રભાવિત કરતા અને પ્રોડક્શનમાં ટકી રહેતા એજન્ટ વચ્ચેનો તફાવત AIની ગુણવત્તા નહીં, પણ સિસ્ટમ પોતાનું કામ ચકાસે છે કે નહીં તે છે. દરેક પગલે યોજના, ક્રિયા, નિરીક્ષણ અને ચકાસણી કરતા એજન્ટો આત્મવિશ્વાસપૂર્વક ખોટા પડવાને બદલે પોતાની ભૂલો જાતે પકડે છે.
આજના મોટાભાગના AI એજન્ટો મૂળભૂત રીતે વધારાનાં પગલાંવાળા ચૅટબોટ છે. તેઓ સાચી દિશામાં છે કે નહીં, ક્યારે રોકાવું કે ક્યારે જુદો અભિગમ અજમાવવો તે જાણવાની કોઈ વ્યવસ્થા ધરાવતા નથી. યોગ્ય નિયંત્રણ સ્તર—સ્પષ્ટ સફળતા માપદંડ, સંરચિત સ્થિતિ અને માન્યતા ચકાસણીઓ—ઉમેરવાથી જ એજન્ટ જેવા દેખાતા ઑબ્જેક્ટને ખરેખર વિશ્વસનીય બનાવી શકાય છે.
તમે ગઈકાલે બપોરે શું ખાધું હતું?
સંભવતઃ તમે “ગઈકાલ + બપોરનું ભોજન” મળે ત્યાં સુધી જીવનની દરેક સ્મૃતિ ફરી યાદ નહીં કરી હોય. તમે સીધા અનુભવના એ ભાગ પર ગયા હશો જ્યાં આ વિચારો વસે છે. એજન્ટો બનાવવા માટે આ એક ઉપયોગી માનસિક મોડલ છે:
વિશાળ સંદર્ભ વિન્ડો સ્મૃતિ નથી.
મેળવેલા દસ્તાવેજોનો ઢગલો સમજણ નથી.
લાંબી ચેન-ઓફ-થોટ વિશ્વસનીયતા નથી.
એ તો ઘટકો છે. પરંતુ એજન્ટને ખરેખર એજન્ટ જેવો બનાવતી વસ્તુ એ જ છે, જેના કારણે તમારું મગજ આખા જીવનના ઇતિહાસને જબરદસ્તીથી તપાસતું નથી: નિયંત્રણ.
તાજેતરના એક સર્વે—વિશાળ ભાષા મોડલ માટે એજન્ટિક রিজনিং—એ સિસ્ટમ બનાવતી વખતે આપણામાંથી ઘણાએ અનુભવેલા પરિવર્તનનો ઉત્તમ સાર આપ્યો (અને નામ આપ્યું): મોડલની અંદરના રિઝનિંગથી આંતરક્રિયા દ્વારા રિઝનિંગ તરફ. આ પોસ્ટ એ સંશોધનપત્રનો સારાંશ નથી. તે આ પરિવર્તનને વ્યવહારુ સિસ્ટમ ડિઝાઇનમાં ઉતારવાનો પ્રયાસ છે:
જો તમે એજન્ટોને ટૂલવાળા ચૅટબોટની જેમ બનાવશો, તો ચૅટબોટ જેવી નિષ્ફળતાઓ મળતી રહેશે, બસ ભૂલો વધુ ખર્ચાળ હશે.
થોડા સમય સુધી “મોડલને વધુ બુદ્ધિશાળી બનાવવા” માટેની આપણી ડિફૉલ્ટ રીત હતી: વધુ સારા પ્રોમ્પ્ટ, ચેન-ઓફ-થોટ, સ્વ-સુસંગતતા / સૅમ્પલિંગ-આધારિત સુધારા અને કદાચ થોડી શોધ.
ReAct એક નિર્ણાયક વળાંક હતો, કારણ કે તેણે “વિચાર → ક્રિયા → નિરીક્ષણ”ને સ્વાભાવિક બનાવ્યું. પરંતુ છૂપી મર્યાદા નોંધો: આમાંનું ઘણું હજુ પણ “વન-શોટ અનુમાન, પણ વધુ ટોકન સાથે” બની રહે છે. સર્વેનું માળખું વધુ સચોટ છે: એજન્ટિક રિઝનિંગ ટેસ્ટ-ટાઇમ આંતરક્રિયાને વિસ્તારવા પર ભાર મૂકે છે—અનુમાનને એવી પુનરાવર્તિત પ્રક્રિયામાં ફેરવે છે જેમાં મોડલ, સ્મૃતિ અને પર્યાવરણ બધાં લૂપમાં રહે છે.
જો તમે ડેમોમાં પ્રભાવશાળી પણ વાસ્તવિક વર્કફ્લોમાં નાજુક લાગતા એજન્ટો બનાવ્યા (અથવા વાપર્યા) હોય, તો આ તમારા માટે છે.
મેં વારંવાર જોયેલી (અને ચોક્કસપણે જાતે પણ બનાવેલી) એક પેટર્ન સમજાવું:
સારું ચૅટ મોડલ લો
થોડાં ટૂલ ઉમેરો (શોધ, DB ક્વેરી, કદાચ કોડ ચલાવવો)
RAG ઉમેરો
“તમે સ્વાયત્ત એજન્ટ છો” એવો સિસ્ટમ પ્રોમ્પ્ટ ઉમેરો
તે રોકાય અથવા સમયમર્યાદા પૂરી થાય ત્યાં સુધી બધું વ્હાઇલ-લૂપમાં ચલાવો
અભિનંદન, તમારી પાસે એજન્ટ જેવો દેખાતો ઑબ્જેક્ટ છે. પરંતુ તે સામાન્ય રીતે અનુમાન કરી શકાય એવી રીતે નિષ્ફળ જાય છે:
સંદર્ભનો ફુગાવો: દરેક નિરીક્ષણ ઉમેરાતું જાય છે; પ્રોમ્પ્ટ પુરાતત્ત્વીય સ્તરો જેવા બની જાય છે.
ટૂલનો આડેધડ ઉપયોગ: “ખોટું ટૂલ, પણ પૂરા આત્મવિશ્વાસથી” ડિફૉલ્ટ નિષ્ફળતા બની જાય છે.
રોકાવાની કોઈ શરતો નહીં: જરૂરી હોવાથી નહીં, પરંતુ ચાલુ રહી શકે છે એટલે તે ચાલુ રહે છે.
ગ્રાઉન્ડિંગની શિસ્ત નહીં: તમે ફરજ ન પાડો ત્યાં સુધી તે પોતે ખોટું છે એ જાણતું નથી.
મેમરી = ચૅટ ઇતિહાસ: જે મૂળભૂત રીતે લૉગ લખીને તેને શીખવાનું નામ આપવા જેવું છે.
એટલે જ “એજન્ટો” ડેમોમાં જાદુઈ અને પ્રોડક્શનમાં અવ્યવસ્થિત લાગે છે. એજન્ટિક સિસ્ટમોને પ્રોડક્શનમાં મૂકવાનો અમારો અનુભવ પણ આ જ દર્શાવે છે: મોડલને બદલે સિસ્ટમનું મૂલ્યાંકન શરૂ કરતાં નિષ્ફળતાની રીતોમાં નેવિગેશન, ટૂલની સુવ્યવસ્થા, સંદર્ભની કાપછાંટ અને મૂલ્યાંકન ડિઝાઇનનો સમાવેશ થાય છે, માત્ર “મોડલે સાચો જવાબ આપ્યો કે નહીં” એટલું નહીં.
તો પ્રશ્ન એ થાય છે: હેતુપૂર્વક રચાયેલ એજન્ટ કેવો હોય?
આને ઓછું અમૂર્ત બનાવવા માટે, મોટાભાગના લોકો કલ્પી શકે એવો એક સરળ વર્કફ્લો જોઈએ: “આવતા મંગળવારે લંડનથી ન્યૂ યૉર્કની મારી ફ્લાઇટ બુક કરો. સાંજે 6 વાગ્યા પહેલાં પહોંચે. કિંમત £900થી ઓછી રાખો. પાંખા તરફની બેઠક રાખો.”
“એજન્ટ જેવા દેખાતા” સામાન્ય અમલીકરણનું સ્વરૂપ આવું હોય છે:
તરત જ એરલાઇન / મુસાફરી નીતિના અનેક દસ્તાવેજો મેળવી લે છે, ભલે હજુ એક પણ જરૂરી ન હોય.
સર્ચ ટૂલને કૉલ કરે છે, પરિણામોની લાંબી યાદી પ્રોમ્પ્ટમાં ચોંટાડે છે અને “એક પસંદ કરે છે.”
મર્યાદાઓ (પહોંચવાનો સમય / સામાન / બેઠક / નીતિ) ચકાસ્યા વિના ઉતાવળે બુકિંગ કરે છે.
નિષ્ફળ જાય તો થોડી જુદી રીતે ફરી પ્રયાસ કરે છે, પરંતુ શું બદલાયું અથવા શું શીખ્યું તેની સ્પષ્ટ સમજ વિના.
નિષ્ફળતાનું કારણ મોડલ રિઝનિંગ ન કરી શકે તે નથી, પણ સિસ્ટમ વર્કફ્લોને નિયંત્રિત કરતી નથી તે છે.
વધુ એજન્ટિક આવૃત્તિ કાર્યને સ્પષ્ટ સ્થિતિ અને ચકાસણીઓ ધરાવતી આંતરક્રિયાત્મક પ્રક્રિયા તરીકે જુએ છે:
યોજના: મર્યાદાઓ ફરી જણાવો + ખૂટતી માહિતીની યાદી બનાવો (દા.ત., “કયા એરપોર્ટની પસંદગી છે?” / “એક સ્ટૉપ ચાલશે?”).
ક્રિયા: સંરચિત ક્વેરી (તારીખની અવધિ, પહોંચવાના સમયની મર્યાદા, બજેટ) સાથે ફ્લાઇટ શોધને કૉલ કરો.
નિરીક્ષણ: પરિણામોને ચોંટાડેલા વિશાળ ઢગલા તરીકે નહીં, પરંતુ સંક્ષિપ્ત સ્થિતિ ઑબ્જેક્ટમાં સંગ્રહો (કિંમત/પહોંચ/વચગાળાના સ્ટૉપ સાથે ટોચના 5 વિકલ્પો).
અપડેટ: મર્યાદાઓ પૂરી ન થાય તો ક્વેરી સુધારો (દા.ત., “સાંજે 6 પહેલાં પહોંચવાની મર્યાદા બહુ કડક છે—સમયની અવધિ વધારીએ કે બજેટ?”).
ચકાસણી: વૅલિડેટર ચલાવો (“પહોંચ < 18:00,” “કિંમત ≤ £900,” “નીતિનું પાલન,” “બેઠક પસંદ કરવાની સુવિધા ઉપલબ્ધ”).
રોકો: બુકિંગ API પુષ્ટિ આપે અને બધા વૅલિડેટર સફળ થાય પછી જ.
જે બદલાયું તે સૂક્ષ્મ છે, પણ નિર્ણાયક છે. માહિતી મેળવવી શરતી છે (આપમેળે થતી પ્રતિક્રિયા નહીં), સંદર્ભનું સંચાલન થાય છે (સ્થિતિ સંરચિત છે, એકઠી કરેલી નથી) અને ચકાસણી લૂપમાં જ છે (વપરાશકર્તા પર છોડેલી નથી). “ફ્લાઇટ બુક કરવી”ને બદલે “ખરીદીનો ઑર્ડર બનાવવો,” “રિફંડ આપવું,” “પ્રોડક્શન કૉન્ફિગ બદલવું” અથવા “PR મોકલવો” મૂકો તો વાત એ જ છે: એજન્ટ ક્રિયા કરી શકે પછી પ્રોમ્પ્ટ કરતાં લૂપ વધુ મહત્ત્વની બને છે.
ઉપર જણાવેલો સર્વે એજન્ટિક রিজনিংને ત્રણ સ્તરમાં ગોઠવે છે: પાયાનું (આયોજન/ટૂલનો ઉપયોગ/શોધ), સ્વ-વિકસતું (પ્રતિસાદ + સ્મૃતિ) અને સામૂહિક (બહુ-એજન્ટ સંકલન).
પરંતુ ઊંડો વિચાર એ છે કે রিজনিং માત્ર વિશ્વસનીય લાગતી ચેન-ઓફ-થોટ પેદા કરવાને બદલે આયોજન, નિર્ણય અને ચકાસણીનો મુખ્ય ગોઠવણી સિદ્ધાંત બને છે. તમારા આર્કિટેક્ચરમાં આવતા ફેરફારો સાથે તેને જોડો નહીં ત્યાં સુધી આ અમૂર્ત લાગે છે. યાદ રાખવા જેવા ત્રણ મુખ્ય મુદ્દા છે:
સારા એજન્ટે માહિતી મેળવવાને “હંમેશાં કરવાનું કામ” ન માનવું જોઈએ. તે નિર્ણય છે, આપમેળે થતી પ્રતિક્રિયા નહીં.
આ એક વ્યવહારુ માર્ગદર્શક નિયમ છે:
જો તમારી સિસ્ટમ દરેક વાર્તાલાપમાં માહિતી મેળવે છે, તો તમે માહિતી મેળવવાની વ્યવસ્થા નહીં, પણ સંદર્ભ વેરો બનાવ્યો છે.
વાસ્તવિક કામમાં આવું હંમેશાં જોવા મળે છે. પ્રોડક્શન ઘટનાને ડિબગ કરતી વખતે તમે બધા લૉગ સંદર્ભમાં ઠાલવતા નથી; તમારી હાલની પરિકલ્પનાના આધારે આગળ કયા મેટ્રિક્સ/લૉગ મેળવવા તે નક્કી કરો છો. આ છે “એજન્ટિક માહિતીપ્રાપ્તિ.” આ રહી વધુ નક્કર પેટર્ન:
માહિતી મેળવવાની જરૂર છે કે નહીં તે નક્કી કરો
હા હોય તો: ક્વેરી તૈયાર કરો, માહિતી મેળવો, ઉપરછલ્લું વાંચો, સાર કાઢો
પુરાવા વિરોધાભાસી હોય તો: ફરી માહિતી મેળવો
ત્યાર પછી જ સંકલન કરો
અહીં જ “એજન્ટિક RAG” પરંપરાગત RAGથી અલગ થવા લાગે છે: માહિતી મેળવવી ડિફૉલ્ટ પાઇપલાઇન તબક્કો નહીં, પરંતુ વિચારપૂર્વકનું રિઝનિંગનું પગલું બને છે.
તમે “મોડલ”નું મૂલ્યાંકન છોડીને “સિસ્ટમ”નું મૂલ્યાંકન શરૂ કરો, ત્યારથી સ્થિતિનું ટ્રૅકિંગ અને ટ્રેસિંગ મહત્ત્વનાં બની જાય છે.
ઉદ્યોગ હવે એજન્ટ વર્કફ્લોની નિરીક્ષણક્ષમતા વિશે વધુ સ્પષ્ટ બન્યો છે. ઉદાહરણ તરીકે, OpenAIનું Agents SDK બિલ્ટ-ઇન ટ્રેસિંગ અને Traces ડૅશબોર્ડ સાથે આવે છે, જે એજન્ટની કામગીરીઓ (જનરેશન, ટૂલ કૉલ, હૅન્ડઑફ, ગાર્ડરેલ અને કસ્ટમ ઇવેન્ટ) નોંધે છે, જેથી તમે દરેક પગલે શું થયું તે ડિબગ અને ઑડિટ કરી શકો.
આ માત્ર “હોય તો સારું” એવી વસ્તુ નથી. આ જ ડિબગ કરી શકાય તેવી સિસ્ટમ અને માત્ર ઉપરછલ્લી રીતે ચકાસી શકાય તેવી સિસ્ટમ વચ્ચેનો તફાવત છે.
મારા મતે, સર્વેનો સૌથી વ્યવહારુ ભાગ એ છે કે તે પ્રતિસાદ વિશે કેટલી સીધી વાત કરે છે. તે પ્રતિસાદને ત્રણ પદ્ધતિમાં વહેંચે છે: ચિંતનાત્મક પ્રતિસાદ (બનાવો → સમીક્ષા કરો → સુધારો), પેરામેટ્રિક અનુકૂલન (ફાઇન-ટ્યુનિંગ / RL દ્વારા શીખવું) અને વૅલિડેટર-સંચાલિત પ્રતિસાદ (વૅલિડેટર સફળ થાય ત્યાં સુધી ફરી પ્રયાસ કરવો).
મોટાભાગની ટીમોએ વૅલિડેટર-સંચાલિત પ્રતિસાદથી શરૂઆત કરવી જોઈએ, કારણ કે તે સાદો અને અસરકારક છે. જો તમે યુનિટ ટેસ્ટ કરતું, સ્કીમા તપાસતું, વ્યવસાયિક નિયમો / મર્યાદાઓ નક્કી કરતું (“ઉચ્ચ સ્તરે મોકલ્યા વિના Xથી વધુ રિફંડ નહીં”) અથવા તથ્યાત્મકતા સ્થાપિત કરતું (“સંદર્ભો જરૂરી”) કોઈ પણ વૅલિડેટર લખી શકો, તો અનિશ્ચિત મોડલ આઉટપુટને ખરેખર વિશ્વસનીય બનાવી શકો.
અહીંનો એક સરળ “અજ્ઞાત અજાણ્યા” પ્રકારનો ફેરફાર એ છે કે એજન્ટની દુનિયામાં વિશ્વસનીયતા ઘણીવાર મોડલ કરતાં લૂપમાંથી વધુ આવે છે.
તાલીમ વિના વર્તનમાં વિશ્વસનીય સુધારો કરતી મને મળેલી આ સૌથી નાની સુવ્યવસ્થિત લૂપ છે:
પગલાંમાં કામ કરો: યોજના → ક્રિયા → નિરીક્ષણ → અપડેટ,
દરેક ક્રિયા પછી નિરીક્ષણને 1–3 મુદ્દામાં સારાંશરૂપે લખો,
સફળતાના માપદંડ પૂરા થાય અથવા બજેટની મર્યાદા આવે ત્યારે રોકાઓ; અત્યાર સુધીનું શ્રેષ્ઠ પરિણામ + બાકી અનિશ્ચિતતાઓ આપો.
આનો હેતુ મોડલને વધુ શબ્દાળુ બનાવવાનો નથી. હેતુ સિસ્ટમને સમજવામાં સરળ બનાવવાનો અને દરેક પગલે “વાસ્તવિકતા સાથે સંપર્ક” ફરજિયાત કરવાનો છે. એન્જિનિયરોને ખૂબ જ પરિચિત લાગે એવું ઉદાહરણ CI-શૈલીનું ક્લોઝ્ડ-લૂપ ગ્રાઉન્ડિંગ છે:
યોજના: ફેરફારોની યાદી સૂચવો
ક્રિયા: ટેસ્ટ / લિન્ટ ચલાવો
નિરીક્ષણ: નિષ્ફળતાઓનું વિશ્લેષણ કરો
અપડેટ: પૅચ કરો અને ફરી પ્રયાસ કરો
અજાણતાં બનેલી એજન્ટ ડિઝાઇનને બહાર લાવતા કેટલાક પ્રશ્નો:
“શું મારો એજન્ટ શું મેળવવું તે પસંદ કરે છે કે હું હંમેશાં માહિતી મેળવી લઉં છું?”
જો માહિતી મેળવવી બિનશરતી હોય, તો તમારે વિલંબ, ખર્ચ, સંદર્ભનું મંદન અને ખરાબ ઇનપુટથી ખરાબ આઉટપુટનું વધેલું જોખમ ભોગવવું પડશે.
“શું મારો એજન્ટ પોતે ખોટો છે તે જાણી શકે છે?”
જો તમારા એજન્ટ માટે પ્રતિસાદનો એકમાત્ર સંકેત “વપરાશકર્તા નારાજ થાય છે” હોય, તો તમે માનવીય પીડા દ્વારા RL કરી રહ્યા છો. વૅલિડેટર-સંચાલિત પુનઃપ્રયાસ લૂપ તેને વાસ્તવિકતાની ચકાસણી આપવાની સૌથી સ્વચ્છ રીત છે.
“શું સ્મૃતિમાં લખી શકાય છે અને શું તે સમય જતાં સુધરે છે?”
જો તમારી “સ્મૃતિ” માત્ર ચૅટ ઇતિહાસ ઉમેરતી હોય, તો તમે મૂળભૂત રીતે લૉગ લખી રહ્યા છો. સર્વેમાં સ્મૃતિનું માળખું મહત્ત્વનું છે: સ્મૃતિ માત્ર પ્રતિલિપિ નહીં, પણ એજન્ટો સમય જતાં સુધારે એવો સતત વિકસતો સંદર્ભ બને છે.
લૉગ તમને શું થયું તે કહે છે, જ્યારે સ્મૃતિ આગલી વખતે શું કરવું તે કહે છે. ચૅટ ઇતિહાસ એક પ્રતિલિપિ છે. સ્મૃતિ એટલે આગળ શું સાચવી રાખવા જેવું છે તે અંગે સતત વિકસતી નીતિ.
વ્યવહારુ શરૂઆત તરીકે “શીખેલા પાઠ”નું નાનું કોષ્ટક બનાવો, જેમાં કાર્યનો પ્રકાર, ટૂલ અને નિષ્ફળતાની રીત કી તરીકે તથા શું કામ આવ્યું અને શું ટાળવું તે મૂલ્ય તરીકે ગોઠવાયેલાં હોય. હેતુ સંપૂર્ણ નૉલેજ ગ્રાફ બનાવવાનો નથી. હેતુ સતત વધતો લાભ આપતું વર્તન સર્જવાનો છે: સ્મૃતિ + પ્રતિસાદ એજન્ટોને “સ્થિતિવિહીન સહાયકો”માંથી સમય જતાં સુધરતી સિસ્ટમોમાં ફેરવે છે.
સમસ્યા પર વધુ એજન્ટો લગાવવાની લાલચ થાય છે, પરંતુ તે ઘણીવાર સંકલનનો વધારાનો ભાર અનેક ગણો કરે છે. “ન્યૂનતમ કાર્યક્ષમ ટીમ”ની સારી પેટર્ન:
સંકલનકર્તા: કાર્ય વિભાજિત કરે + સોંપે
કાર્યાન્વયકર્તા: ટૂલ કૉલ / ફેરફારો કરે
વિવેચક/મૂલ્યાંકનકર્તા: ચોકસાઈ/જોખમ તપાસે
સ્મૃતિ સંભાળનાર: પાઠ લખે/ચકાસીને ગોઠવે
દરેક એજન્ટની જવાબદારી શું છે તે તમે સમજાવી ન શકો, તો કદાચ તમને હજુ બહુવિધ એજન્ટોની જરૂર નથી.
જો આપણે ખરેખર આ માળખાકીય પરિવર્તન સ્વીકારીએ, તો કદાચ પ્રોમ્પ્ટમાં બધું ઠાંસવાનું, નિષ્ફળતાને અંતિમ આઉટપુટ માનવાનું અને એજન્ટોને ચૅટબોટની જેમ મૂલવવાનું બંધ કરીશું. અને એજન્ટોને તેઓ ખરેખર જે છે તેવા માનવાનું શરૂ કરીશું: ભાષા જેમનું નિયંત્રણ માધ્યમ છે એવી સૉફ્ટવેર સિસ્ટમો, જેમાં વિશ્વસનીયતા લૂપમાંથી આવે છે.
બીજું મોડલ ઉમેરતા પહેલાં બીજો મૂલ્યાંકન લૂપ ઉમેરો. બધી માહિતી મેળવતા પહેલાં તેને શરતી બનાવો. દસ વૅલિડેટર મોકલતાં પહેલાં એક મોકલો. સ્મૃતિને ડેટાબેઝ નહીં, પણ નીતિગત નિર્ણયો જેવી માનો. અને બહુ-એજન્ટ પદ્ધતિ અપનાવતી વખતે વીસ નહીં, બે એજન્ટથી શરૂ કરો. આ નિયમો નથી; આ એવી પેટર્ન છે જે પ્રોડક્શનમાં ટકી રહી છે.