Building a Network Troubleshooting Agent: Architecture, Tools, Guardrails, and Lessons Learned#

Karthik Srinivas Muthuramakrishnan – Microsoft

• Why: Agentic network ops is arriving, and the hard problems are authorization and evidence control, not model choice — the design here (scoped approvals, fail-closed authority) maps directly onto the PM's workload/agentic-identity expertise.
• What: An agent architecture that keeps reasoning, policy, and execution strictly separate: "the model proposes, trusted code decides what can execute." Four pillars: a model-agnostic harness (playbook version, tool schemas, target, and policy budget held constant while model and tool sequence vary — making runs comparable); guardrails (policy checks before any request reaches the adapter: tool allowlist, rate/concurrency, equivalent-call loop limits, failure thresholds, session budget with kill switch); audit (ordered observable events, not private model reasoning — one session artifact answers six operational questions); and memory (verified history reorders safe reads earlier but never authorizes; compatibility keys include device identity, software and playbook versions).
• How: Approval binds one exact action — approver identity, target router, action name, arguments digest, expiry — and fails closed on wrong target, changed arguments, or expiry. Typed, staged reads per versioned playbook (e.g. bgp-neighbor-down 1.0.0) keep deterministic operations deterministic.
• Where applicable: Demonstrated in a virtual router environment at Microsoft; the pattern generalizes to any organization exposing network capabilities to LLM agents, and the approval-grant model is essentially scoped, short-lived credentials — familiar territory for anyone thinking about workload identity for agents.