ನಿರ್ಧಾರ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಕ್ರಾಸ್-ಸಿಸ್ಟಮ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್

ಒಂದು ವಿಶಿಷ್ಟ ಖರೀದಿ-ಪಾವತಿ ವರ್ಕ್‌ಫ್ಲೋ ಡಜನ್ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಸ್ಪರ್ಶಿಸುತ್ತದೆ. ಖರೀದಿ ವಿನಂತಿ ಒಂದು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಇನ್ನೊಂದರಲ್ಲಿ ಅನುಮೋದನ ಸರಪಳಿಗೆ ರೂಟ್ ಮಾಡಲಾಗುತ್ತದೆ, ಮೂರನೇಯದರಲ್ಲಿ ವೆಂಡರ್ ಲುಕಪ್ ಟ್ರಿಗರ್ ಮಾಡುತ್ತದೆ, ನಾಲ್ಕನೇಯದರಲ್ಲಿ ಖರೀದಿ ಆದೇಶ ರಚಿಸುತ್ತದೆ, ಐದನೇಯದರಲ್ಲಿ ಸ್ವೀಕರಣ ಪ್ರಕ್ರಿಯೆ ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಆರನೇಯದರಲ್ಲಿ ಇನ್‌ವಾಯ್ಸ್‌ಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ, ಏಳನೇಯದರಲ್ಲಿ ಪಾವತಿ ನಿಗದಿಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಎಂಟನೇಯದರಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ದಾಖಲಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ವ್ಯವಸ್ಥೆ ತನ್ನದೇ API, ತನ್ನದೇ ನವೀಕರಣ ವೇಳಾಪಟ್ಟಿ, ತನ್ನದೇ ದೃಢೀಕರಣ ಮಾದರಿ, ಮತ್ತು ತನ್ನದೇ ವೈಫಲ್ಯ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ.

ಸಾಂಪ್ರದಾಯಿಕ ಸ್ವಯಂಚಾಲನ ಇದನ್ನು ಕಠಿಣ ಪೈಪ್‌ಲೈನ್‌ಗಳಿಂದ ನಿರ್ವಹಿಸುತ್ತದೆ. ಹಂತ ಒಂದು API A ಅನ್ನು ಕರೆಯುತ್ತದೆ, ಪ್ರತಿಕ್ರಿಯೆ ಪಾರ್ಸ್ ಮಾಡುತ್ತದೆ, ಹಂತ ಎರಡಕ್ಕೆ ಒಂದು ಕ್ಷೇತ್ರ ರವಾನಿಸುತ್ತದೆ. ಅದು ತನ್ನ ಕೆಲಸ ಮಾಡುವವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಒಂದು ವೆಂಡರ್ ರೆಕಾರ್ಡ್ ನಿರೀಕ್ಷಿತಕ್ಕಿಂತ ಸ್ವಲ್ಪ ಭಿನ್ನ ಸ್ವರೂಪದಲ್ಲಿ ಇರುತ್ತದೆ. ಪೈಪ್‌ಲೈನ್ ವಿನ್ಯಾಸ ಮಾಡಿರದ ಸ್ಥಿತಿ ಕೋಡ್‌ನೊಂದಿಗೆ ಅನುಮೋದನೆ ಹಿಂತಿರುಗುತ್ತದೆ. API ನವೀಕರಣದಲ್ಲಿ ಹೊಸ ಅಗತ್ಯ ಕ್ಷೇತ್ರ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಒಂದು ಮುರಿದ ಹಂತ ಸಂಪೂರ್ಣ ಸರಪಳಿಯನ್ನು ಮುರಿಯುತ್ತದೆ.

