Slack के engineers ने एक architecture breakdown प्रकाशित किया — InfoQ ने 28 अप्रैल को कवर किया — जो बताता है कि वे लंबे multi-agent systems में context कैसे manage करते हैं, जहां एक application सैकड़ों requests और मेगाबाइट output तक फैल सकती है। मानक agent frameworks calls के बीच chat history जमा करते हैं, लेकिन लंबे production sessions में यह दृष्टिकोण context window की सीमा से टकराता है और hard limit से बहुत पहले ही response quality घटाता है। Staff engineer Dominic Marks विकल्प का वर्णन करते हैं: chat logs जमा करने को structured memory channels, समर्पित critic agents, और run के पूरे जीवनकाल में बचने वाली एक distilled timeline से बदलना।
Architecture एक coordinator/dispatcher pattern है। एक केंद्रीय coordinator requests प्राप्त करता है और उन्हें नीचे की ओर specialized agents को भेजता है — experts जो वास्तविक काम करते हैं, और critics जो experts के output का मूल्यांकन करते हैं। Critics ज़रूरी हैं क्योंकि (Slack के शब्दों में) experts के findings का एक हिस्सा "या तो गढ़ा गया हो सकता है या डेटा की मोटी ग़लत व्याख्या कर सकता है।" तीन structured context channels असीमित chat log के बजाय running state ले जाते हैं। director's journal director की structured working memory रखती है — findings, observations, decisions, खुले प्रश्न, hypotheses — और इसका वर्णन "वह सामान्य narrative जो बाक़ी agents को रास्ते पर रखती है" के रूप में किया गया है। critic's review credibility scores के साथ एक annotated findings report है, जिसे critics संकीर्ण निर्देश पर बनाते हैं — "केवल प्रस्तुत findings पर निर्णय करना" — यानी न drift, न आविष्कार। critic's timeline director's journal, नवीनतम review, और पिछली timeline से एक coherent narrative बनाती है, findings deduplicate करती है और credibility-weighted evidence को प्राथमिकता देकर conflicts हल करती है।
यह pattern मायने रखता है क्योंकि chat-log जमा करने की रणनीति जो छोटे single-agent interactions के लिए काम करती है, multi-step production workflows पर scale नहीं होती। तीन बातें जो Slack का design निहित करता है, अब लंबे agents के लिए industry common sense हैं: critic agents ज़रूरी हैं क्योंकि expert agents महत्वपूर्ण दरों पर hallucinate करते हैं; structured memory raw chat history को मात देती है क्योंकि यह summarization और credibility scoring पर मजबूर करती है; और समय-क्रमबद्ध narrative-distillation — Slack की "timeline" — agents को सैकड़ों requests में coherent रखने के लिए ज़रूरी है। यह pattern सामान्यीकरण योग्य है: कोई भी टीम जो multi-agent workflows चलाती है जो सेकंडों के बजाय मिनटों से घंटों तक फैलते हैं, उसे director/critic/timeline split का कोई न कोई रूप, या उसके बहुत क़रीब का कुछ चाहिए होगा। सटीक channel नाम और संरचनाएं भिन्न होंगी, लेकिन तीन भूमिकाएं — narrative carrier, credibility scorer, timeline builder — frameworks में convergence की संभावना है।
Builders के लिए, तीन ठोस बातें। पहला, अगर आप ऐसे agentic workflows बना रहे हैं जो एक chat-window के state से अधिक तक फैलते हैं, तो केवल message history जमा न करें — पहले दिन से ही credibility metadata के साथ structured memory channels design करें। उस pattern को बाद में retrofit करना कष्टदायक है। दूसरा, "केवल प्रस्तुत findings पर निर्णय करने" तक सीमित critic agents Slack द्वारा खोजा सबसे सस्ता hallucination defense हैं: संकीर्ण scope + समर्पित भूमिका + credibility scoring। expert agent के अपने ही errors पकड़ लेने की उम्मीद करने के बजाय इसे अपनी multi-agent layer में बनाएं। तीसरा, engineering संस्कृति मायने रखती है: Slack इस architecture को सार्वजनिक रूप से प्रकाशित कर रहा है, जिसका मतलब है कि भविष्य के open-source frameworks संभवतः coordinator/director/critic/timeline जैसी किसी चीज़ पर standardize करेंगे। अगले कुछ महीनों में LangGraph, AutoGen और CrewAI पर नज़र रखें कि यह pattern एक प्रथम-श्रेणी abstraction के तौर पर उतरता है या नहीं।