The Demo Broke and the Agent Fixed It: Taran Deshpande at CHI-NOG 13

Four XRd containers, a full room, and a BGP table with zero prefixes in it. Taran Deshpande’s AI agent had just designed and launched an SRv6 L3VPN lab live on stage at CHI-NOG 13. ISIS came up clean. The VPN refused to converge. And Deshpande didn’t touch his keyboard.

The agent re-ran its show commands, waited long enough to rule out slow convergence, and its status output ticked over to a diagnosis, something close to “still shows zero prefixes, okay, configuration issue.” Then it looped back to its own design phase, reworked the BGP config, tore the lab down with its own tooling, relaunched all four routers, and walked its checks again. Second pass, ISIS up, BGP converged, and the end to end ping between the CEs went through. Nobody edited a config by hand.

A Cisco TME demo that runs clean from prompt to passing ping reads like a launch video, and I probably would have skipped writing it up. The failure earned this post. Watching an agent hit a real problem in front of a live audience and dig itself out beats any launch video Cisco could have cut.

One prompt, four routers

Deshpande has been a technical marketing engineer at Cisco for about five years, building hands on labs and workshops for customers. The talk was called “Let the AI Build the Lab: Hands-Off Virtual Topology Prototyping,” and his opening read of the room was dead on. Most network engineers who’ve tried AI have used it the same couple of ways… write a Python script, explain an error message. All useful, and in his words, we’re “leaving something bigger on the table.” My own AI use ran past that stage a while ago, which is probably why the “something bigger” was the part I came to hear.

His test was one prompt. Create a new lab illustrating a simple SRv6 L3VPN, then run show commands against it and build a report that could teach someone how SIDs work. From that single sentence the agent picked a four router linear topology, two CEs and two PEs, checked the VM to confirm it could carry four XRd containers, and generated the XR Compose file, the per router configurations, and a readme with the topology diagram, addressing plan, SRv6 locators, and a list of key show commands. It even suggested evolutions of the lab you might build next.

The framing for why a coding agent fits this work landed for me. Router configs are close enough to code, and getting the protocols to converge is close enough to debugging. The tooling that got good at one turns out to be good at the other.

The stack, which is mostly markdown

The ingredient list is short. Cursor as the agent (a VS Code fork with the AI agent built in), Claude Opus as the model, IOS XRd as the router, and XR Compose, a Docker Compose wrapper built alongside XRd for containerized topologies. XRd is the containerized IOS XR, light enough that a small VM runs a pile of them, and it boots in under 30 seconds. During the launch phase you could watch docker ps list all four routers maybe 20 or 30 seconds after the agent kicked them off.

The skills themselves are nothing new. A skill is a packet of instructions that teaches the agent a workflow, every agent ecosystem has them, and his two are, in his words, “just big markdown files,” which describes every skill I’ve ever seen. What got my attention was the hands. When Deshpande asked who in the room had used agent skills, only a handful went up, which says more about where the field actually is with this stuff than anything on a slide. The files are still worth opening, and he did, on screen. The lab assistant skill describes how to design, launch, and test a good lab. The XR Compose skill documents the tooling, how to clean a lab, read router logs, shut things down, restart. Plain English, no code, the kind of document you’d write for a new hire. (A third small skill did nothing except print readable status lines so the audience could follow the agent’s progress.)

Everything in the stack is free. XRd is downloadable from Cisco for lab use, XR Compose and both skills are open source in Cisco’s xrd-tools repo (the skills sit under skills/ and follow the open Agent Skills format, so they aren’t tied to Cursor), and the VM he ran it on was the free, reservable XRd Sandbox on Cisco DevNet. Bring your own agent and model.

The loop is the argument

The lab assistant skill enforces a three phase workflow (design, launch, interact), and that structure is the whole reason this works better than pasting a prompt into a chat window.

Design comes from the model’s base knowledge, which means it arrives with the model’s hallucinations. So before anything boots, the skill routes the agent through a design review. The agent rereads the configs it generated, identifies each feature in play, and searches Cisco’s public documentation to verify its own work, in this case a CCO doc and an XR docs blog post on SRv6. In the demo, this stage had caught a mistake in the PE configs, and the agent corrected the files and produced a feature by feature checklist mapping SRv6, ISIS, and BGP against the source docs. It’s Gene Kranz’s rule from Apollo 13 (“let’s not make things any worse by guessing”) written into a markdown file.

Launch is gated. Wait for every router to boot, validate that each one accepted its startup config, check protocol convergence, then run smoke tests, usually protocol show commands or an end to end ping. A failure at any gate sends the agent back to design to debug, and then it relaunches. On stage, the gate that tripped was convergence, and the recovery up top was this machinery doing its job in public.