ಆಳವಾದ ಸಮಸ್ಯೆ ತಾಂತ್ರಿಕ ದುರ್ಬಲತೆ ಅಲ್ಲ. ನಿಜವಾದ ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ನಿರ್ಧಾರದ ಅಗತ್ಯ ಇದೆ. ಈ ಇನ್‌ವಾಯ್ಸ್ ವ್ಯತ್ಯಾಸವನ್ನು ಹೆಚ್ಚಿಸಬೇಕೇ ಅಥವಾ ಸ್ವಯಂ-ಪರಿಹರಿಸಬೇಕೇ? ಈ ವೆಂಡರ್‌ನ ತಡ ವಿತರಣಾ ಮಾದರಿ ಒಪ್ಪಂದ ಪರಿಶೀಲನೆಯನ್ನು ಸಮರ್ಥಿಸುತ್ತದೆಯೇ? ಈ ನಿರ್ಧಾರಗಳು ಪ್ರಸ್ತುತ ಜನರ ತಲೆಯಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ, ಅಂದರೆ ಸ್ವಯಂಚಾಲನ ಕೇವಲ ಸಂತೋಷದ ಮಾರ್ಗವನ್ನು ನಿರ್ವಹಿಸಬಲ್ಲದು.

Triggerfish ಇದನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುತ್ತದೆ

Triggerfish ನ ವರ್ಕ್‌ಫ್ಲೋ ಎಂಜಿನ್ YAML-ಆಧಾರಿತ ವರ್ಕ್‌ಫ್ಲೋ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ನಡೆಸುತ್ತದೆ ಅದು ಒಂದೇ ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ನಿರ್ಣಾಯಕ ಸ್ವಯಂಚಾಲನ ಮತ್ತು AI ತರ್ಕವನ್ನು ಮಿಶ್ರಣ ಮಾಡುತ್ತದೆ. ವರ್ಕ್‌ಫ್ಲೋದ ಪ್ರತಿ ಹಂತ ಎಲ್ಲ Triggerfish ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿಯಂತ್ರಿಸುವ ಅದೇ ಸುರಕ್ಷತಾ ಜಾರಿ ಪದರದ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ.

ನಿರ್ಣಾಯಕ ಕೆಲಸಕ್ಕೆ ನಿರ್ಣಾಯಕ ಹಂತಗಳು

ವರ್ಕ್‌ಫ್ಲೋ ಹಂತವು ತಿಳಿದ ಇನ್‌ಪುಟ್ ಮತ್ತು ತಿಳಿದ ಔಟ್‌ಪುಟ್ ಹೊಂದಿದ್ದರೆ, ಅದು ಮಾನಕ HTTP ಕರೆ, ಶೆಲ್ ಆಜ್ಞೆ, ಅಥವಾ MCP ಟೂಲ್ ಆಹ್ವಾನವಾಗಿ ಚಲಿಸುತ್ತದೆ. LLM ಒಳಗೊಳ್ಳದೆ, ಲೇಟೆನ್ಸಿ ದಂಡ ಇಲ್ಲದೆ, ಅನುಮಾನ ವೆಚ್ಚ ಇಲ್ಲದೆ. ವರ್ಕ್‌ಫ್ಲೋ ಎಂಜಿನ್ REST APIs ಗೆ call: http, ಯಾವುದೇ ಸಂಪರ್ಕಿತ MCP ಸರ್ವರ್‌ಗೆ call: triggerfish:mcp, ಮತ್ತು ಕಮಾಂಡ್-ಲೈನ್ ಟೂಲ್‌ಗಳಿಗೆ run: shell ಬೆಂಬಲಿಸುತ್ತದೆ.

ನಿರ್ಧಾರಗಳಿಗಾಗಿ LLM ಉಪ-ಏಜೆಂಟ್‌ಗಳು

