एक शुरुआती tester एक लंबे task पर काम करा रही थी, तभी उसने chat में एक correction टाइप की — बिना कुछ रोके। बाद में उसने हमें बताया कि वह पल उम्मीद से ज़्यादा अच्छा लगा: दूसरा agent tool जो वह इस्तेमाल करती है, नया message स्वीकार करने से पहले उससे run रुकवाता है। "सिर्फ़ बात करने के लिए उसे रोकना बेतुका लगता था," उसने कहा, "इसके मुक़ाबले।"
वह सही है, और यह फ़र्क़ कोई छोटी UX नफ़ासत नहीं है। यह एक design decision से आता है जो हमने शुरू में लिया और बार-बार दोहराते हैं: agent एक colleague है, machine नहीं। आप किसी colleague को बीच-बात में interrupt करते हैं और वह उसे बात में मिला लेता है। आप उसे power-cycle नहीं करते।
"पहले रोको" क्यों ग़लत default है
बोलने से पहले user से run रुकवाने की तीन कीमतें हैं, तीनों user चुकाता है:
- Correction बहुत देर से आती है। जिस पल आपको agent को भटकते हुए दिखता है, ठीक तभी आपको बोलना चाहिए। रुकवाने पर मजबूर करने का मतलब है उसे ग़लत रास्ते पर time और tokens जलाते देखना, जब तक आप halt button ढूँढते रहते हैं।
- रोकना state मिटा देता है। रुका हुआ run दोबारा शुरू नहीं होता — आप फिर से शुरू करते हैं, या बुरा यह कि आपको एक "cancelled" stub मिलता है और context फिर से समझाना पड़ता है। आपकी mid-flight course correction की कीमत पूरा चलता हुआ काम हो जाती है।
- यह किसकी सेवा कौन कर रहा है, उल्टा कर देता है। "machine अभी आपकी बात नहीं सुन सकती, बाद में आइए" machine की सुविधा है, आपकी नहीं।
हमारा असल में कैसे काम करता है
जब run के चलते हुए आप कोई message भेजते हैं, तीन चीज़ें क्रम से होती हैं:
- आपके शब्द पहले save होते हैं। Message तुरंत conversation history में उतर जाता है — कुछ भी dispatch होने से पहले। आपका intent उसी पल से durable है; कोई queue, buffer या timing उसे खो नहीं सकती।
- यह अगले step boundary पर पहुँचता है। Agent tool-call के बीच में हाथ का काम नहीं छोड़ता — वह आपका message अगले natural pause पर पढ़ता है, जिस तरह कोई इंसान अपनी बात पूरी करके फिर आपकी बात लेता है।
- यह रुख़ मोड़ता है, restart नहीं करता। run ने जो कुछ कर लिया वह बना रहता है। आपका message एक चलते task पर लगी course correction है, reboot नहीं।
नीचे बसा सिद्धांत: user intent की durability, system की convenience से ऊपर है। एक बार शब्द save हो गए, तो आगे की हर चीज़ सिर्फ़ timing है — और timing को graceful बनाया जा सकता है। बिना save हुआ intent बिलकुल recover नहीं हो सकता।
Practice में यह कैसा दिखता है
सबसे साफ़ उदाहरण पहले से public है। clock वाली कहानी में, founder की माँग दो बार मुड़ी जबकि agent काम कर रहा था — "असल में, इसका एक HTML version बना दो," फिर "इसे एक installable web app की तरह package करो।" हर interjection mid-run में उतरी और trajectory को मोड़ गई। किसी ने stop नहीं दबाया; जो app ship हुई वह हवा में दी गई corrections से आकार पाई।
रोज़मर्रा का ज़्यादा सूक्ष्म version फ़ीका और ज़्यादा क़ीमती है: आप किसी research task में दस messages आगे हैं, आपको दिखता है कि वह ग़लत comparison बना रहा है, आप टाइप करते हैं "उसके बजाय X से compare करो" — और उसे मुड़ते देखते हैं, बिना उन आठ अच्छे sources खोए जो उसने पहले ही इकट्ठा कर लिए थे।
सिद्धांत साथ चलता है
इस हफ़्ते हम दूसरी तरफ़ से उसी सवाल पर पहुँचे: जब हम आपको interrupt करें तो क्या होता है — deploy के लिए server restart? ईमानदार जवाब वही rule निकला। Deploys के दौरान server अब mid-run injections स्वीकार करता है (आपके save हुए शब्द बचे रहते हैं और अगला run उन्हें context में उठाता है), जबकि सिर्फ़ नए run शुरू होना pause होता है। User के पहले से टाइप किए input को reject करना हमारी convenience का आपके intent पर हावी होना होता — ठीक वही उल्टा क्रम जिसकी हमने ऊपर आलोचना की, बस ops की पोशाक पहने।
हम यह दावा नहीं कर रहे कि यह नई चीज़ है — queued interruptions अच्छे systems में हमेशा से ऐसे ही काम करते रहे हैं। बस agent UX में यह दुर्लभ है, जहाँ "machine से बात करने के लिए उसे रोको" किसी तरह norm बन गया। हमें वह boring, correct default बनकर ख़ुशी है।
Inside OnePress — the build log
More posts like this, plus the weekly AI digest, straight to your inbox.
Get the build log in your inbox →Reading this and have thoughts?
Spot a mistake, disagree, or want a follow-up? Tell us — a human reads it.