ಪ್ರತಿಯೊಂದು API ಅನ್ನು ಏಜೆಂಟ್‌ಗಳಿಗಾಗಿ ಮರುನಿರ್ಮಿಸಲಾಗುವುದು

MCP ಸಂಪರ್ಕದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಆದರೆ ಇದು 'verb gap' ಅನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ.

ನೀವು ಒಂದು ಮಧ್ಯಾಹ್ನದೊಳಗೆ ಪರಿಪೂರ್ಣ REST API ಅನ್ನು MCP ನಲ್ಲಿ ಸುತ್ತಬಹುದು (wrap). ಆದರೂ ಸಹ, ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಕಷ್ಟಪಡಬಹುದು. ಅದು ತಪ್ಪಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಆರಿಸಬಹುದು. ಒಂದು ಟೂಲ್ ಸಾಕಾಗುವ ಜಾಗದಲ್ಲಿ ಮೂರು ಟೂಲ್‌ಗಳನ್ನು ಕರೆಯಬಹುದು. ಕೇಳದೆ ವಿನಾಶಕಾರಿ ಬರವಣಿಗೆಯನ್ನು (destructive write) ಮಾಡಬಹುದು.

API ಕೆಟ್ಟು ಹೋಗಿಲ್ಲ. ಅದು ಕೇವಲ ತಪ್ಪು ಬಳಕೆದಾರರಿಗಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ.

ಇಪ್ಪತ್ತು ವರ್ಷಗಳಿಂದ, API ಗಳನ್ನು ಮನುಷ್ಯರಿಗಾಗಿ ನಿರ್ಮಿಸಲಾಗುತ್ತಿತ್ತು. ಮನುಷ್ಯರು ಉದ್ದೇಶ (intent) ಮತ್ತು ಮಾನಸಿಕ ಮಾದರಿಯನ್ನು (mental model) ತರುತ್ತಾರೆ. ಏಜೆಂಟ್‌ಗಳು ಇವೆರಡನ್ನೂ ತರುವುದಿಲ್ಲ. ಅವು ನಿಮ್ಮ ಇಂಟರ್ಫೇಸ್‌ನಿಂದಲೇ ಇವೆರಡನ್ನೂ ಮರುನಿರ್ಮಿಸಿಕೊಳ್ಳಬೇಕು.

ಪ್ರಾಥಮಿಕ ಬಳಕೆದಾರರು ಇಷ್ಟು ಮಟ್ಟಿಗೆ ಬದಲಾದಾಗ, ಇಂಟರ್ಫೇಸ್ ಕೂಡ ಬದಲಾಗಲೇಬೇಕು.

ಗಂಭೀರವಾದ ಉತ್ಪನ್ನದ ಇಂಟರ್ಫೇಸ್‌ಗಳು ಕೇವಲ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ API ಗಳನ್ನು ಸುತ್ತುವರಿಯುವುದಿಲ್ಲ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ಅವು ಏಜೆಂಟ್-ನೇಟಿವ್ (agent-native) ಕಾರ್ಯಾಚರಣೆಗಳ ಸುತ್ತ ಅವುಗಳನ್ನು ಮರುನಿರ್ಮಿಸುತ್ತವೆ.

ಇದರ್ಥ ಸಂಪನ್ಮೂಲ-ಆಧಾರಿತ (resource-shaped) API ಗಳಿಂದ ಉದ್ದೇಶ-ಆಧಾರಿತ (intent-shaped) ಒಪ್ಪಂದಗಳಿಗೆ ಬದಲಾಗುವುದು. ನಾವು ಗುರಿಗಳು, ಸ್ಥಿತಿ (state), ಪಾರ್ಶ್ವ ಪರಿಣಾಮಗಳು (side-effects), ಅನುಮೋದನೆ (approval) ಮತ್ತು ಚೇತರಿಕೆಯ (recovery) ಸುತ್ತ ಮರು ವಿನ್ಯಾಸಗೊಳಿಸಬೇಕು.

MCP ಸಂಪರ್ಕ ಮತ್ತು ಸಾರಿಗೆಗೆ (transport) ಉತ್ತಮ ಮಾನದಂಡವಾಗಿದೆ. ಆದರೆ ಅದರ ಸ್ಪೆಸಿಫಿಕೇಶನ್‌ನಲ್ಲಿ (spec), ಒಂದು ಟೂಲ್ ಎಂಬುದು ಕೇವಲ ಹೆಸರು ಮತ್ತು ಸ್ಕೀಮಾವನ್ನು ಹೊಂದಿರುವ ಒಂದು ಫಂಕ್ಷನ್ ಆಗಿದೆ. ಅದು ಕಾರ್ಯಾಚರಣೆಗಳ ಕ್ರಮವನ್ನು ಅಥವಾ ಯಾವುವು ಅಪಾಯಕಾರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ.

ಇದು 'verb gap' ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. API ಗಳು ಏಜೆಂಟ್‌ಗಳಿಗೆ ನಾಮಪದಗಳು (nouns) ಮತ್ತು CRUD ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನೀಡುತ್ತವೆ. ಏಜೆಂಟ್‌ಗಳಿಗೆ ಉದ್ದೇಶವನ್ನು ಹೊಂದಿರುವ ಕ್ರಿಯಾಪದಗಳು (verbs) ಬೇಕು.