ವರ್ಕ್‌ಫ್ಲೋ ಹಂತಕ್ಕೆ ಸಂದರ್ಭೋಚಿತ ತರ್ಕದ ಅಗತ್ಯ ಇದ್ದರೆ, ಎಂಜಿನ್ call: triggerfish:llm ಬಳಸಿ ನಿಜವಾದ LLM ಉಪ-ಏಜೆಂಟ್ ಅಧಿವೇಶನ ಉತ್ಪಾದಿಸುತ್ತದೆ. ಇದು ಒಂದೇ ಪ್ರಾಂಪ್ಟ್/ಪ್ರತಿಕ್ರಿಯೆ ಅಲ್ಲ. ಉಪ-ಏಜೆಂಟ್ Triggerfish ನಲ್ಲಿ ನೋಂದಾಯಿಸಲಾದ ಪ್ರತಿ ಟೂಲ್‌ಗೆ ಪ್ರವೇಶ ಹೊಂದಿರುತ್ತದೆ, ಇದರಲ್ಲಿ ವೆಬ್ ಹುಡುಕಾಟ, ಮೆಮೊರಿ, ಬ್ರೌಸರ್ ಸ್ವಯಂಚಾಲನ, ಮತ್ತು ಎಲ್ಲ ಸಂಪರ್ಕಿತ ಏಕೀಕರಣಗಳು ಸೇರಿವೆ.

ಉಪ-ಏಜೆಂಟ್‌ನ ಔಟ್‌ಪುಟ್ ನೇರವಾಗಿ ವರ್ಕ್‌ಫ್ಲೋದ ಮುಂದಿನ ಹಂತಕ್ಕೆ ಹೋಗುತ್ತದೆ. ತರ್ಕದ ಸಮಯದಲ್ಲಿ ವರ್ಗೀಕೃತ ಡೇಟಾ ಪ್ರವೇಶಿಸಿದ್ದರೆ, ಅಧಿವೇಶನ taint ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ ಮತ್ತು ಮೂಲ ವರ್ಕ್‌ಫ್ಲೋಗೆ ಹಿಂದಕ್ಕೆ ಹರಡುತ್ತದೆ.

ನೈಜ ಸಂದರ್ಭದ ಆಧಾರದ ಮೇಲೆ ಷರತ್ತುಬದ್ಧ ಶಾಖೆಗಳು

ವರ್ಕ್‌ಫ್ಲೋ DSL ಷರತ್ತುಬದ್ಧ ರೂಟಿಂಗ್‌ಗಾಗಿ switch ಬ್ಲಾಕ್‌ಗಳು, ಬ್ಯಾಚ್ ಸಂಸ್ಕರಣೆಗಾಗಿ for ಲೂಪ್‌ಗಳು, ಮತ್ತು ವರ್ಕ್‌ಫ್ಲೋ ಸ್ಥಿತಿ ನವೀಕರಿಸಲು set ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಸಂಗ್ರಹ ಷರತ್ತುಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಲ್ಲ LLM ಉಪ-ಏಜೆಂಟ್ ಹಂತಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಿ, ವರ್ಕ್‌ಫ್ಲೋ ಕೇವಲ ಕ್ಷೇತ್ರ ಮೌಲ್ಯಗಳ ಬದಲು ನಿಜವಾದ ವ್ಯಾಪಾರ ಸಂದರ್ಭದ ಆಧಾರದ ಮೇಲೆ ಶಾಖೆಯಾಗಬಲ್ಲದು.

ವ್ಯವಸ್ಥೆಗಳು ಬದಲಾದಾಗ ಸ್ವಯಂ-ಚಿಕಿತ್ಸೆ

