Agentic AI for networking: choosing the tool
Agentic AI for networking: a large tool catalog makes choosing the tool the cost. The same change then ran about fourteen times faster.
This is a note on agentic AI for networking. I watched an agent work this week. The change itself was small. What came before it was long: open a file, read a description, check again whether the tool is even offered. The agent spent that time searching.
What I am trying to solve
The job is ordinary network work, done by an agent. Create a service on two routers. Read it back. Remove it. Confirm it is gone.
The agent writes through a controller. In the lab that controller is Cisco Network Services Orchestrator. The controller already has the routers in its inventory. The agent reaches it through Model Context Protocol tools: who am I, is the service there, create it, delete it, show the result on the device.
The same shape fits another Internet Protocol controller. The agent should not care which product sits underneath, as long as each tool does one clear thing and the result can be checked.
What I am trying to get right is the gap between that clear tool and an agent that still has to find it. The network change is small. The catalog of tools in front of it is large. If every request starts from the catalog, the budget goes into the search.
When the tool list becomes the bill
A handful of tools you read and pick. At a few dozen the model still copes, with the odd wrong turn. Once the Model Context Protocol surface grows into a massive catalog, selection itself is the work.
Which tool creates a service. Which one only reads it. Which one belongs to a routing question, which one to a check that the service is still there, which one to a fault that has nothing to do with the change. Use cases do not share one tool. Create, remove, and check are different calls.
If every step carries the whole catalog, you pay for the choice before anything on the router changes. A wrong tool, a second try, a longer prompt. The cost then follows the size of the list, not the size of the change. At massive scale, choosing the tool is the cost factor, and the network work comes after it.
The catalog is not the work
A tool catalog is useful when you are building something new. It is a poor place to start when the task looks like one that has already been done. The agent reads names, guesses arguments, corrects itself, and calls that progress. Most of the time sits in the search. The small rest is the action.
A person who has fixed the same fault before starts from the last time it worked, and then checks whether the world is still the same.
What I mean by the innovation
The next similar task should begin where the last one ended: on a path that already produced a result. The model should still check that the device, the interface, and the catalog still match. It should not be paid to discover the tool again.
A stored path is not permission to replay it blindly. Tuesday can be right and Friday wrong, because an interface changed or the tool is no longer offered. The check stays. The search does not have to.
What the clock said afterwards
The same change, twice. Once to create it, once to remove it.
The first time, an agent started from the catalog.
- Create: 7 minutes 6 seconds, 58 tool calls.
- Remove: 5 minutes 22 seconds, 42 tool calls.
A language model sat in every one of those steps. I do not have a token bill for that run. I will not invent one.
The second time, the path was already known.
- Create: 30 seconds, 7 calls.
- Remove: 26 seconds, 7 calls.
That run did not call a language model. Its model cost was zero.
On the clock that is about fourteen times and about twelve times. One order of magnitude. Several orders of magnitude would be a hundred times or a thousand times, and I did not measure that. What I did measure is enough: the action was already short, and the search in front of it nearly disappeared. On top of that, the model bill on the second path was zero.
How you can see it
On a slow run, count how many calls are search and how many are the action. If the action is short and the search is long, the lever is experience, not a larger model.
Then it is worth not starting the next task from zero.