ನನ್ನ AI ಏಜೆಂಟ್‌ಗಳು ನಮ್ಮ ತಂಡದ ಚಾಟ್‌ನಲ್ಲಿ ಫಲಿತಾಂಶಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡಿದವು. ಒಬ್ಬ ಮನುಷ್ಯ ಪ್ರತಿಕ್ರಿಯಿಸಿದಾಗ, ಮೊದಲ ಸಂದೇಶವನ್ನು ನೋಡದೆಯೇ ಎರಡನೇ ಏಜೆಂಟ್ ಮಧ್ಯಪ್ರವೇಶಿಸಿತು. ಈ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಸಂದರ್ಭದ ಮಾಹಿತಿಯನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು (missed context), ಕೆಲಸದ ಪುನರಾವರ್ತನೆ (duplicated work) ಮತ್ತು ತಪ್ಪುಗಳು ಸಂಭವಿಸಿದವು. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೆಮೊರಿ ಸರ್ವರ್ ಮತ್ತು ಮಾನಿಟರಿಂಗ್ ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ಲಘುವಾದ Inter-Agent Communication Protocol (IACP) ಅನ್ನು ಅಳವಡಿಸಿದ ನಂತರ, ಈ ಗೊಂದಲಗಳು ನಿಂತವು ಮತ್ತು ಕೆಲಸದ ಹರಿವು (workflow) ಸುಗಮವಾಯಿತು.

ಸಮಸ್ಯೆ ಏಕೆ ಮುಖ್ಯವಾಗಿತ್ತು

ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ, AI ಏಜೆಂಟ್‌ಗಳು ಕೇವಲ ಪ್ರತ್ಯೇಕ ಪ್ರಯೋಗಗಳಲ್ಲ; ಅವು ಡೇಟಾವನ್ನು ಪಡೆಯುವ, ಕೋಡ್ ಜನರೇಟ್ ಮಾಡುವ ಅಥವಾ ಡಿಪ್ಲಾಯ್‌ಮೆಂಟ್‌ಗಳನ್ನು ಪ್ರಚೋದಿಸುವ ಮೈಕ್ರೋ-ಸರ್ವಿಸ್‌ಗಳಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ ಕೇವಲ ಮನುಷ್ಯರೊಂದಿಗೆ ಮಾತ್ರ ಮಾತನಾಡಿದಾಗ, ಅತಿಕ್ರಮಿಸುವ ಜವಾಬ್ದಾರಿಗಳು ಗುಪ್ತವಾದ 'ರೇಸ್ ಕಂಡೀಶನ್' (race condition) ಆಗುತ್ತವೆ. ಒಂದು ಸಣ್ಣ Slack ಸಂದೇಶವು ಹಾನಿಕಾರಕವಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ವಿಭಿನ್ನವಾದ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಡೆವಲಪರ್‌ಗಳು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಎರಡು ಬಾಟ್‌ಗಳು ಒಂದೇ ರೆಪೊಸಿಟರಿಯನ್ನು ಎಡಿಟ್ ಮಾಡಿದಾಗ ಪೈಪ್‌ಲೈನ್‌ಗಳು ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಆಟೊಮೇಷನ್ ಮೇಲಿನ ವಿಶ್ವಾಸ ಕಡಿಮೆಯಾಗುತ್ತದೆ.

ಕಣ್ಮರೆಗೊಂಡ ಕೊಂಡಿ: ರಿಯಲ್-ಟೈಮ್ ಶೇರ್ಡ್ ಸ್ಟೇಟ್

