# Wiring an agent to the lab

How the field test was actually plumbed, and how to build the read-only
posture the prompt assumes. Nothing here is specific to our lab; the same shape
works against anything you can reach from a CLI.

## What you need

- Cisco Modeling Labs 2.7 or later, with the `iol-xe` image. CML Free tier
  runs this topology comfortably; it is four nodes and about 4 GB of RAM.
- An agent that can run shell or API calls. The run in the article used Claude
  Code with an MCP server in front of the CML API.
- No paid tooling beyond CML itself.

If you do not have CML, the same three faults reproduce in EVE-NG, GNS3, or on
physical gear. Only the plumbing in step 2 changes.

## 1. Import the lab

In CML: **Labs -> Import**, choose `ospf-break-fix.yaml`, then start it. The
startup configs ride along in the topology file, so the routers boot with OSPF
already converged. Give it two or three minutes, then check any router:

```
R1# show ip ospf neighbor
```

Two neighbors, both FULL. Do that on all four before you break anything, so you
know your starting point is real and not assumed.

Credentials are `cisco` / `cisco`, enable `cisco`.

## 2. Give the agent a way in

Three options, cheapest first.

**Option A: hand it the console.** Run the show commands yourself and paste the
output into the conversation. This sounds primitive and it is, but it is the
honest baseline: it tests the reasoning and nothing else. If an agent cannot
diagnose from pasted output, no amount of tool wiring will save it.

**Option B: SSH from a shell tool.** If your agent can run shell commands, give
it SSH access to the routers through the CML terminal server. Read-only is
enforced by you reviewing each command before it runs, which most agent CLIs
support natively.

**Option C: the CML API through an MCP server.** What the field test used. CML
exposes a REST API, and an MCP server in front of it lets the agent call
`send_cli_command` against a node by label. Search for a CML MCP server, or
write a thin one; the API surface you need is small: list labs, list nodes,
send a command.

Whichever you pick, the important part is step 3.

## 3. Enforce read-only, do not request it

The prompt tells the agent to stay in show commands during diagnosis. That
instruction is worth having and it is not a control. Instructions are requests.
A control is something that makes the write impossible.

In rough order of how much they are worth:

1. **A read-only device account.** On IOS, a privilege level 1 user with no
   enable secret can run most show commands and cannot configure anything. Give
   the agent that account for phase 1 and hold the privileged one yourself.
   This is the only option on this list that an agent cannot talk its way past.
2. **Tool-level allowlisting.** If your agent framework can restrict which
   tools run without approval, allow the read path and require approval on the
   write path. In Claude Code this is the permissions system; other frameworks
   have equivalents.
3. **A human in the loop on every config command.** Weakest of the three,
   because it depends on you reading carefully at 2 a.m., which is exactly when
   you will not.

Use 1 and 2 together. The prompt's approval pause is then a convenience rather
than the only thing standing between the model and your routers.

## 4. Save the transcript before you form an opinion

Turn on logging before the run, not after. The transcript is the only durable
artifact, and the interesting parts are usually the moments you were not
watching: the command it ran that you would not have, or the confident wrong
turn it corrected two steps later.

Save it even when the run goes badly. Especially then.

## 5. Run it

Apply a break from `breaks.md`, wait for the dead timer, paste the prompt from
`agent-prompt.md`, and score the result with the table at the bottom of that
file.

Then do the honest version: apply two breaks at once and run it again.