Runbooks have a lifespan. When they are written, they capture the knowledge of the person who wrote them, in the context of the network that existed at the time. Six months later, the network has changed, the person who wrote the runbook has moved on, and the runbook is subtly wrong in ways that no one has noticed yet because it has not been needed. Then an incident occurs and the engineer following the runbook spends 40 minutes trying to reconcile the documented procedure with the reality in front of them before abandoning the runbook and working from memory.
This is not mainly a discipline problem. It is what happens when static documents describe changing environments. Runbooks decay even under careful review because no team can continuously synchronize every procedure with every network change.
Sources of Runbook Drift
Runbook decay takes several forms, not all of them visible.
The clearest form is stale detail: a command names a removed device or interface, a readdressing project changed the interface name, or a test IP was reassigned by another team. At step 3, the engineer encounters an error and must debug the runbook before debugging the incident.
Topology drift is less obvious. A runbook for a failed BGP peer may assume a standby path remains available. If that path was removed during a capacity reduction and the procedure stayed unchanged, failover can fail silently. The commands may be valid, but the topology they depend on is gone.
The hardest form is procedural obsolescence. A procedure may fit the original network yet fail after an operating system update changes command behavior, a vendor defect appears and is fixed, or a parameter's default changes. The author remembers the old behavior. An engineer using the runbook years later may not know it changed.
The Cost of Drift Has Grown
When engineers perform every repair manually, teams can contain runbook decay through review schedules, post-incident edits, and knowledge transfer during onboarding. These practices do not stop decay, but they keep it manageable.
As repair becomes automated, accuracy matters in a sharper way. An agent can follow a stale procedure quickly and confidently, without the human hesitation that might catch a bad assumption. Human execution is checked by experience and skepticism. Automated execution is limited by the quality of its procedure and inputs.
The maintenance burden does not disappear; it shifts from synchronizing documents with the network to keeping action parameters current. That is a narrower problem, pointing toward automation that reads device state first.
A Different Repair Architecture
The key difference between a static runbook and agent-driven repair is architectural, not merely technological. It concerns the information available to the repair logic.
A static runbook uses information captured when it was written. It may say, "if BGP peer X is down, execute these commands," with a peer address, interface, and next-hop that were once correct. It does not verify that they remain correct at execution time.
An agent-driven process checks current device state before choosing an action. It reads the routing table for the affected prefix, verifies the active BGP peer address, and checks interface status at both ends before deciding whether to bounce the link. Actions use what the device currently reports, not what an old document says it should report.
This helps with each form of decay above. If the peer address changed, the agent retrieves the current value. If a standby path disappeared, topology checks can detect that before an ineffective failover runs.
Where Agent Repair Stops
Agent-driven repair has limits. Current device state alone may not provide enough context for a correct decision.
One limit is a novel failure mode. If the action library has no response for it, the agent cannot repair it autonomously. It should report the gap and escalate rather than guess. Confidence scoring before execution helps prevent that mistake.
Another limit is a multi-device failure. When several devices degrade together and their causal relationship is unclear, the agent may repair a symptom instead of the underlying fault. Topology-aware correlation helps, but it is imperfect. Some incidents still require human pattern recognition.
A third limit is action coverage. Agent-driven repair still depends on defined actions. If the right response is absent from the action set, the agent cannot perform it. Those actions use current state rather than old documentation, but the set still requires maintenance.
Moving Beyond Documented Procedures
Teams moving from manual runbooks to agent-driven automation do not need to discard existing material. Runbooks preserve institutional knowledge, including the team's imperfect record of how common faults are repaired.
The practical step is to convert that procedural logic into actions that query device state at execution time. Durable automation does not hard-code today's addresses and interface names. It checks the network as it is and adapts its parameters.
For the PhysicalLayer agent, each repair action reads device state first. The action for a BGP soft reset does not contain a fixed peer address. It queries the device's BGP summary, identifies the affected peer as configured now, and acts on that result. An interface bounce first confirms that the interface exists and has the expected operational state. These small choices keep agent-driven repair from inheriting the decay built into static runbooks.