ಹೆಚ್ಚಿನ ತಂಡಗಳು ಏಜೆಂಟ್‌ಗಳನ್ನು ಕೇವಲ ಪ್ರಾಂಪ್ಟ್ ಪಡೆದು ಫಲಿತಾಂಶವನ್ನು ನೀಡುವ "ಬ್ಲಾಕ್ ಬಾಕ್ಸ್"ಗಳಂತೆ ಪರಿಗಣಿಸುತ್ತವೆ, ಅಂದರೆ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ಅಗತ್ಯ ಮಾಹಿತಿ ಇದೆ ಎಂದು ಭಾವಿಸುತ್ತವೆ. ವಾಸ್ತವದಲ್ಲಿ, ಏಜೆಂಟ್‌ಗಳು ಒಂದು ಕೆಲಸದ ಸ್ಥಳವನ್ನು (workspace) ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ ಎಲ್ಲಿ ಸ್ಥಿತಿ (state) ನಿರಂತರವಾಗಿ ಬದಲಾಗುತ್ತಿರುತ್ತದೆ: ಒಂದು ರೆಪೊಸಿಟರಿ ಲಾಕ್ ಆಗಿರಬಹುದು, ಒಂದು ಸೇವೆ ಸ್ಥಗಿತಗೊಂಡಿರಬಹುದು ಅಥವಾ ಹಿಂದಿನ ವಿಶ್ಲೇಷಣೆಯು ಈಗಷ್ಟೇ ಮುಕ್ತಾಯಗೊಂಡಿರಬಹುದು. ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಮೆಕ್ಯಾನಿಸಂ ಇಲ್ಲದಿದ್ದರೆ, ಪ್ರತಿಯೊಂದು ಬಾಟ್ ಕೂಡ ಹಳೆಯ ಮಾಹಿತಿಯನ್ನೇ (stale snapshot) ಆಧರಿಸಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಕರಗಳ ಮೇಲೆ IACP ನಿರ್ಮಿಸುವುದು

