ಪ್ರತಿಯೊಂದು ಉತ್ಪನ್ನದ ರೋಡ್ಮ್ಯಾಪ್ನಲ್ಲಿ (product roadmap) "AI Agent" ಎಂಬ ಬುಲೆಟ್ ಪಾಯಿಂಟ್ ಇರುತ್ತದೆ. ಈ ಪದವು ಪ್ರಗತಿಯಂತೆ ಕೇಳಿಸುತ್ತದೆ. ಇದು ನಿಮ್ಮ ತಂಡವು ಕೇವಲ ವರ್ತಮಾನವನ್ನು ನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ, ಬದಲಾಗಿ ಭವಿಷ್ಯವನ್ನು ನಿರ್ಮಿಸುತ್ತಿದೆ ಎಂದು ನಾಯಕತ್ವಕ್ಕೆ ಸಂಕೇತ ನೀಡುತ್ತದೆ. ಆದರೆ ಹೆಚ್ಚಿನ ಡೆಮೊ ವಿಡಿಯೋಗಳು ನಿಮಗೆ ತೋರಿಸದ ಕಹಿ ಸತ್ಯವೇನೆಂದರೆ: ಒಂದು ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಏಜೆಂಟ್ ಎಂಬುದು ಅತ್ಯಂತ ದುಬಾರಿ ಮತ್ತು ಅತಿ ಕಡಿಮೆ ಊಹಿಸಬಹುದಾದ ಮಾರ್ಗವಾಗಿದೆ. ಹೆಚ್ಚಿನ ವ್ಯವಹಾರದ ಕಾರ್ಯಗಳಿಗೆ, ಇದು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪು ಸಾಧನವಾಗಿದೆ. ಅತ್ಯುತ್ತಮ ಎಂಜಿನಿಯರ್ಗಳು ಅದನ್ನು ನಿರ್ಮಿಸಲು ಅವಸರಿಸುವವರಲ್ಲ. ಬದಲಾಗಿ, ಯಾವಾಗ ನಿಲ್ಲಿಸಬೇಕು ಎಂದು ತಿಳಿದಿರುವವರೇ ನಿಜವಾದ ಎಂಜಿನಿಯರ್ಗಳು.
ವರ್ಗೀಕರಣದ ಬಲೆ (The Classification Trap)
ಒಂದು ತಂಡವು ತಮ್ಮ ಮೊದಲ ಏಜೆಂಟ್ನ ವ್ಯಾಪ್ತಿಯನ್ನು (scope) ನಿರ್ಧರಿಸುವುದನ್ನು ಗಮನಿಸಿ, ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಹೀಗನ್ನಬಹುದು. ಒಂದು ಸಪೋರ್ಟ್ ಇಮೇಲ್ ಬರುತ್ತದೆ. ಒಂದು ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ (LLM) ಅದರ ವಿಷಯ ಮತ್ತು ವಿಷಯದ ವಿವರವನ್ನು ಓದುತ್ತದೆ, ಅದು ಬಿಲ್ಲಿಂಗ್ ಪ್ರಶ್ನೆಯೇ ಅಥವಾ ತಾಂತ್ರಿಕ ದೋಷವೇ (technical bug) ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಸೂಕ್ತ ಕ್ಯೂ (queue) ಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ. ತಂಡವು ಇದನ್ನು ಏಜೆಂಟ್ ಎಂದು ಕರೆಯುತ್ತದೆ. ಆದರೆ ಅದು ಏಜೆಂಟ್ ಅಲ್ಲ.
ಅವರು ನಿರ್ಮಿಸಿರುವುದು ಅದರೊಳಗೆ ಒಂದೇ ಮಾಡೆಲ್ ಕರೆಯನ್ನು ಹೊಂದಿರುವ ಒಂದು ನಿರ್ಧಾರಿತ ಹರಿವು (deterministic flow). ಹಂತಗಳು ನಿಗದಿತವಾಗಿವೆ: ಇಮೇಲ್ ಸ್ವೀಕರಿಸುವುದು, ಮಾಡೆಲ್ ಕರೆಯುವುದು, ಕ್ಯೂಗೆ ವರ್ಗಾಯಿಸುವುದು. ಇದರಲ್ಲಿ ಯಾವುದೇ ಲೂಪ್ (loop), ಟೂಲ್ ಬಳಕೆ ಅಥವಾ ಮೊದಲ ಪ್ರಯತ್ನ ವಿಫಲವಾದಾಗ ತನ್ನ ಯೋಜನೆಯನ್ನು ಮರುಪರಿಶೀಲಿಸಲು ಸಿಸ್ಟಮ್ ನಿಲ್ಲುವ ಕ್ಷಣವಿಲ್ಲ. ಇದು ನಾಲೇಜ್ ಬೇಸ್ ಅನ್ನು ಹುಡುಕುವುದಿಲ್ಲ, ಕೋಡ್ ಬರೆಯುವುದಿಲ್ಲ ಅಥವಾ ಮಧ್ಯದಲ್ಲಿ ಆರ್ಡರ್ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ. ಇದು ಒಂದು ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಮುನ್ನಡೆಯುತ್ತದೆ. ಆ ಒಂದೇ ಕರೆಯನ್ನು ಮೈಕ್ರೋಸರ್ವಿಸ್ನಲ್ಲಿ ಸುತ್ತುವರಿಯುವುದು ಅದನ್ನು ಏಜೆಂಟ್ ಮಾಡುವುದಿಲ್ಲ.
ಹರಿವನ್ನು ಏಜೆಂಟ್ ಎಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸುವುದರಿಂದ ಆಗುವ ನಿಜವಾದ ವೆಚ್ಚ ಕೇವಲ ಹೆಚ್ಚುವರಿ ಮೂಲಸೌಕರ್ಯವಲ್ಲ (infrastructure). ಬದಲಾಗಿ, ಯಾವುದೇ ಲಾಭವಿಲ್ಲದೆ ನೀವು ಆಹ್ವಾನಿಸಿದ ಅನಿಶ್ಚಿತತೆ (non-determinism). ಒಂದೇ ಇಮೇಲ್ ಮಂಗಳವಾರ ಬೆಳಿಗ್ಗೆ ಮತ್ತು ಬುಧವಾರ ಮಧ್ಯಾಹ್ನ ವಿಭಿನ್ನವಾಗಿ ವರ್ಗಾವಣೆಯಾಗಬಹುದು, ಏಕೆಂದರೆ ಟೆಂಪರೇಚರ್ (temperature) ಶೂನ್ಯವಾಗಿಲ್ಲದಿರಬಹುದು ಅಥವಾ ಪ್ರಾಂಪ್ಟ್ ಬದಲಾಗಿರಬಹುದು. ಕೇವಲ ಒಂದು ವರ್ಗೀಕರಣ ಹಂತವಿರುವ ಹರಿವು ಸಮಸ್ಯೆಯನ್ನು ವೇಗವಾಗಿ ಮತ್ತು ಅಗ್ಗವಾಗಿ ಪರಿಹರಿಸುವಾಗ, ನೀವು ಲೇಟೆನ್ಸಿ (latency), ಟೋಕನ್ ವೆಚ್ಚಗಳು ಮತ್ತು ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ ಓವರ್ಹೆಡ್ಗಾಗಿ ಏಜೆಂಟ್ ಬೆಲೆಗಳನ್ನು ಪಾವತಿಸುತ್ತೀರಿ.
ಏಣಿಯ ಮೂಲಕ ಕೆಲಸ ಮಾಡಿ (Work Down the Ladder)
ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳಿಗೆ ಅವುಗಳನ್ನು ಅಷ್ಟೇ ಚೆನ್ನಾಗಿ ಪರಿಹರಿಸುವ ಸರಳ ಮಾರ್ಗಗಳಿವೆ. ಇದನ್ನು ಏಣಿಯಂತೆ ಭಾವಿಸಿ ಮತ್ತು ಕೆಳಗಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ.
ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸರಿಪಡಿಸಿ. ಕೆಲವೊಮ್ಮೆ ಎರಡು ಸಿಸ್ಟಮ್ಗಳು ಪರಸ್ಪರ ಒಪ್ಪದ ಕಾರಣದಿಂದಾಗಿ ಕೆಲಸ ಅಸ್ತಿತ್ವದಲ್ಲಿರುತ್ತದೆ. ನಿಮ್ಮ CRM ನಲ್ಲಿರುವ ಗ್ರಾಹಕರ ದಾಖಲೆಯು ನಿಮ್ಮ ಟಿಕೆಟಿಂಗ್ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನೊಂದಿಗೆ ಸಿಂಕ್ ಆಗದಿದ್ದರೆ, ಮನುಷ್ಯನು ಪ್ರತಿದಿನ ಬೆಳಿಗ್ಗೆ ಅದನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ಸರಿಪಡಿಸಬೇಕಾಗುತ್ತದೆ. ಆ ಕೊಂಡಿಯನ್ನು ಏಜೆಂಟ್ ಬಳಸಿ ಆಟೋಮೇಟ್ ಮಾಡಬೇಡಿ. ಅದನ್ನು ಇಲ್ಲವೇ ಮಾಡಬೇಡಿ. ಡೇಟಾ ಪೈಪ್ಲೈನ್ ಆರೋಗ್ಯಕರವಾಗಿದ್ದರೆ, ಆ ಕೆಲಸವೇ ಮಾಯವಾಗುತ್ತದೆ.
ಕ್ವೆರಿಯನ್ನು ಬಳಸಿ. ಉತ್ತರವು ಸರಳವಾದ ಲುಕ್ಅಪ್ ಅಥವಾ ಅಗ್ಗ್ರೆಗೇಶನ್ ಆಗಿದ್ದರೆ, ಅದನ್ನು ಹಾಗೆಯೇ ಪರಿಗಣಿಸಿ. "ಕಳೆದ ಮಂಗಳವಾರ ನಾವು ಎಷ್ಟು ರಿಫಂಡ್ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದೆವು?" ಎಂಬ ಪ್ರಶ್ನೆಗೆ ತರ್ಕದ (reasoning) ಅಗತ್ಯವಿಲ್ಲ. ಅದಕ್ಕೆ SQL ಬೇಕು. ನ್ಯಾಚುರಲ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಅನ್ನು SQL ಗೆ ಪರಿವರ್ತಿಸುವ ಏಜೆಂಟ್ ಕೇಳಲು ಸೊಗಸಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಅದರ ನಿರ್ವಹಣಾ ಹೊರೆ ನಿಮ್ಮ ಡ್ಯಾಶ್ಬೋರ್ಡ್ನಿಂದ ಮೂರು ಕ್ವೆರಿಗಳನ್ನು ಬರೆಯುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗುತ್ತದೆ.
ನಿರ್ಧಾರಿತ ಹರಿವನ್ನು (deterministic flow) ನಿರ್ಮಿಸಿ. ನಿಯಮಗಳು ನಿಗದಿತವಾಗಿದ್ದಾಗ ಮತ್ತು ಫಲಿತಾಂಶವು ಪುನರಾವರ್ತಿತವಾಗಿದ್ದಾಗ, ಸ್ಪಷ್ಟವಾದ ಲಾಜಿಕ್ ಬಳಸಿ. ಆರ್ಡರ್ ಮೌಲ್ಯವು ಒಂದು ಮಿತಿಯನ್ನು ಮೀರಿದರೆ, ಹಣಕಾಸು ವಿಭಾಗಕ್ಕೆ ವರ್ಗಾಯಿಸಿ. ಬಳಕೆದಾರರು ಮೂವತ್ತು ದಿನಗಳ ಕಾಲ ಸಕ್ರಿಯರಲ್ಲದಿದ್ದರೆ, ಮರು-ಸಕ್ರಿಯಗೊಳಿಸುವ ಇಮೇಲ್ ಕಳುಹಿಸಿ. ಕೋಡ್ ಇದನ್ನು ಶೂನ್ಯ ವ್ಯತ್ಯಾಸ ಮತ್ತು ಸಂಪೂರ್ಣ ಅವಲೋಕನೀಯತೆಯೊಂದಿಗೆ (observability) ನಿರ್ವಹಿಸುತ್ತದೆ. ನೀವು ಇದನ್ನು ಯೂನಿಟ್-ಟೆಸ್ಟ್ ಮಾಡಬಹುದು. ಆದರೆ ನೀವು ಕೇವಲ ಒಂದು 'vibe' ಅನ್ನು ಯೂನಿಟ್-ಟೆಸ್ಟ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಒಂದೇ ಮಾಡೆಲ್ ಕರೆಯನ್ನು ಹೊಂದಿರುವ ಹರಿವನ್ನು ಬಳಸಿ. ವರ್ಗೀಕರಣ (classification), ಸೆಂಟಿಮೆಂಟ್ ಟ್ಯಾಗಿಂಗ್ ಅಥವಾ ಡೇಟಾ ಎಕ್ಸ್ಟ್ರಾಕ್ಷನ್ ಇವು ಇಲ್ಲಿ ಬರುತ್ತವೆ. ಮಾಡೆಲ್ ಒಂದು ಕಟ್ಟುನಿಟ್ಟಾದ ಸ್ಕ್ರಿಪ್ಟ್ನೊಳಗೆ ಒಂದೇ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ನೀವು ಒಂದು ದಾಖಲೆಯನ್ನು ಪಡೆದು, ಇನ್ವಾಯ್ಸ್ ಸಂಖ್ಯೆಯನ್ನು ಹೊರತೆಗೆಯುತ್ತೀರಿ ಮತ್ತು ಅದನ್ನು ಡೇಟಾಬೇಸ್ಗೆ ಬರೆಯುತ್ತೀರಿ. ಸುತ್ತಲಿನ ಹಂತಗಳು ಹಾರ್ಡ್ಕೋಡ್ ಆಗಿರುತ್ತವೆ. ಮಾಡೆಲ್ ಮುಂದೆ ಏನು ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ; ಅದು ಕೇವಲ ತಾನು ನೋಡಿದ್ದನ್ನು ಲೇಬಲ್ ಮಾಡುತ್ತದೆ. ಇದು ಒಂದು ಶಕ್ತಿಯುತ ಮಾದರಿಯಾಗಿದೆ, ಆದರೆ ಇದು ಇನ್ನೂ ಒಂದು ಹರಿವೇ ಆಗಿದೆ.
ಕೊನೆಯದಾಗಿ ಏಜೆಂಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಮಾಡೆಲ್ ಕಾರ್ಯದ ಮಧ್ಯದಲ್ಲಿ ಏನನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಮುಂದಿನ ಕ್ರಮವು ನಿಜವಾಗಿಯೂ ಅವಲಂಬಿತವಾಗುವ ಕಾರ್ಯಗಳಿಗಾಗಿ ಈ ಹಂತವನ್ನು ಮೀಸಲಿಡಿ. ಸಿಸ್ಟಮ್ ಒಂದು ಇಮೇಲ್ ಅನ್ನು ಓದಬೇಕು, ಲೊಜಿಸ್ಟಿಕ್ಸ್ API ಯಲ್ಲಿ ಶಿಪ್ಮೆಂಟ್ ಅನ್ನು ಹುಡುಕುವ ಅಗತ್ಯವಿದೆ ಎಂದು ಅರಿಯಬೇಕು, ಶಿಪ್ಮೆಂಟ್ ವಿಳಂಬವಾಗಿದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಬೇಕು ಮತ್ತು ನಂತರ ಆ ಹೊಸ ಡೇಟಾ ಆಧಾರದ ಮೇಲೆ ಕಸ್ಟಮ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಿದ್ಧಪಡಿಸಬೇಕಾದರೆ, ನೀವು ಏಜೆಂಟ್ ವ್ಯಾಪ್ತಿಯಲ್ಲಿದ್ದೀರಿ ಎಂದರ್ಥ. ಪ್ರತಿ ಹೊಸ ಸತ್ಯದ ನಂತರ ಮಾಡೆಲ್ ಏನು ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸುವುದರಿಂದ, ಹಾದಿಯನ್ನು ಮೊದಲೇ ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ.
ವೈಟ್ಬೋರ್ಡ್ ಪರೀಕ್ಷೆ (The Whiteboard Test)
ಸಭೆಯಲ್ಲಿ ಚರ್ಚೆಯನ್ನು ಇತ್ಯರ್ಥಪಡಿಸಲು ಒಂದು速 ಮಾರ್ಗವಿದೆ. ನಿಮ್ಮ ತಂಡವನ್ನು ವೈಟ್ಬೋರ್ಡ್ ಮೇಲೆ ನಿರ್ಧಾರದ ಶಾಖೆಗಳನ್ನು (decision branches) ಬಿಡಿಸಲು ಕೇಳಿ.
ಮಾಡೆಲ್ ರನ್ ಆಗುವ ಮೊದಲು ನೀವು ಪ್ರತಿಯೊಂದು ಹಾದಿಯನ್ನು ನಕ್ಷೆ ಮಾಡಬಲ್ಲರೆ, ಹರಿವನ್ನು (flow) ನಿರ್ಮಿಸಿ. ಡೈಮಂಡ್ ಆಕಾರಗಳನ್ನು ಬಿಡಿಸಿ, if-statements ಬರೆಯಿರಿ ಮತ್ತು ಮುಗಿಸಿ. ಮುನ್ಸೂಚನೆ (Predictability) ಎಂಬುದು ಒಂದು ವೈಶಿಷ್ಟ್ಯವೇ ಹೊರತು ಮಿತಿಯಲ್ಲ.
ಮುಂದಿನ ಹಂತವೇನು ಎಂಬುದನ್ನು ಮಾಡೆಲ್ ತಾನೇ ನಿರ್ಧರಿಸಬೇಕಾದಲ್ಲಿ, ಅದು ಟೂಲ್ ಅನ್ನು ಆರಿಸಬೇಕಾದಲ್ಲಿ, ಪ್ಯಾರಾಮೀಟರ್ಗಳನ್ನು ಹೊಂದಿಸಬೇಕಾದಲ್ಲಿ ಮತ್ತು ಮರುಚಿಂತನೆ ಮಾಡಲು ಲೂಪ್ ಆಗಬೇಕಾದಲ್ಲಿ, ಆಗ ನಿಮಗೆ ಏಜೆಂಟ್ ಬೇಕಾಗುತ್ತದೆ. ಆ ಡೈನಾಮಿಕ್ ರೂಟಿಂಗ್ (dynamic routing) ಎಂಬುದು ವಿಭಜನಾ ರೇಖೆಯಾಗಿದೆ. ಹೊಸ API ಬಳಸಬೇಕೆಂಬ ಆಸೆಯಿಂದ ಅದನ್ನು ಅಚಾನಕ್ಕಾಗಿ ದಾಟಬೇಡಿ.
ಅಡಗಿರುವ ತೆರಿಗೆ (The Hidden Tax)
ಡೆಮೋಗಳು ಏಜೆಂಟ್ಗಳನ್ನು ಅಡೆತಡೆಯಿಲ್ಲದಂತೆ ಕಾಣುವಂತೆ ಮಾಡುತ್ತವೆ. ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ವೇಗವಾಗಿ ಹೆಚ್ಚಾಗುವ ನಾಲ್ಕು ತೆರಿಗೆಗಳು (taxes) ಎದುರಾಗುತ್ತವೆ.
ಅನಿಶ್ಚಿತತೆ (Non-determinism). ಒಂದೇ...