ಒಂದು API ತನ್ನ ಪ್ರತಿಕ್ರಿಯೆ ಸ್ವರೂಪ ಬದಲಾಯಿಸಿದ ಕಾರಣ ನಿರ್ಣಾಯಕ ಹಂತ ವಿಫಲವಾದಾಗ, ವರ್ಕ್‌ಫ್ಲೋ ನಿಲ್ಲುವುದಿಲ್ಲ. ಎಂಜಿನ್ ವಿಫಲ ಹಂತವನ್ನು LLM ಉಪ-ಏಜೆಂಟ್‌ಗೆ ನಿಯೋಜಿಸಬಲ್ಲದು. ಹೊಸ ಅಗತ್ಯ ಕ್ಷೇತ್ರ ಸೇರಿಸಿದ API ಅನ್ನು ಉಪ-ಏಜೆಂಟ್ ದೋಷ ಸಂದೇಶ ಓದಿ ವಿನಂತಿ ಸರಿಹೊಂದಿಸಿ ನಿರ್ವಹಿಸುತ್ತದೆ. ತನ್ನ ದೃಢೀಕರಣ ಹರಿವು ಬದಲಾಯಿಸಿದ ವ್ಯವಸ್ಥೆಯನ್ನು ಬ್ರೌಸರ್ ಸ್ವಯಂಚಾಲನ ಟೂಲ್‌ಗಳು ನ್ಯಾವಿಗೇಟ್ ಮಾಡುತ್ತವೆ.

ಇದರ ಅರ್ಥ ಪ್ರತಿ ವೈಫಲ್ಯ ಮಾಯಾಜಾಲದಂತೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ ಎಂದಲ್ಲ. ಆದರೆ ವರ್ಕ್‌ಫ್ಲೋ ಮೌನವಾಗಿ ವಿಫಲವಾಗುವ ಬದಲು ಕ್ರಮೇಣ ಕ್ಷೀಣಿಸುತ್ತದೆ ಎಂದು ಅರ್ಥ.

ಸಂಪೂರ್ಣ ಸರಪಳಿಯಾದ್ಯಂತ ಸುರಕ್ಷತೆ

Triggerfish ವರ್ಕ್‌ಫ್ಲೋದ ಪ್ರತಿ ಹಂತ ಯಾವುದೇ ನೇರ ಟೂಲ್ ಕರೆಯ ಅದೇ ನೀತಿ ಜಾರಿ hooks ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ. PRE_TOOL_CALL ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು ಅನುಮತಿಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ. POST_TOOL_RESPONSE ಹಿಂತಿರುಗಿದ ಡೇಟಾವನ್ನು ವರ್ಗೀಕರಿಸುತ್ತದೆ. PRE_OUTPUT ಯಾವುದೂ ಗುರಿ ಅನುಮತಿಸುವ ವರ್ಗೀಕರಣ ಮಟ್ಟಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ವರ್ಗೀಕರಣದಲ್ಲಿ ವ್ಯವಸ್ಥೆ ಬಿಡಲಾಗುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ವರ್ಕ್‌ಫ್ಲೋ ವ್ಯಾಖ್ಯಾನ ಸ್ವತಃ classification_ceiling ಸೆಟ್ ಮಾಡಬಲ್ಲದು. INTERNAL ನಲ್ಲಿ ವರ್ಗೀಕರಿಸಿದ ಸಾಪ್ತಾಹಿಕ ಸಾರಾಂಶ ವರ್ಕ್‌ಫ್ಲೋ CONFIDENTIAL ಡೇಟಾ ಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ, ಅದನ್ನು ಮಾಡಲು ರುಜುವಾತುಗಳಿದ್ದರೂ ಸಹ. ಮಿತಿ ಕೋಡ್‌ನಲ್ಲಿ ಜಾರಿಯಾಗುತ್ತದೆ, LLM ಪ್ರಾಂಪ್ಟ್ ಸೂಚನೆಯನ್ನು ಗೌರವಿಸಬಹುದೆಂದು ಆಶಿಸಿ ಅಲ್ಲ.

Cron ಮತ್ತು Webhook ಟ್ರಿಗರ್‌ಗಳು

