April 2026 में हर Agent Platform ने Tracing शिप की। कोई भी नहीं बता सकता कि तुम्हारे Agent ने गलत Decision क्यों लिया

तुमने अपना पहला production agent शिप कर दिया — एक AI जो सिर्फ सवालों के जवाब नहीं देता बल्कि असल में काम करता है: 50–200 tool calls chain करता है (Slack, Linear, GitHub जैसी external services को requests), कोड लिखता है, messages भेजता है, tickets बनाता है। Customer result पर depend कर रहा है। Life झकास है।

फिर एक customer को गलत जवाब मिलता है। तुम्हारे agent ने गलत Linear project में लिख दिया, एक खराब PR merge कर दिया, CEO को Slack DM भेज दिया junior engineer की जगह। तुम्हें पता लगाना है क्यों — इससे पहले कि ये दोबारा करे।

तो तुम उन चमचमाते नए observability tools की तरफ भागते हो जो April 2026 में हर major platform ने शिप किए। 8 April को Anthropic ने Managed Agents लॉन्च किए built-in session tracing और tool call logs के साथ। 10 April को Zed ने Agent Metrics शिप किए — dashboards जो 2 million sessions, 15.4 million turns track कर रहे हैं, 536 अलग-अलग agents के latency histograms। 15 April को OpenAI ने अपना Agents SDK अपडेट किया auto-tracing के साथ जो हर tool call, handoff, और model output record करता है — zero extra instrumentation — plus पूरी OpenTelemetry compatibility (OpenTelemetry industry standard है performance data collect करने का, जैसे monitoring tools के लिए एक universal plug)।

हर vendor ने एक ही problem solve किया: दिखाओ क्या हुआ। और अच्छा किया। तुम traces खोलते हो — हर LLM invocation, हर tool call, हर token (AI जो word-chunk process करता है) के लिए spans (हर operation का individual record)। खूबसूरत waterfall diagrams। precise latency numbers।

पर यहाँ चीज़ें टूटती हैं। Agent trace microservice trace नहीं है। Microservices — वो छोटे, independent programs जो ज़्यादातर web apps चलाते हैं — deterministic होते हैं: same input, same output, same bug, reproducible fix। Agents non-deterministic हैं: बिल्कुल same task दोबारा चलाओ, step 47 पर अलग decisions मिलेंगे। Agent ने path A चुना, पर तुम देख नहीं सकते कि path B कैसा दिखता, या क्यों उसने 80,000 tokens के accumulated context (AI की "working memory" — वो सबकुछ जो उसने अब तक पढ़ा और generate किया है) को देखते हुए A चुना B नहीं।

Simon Willison ने अपने 3 April के Agentic Engineering Patterns गाइड में लिखा: "हम ensure नहीं कर सकते कि agent faithfully काम कर रहा है या problems diagnose नहीं कर सकते अगर उसके operations पूरी तरह opaque हैं।" और Sentry की 16 April की post-mortem ने exact failure mode पकड़ी: हर span status: ok report कर रहा है, पर output पूरा गलत है। Bug agents के बीच में बैठा है — एक tool call चुपचाप दो steps बाद दूसरे agent का input खराब कर देती है।

Agent की गलत decision को उसके trace से debug करना वैसा ही है जैसे किसी इंसान की decision को उसके Google Calendar से debug करना — तुम देख सकते हो किन meetings में गया, ये नहीं कि क्या सोच रहा था।

Market का workaround: LLM-as-judge — एक दूसरे AI model का इस्तेमाल पहले model की decisions evaluate करने के लिए। Braintrust (February में $80M raise किया $800M valuation पर), LangSmith की trajectory evals, और Arize Phoenix सब evaluation को traces पर bolt करते हैं। पर हर एक नई dependency जोड़ता है, हर decision point पर extra token cost, और — यहाँ मज़ा आता है — judge model में वही architectural blind spots हैं जो उस agent में हैं जिसे वो judge कर रहा है। अंधा अंधे को रास्ता दिखा रहा है, बस।

आज का practical workaround: अपने agent को force करो कि हर branching point पर structured reasoning emit करे। सिर्फ tool call record नहीं, बल्कि एक JSON rationale:

import json

def log_decision(step: int, options: list[str], chosen: str, reasoning: str):
    """Emit a searchable reasoning trail at every branch."""
    entry = {
        "step": step,
        "options_considered": options,
        "chosen_action": chosen,
        "reasoning": reasoning,
        "context_tokens_used": get_current_context_length(),
    }
    logger.info("agent_decision", extra=entry)
    return entry

# Inside your agent loop:
log_decision(
    step=47,
    options=["post to #general", "post to #engineering", "DM the assignee"],
    chosen="DM the assignee",
    reasoning="Ticket is labeled 'confidential', channel posting violates policy"
)

हाँ, extra tokens लगेंगे। हाँ, execution slow होगा। पर failure के बाद एक searchable reasoning trail बनाने का यही एकमात्र तरीका है जिसे कोई इंसान audit कर सके — क्योंकि अकेले traces तुम्हें नहीं बताएँगे कि step 47 क्यों उल्टा पड़ गया।

हर platform ने "क्या हुआ" शिप किया। किसी ने "क्यों ये रास्ता, वो क्यों नहीं" शिप नहीं किया। जो पहली company reasoning-native observability बनाएगी — trace-native नहीं, reasoning-native — वो हर production agent के लिए debugging layer own करेगी, वैसे ही जैसे Datadog microservices की monitoring own करता है। तब तक, तुम अपने agent का calendar पढ़ रहे हो और अंदाज़ा लगा रहे हो कि वो क्या सोच रहा था।