મારા AI એજન્ટોએ અમારી ટીમ ચેટમાં પરિણામો પોસ્ટ કર્યા. એક માણસે જવાબ આપ્યો, અને બીજો એજન્ટ પહેલા સંદેશને જોયા વિના જ વચ્ચે આવી ગયો. આના કારણે સંદર્ભ ગુમાવવો, કામનું પુનરાવર્તન અને સીધી ભૂલો જેવી સમસ્યાઓ સર્જાઈ. હાલના મેમરી સર્વર અને મોનિટરિંગ સ્ટેક સાથે એક હળવું Inter-Agent Communication Protocol (IACP) જોડ્યા પછી, આ અરાજકતા અટકી ગઈ અને વર્કફ્લો વધુ સચોટ બન્યો.

સમસ્યા શા માટે મહત્વની હતી

પ્રોડક્શનમાં, AI એજન્ટો હવે માત્ર અલગ પ્રયોગો નથી; તેઓ માઇક્રો-સર્વિસ તરીકે કામ કરે છે જે ડેટા મેળવે છે, કોડ જનરેટ કરે છે અથવા ડિપ્લોયમેન્ટ્સ ટ્રિગર કરે છે. જ્યારે દરેક એજન્ટ ફક્ત માણસો સાથે જ વાત કરે છે, ત્યારે જવાબદારીઓનું ઓવરલેપિંગ એક છુપી race condition બની જાય છે. એક સામાન્ય Slack મેસેજ નિર્દોષ લાગે છે, પરંતુ ડેવલપર્સ વિરોધાભાસી આઉટપુટને ઉકેલવામાં મિનિટો બગાડે છે, જ્યારે બે બોટ્સ એક જ રિપોઝિટરીમાં એડિટ કરે ત્યારે પાઇપલાઇન્સ અટકી જાય છે, અને ઓટોમેશન પરનો વિશ્વાસ ઘટે છે.

ખૂટતી કડી: રીઅલ-ટાઇમ શેર કરેલ સ્ટેટ

મોટાભાગની ટીમો એજન્ટોને “black boxes” તરીકે જુએ છે જે પ્રોમ્પ્ટ મેળવે છે અને પરિણામ આપે છે, એવું માનીને કે પ્રોમ્પ્ટમાં તમામ જરૂરી સંદર્ભ હોય છે. વાસ્તવમાં, એજન્ટો એક એવા વર્કસ્પેસ શેર કરે છે જ્યાં સ્ટેટ સતત બદલાતું રહે છે: એક રિપોઝિટરી લોક હોઈ શકે છે, કોઈ સર્વિસ ડાઉન હોઈ શકે છે, અથવા અગાઉનું વિશ્લેષણ હમણાં જ પૂર્ણ થયું હોઈ શકે છે. બ્રોડકાસ્ટ મિકેનિઝમ વગર, દરેક બોટ જૂના સ્નેપશોટ (stale snapshot) પરથી કામ કરે છે.

હાલના ટૂલ્સ પર IACP બનાવવું

નવું પ્લેટફોર્મ બનાવવાને બદલે, મેં કન્વર્સેશન હિસ્ટ્રી સ્ટોર કરતા મેમરી સર્વર અને એજન્ટ હેલ્થ ટ્રેક કરતા મોનિટરિંગ સૂટનો વિસ્તાર કર્યો. આ પ્રોટોકોલ પાંચ ચોક્કસ ક્ષમતાઓ ઉમેરે છે:

  • Structured Identity – દરેક આઉટબાઉન્ડ મેસેજમાં claude@greenmac:8f3a2c જેવો યુનિક આઈડેન્ટિફાયર હોય છે. આ ફોર્મેટ તરત જ પ્રાપ્તકર્તાને જણાવે છે કે મેસેજ કોણે અને કયા ઇન્સ્ટન્સમાંથી મોકલ્યો છે, જેનાથી અસ્પષ્ટ “bot says X” જેવા વિધાનો દૂર થાય છે.

  • History Injection – જવાબ જનરેટ કરતા પહેલા, બોટ અન્ય એજન્ટોના મેસેજ સહિતનો તાજેતરનો ચેટ સેગમેન્ટ ખેંચે છે અને તેને તેના પ્રોમ્પ્ટની આગળ જોડે છે. આથી સંદર્ભ ક્યારેય ખોવાતો નથી, અને મોડેલ તેના સાથીઓએ અગાઉ શું યોગદાન આપ્યું છે તેના વિશે તર્ક કરી શકે છે.

  • State Transitions – એજન્ટો વારંવાર હાર્ટબીટ્સ (heartbeats) મોકલવાનું બંધ કરે છે. તેના બદલે, જ્યારે પણ તેમનું આંતરિક સ્ટેટ બદલાય ત્યારે તેઓ સ્ટેટસ ચેન્જ—working, blocked, અથવા idle—પોસ્ટ કરે છે. કન્ઝ્યુમર્સ તરત જ પ્રતિક્રિયા આપે છે, ઉદાહરણ તરીકે, જ્યારે અપસ્ટ્રીમ એજન્ટ idle રિપોર્ટ કરે ત્યારે જ ડિપેન્ડન્ટ ટાસ્કને ક્યુ (queue) માં મૂકે છે.

  • Advisory Leases – જ્યારે એજન્ટને કોઈ રિસોર્સ (એક રિપો, એક API એન્ડપોઈન્ટ, એક કમ્પ્યુટ નોડ) માટે એક્સક્લુઝિવ એક્સેસની જરૂર હોય, ત્યારે તે TTL (time-to-live) સાથે લીઝ (lease) ક્લેમ કરે છે. જો એજન્ટ ક્રેશ થાય, તો લીઝ આપમેળે સમાપ્ત થઈ જાય છે, જે રિસોર્સને અન્ય માટે મુક્ત કરે છે અને બે બોટ્સને એકબીજાના કામમાં અવરોધ આવતા અટકાવે છે.

  • Inbox Mechanism – જો ઇનબોક્સમાં વણપઢેલા મેસેજ હોય, તો “stop hook” એજન્ટના વર્કફ્લોને સ્થગિત કરે છે. એજન્ટે તેનું વર્તમાન કાર્ય પૂર્ણ કરતા પહેલા તે આઇટમ્સ પર પ્રક્રિયા કરવી આવશ્યક છે, જે સુનિશ્ચિત કરે છે કે પેન્ડિંગ કોઓર્ડિનેશન સિગ્નલ્સની અવગણના ન થાય.

