En bref. Avant de corriger une panne, un ingénieur passe du temps à reconstituer le contexte : schémas, plans d'adressage, configurations. Un agent peut le faire à sa place, à trois conditions : il lit votre vraie documentation, il ne peut rien modifier, et une personne approuve et applique chaque changement. Commencez par un pilote de quatre semaines et mesurez les heures gagnées.
The situation
- An error comes in.
- Before fixing anything, an engineer rebuilds the context: which devices are on the path, which IP plan applies, what the flow matrix allows, how each device is configured.
- All of it exists, spread across diagrams, spreadsheets and a configuration repository.
- Gathering it is the slow part, and it is repeated for every incident.
Why most first agents stall
- They ask for write access "to be useful", and security says no.
- They answer from general knowledge instead of your network, so engineers stop trusting them.
- Nobody measured the time before, so nobody can show the time saved.
What to build first
1. Read-only, by design
- Give the agent read access to configurations through an MCP server you control.
- Build no write path to the equipment at all. The fix is proposed, never applied by the agent.
- This is what turns the security conversation from "no" into "how do we log it".
2. Grounded in your documentation
Let the agent retrieve from:
- network diagrams
- IP plans
- the flow matrix
- later: past incidents and runbooks
3. Where engineers already work
- Put the agent inside a tool your engineers already use: an AI-enabled editor like Windsurf, or Microsoft 365 Copilot.
- Skip the orchestration framework for a pilot. An existing agent plus your MCP servers is enough, and it is what makes four weeks realistic.
4. Let it write the ticket, not the change
Through your tracker's MCP server (Atlassian publishes an official one), the agent drafts the story:
- summary
- root cause
- affected devices
- proposed fix
- priority
A person approves the story, approves the change, and applies it.
5. Defer what a pilot does not need, on purpose
Write down what version 2 must add before anything goes to production:
- logging of every agent action
- service identities instead of personal credentials
- reading live configurations from the equipment, not a copy that can drift
Measure it
- Before the pilot: hours per engineer per month spent gathering context. An honest estimate is fine.
- During the pilot: the same number, with the agent.
- Then: multiply the difference by your hourly cost. That is the business case for version 2.
In one pilot, 15 engineers each saved about 4 hours a month: 60 hours across the team, roughly CA$9,000 a month at CA$150 an hour.
How we did it
We built this as a four-week pilot for the network team of a telecommunications operator running Cisco and Juniper equipment.
Want help putting this into practice?
We work alongside your team to design, build, and operate the controls described above.