ಹೊಸ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಬದಲು, ನಾನು ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸವನ್ನು ಸಂಗ್ರಹಿಸುವ ಮೆಮೊರಿ ಸರ್ವರ್ ಮತ್ತು ಏಜೆಂಟ್ ಆರೋಗ್ಯವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ ಮಾನಿಟರಿಂಗ್ ಸೂಟ್ ಅನ್ನು ವಿಸ್ತರಿಸಿದೆ. ಈ ಪ್ರೊಟೊಕಾಲ್ ಐದು ನಿರ್ದಿಷ್ಟ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ:

  • Structured Identity – ಪ್ರತಿಯೊಂದು ಹೊರಹೋಗುವ ಸಂದೇಶವು claude@greenmac:8f3a2c ನಂತಹ ವಿಶಿಷ್ಟ ಗುರುತನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಈ ಫಾರ್ಮ್ಯಾಟ್ ಸಂದೇಶವನ್ನು ಯಾರು ಮತ್ತು ಯಾವ ಇನ್‌ಸ್ಟೆನ್ಸ್‌ನಿಂದ ಕಳುಹಿಸಿದ್ದಾರೆ ಎಂಬುದನ್ನು ತಕ್ಷಣವೇ ತಿಳಿಸುತ್ತದೆ, ಇದರಿಂದ "ಬಾಟ್ X ಎಂದು ಹೇಳಿದೆ" ಎಂಬ ಅಸ್ಪಷ್ಟತೆ ನಿವಾರಣೆಯಾಗುತ್ತದೆ.

  • History Injection – ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಜನರೇಟ್ ಮಾಡುವ ಮೊದಲು, ಬಾಟ್ ಇತರ ಏಜೆಂಟ್‌ಗಳ ಸಂದೇಶಗಳು ಸೇರಿದಂತೆ ಇತ್ತೀಚಿನ ಚಾಟ್ ಭಾಗವನ್ನು ಪಡೆದು, ಅದನ್ನು ತನ್ನ ಪ್ರಾಂಪ್ಟ್‌ಗೆ ಸೇರಿಸುತ್ತದೆ. ಇದರಿಂದ ಸಂದರ್ಭದ ಮಾಹಿತಿ (context) ಎಂದಿಗೂ ಕಳೆದುಹೋಗುವುದಿಲ್ಲ ಮತ್ತು ಮಾಡೆಲ್ ತನ್ನ ಸಹೋದ್ಯೋಗಿಗಳು ಈಗಾಗಲೇ ಏನು ನೀಡಿದ್ದಾರೆ ಎಂಬುದರ ಬಗ್ಗೆ ವಿವೇಚಿಸಬಹುದು.

  • State Transitions – ಏಜೆಂಟ್‌ಗಳು ಪದೇ ಪದೇ ಹಾರ್ಟ್‌ಬೀಟ್‌ಗಳನ್ನು (heartbeats) ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ. ಬದಲಾಗಿ, ಅವುಗಳ ಆಂತರಿಕ ಸ್ಥಿತಿ ಬದಲಾದಾಗಲೆಲ್ಲಾ ಅವು working, blocked, ಅಥವಾ idle ಎಂಬ ಸ್ಟೇಟಸ್ ಬದಲಾವಣೆಯನ್ನು ಪೋಸ್ಟ್ ಮಾಡುತ್ತವೆ. ಬಳಕೆದಾರರು ತಕ್ಷಣವೇ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಏಜೆಂಟ್ idle ಎಂದು ವರದಿ ಮಾಡಿದಾಗ ಮಾತ್ರ ಅವಲಂಬಿತ ಕಾರ್ಯವನ್ನು ಕ್ಯೂನಲ್ಲಿ ಸೇರಿಸುವುದು.

  • Advisory Leases – ಏಜೆಂಟ್‌ಗೆ ಯಾವುದಾದರೂ ಸಂಪನ್ಮೂಲದ (ರೆಪೊ, API ಎಂಡ್‌ಪಾಯಿಂಟ್, ಕಂಪ್ಯೂಟ್ ನೋಡ್) ಮೇಲೆ ವಿಶೇಷ ಪ್ರವೇಶ ಬೇಕಾದಾಗ, ಅದು TTL (time-to-live) ನೊಂದಿಗೆ ಲೀಸ್ (lease) ಪಡೆಯುತ್ತದೆ. ಏಜೆಂಟ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, ಲೀಸ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮುಕ್ತಾಯಗೊಳ್ಳುತ್ತದೆ, ಇದು ಸಂಪನ್ಮೂಲವನ್ನು ಇತರರಿಗಾಗಿ ಬಿಡುಗಡೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಎರಡು ಬಾಟ್‌ಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಒಂದೇ ಕೆಲಸ ಮಾಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

  • Inbox Mechanism – ಏಜೆಂಟ್‌ನ ಇನ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಓದದ ಸಂದೇಶಗಳಿದ್ದರೆ, "ಸ್ಟಾಪ್ ಹುಕ್" (stop hook) ಏಜೆಂಟ್‌ನ ಕೆಲಸದ ಹರಿವನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ನಿಲ್ಲಿಸುತ್ತದೆ. ಬಾಟ್ ತನ್ನ ಪ್ರಸ್ತುತ ಕಾರ್ಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸುವ ಮೊದಲು ಆ ಸಂದೇಶಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು, ಇದರಿಂದ ಬಾಕಿ ಇರುವ ಸಂವಹನ ಸೂಚನೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸದಂತೆ ನೋಡಿಕೊಳ್ಳಬಹುದು.

ಈ ಭಾಗಗಳು ಪ್ರತಿಯೊಬ್ಬ ಪಾಲ್ಗೊಳ್ಳುವವರನ್ನು ಒಂದೇ ಮಟ್ಟದಲ್ಲಿ ಇರಿಸುವ ಸರಳ ಮತ್ತು ಗಮನಿಸಬಹುದಾದ ಸಂವಹನ ಪದರವನ್ನು (communication layer) ಸೃಷ್ಟಿಸುತ್ತವೆ.

ಇದನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ತಂಡಗಳಿಗೆ ಎದುರಾಗುವ ಅಪಾಯಗಳು