ವರ್ಕ್‌ಫ್ಲೋಗಳಿಗೆ ಯಾರಾದರೂ ಅವುಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪ್ರಾರಂಭಿಸುವ ಅಗತ್ಯ ಇಲ್ಲ. ಶೆಡ್ಯೂಲರ್ ಆವರ್ತಕ ವರ್ಕ್‌ಫ್ಲೋಗಳಿಗೆ cron-ಆಧಾರಿತ ಟ್ರಿಗರ್‌ಗಳು ಮತ್ತು ಈವೆಂಟ್-ಚಾಲಿತ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಗಾಗಿ webhook ಟ್ರಿಗರ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಬೆಳಿಗ್ಗೆ ಬ್ರೀಫಿಂಗ್ ವರ್ಕ್‌ಫ್ಲೋ ಬೆಳಿಗ್ಗೆ 7 ಗಂಟೆಗೆ ಚಲಿಸುತ್ತದೆ. GitHub webhook ಕಳಿಸಿದಾಗ PR ವಿಮರ್ಶೆ ವರ್ಕ್‌ಫ್ಲೋ ಚಾಲನೆಯಾಗುತ್ತದೆ. ಹಂಚಿಕೆಯ ಡ್ರೈವ್‌ನಲ್ಲಿ ಹೊಸ ಫೈಲ್ ಕಾಣಿಸಿಕೊಂಡಾಗ ಇನ್‌ವಾಯ್ಸ್ ಸಂಸ್ಕರಣೆ ವರ್ಕ್‌ಫ್ಲೋ ಟ್ರಿಗರ್ ಆಗುತ್ತದೆ.

ಅಭ್ಯಾಸದಲ್ಲಿ ಇದು ಹೇಗೆ ಕಾಣುತ್ತದೆ

NetSuite, Coupa, DocuSign, ಮತ್ತು Slack ಅದ್ಯಂತ ಖರೀದಿ-ಪಾವತಿ ನಡೆಸುವ ಮಧ್ಯಮ-ಮಾರುಕಟ್ಟೆ ಕಂಪನಿ ಸಂಪೂರ್ಣ ಚಕ್ರ ನಿರ್ವಹಿಸುವ Triggerfish ವರ್ಕ್‌ಫ್ಲೋ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ನಿರ್ಣಾಯಕ ಹಂತಗಳು ಖರೀದಿ ಆದೇಶಗಳು ರಚಿಸಲು, ಅನುಮೋದನೆಗಳನ್ನು ರೂಟ್ ಮಾಡಲು, ಮತ್ತು ಇನ್‌ವಾಯ್ಸ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು API ಕರೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ. LLM ಉಪ-ಏಜೆಂಟ್ ಹಂತಗಳು ಅಪವಾದಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ: PO ಗೆ ಹೊಂದಿಕೆಯಾಗದ ಲೈನ್ ಐಟಂಗಳ ಇನ್‌ವಾಯ್ಸ್‌ಗಳು, ನಿರೀಕ್ಷಿತ ಸ್ವರೂಪದಲ್ಲಿ ದಾಖಲೆ ಸಲ್ಲಿಸಿದ ವೆಂಡರ್‌ಗಳು, ವಿನಂತಿಕರ್ತನ ಇತಿಹಾಸದ ಸಂದರ್ಭ ಅಗತ್ಯವಿರುವ ಅನುಮೋದನೆ ವಿನಂತಿಗಳು.

Coupa ತನ್ನ API ನವೀಕರಿಸಿ ಕ್ಷೇತ್ರ ಹೆಸರು ಬದಲಾಯಿಸಿದಾಗ, ವರ್ಕ್‌ಫ್ಲೋದ ನಿರ್ಣಾಯಕ HTTP ಹಂತ ವಿಫಲವಾಗುತ್ತದೆ. ಎಂಜಿನ್ ಉಪ-ಏಜೆಂಟ್‌ಗೆ ನಿಯೋಜಿಸುತ್ತದೆ ಅದು ದೋಷ ಓದುತ್ತದೆ, ಬದಲಾದ ಕ್ಷೇತ್ರ ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು ಸರಿಯಾದ ಮಾಪಕದೊಂದಿಗೆ ಮರು-ಪ್ರಯತ್ನ ಮಾಡುತ್ತದೆ. ಮಾನವ ಹಸ್ತಕ್ಷೇಪ ಇಲ್ಲದೆ ವರ್ಕ್‌ಫ್ಲೋ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ.