ನಾಲ್ಕು ಸ್ವಾಯತ್ತ AI ಏಜೆಂಟ್ಗಳು ಈಗ ಸಾಫ್ಟ್ವೇರ್ ದೋಷವನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು, ತಪ್ಪಾದ ಕೋಡ್ ಅನ್ನು ಎಡಿಟ್ ಮಾಡಬಹುದು ಮತ್ತು ಪರಿಹಾರವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು—ಇವೆಲ್ಲವೂ ಒಂದು ನಿಮಿಷದ ಒಳಗೇ ಸಾಧ್ಯವಾಗಿದ್ದು, ಇದಕ್ಕೆ SigNoz ಹ್ಯಾಕಥಾನ್ಗಾಗಿ ನಿರ್ಮಿಸಲಾದ ಹೊಸ observability-ಆಧಾರಿತ ವರ್ಕ್ಫ್ಲೋ ಕಾರಣವಾಗಿದೆ.
AgentOps ಎಂದು ಕರೆಯಲ್ಪಡುವ ಈ ವ್ಯವಸ್ಥೆಯು, ದೋಷಗಳ ಏರಿಕೆಯನ್ನು (error spikes) ಗಮನಿಸಲು SigNoz ಅನ್ನು ವೀಕ್ಷಿಸುತ್ತದೆ, ಸಂಬಂಧಿತ ಲಾಗ್ಗಳು ಮತ್ತು ಟ್ರೇಸ್ಗಳನ್ನು ಪಡೆಯುತ್ತದೆ, ಅದಕ್ಕೆ ಕಾರಣವಾದ ನಿಖರವಾದ ಫೈಲ್ ಮತ್ತು ಲೈನ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ, ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ನಲ್ಲಿ (sandbox) ಮೂಲ ಕೋಡ್ ಅನ್ನು ಎಡಿಟ್ ಮಾಡುತ್ತದೆ, ನಂತರ ಬಗ್ ಹೋಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಲು ವಿನಂತಿಯನ್ನು (request) ಮರುಪ್ರದರ್ಶಿಸುತ್ತದೆ. ಪ್ರತಿ ಪೂರ್ಣ ಚಕ್ರವು 30-60 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಮುಕ್ತಾಯವಾಗುತ್ತದೆ ಮತ್ತು ಇಡೀ ಪ್ರಕ್ರಿಯೆಯು ಯಾವುದೇ ಮಾನವ ಪ್ರಾಂಪ್ಟ್ ಇಲ್ಲದೆ ನಡೆಯುತ್ತದೆ.
AI ಏಜೆಂಟ್ಗಳಿಗೆ observability ಏಕೆ ಮುಖ್ಯ
ಸಾಂಪ್ರದಾಯಿಕ SRE ಪದ್ಧತಿಯು ಲಾಗ್ಗಳು, ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಟ್ರೇಸ್ಗಳನ್ನು ಒಂದು ಸೇವೆಯ (service) ಕಣ್ಣುಗಳೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ. ಒಂದು ವಿನಂತಿ ವಿಫಲವಾದಾಗ, ಎಂಜಿನಿಯರ್ ತಪ್ಪಾದ ಘಟಕವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಟ್ರೇಸ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತಾರೆ. ಇದೇ ತತ್ವವು ಈಗ AgentOps ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ಇಲ್ಲಿ ಗಮನಿಸಲ್ಪಡುವ "ಸೇವೆ" ಎಂದರೆ ಸ್ವತಃ AI ಏಜೆಂಟ್ ಆಗಿರುತ್ತದೆ.
ಏಜೆಂಟ್ ಬಳಸುವ ಪ್ರತಿಯೊಂದು ಸಾಧನವು—ಅದು language model call ಆಗಿರಲಿ, ಫೈಲ್-ಸಿಸ್ಟಮ್ ಎಡಿಟ್ ಆಗಿರಲಿ ಅಥವಾ ಟೆಸ್ಟ್ ರನ್ನರ್ ಆಗಿರಲಿ—ಟ್ರೇಸ್ನಲ್ಲಿ ಒಂದು span ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಒಂದು span ಪ್ರಾರಂಭದ ಸಮಯ, ಅವಧಿ ಮತ್ತು ಯಶಸ್ಸಿನ ಸ್ಥಿತಿಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಇದರಿಂದ ಏಜೆಂಟ್ ಪ್ರತಿಯೊಂದು ತರ್ಕದ ಹಂತವು (reasoning step) ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅದು ಯಶಸ್ವಿಯಾಯಿತೇ ಎಂದು ನೋಡಬಹುದು. ಆ spanಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸುವ ಮೂಲಕ, ಮನುಷ್ಯರು ಮ್ಯಾನುಯಲ್ ಆಗಿ ಡಿಬಗ್ ಮಾಡುವಾಗ ಮಾಡುವಂತೆಯೇ, ಏಜೆಂಟ್ ತನ್ನದೇ ಆದ ಆಲೋಚನಾ ಪ್ರಕ್ರಿಯೆಯ ಸಂಪೂರ್ಣ ಚಿತ್ರಣವನ್ನು ರೂಪಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ಪ್ರಮುಖ ಬದಲಾವಣೆಯೆಂದರೆ "reporting layer ಆಗಿ observability" ಇಂದ "perception ಆಗಿ observability" ಗೆ ಬದಲಾಗುವುದು. AgentOps ಟ್ರೇಸ್ ಡೇಟಾವನ್ನು ಮತ್ತೆ ಏಜೆಂಟ್ಗಳಿಗೆ ನೀಡುತ್ತದೆ, ಇದು ಅವುಗಳು ತಮ್ಮದೇ ಆದ ಕ್ರಮಗಳ ಬಗ್ಗೆ ನೈಜ ಸಮಯದಲ್ಲಿ (real time) ತರ್ಕಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, AI ಕೇವಲ ಒಂದು ಪರಿಕಲ್ಪನೆಯನ್ನು (hypothesis) ರೂಪಿಸುವುದು ಮಾತ್ರವಲ್ಲದೆ, ಸಮಸ್ಯೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಬಳಸುವ ಅದೇ ಟೆಲಿಮೆಟ್ರಿ (telemetry) ಮೂಲಕ ಅದನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.
ನಾಲ್ಕು ಹಂತಗಳ ವರ್ಕ್ಫ್ಲೋ
- Monitor – ಲೈಟ್ವೇಯ್ಟ್ ವಾಚರ್ (lightweight watcher) ಹೊಸದಾಗಿ ವರದಿಯಾದ ದೋಷಗಳಿಗಾಗಿ SigNoz ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತದೆ.
- Diagnose – ಏಜೆಂಟ್ ಸಂಬಂಧಿತ ಲಾಗ್ಗಳು ಮತ್ತು ಟ್ರೇಸ್ಗಳನ್ನು ಪಡೆದು, ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ ಮತ್ತು ವೈಫಲ್ಯಕ್ಕೆ ಕಾರಣವಾದ ಮೂಲ ಫೈಲ್ ಮತ್ತು ಲೈನ್ ಸಂಖ್ಯೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ.
- Fix – ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ಡ್ ಫೈಲ್-ಸಿಸ್ಟಮ್ ಸರ್ವರ್ ಬಳಸಿ, ಏಜೆಂಟ್ ಗುರುತಿಸಲಾದ ಲೈನ್ನಲ್ಲಿ ಪ್ಯಾಚ್ (patch) ಅನ್ನು ಬರೆಯುತ್ತದೆ. ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಕಟ್ಟುನಿಟ್ಟಿನ ಅನುಮತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಎಡಿಟ್ ನೀತಿಯನ್ನು ಉಲ್ಲಂಘಿಸಿದರೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹಿಂದಿನ ಸ್ಥಿತಿಗೆ ಮರಳಿಸುತ್ತದೆ (roll back).
- Verify – ಏಜೆಂಟ್ ಪ್ಯಾಚ್ ಮಾಡಿದ ಕೋಡ್ ವಿರುದ್ಧ ಮೂಲ ವಿನಂತಿಯನ್ನು ಮರು-ನೀಡಿಸುತ್ತದೆ. ಟ್ರೇಸ್ ಸುಗಮವಾಗಿ ನಡೆದರೆ, ಪರಿಹಾರವನ್ನು ಕಮಿಟ್ ಮಾಡಲಾಗುತ್ತದೆ; ಇಲ್ಲದಿದ್ದರೆ ಏಜೆಂಟ್ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ.
ಎಲ್ಲಾ ಹಂತಗಳನ್ನು ಏಜೆಂಟ್ಗಳ ಒಂದೇ ಗುಂಪು ನಿರ್ವಹಿಸುತ್ತದೆ, ಪ್ರತಿಯೊಂದೂ ಸ್ವಾಯತ್ತ ಮೈಕ್ರೋ-ಸರ್ವಿಸ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇಡೀ ಪ್ರಕ್ರಿಯೆಯನ್ನು OpenTelemetry-совмести spanಗಳ ಮೂಲಕ ಗಮನಿಸಬಹುದು, ಇವುಗಳನ್ನು SigNoz ಸ್ವೀಕರಿಸಿ ದೃಶ್ಯೀಕರಿಸುತ್ತದೆ.
ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಬಗ್ಗೆ ಕಷ್ಟಪಟ್ಟು ಕಲಿತ ಪಾಠಗಳು
ದೋಷದ ಸ್ಪಷ್ಟತೆ (Error clarity)
ಸಾಮಾನ್ಯ "failed" ಸ್ಥಿತಿಯು ಏನನ್ನೂ ತಿಳಿಸುವುದಿಲ್ಲ. ತಂಡವು ವಿವರವಾದ ವೈಫಲ್ಯದ ಕಾರಣಗಳನ್ನು ಸೇರಿಸಿದೆ—ಉದಾಹರಣೆಗೆ, "ತಪ್ಪು ಪರಿಕಲ್ಪನೆ" ಅಥವಾ "ಪ್ಯಾಚ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹಾಳುಮಾಡಿದೆ"—ಹಾಗಾಗಿ ಮುಂದಿನ ಏಜೆಂಟ್ಗಳು ಮರುಪ್ರಯತ್ನಿಸಬೇಕೆ, ಹಿಂದಕ್ಕೆ ಹೋಗಬೇಕೆ ಅಥವಾ ಸ್ಥಗತಗೊಳಿಸಬೇಕೆ ಎಂದು ನಿರ್ಧರಿಸಬಹುದು. ಇದು ಮನುಷ್ಯರು ಪೋಸ್ಟ್-ಮೋರ್ಟಮ್ (post-mortems) ಮಾಡುವಾಗ ಮೂಲ ಕಾರಣಗಳನ್ನು ಗುರುತಿಸುವ ರೀತಿಯನ್ನೇ ಹೋಲುತ್ತದೆ.
ಡೇಟಾ ವಿಳಂಬ (Data latency)
ಟೆಲಿಮೆಟ್ರಿ ತಕ್ಷಣವೇ ಕಾಣಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಏಜೆಂಟ್ಗಳು ಈಗ ಒಂದು ಸಣ್ಣ ವಿರಾಮ ಮತ್ತು ಸ್ಯಾನಿಟಿ ಚೆಕ್ ಅನ್ನು ಒಳಗೊಂಡಿವೆ, ಇದರಿಂದ ಪರಿಹಾರವನ್ನು ಖಚಿತಪಡಿಸುವ ಮೊದಲು ಅಗತ್ಯ ಲಾಗ್ಗಳು ಬಂದಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು. ಈ ರಕ್ಷಣೆಯಿಲ್ಲದೆ, ಏಜೆಂಟ್ ಅಪೂರ್ಣ ಡೇಟಾದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು ಮತ್ತು ತಪ್ಪು ಫಲಿತಾಂಶವನ್ನು (false positive) ನೀಡಬಹುದು.
ಭದ್ರತಾ ಗಡಿಗಳು (Security boundaries)
AI ಗೆ ಕೋಡ್ ಬರೆಯಲು ಅನುಮತಿಸುವುದು ಪ್ರಿವಿಲೇಜ್ ಎಸ್ಕಲೇಷನ್ (privilege escalation) ಅಪಾಯವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಒಂದು ಮೀಸಲಾದ ಫೈಲ್ಸಿಸ್ಟಮ್ ಸರ್ವರ್ನ ಹಿಂದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಬರೆಯುವ ವ್ಯಾಪ್ತಿಯನ್ನು ಗುರಿ ರೆಪೊಸಿಟರಿ (target repository) ಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಪರೀಕ್ಷೆ ವಿಫಲವಾದರೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹಿಂದಿನ ಸ್ಥಿತಿಯನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ. ಈ ನಿಯಂತ್ರಣ ಮಾದರಿಯು AI ಶಕ್ತಿಯನ್ನು ನಿಯಂತ್ರಣದಲ್ಲಿಡುತ್ತದೆ.
ಟೋಕನ್ ಮಿತಿಗಳು (Token limits)
Large language models API ಟೋಕನ್ಗಳನ್ನು ಬಳಸುತ್ತವೆ ಮತ್ತು ತನಿಖೆಯ ಮಧ್ಯದಲ್ಲಿ ದೈನಂದಿನ ಕೋಟಾಗಳು ಖಾಲಿಯಾಗಬಹುದು. AgentOps ಪ್ರತಿ ಘಟನೆಯ ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಮಿತಿ ತಲುಪಿದ ತಕ್ಷಣ ಮುಂದಿನ ಕರೆಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ, ಇದರಿಂದ ಕೋಟಾ ಮುಗಿದಾಗ ಸರಣಿ ವೈಫಲ್ಯಗಳನ್ನು ತಡೆಯಬಹುದು.
ಡೆಮೊ ಏನನ್ನು ಸಾಬೀತುಪಡಿಸಿತು
ತಂಡವು ಕೋಡ್ಬೇಸ್ನಲ್ಲಿ ಎಂದೂ ಕಾಣಿಸಿಕೊಳ್ಳದ ಹೊಸ ಬಗ್ ಅನ್ನು ಸೇರಿಸಿತು. AgentOps ಅಸಹಜತೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಿತು, ಅದನ್ನು ನಿಖರವಾದ ಲೈನ್ ವರೆಗೆ ಟ್ರೇಸ್ ಮಾಡಿತು, ತಿದ್ದುಪಡಿ ಎಡಿಟ್ ಅನ್ನು ರಚಿಸಿತು, ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ನಲ್ಲಿ ಪ್ಯಾಚ್ ಅನ್ನು ಅನ್ವಯಿಸಿತು ಮತ್ತು ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿತು—ಇವೆಲ್ಲವೂ ಯಾವುದೇ ಮ್ಯಾನುಯಲ್ ಕೋಡ್ ಬದಲಾವಣೆ ಅಥವಾ ಹೊಸ ಪ್ರಾಂಪ್ಟ್ಗಳಿಲ್ಲದೆ ನಡೆದವು. ಇಡೀ ಪ್ರಕ್ರಿಯೆಯ ಸಮಯವು ಒಂದು ನಿಮಿಷದ ಒಳಗೇ ಇತ್ತು, ಇದು ವರದಿಯಾದ 30-60 ಸೆಕೆಂಡುಗಳ ಅವಧಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.
ವಿರುದ್ಧ ಅಂಶ: ಸ್ವಾಯತ್ತತೆ ಎಂಬುದು ಎಲ್ಲದಕ್ಕೂ ಪರಿಹಾರವಲ್ಲ
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
- Model-agnostic telemetry – As more vendors expose OpenTelemetry-compatible spans, the approach could become vendor-neutral, easing adoption across heterogeneous stacks.
- Policy-driven guardrails – Embedding configurable policies that dictate which files an agent may edit, or which test suites must pass before a commit, will address governance concerns.
- Cost-aware token budgeting – Dynamic token allocation based on incident severity could prevent quota exhaustion while preserving the ability to handle high-impact bugs.
AgentOps shows that the bug-fix cycle can take 30-60 seconds. The experiment demonstrates a proof-of-concept that observability can be used by autonomous software assistants.