આ ભાગો મળીને એક સરળ, અવલોકનક્ષમ (observable) કોમ્યુનિકેશન લેયર બનાવે છે જે દરેક સહભાગીને સમાન માહિતી સાથે રાખે છે.

જે ટીમો તેને અવગણે છે તેમના માટેના જોખમો

જો કોઈ ટીમ એડ-હોક પ્રોમ્પ્ટ્સ અને મેન્યુઅલ મોનિટરિંગ પર નિર્ભર રહે છે, તો છુપા ખર્ચાઓ વધતા જાય છે:

  • Duplicated effort – બે એજન્ટો સમાન રિપોર્ટ્સ જનરેટ કરી શકે છે, જેનાથી કમ્પ્યુટ સાયકલ અને ક્લાઉડ ખર્ચ વધે છે.
  • Resource contention – કોડબેઝમાં એકસાથે થતા રાઈટ્સ (writes) મર્જ કોન્ફ્લિક્ટ્સ (merge conflicts) પેદા કરે છે જેના માટે માનવીય હસ્તક્ષેપની જરૂર પડે છે.
  • Operational risk – જૂના સ્ટેટસ પર કામ કરતો એજન્ટ ડિપ્લોયમેન્ટનો પ્રયાસ કરી શકે છે જ્યારે બીજો એજન્ટ પહેલેથી જ રોલબેક કરી રહ્યો હોય, જેનાથી સર્વિસ અસ્થિર થઈ શકે છે.

એજન્ટો કેવી રીતે ઓળખ, સ્ટેટ અને રિસોર્સ ક્લેમ્સ જાહેર કરે છે તેને ઔપચારિક બનાવીને, IACP કોઈ હેવીવેઇટ ઓર્કેસ્ટ્રેશન એન્જિનની માંગ કર્યા વિના આ જોખમો ઘટાડે છે.

વિરોધ પક્ષ: વધારાનો ઓવરહેડ

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

આગળ શું જોવું

આ પ્રોટોકોલ હજુ પ્રોટોટાઇપ છે, પરંતુ તેનું મોડ્યુલર સ્વરૂપ કોઈપણ લેંગ્વેજ-એગ્નોસ્ટિક (language-agnostic) એજન્ટ ફ્રેમવર્ક સાથે સંકલન માટે આમંત્રણ આપે છે. સંભવિત આગામી પગલાઓમાં શામેલ છે:

  • એક લાઇટવેઇટ SDK પ્રકાશિત કરવું જેથી ડેવલપર્સ કોર લોજિકમાં ફેરફાર કર્યા વિના પાંચ હૂક્સ ઉમેરી શકે.
  • મોનિટરિંગ સૂટમાં એવા મેટ્રિક્સ ઉમેરવા જે સ્ટેટ ટ્રાન્ઝિશન અને લીઝ ચર્નને વિઝ્યુઅલાઈઝ કરે, જે ટીમોને અવરોધો (bottlenecks) શોધવામાં મદદ કરે.
  • પોલિસી લેયર્સ સાથે પ્રયોગો કરવા જે હાઈ-ટ્રાફિક પરિસ્થિતિઓમાં અન્ય કરતા અમુક એજન્ટ્સની લીઝને આપમેળે પ્રાધાન્ય આપે.

જો આ એક્સ્ટેન્શન લોકપ્રિયતા મેળવશે, તો IACP મલ્ટી-એજન્ટ પ્રોડક્શન પાઇપલાઇન્સ માટે એક ડી-ફેક્ટો સ્ટાન્ડર્ડ બની શકે છે, જેમ કે HTTP એ વેબ સેવાઓ માટે કર્યું હતું.

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