ಒಂದು ತಂಡವು ಕೇವಲ ಅಡ್-ಹೋಕ್ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಮತ್ತು ಮ್ಯಾನುಯಲ್ ಮಾನಿಟರಿಂಗ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದರೆ, ಗುಪ್ತ ವೆಚ್ಚಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ:

  • Duplicated effort – ಎರಡು ಏಜೆಂಟ್‌ಗಳು ಒಂದೇ ರೀತಿಯ ವರದಿಗಳನ್ನು ತಯಾರಿಸಬಹುದು, ಇದರಿಂದ ಕಂಪ್ಯೂಟ್ ಸೈಕಲ್‌ಗಳು ಮತ್ತು ಕ್ಲೌಡ್ ವೆಚ್ಚಗಳು ವ್ಯರ್ಥವಾಗುತ್ತವೆ.
  • Resource contention – ಕೋಡ್ ಬೇಸ್‌ನಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ಮಾಡುವ ಬದಲಾವಣೆಗಳು (writes) ಮರ್ಜ್ ಕಾನ್ಲಿಕ್ಟ್‌ಗಳಿಗೆ (merge conflicts) ಕಾರಣವಾಗುತ್ತವೆ, ಇವುಗಳನ್ನು ಸರಿಪಡಿಸಲು ಮನುಷ್ಯರ ಅಗತ್ಯವಿರುತ್ತದೆ.
  • Operational risk – ಹಳೆಯ ಸ್ಟೇಟಸ್ ಅನ್ನು ಆಧರಿಸಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಏಜೆಂಟ್, ಇನ್ನೊಂದು ಏಜೆಂಟ್ ಈಗಾಗಲೇ ರೋಲ್-ಬ್ಯಾಕ್ ಮಾಡುತ್ತಿರುವಾಗ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಬಹುದು, ಇದು ಸೇವೆಯನ್ನು ಅಸ್ಥಿರಗೊಳಿಸುತ್ತದೆ.

ಏಜೆಂಟ್‌ಗಳು ತಮ್ಮ ಗುರುತು, ಸ್ಥಿತಿ ಮತ್ತು ಸಂಪನ್ಮೂಲದ ಹಕ್ಕುಗಳನ್ನು ಹೇಗೆ ಘೋಷಿಸಬೇಕು ಎಂಬುದನ್ನು ಔಪಚಾರಿಕಗೊಳಿಸುವ ಮೂಲಕ, IACP ಯಾವುದೇ ಭಾರೀ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಇಂಜಿನ್ ಇಲ್ಲದೆಯೇ ಈ ಅಪಾಯಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ವಿರೋಧಾತ್ಮಕ ಅಂಶ: ಹೆಚ್ಚುವರಿ ಹೊರೆ

ಇತಿಹಾಸವನ್ನು ಸೇರಿಸುವುದು ಮತ್ತು ಲೀಸ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ವಿಳಂಬ (latency) ಮತ್ತು ಹೆಚ್ಚಿನ ಕೋಡ್ ಪಥಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ ಎಂದು ವಿಮರ್ಶಕರು ವಾದಿಸುತ್ತಾರೆ. ಕೇವಲ ಒಂದು ನಿರ್ದಿಷ್ಟ ಕೆಲಸವನ್ನು ಮಾಡುವ ಏಜೆಂಟ್ ಇರುವ ಪರಿಸರದಲ್ಲಿ, ಈ ಪ್ರೊಟೊಕಾಲ್‌ನ ಪ್ರಯೋಜನಗಳು ಅಲ್ಪವಾಗಿರಬಹುದು. ಆದಾಗ್ಯೂ, ಈ ಅನುಷ್ಠಾನವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೆಮೊರಿ ಮತ್ತು ಮಾನಿಟರಿಂಗ್ ಸೇವೆಗಳನ್ನೇ ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೆಚ್ಚುವರಿ ಹೊರೆ ಕಡಿಮೆ ಇರುತ್ತದೆ. ಏಜೆಂಟ್‌ಗಳ ನಡುವೆ ಗೊಂದಲ ಅನುಭವಿಸುತ್ತಿರುವ ತಂಡಗಳಿಗೆ, ಈ ಬದಲಾವಣೆಯು ಸ್ಪಷ್ಟವಾಗಿ ಲಾಭದಾಯಕವಾಗಿದೆ.

ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು

ಈ ಪ್ರೊಟೊಕಾಲ್ ಇನ್ನೂ ಪ್ರೊಟೊಟೈಪ್ ಹಂತದಲ್ಲಿದೆ, ಆದರೆ ಅದರ ಮಾಡ್ಯುಲರ್ ಸ್ವರೂಪವು ಯಾವುದೇ ಭಾಷಾ-ತಟಸ್ಥ (language-agnostic) ಏಜೆಂಟ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳೊಂದಿಗೆ ಸಂಯೋಜನೆಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಸಂಭಾವ್ಯ ಮುಂದಿನ ಹಂತಗಳು ಇಂತಿವೆ:

  • ಡೆವಲಪರ್‌ಗಳು ಕೋರ್ ಲಾಜಿಕನ್ನು ಬದಲಾಯಿಸದೆ ಐದು ಹುಕ್‌ಗಳನ್ನು ಸೇರಿಸಲು ಅನುಕೂಲವಾಗುವಂತೆ ಒಂದು ಲಘು ತೂಕದ SDK ಅನ್ನು ಪ್ರಕಟಿಸುವುದು.
  • ಸ್ಟೇಟ್ ಟ್ರಾನ್ಸಿಷನ್‌ಗಳು ಮತ್ತು ಲೀಸ್ ಚರ್ನ್ ಅನ್ನು ದೃಶ್ಯೀಕರಿಸುವ ಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಮಾನಿಟರಿಂಗ್ ಸೂಟ್‌ಗೆ ಸೇರಿಸುವುದು, ಇದು ತಂಡಗಳು ಅಡಚಣೆಗಳನ್ನು (bottlenecks) ಗುರುತಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
  • ಹೆಚ್ಚಿನ ಟ್ರಾಫಿಕ್ ಇರುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಕೆಲವು ಏಜೆಂಟ್‌ಗಳ ಲೀಸ್‌ಗಳಿಗೆ ಇತರರಿಗಿಂತ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಆದ್ಯತೆ ನೀಡುವ ಪಾಲಿಸಿ ಲೇಯರ್‌ಗಳೊಂದಿಗೆ ಪ್ರಯೋಗ ಮಾಡುವುದು.

ಈ ವಿಸ್ತರಣೆಗಳು ಜನಪ್ರಿಯತೆಯನ್ನು ಪಡೆದರೆ, ವೆಬ್ ಸೇವೆಗಳಿಗೆ HTTP ಹೇಗೆ ಒಂದು ಮಾನದಂಡವಾಯಿತೋ, ಹಾಗೆಯೇ IACP ಕೂಡ ಮಲ್ಟಿ-ಏಜೆಂಟ್ ಪ್ರೊಡಕ್ಷನ್ ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗೆ ಒಂದು ಡಿ-ಫ್ಯಾಕ್ಟೊ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಆಗಬಹುದು.

ಮುಖ್ಯ ಅಂಶ: ಯಾರು ಮಾತನಾಡುತ್ತಿದ್ದಾರೆ, ಇತ್ತೀಚಿನ ಸಂಭಾಷಣೆ ಹೇಗಿದೆ, ಏಜೆಂಟ್‌ನ ಸ್ಥಿತಿ ಯಾವಾಗ ಬದಲಾಗುತ್ತದೆ, ಯಾರು ಸಂಪನ್ಮೂಲವನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಬಾಕಿ ಇರುವ ಸಂದೇಶಗಳಿವೆಯೇ ಎಂಬಂತಹ ಕೆಲವು ಸರಳ ನಿಯಮಗಳು—AI ಏಜೆಂಟ್‌ಗಳು ಪರಸ್ಪರ ಅರ್ಥಮಾಡಿಕೊಳ್ಳದೆ ಮಾತನಾಡುವುದನ್ನು ತಡೆಯಬಹುದು ಮತ್ತು ಗೊಂದಲಮಯ ಚಾಟ್‌ರೂಮ್ ಅನ್ನು ನಂಬಿಕಾರ್ಹ ಸಮನ್ವಯ ಚಾನಲ್ ಆಗಿ ಪರಿವರ್ತಿಸಬಹುದು.