The third phase, interact, is open ended. For this prompt it meant running show commands against the live lab and assembling a walkthrough of how SIDs and locators work, keyed to the actual addressing of the running topology. Deshpande, a learn by doing guy, said something like this could have helped him back when he was learning SRv6. Same here, obviously.

His numbers for the approach. Around 50 test runs, a working lab every time, though “sometimes it has to do more loops and iterations than others.” He was upfront that the whole thing is non-deterministic and that he had no idea which path the live demo would take. Compare that to his experience one shot prompting an LLM for the same job, which produced mistakes he had to find and debug himself. The loop moves the debugging onto the agent, and the design review moves the fact checking onto the vendor docs. What’s left for the human is the prompt and the judgment about whether the finished lab is teaching you the right things.

The question the room couldn’t answer

The Q&A went straight to the practical stuff. One attendee thought he’d spotted Opus 4.7 on screen. It was 4.6, picked over 4.7 because it ran faster for a live demo, and he’s used both. Asked about smaller models, he was blunt. He’s tried non-thinking Opus and found it “to be honest, not that good.” His floor is “you need a thinking model at least.” He’s also run the workflow with GPT 5.5 and with Cursor’s own Composer model.

Then somebody asked the question I’d been sitting on. How many tokens did that run burn? Deshpande didn’t know, and tried asking the agent on the spot, which got him told to count that query too. The last word from the room as the session wrapped was “if you do get that token answer, you let me know,” and Deshpande admitted he’s concerned about it himself.

I left wanting that number more than any other fact from the session. A thinking model that loops through a design review and debug cycle two or three times is doing a lot of reading and a lot of reasoning, and every pass through those router configs and vendor docs is billable input. For an engineer spinning up a home lab on a personal Cursor subscription, who cares. Deshpande’s day job is different. Scaling hands on labs out to Cisco’s customer base makes the per lab token bill the difference between a neat trick and a program. Nobody in the room had the number.

The deterministic version of half this demo

Watching the agent invent an addressing plan and four router configs from one sentence, I kept thinking about netlab, Ivan Pepelnjak’s lab automation tool. I’ve been spending serious time in it lately, so the shape was instantly familiar… a few lines of YAML naming the devices, links, and protocols, and netlab works out the addressing, writes the configs, and hands you a converged topology on Containerlab. The design and launch phases of Deshpande’s loop, the topology, the addressing, the configs, the boot, are exactly the plumbing netlab automates today, deterministically, with identical output every run and for exactly zero tokens.

So what’s the agent actually buying you? The design review against the vendor docs, the debug loop when convergence fails, and the walkthrough keyed to the running lab… netlab was never going to do any of those. The move I want to try is aiming both tools at the same problem. Hand the agent a netlab skill in place of the raw tooling skill and its lab description shrinks from four full router configs to a handful of YAML lines, which leaves the model far less surface area to hallucinate on. (Yes, I have some netlab posts in the queue…)

Bookends

Earlier in this series I covered Tyler Conrad’s talk on building the back end fabrics that train these models, networking in service of AI. Deshpande’s talk is the flip side, AI building labs for the network engineer. CHI-NOG 13 booked both ends of that relationship.

Deshpande spent real time insisting the workflow transfers. The Cisco pieces are swappable. Point the design review at Nokia’s SR Linux documentation instead of CCO, hand the agent a Containerlab tool skill instead of the XR Compose one, and the same loop builds you an SR Linux lab. Same story for Juniper cRPD against Juniper’s tech library, or any NOS plus any emulator, KNE, GNS3, take your pick. The whole workflow lives in two markdown files, and markdown doesn’t care whose CLI it’s converging. His own claim was that none of the cool factor in the demo comes from the specific Cisco products. I’ve got no reason to doubt it.

I haven’t run any of this myself, so file everything above under “watched it work once, on stage, on the presenter’s VM.” The transferability claim is the one I’d test first, the same workflow rebuilt on Containerlab with a non-Cisco NOS, where the model has less of the vendor’s documentation to lean on. If you get there before I do, I want to hear how it went.

CHI-NOG has the recording up, and the failure loop is worth watching in real time. The slides are posted too.

Disclosure. I attended Taran Deshpande’s session at CHI-NOG 13 in Chicago. CHI-NOG didn’t comp my registration or travel. Deshpande is a Cisco employee and this was a Cisco stack demo, but Cisco didn’t sponsor this post or buy me anything. The opinions here are mine. For more, please read my full disclaimer.