GitHub ಅನ್ನು ನೋಡಿ. ಏಜೆಂಟ್ ತರ್ಕವನ್ನು (reasoning) ಸುಧಾರಿಸಲು ಅವರು ತಮ್ಮ ಟೂಲ್ ಸೆಟ್ ಅನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತಿದ್ದಾರೆ. ಉತ್ಪನ್ನದ API ಯಿಂದ ಏಜೆಂಟ್ ಟೂಲ್‌ಗಳಿಗೆ 1:1 ಮ್ಯಾಪಿಂಗ್ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂಬುದು ಅವರಿಗೆ ತಿಳಿಯುತ್ತಿದೆ.

ಸಂಶೋಧನೆಯ ಪ್ರಕಾರ, ಒಂದು API ರಚನಾತ್ಮಕವಾಗಿ ಸರಿಯಾಗಿರಬಹುದು ಆದರೆ ಏಜೆಂಟ್‌ಗೆ ಅರ್ಥಾತ್ಮಕವಾಗಿ (semantically) ಪ್ರಯೋಜನವಿಲ್ಲದಂತಿರಬಹುದು. ಏಜೆಂಟ್-ನೇಟಿವ್ API ಕೇವಲ "ನಾನು ಏನನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು?" ಎಂಬುದಕ್ಕೆ ಮಾತ್ರ ಉತ್ತರಿಸುವುದಿಲ್ಲ. ಅದು ಈ ಕೆಳಗಿನವುಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ:

  • ಗುರಿ ಏನು?
  • ನಾನು ಯಾವ ಸ್ಥಿತಿಯಲ್ಲಿದ್ದೇನೆ?
  • ಪಾರ್ಶ್ವ ಪರಿಣಾಮಗಳು ಯಾವುವು?
  • ನನಗೆ ಅನುಮೋದನೆ ಬೇಕೇ?
  • ನಾನು ಹೇಗೆ ಚೇತರಿಸಿಕೊಳ್ಳಲಿ?

ನೇರ ಬರವಣಿಗೆಯ ಬದಲಿಗೆ (raw write), ನಿಮಗೆ ಈ ಕೆಳಗಿನ ವಿಭಜನೆಯ ಅಗತ್ಯವಿದೆ:

  • ಕ್ರಿಯೆಯನ್ನು ಮುನ್ನೋಟಿಸಿ (Preview).
  • ಸ್ಪಷ್ಟ ಅನುಮೋದನೆಯನ್ನು ಪಡೆಯಿರಿ.
  • ಬದಲಾವಣೆಯನ್ನು ಕಮಿಟ್ ಮಾಡಿ.
  • ವಿಫಲವಾದರೆ ರೋಲ್‌ಬ್ಯಾಕ್ (Rollback) ಮಾಡಿ.

ಇದು ಕೇವಲ "ಏಜೆಂಟ್ ಎಡಿಷನ್" ಅಲ್ಲ. ಇದು ಸರಳವಾಗಿ ಉತ್ತಮವಾದ API ಆಗಿದೆ. ಡೆವಲಪರ್‌ಗಳು ಕೂಡ ಮುನ್ನೋಟಗಳು (previews), ಸ್ಪಷ್ಟ ಅನುಮತಿ ದೋಷಗಳು (permission errors) ಮತ್ತು ರೋಲ್‌ಬ್ಯಾಕ್‌ಗಳನ್ನು ಬಯಸುತ್ತಾರೆ. ಅಂತಿಮವಾಗಿ, ಏಜೆಂಟ್-ನೇಟಿವ್ ವಿನ್ಯಾಸವು ಮನುಷ್ಯ-ಕೇಂದ್ರಿತ ವಿನ್ಯಾಸವನ್ನು ಬದಲಿಸುತ್ತದೆ.

ಈ ಬದಲಾವಣೆ ಬಹಳ ದೊಡ್ಡದಾಗಿದೆ. ಇದು API ಗಳು, CLI ಗಳು ಮತ್ತು ಲಾಗ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ನಾವು ಮನುಷ್ಯರು ಓದಬಲ್ಲ ಪಠ್ಯದಿಂದ (human-readable prose) ಯಂತ್ರಗಳು ವಿಶ್ಲೇಷಿಸಬಲ್ಲ ಸ್ಥಿತಿಗೆ (machine-parseable state) ಬದಲಾಗಬೇಕು.

ಸುರಕ್ಷತೆಯು ನೀವು ನಂತರ ಸೇರಿಸುವ ಕವಚವಲ್ಲ (wrapper). ಸುರಕ್ಷತೆಯು ನೀವು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲೇ ವಿನ್ಯಾಸಗೊಳಿಸುವ ಒಂದು ಗುಣವಾಗಿದೆ.

Source: https://dev.to/gyu07/every-api-will-be-rebuilt-for-agents-2hj4

Optional learning community: https://t.me/GyaanSetuAi