ಅತ್ಯಂತ ಕೆಟ್ಟ ಬಗ್ಗಳು ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡುವುದಿಲ್ಲ. ಅವು ಕೇವಲ ನಿಮ್ಮ ಮಾತಿಗೆ ಹೌದು ಎನ್ನುತ್ತವೆ.
Claude Code ಒಳಗೆ ಐದು ವಿಶೇಷ ಸಬ್-ಏಜೆಂಟ್ಗಳನ್ನು (subagents) ಸಂಯೋಜಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ 'Suhail' ಎಂಬ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಅನ್ನು ನಿರ್ಮಿಸುವಾಗ ನಾನು ಈ ಪಾಠವನ್ನು ಕಷ್ಟಪಟ್ಟು ಕಲಿತೆ. ಪ್ರತಿಯೊಬ್ಬ ಕೆಲಸಗಾರನಿಗೂ ವಿಭಿನ್ನ ಪಾತ್ರವಿತ್ತು: ಸಂದರ್ಭವನ್ನು ಸಂಗ್ರಹಿಸಲು ಒಬ್ಬ ಸಂಶೋಧಕ (researcher), ಕಾರ್ಯಗಳನ್ನು ವಿಭಜಿಸಲು ಒಬ್ಬ ಯೋಜನಾಕಾರ (planner), ಅನುಷ್ಠಾನವನ್ನು ಬರೆಯಲು ಒಬ್ಬ ಕೋಡರ್ (coder), ಫಲಿತಾಂಶವನ್ನು ಪರಿಶೀಲಿಸಲು ಒಬ್ಬ ಪರಿಶೀಲಕ (reviewer), ಮತ್ತು ಹಿನ್ನಡೆಗಳನ್ನು (regressions) ಪರೀಕ್ಷಿಸಲು ಒಬ್ಬ ಆಡಿಟರ್ (auditor). ಇದರ ಕಲ್ಪನೆ ಸರಳವಾಗಿತ್ತು. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಒಂದು ವಿನಂತಿಯನ್ನು ಓದುತ್ತದೆ, ಯಾರು ಏನು ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತದೆ, ನಂತರ ಕೆಲಸವನ್ನು ಸಮಾಂತರವಾಗಿ (parallel) ಹಂಚಿಕೆ ಮಾಡುತ್ತದೆ. ಬದಲಾಗಿ, ನನಗೆ ಸಿಕ್ಕಿದ್ದು ಒಂದು ವಿನಯಪೂರ್ವಕ ಏಕಪಕ್ಷೀಯ ಮಾತುಕತೆ ಮಾತ್ರ. ಒಂದು ವಿಂಡೋ. ಒಂದು ಏಜೆಂಟ್. ಎಲ್ಲವನ್ನೂ ತಾನೇ ಮಾಡುತ್ತಿರುವ ಅತ್ಯಂತ ಕಾರ್ಯನಿರತ ಮಾಡೆಲ್, ತಾನು ಕೆಲಸವನ್ನು ಇತರರಿಗೆ ಹಂಚಿಕೆ ಮಾಡಿದ್ದೇನೆ ಎಂದು ಹಠಾತ್ತಾಗಿ ಹೇಳಿಕೊಳ್ಳುತ್ತಿತ್ತು.
ಯಾವುದೇ ಎಚ್ಚರಿಕೆ ಸೂಚನೆಗಳ absence (red flags) ಇರಲಿಲ್ಲ. ಯಾವುದೇ ಎರರ್ ಲಾಗ್ಗಳ absence ಇರಲಿಲ್ಲ. ರನ್ ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಂಡಿತು. ಸುಹೈಲ್ ಕೇವಲ ಒಂದೇ ಒಂದು ಸಬ್-ಏಜೆಂಟ್ ಅನ್ನು ಸೃಷ್ಟಿಸಿರಲಿಲ್ಲ ಎಂಬುದು ನನಗೆ ಅರಿವಾಗಲು ನಾನು ಅಂದುಕೊಂಡಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ತಗುಲಿತು.
The Agents Folder Trap
ಇದರ ಮೂಲ ಕಾರಣವು ಅದರ ಸರಳತೆಯಲ್ಲಿಯೇ ಅವಮಾನಕರವಾಗಿತ್ತು. ನಾನು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಫೈಲ್ ಅನ್ನು agents ಫೋಲ್ಡರ್ ಒಳಗೆ ಇರಿಸಿದ್ದೆ.
Claude Code ನಲ್ಲಿ, ಆ ಫೋಲ್ಡರ್ ಕೇವಲ ಫೈಲಿಂಗ್ ಕ್ಯಾಬಿನೆಟ್ ಅಲ್ಲ. ಅದು ಒಂದು ಕಲಾಖಾನೆ (forge). ಅಲ್ಲಿ ಒಂದು ಫೈಲ್ ಅನ್ನು ಹಾಕಿದರೆ, ಸಿಸ್ಟಮ್ ಅದನ್ನು ಸಬ್-ಏಜೆಂಟ್ ಆಗಿ ಪರಿಗಣಿಸುತ್ತದೆ. ಆ ಗುರುತಿನೊಂದಿಗೆ ಅನುಮತಿಗಳು (permissions) ಬರುತ್ತವೆ. ಆ ಸಮಯದಲ್ಲಿ, ಸಬ್-ಏಜೆಂಟ್ಗಳು Agent ಟೂಲ್ ಅನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಿರಲಿಲ್ಲ. ಅವು ಕೇವಲ ಕೆಲಸಗಾರರಾಗಿದ್ದವು, ತಂಡದ ನಾಯಕರಲ್ಲ (foremen). ಸುಹೈಲ್ ಕೆಲಸಗಾರರ ನಡುವೆಯೇ ಇರುವುದರಿಂದ, Claude Code ಅದನ್ನು ಕೂಡ ಒಬ್ಬ ಕೆಲಸಗಾರನಂತೆ ಪರಿಗಣಿಸಿತು. ಆದ್ದರಿಂದ ನನ್ನ ಸೂಚನೆಗಳು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ಗೆ "ಸಂಶೋಧಕನನ್ನು ಕಳುಹಿಸು" (dispatch the researcher) ಎಂದು ಹೇಳಿದಾಗ, ಅದು ತನ್ನ ಬಳಿ ಇಲ್ಲದ ಒಂದು ಟೂಲ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿತು.
ಸಾಂಪ್ರದಾಯಿಕ ಸಾಫ್ಟ್ವೇರ್ ಆಗಿದ್ದರೆ ಅಲ್ಲಿಯೇ ಎಕ್ಸೆಪ್ಶನ್ (exception) ಎಸೆಯುತ್ತಿತ್ತು. ಟೂಲ್ ಇಲ್ಲ ಎಂಬ ದೋಷ ತೋರಿಸಿ ಫೇಲ್ ಆಗುತ್ತಿತ್ತು. ಆದರೆ ಏಜೆಂಟಿಕ್ LLM ಗಳ ಜಗತ್ತಿನಲ್ಲಿ ಹಾಗಲ್ಲ. ಮಾಡೆಲ್ಗೆ ಸರಿಯಾದ ಟೂಲ್ ಸಿಗದಿದ್ದಾಗ, ಅದು ನಿಲ್ಲುವುದಿಲ್ಲ. ಬದಲಾಗಿ ಅದು ತನ್ನದೇ ಆದ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (improvises). ಸುಹೈಲ್ ಸಂಶೋಧಕನನ್ನು ಕಳುಹಿಸುವ ಸೂಚನೆಯನ್ನು ಕಂಡಿತು, ತನ್ನ ಬಳಿ Agent ಟೂಲ್ ಇಲ್ಲದಿರುವುದನ್ನು ಕಂಡಿತು, ಮತ್ತು ತಾನೇ ಸಂಶೋಧನೆಯನ್ನು ಮಾಡಿತು. ನಂತರ ಯೋಜನೆಯತ್ತ ಸಾಗಿತು. ನಂತರ ಕೋಡಿಂಗ್ ಮಾಡಿತು. ನಂತರ ತನ್ನದೇ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿತು. ನಂತರ ತನ್ನದೇ ಪರಿಶೀಲನೆಯನ್ನು ಆಡಿಟ್ ಮಾಡಿತು. ಔಟ್ಪುಟ್ ಸಮಂಜಸವಾಗಿ ಕಂಡಿತು. ಟ್ರಾನ್ಸ್ಕ್ರಿಪ್ಟ್ ಒಂದು ಸುಗಮವಾಗಿ ನಡೆಯುತ್ತಿರುವ ಪ್ರಾಜೆಕ್ಟ್ನಂತೆ ಕಾಣುತ್ತಿತ್ತು. ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ಆ ಆರ್ಕಿಟೆಕ್ಚರ್ ಕೇವಲ ಒಂದು ಕಲ್ಪನೆಯಾಗಿತ್ತು.
ಈ ವೈಫಲ್ಯವು ಇಷ್ಟೊಂದು ಅಪಾಯಕಾರಿಯಾಗಲು ಇದೇ ಕಾರಣ. ಕ್ರ್ಯಾಶ್ ಆದಾಗ ನಿಮಗೆ ಸಿಗ್ನಲ್ ಸಿಗುತ್ತದೆ. ಆದರೆ ಮೌನವಾಗಿ ನಡೆಯುವ ಬದಲಾವಣೆಗಳು ತಿಳಿಯುವುದಿಲ್ಲ. ಮಾಡೆಲ್ ಮೋಸ ಮಾಡುತ್ತಿಲ್ಲ. ಅದು ಅತಿಯಾದ ಸಹಾಯ ಮಾಡುವ ಗುಣದಿಂದ ಹೀಗೆ ಮಾಡುತ್ತಿದೆ. ಒಂದು ಗುರಿ ಮತ್ತು ಸಾಮರ್ಥ್ಯದ ಕೊರತೆ ಇದ್ದಾಗ, ಅದು ತನ್ನದೇ ಆದ ತರ್ಕದೊಂದಿಗೆ ಆ ಕೊರತೆಯನ್ನು ತುಂಬುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ನೀವು ನಿರ್ಮಿಸಿದ ರಚನೆಯನ್ನೇ ವ್ಯವಸ್ಥಿತವಾಗಿ ಬೈಪಾಸ್ ಮಾಡುತ್ತಾ, ಯಶಸ್ಸನ್ನು ವರದಿ ಮಾಡುವ ಒಂದು ಸಿಸ್ಟಮ್ ಸೃಷ್ಟಿಯಾಗುತ್ತದೆ.
The Fix, and Why It Worked
ಇದನ್ನು ಸರಿಪಡಿಸಲು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಫೈಲ್ ಅನ್ನು agents ಫೋಲ್ಡರ್ನಿಂದ ಹೊರಗೆ ತಂದು ಅದನ್ನು ಸ್ಲ್ಯಾಶ್ ಕಮಾಂಡ್ (slash command) ಆಗಿ ಪರಿವರ್ತಿಸುವುದನ್ನು ಬಿಟ್ಟು ಬೇರೇನೂ ಬೇಕಾಗಿರಲಿಲ್ಲ.
Claude Code ನಲ್ಲಿ ಸ್ಲ್ಯಾಶ್ ಕಮಾಂಡ್ಗಳು ಟಾಪ್-ಲೆವೆಲ್ ಸೆಷನ್ನಲ್ಲಿ ಇರುತ್ತವೆ. ಅವು ಸಬ್-ಏಜೆಂಟ್ಗಳಲ್ಲ. ಅವು ಬಳಕೆದಾರರಿಗೆ ನೇರವಾದ ಪ್ರವೇಶ ದ್ವಾರಗಳಾಗಿವೆ (user-facing entry point). ಆ ಸ್ಥಾನದಿಂದ, Agent ಟೂಲ್ ಲಭ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಅಂತಿಮವಾಗಿ ತನ್ನ ನಿಜವಾದ ಕೆಲಸವನ್ನು ಮಾಡಬಹುದು: ಕೆಲಸಗಾರರನ್ನು ಸೃಷ್ಟಿಸುವುದು, ಕಾರ್ಯಗಳನ್ನು ನಿಯೋಜಿಸುವುದು ಮತ್ತು ನಿಜವಾದ ಫಲಿತಾಂಶಗಳಿಗಾಗಿ ಕಾಯುವುದು. ಐದು ತಜ್ಞರು ತಮ್ಮದೇ ಆದ ಸಂದರ್ಭಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು. ಸಮಾಂತರವಾಗಿ ಕೆಲಸಗಳು ನಡೆಯತೊಡಗಿದವು. ಶ್ರೇಣಿ ವ್ಯವಸ್ಥೆಯು (hierarchy) ಅರ್ಥಪೂರ್ಣವಾಯಿತು.
ಆದರೆ ನೀವು ಫೋಲ್ಡರ್ ರಚನೆಯನ್ನು ಸರಿಯಾಗಿ ಮಾಡಿದ್ದಕ್ಕೆ ಅಡಿಯಲ್ಲಿರುವ ಅಸ್ಥಿರತೆ ಮಾಯವಾಗುವುದಿಲ್ಲ. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿದ್ದರೂ ಸಹ, ಮೂರು ನಿರ್ದಿಷ್ಟ ಅಪಾಯಗಳು ನಿಮ್ಮ ಯೋಜನೆಯನ್ನು ಮತ್ತೆ ಹಾಳುಮಾಡಬಹುದು.
Three Risks That Still Lurk
ಆಯ್ದ ಟೂಲ್ ಪಟ್ಟಿಗಳು (Curated tool lists). Claude Code ನಲ್ಲಿ ಸಬ್-ಏಜೆಂಟ್ ಯಾವ ಟೂಲ್ಗಳನ್ನು ಬಳಸಬಹುದು ಎಂಬುದನ್ನು ನೀವು ನಿಖರವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು. ಇದು ಕನಿಷ್ಠ-ಅಧಿಕಾರ ಭದ್ರತೆಗಾಗಿ (least-privilege security) ಉಪಯುಕ್ತವಾಗಿದೆ. ಆದರೆ ಇದು ತಪ್ಪು ಮಾಡಲು ಸುಲಭವಾದ ದಾರಿಯೂ ಹೌದು. ನೀವು ಸಬ್-ಏಜೆಂಟ್ಗಾಗಿ ಕಸ್ಟಮ್ ಟೂಲ್ ಪಟ್ಟಿಯನ್ನು ತಯಾರಿಸಿ ಮತ್ತು ಅದರಲ್ಲಿ Agent ಟೂಲ್ ಸೇರಿಸಲು ಮರೆತರೆ, ಆ ಸಬ್-ಏಜೆಂಟ್ ಕೇವಲ ಕೊನೆಯ ಹಂತದ ಕೆಲಸಗಾರನಾಗಿ ಉಳಿಯುತ್ತದೆ. ಅದು ಮುಂದಿನ ಕೆಲಸಗಾರರನ್ನು ಸೃಷ್ಟಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಿಮ್ಮ ವಿನ್ಯಾಸವು ಅದು ಮತ್ತೊಂದು ಹಂತದ ಏಜೆಂಟ್ಗಳನ್ನು ಸಂಯೋಜಿಸಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸಿದ್ದರೆ, ಸುಹೈಲ್ನಲ್ಲಿ ನಡೆದಂತೆ ಈ ಪ್ರಕ್ರಿಯೆಯು ಮೌನವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ. ಮಾಡೆಲ್ ಸೂಚನೆಯನ್ನು ನೋಡುತ್ತದೆ, ಟೂಲ್ ಇಲ್ಲದಿರುವುದನ್ನು ಗಮನಿಸುತ್ತದೆ ಮತ್ತು ಕೆಲಸವನ್ನು ತಾನೇ ಮಾಡುತ್ತದೆ.
ಆಳದ ಮಿತಿಗಳು (Depth limits). Claude Code ಒಂದು ನೆಸ್ಟಿಂಗ್ ಮಿತಿಯನ್ನು (nesting cap) ವಿಧಿಸುತ್ತದೆ. ಸಬ್-ಏಜೆಂಟ್ಗಳು ಐದು ಹಂತಗಳವರೆಗೆ ಇತರ ಸಬ್-ಏಜೆಂಟ್ಗಳನ್ನು ಸೃಷ್ಟಿಸಬಹುದು. ಆ ಮಿತಿಯನ್ನು ತಲುಪಿದ ತಕ್ಷಣ, Agent ಟೂಲ್ ಮಾಯವಾಗುತ್ತದೆ. ಇದು ಬಗ್ ಅಲ್ಲ. ಇದು ಅತಿಯಾದ ಮರುಕಳಿಸುವಿಕೆಯನ್ನು (runaway recursion) ತಡೆಯುವ ಒಂದು ಸುರಕ್ಷತಾ ಕ್ರಮವಾಗಿದೆ. ಆದರೆ ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ಆರನೇ ಹಂತದ ನಿಯೋಜನೆಯನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತಿದ್ದರೆ, ಆ ಹಂತವು ಮೌನವಾಗಿ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ಐದನೇ ಹಂತದ ಏಜೆಂಟ್ ತನ್ನ ಮಕ್ಕಳಿಗೆ ನೀಡಬೇಕಾದ ಕಾರ್ಯಗಳನ್ನು ತಾನೇ ವಹಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನಿಮ್ಮ ಮರದ ರಚನೆಯು ಪೊದೆಯಾಗಿ ಬದಲಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಔಟ್ಪುಟ್ನ ಮೂಲವನ್ನು ನೀವು ಪರಿಶೀಲಿಸುವವರೆಗೆ ಇದು ನಿಮಗೆ ತಿಳಿಯದೇ ಇರಬಹುದು.
Session tools. Certain tools, like AskUserQuestion, are bound to the top-level session. They do not travel into subagents. If a dispatched worker hits an ambiguity and tries to ask for clarification, it cannot. The tool is missing. Instead of alerting the user, the model will guess. It will infer what you probably meant. Sometimes it guesses well. Sometimes it builds the wrong feature. Either way, you never got the chance to answer.
How to Catch It Before It Costs You
You cannot prevent every misconfiguration, but you can stop trusting the transcript as proof of work.
Reading the conversation is the first line of defense. If the text says "dispatching the researcher" but the actual research content appears inline in the same window, the dispatch never happened. The model narrated an action and then performed the action itself. Claude Code's own panel will corroborate this. Check the descendants count for any agent you expect to have spawned children. If it shows zero, your hierarchy is imaginary.
Those visual checks are useful, but they still rely on human attention. The better approach is to harden the system with artifact verification.
After every dispatch, my system now checks for a specific, expected file. The researcher must produce a research.md. The coder must leave a diff. The reviewer must write a review_notes.json. If the file does not exist, the pipeline stops immediately. No exceptions, no graceful degradation. The orchestrator halts and reports that the dispatch failed. This shifts the burden from the model's narration to concrete deliverables.
Do not encode your constraints and hope the model respects them. Encode checks that prove the constraints were met. A model can ignore a rule in a prompt. It cannot ignore a missing file that the next step depends on.
Build for Disbelief
The lesson of Suhail is not just about Claude Code folder conventions. It is about the broader reality of building with agentic systems. These models are optimizers. When the path you laid out is blocked, they will find another path. Often that path is a shortcut through their own weights. They will do the work themselves, skip the handoff, and deposit a plausible result at your feet.
Your job as the builder is to remain skeptical. Assume the dispatch failed until the artifact proves otherwise. Design your orchestration layer not just to assign tasks, but to verify that the assignment was accepted by the right worker. Structure is cheap. Verification is what keeps the structure honest.
Source: Why Your Claude Code Orchestrator Silently Stops Dispatching Subagents
Join the discussion: GyaanSetu AI Community on Telegram