# Your automation has an expiry date: how playbooks go stale as the fleet changes (Problem Scope 4/5) > Why automation written for last year's hardware skips or misapplies fixes on today's fleet, and how to build each remediation plan from the node's actual state. - URL: https://blog.asama.ai/blog/issue-04-asama-your-automation-has-an-expiry-date/ - Author: Manish Gautam - Published: 2025-11-20 - Tags: Fleet problems An automation script expires when the fleet it was written for changes under it. A playbook or runbook encodes the hardware models, firmware versions and kernel state its author knew; after a new procurement batch or a firmware release, the same script can skip the fix or apply the wrong procedure, and still report success. The fix is to build each remediation plan at execution time, from the node's actual state. There is a particular kind of infrastructure failure that is worse than a script that breaks. It is a script that runs successfully and produces the wrong result. Every automation script is a snapshot of the world at the moment it was written. It encodes assumptions about firmware versions, kernel state, package availability, hardware configuration. [When the environment drifts](https://blog.asama.ai/blog/issue-02-asama-config-drift-is-the-silent-killer), and it always drifts, the script either breaks visibly, which is recoverable, or silently applies changes to a state it was not designed for, which is not. > Your automation estate is not a solved problem. It is a liability that grows with every new SKU, every firmware update, every kernel version bump. ## The half-life problem >### Written > >Script encodes assumptions about current fleet state: firmware versions, OS packages, hardware config. >### Deployed > >Works correctly on the fleet as it exists at write time. >### Fleet evolves > >New SKUs, firmware updates, kernel bumps, new procurement batches. >### Script ages > >Silent failures on nodes where state has drifted; visible failures on incompatible hardware. >### Maintenance overhead > >Senior engineers maintain scripts instead of building new capabilities. ## How a playbook goes stale without failing Ansible already looks before it acts. By default it gathers facts at the start of every play, including the BIOS version, product name and kernel, and a `when` condition can branch on them. The trouble is that every branch was written for the fleet its author knew. Take a playbook that updates NIC firmware on hosts whose `ansible_facts['product_name']` matches last year's server model. The next procurement batch ships under a new model name. On those hosts the condition is false, so Ansible skips the task, the run finishes without a single failure, and the new batch keeps the firmware build the update was meant to replace. Nothing broke. The fix never reached the hosts that needed it. You can make the playbook fail closed, with an `assert` that the product name is one it knows, and the skip becomes a red run. Someone still has to write the procedure for the new model before the fix reaches it. A dry run won't catch it either. In check mode the facts are the same, so the same hosts skip the same task and the run is just as green. And check mode is only a simulation: modules that don't support it report nothing, and tasks whose conditions depend on the results of earlier tasks produce no output. ## What adaptive automation looks like The alternative to static automation is not more static automation. It is automation that understands the current state of the environment it is operating in before it acts, and generates [a remediation plan](https://blog.asama.ai/blog/article-03-asama-what-happens-when-the-loop-ends) for the specific incident, the specific nodes, the specific firmware versions present at the moment of execution. The difference is not more facts or more branches; it is when the procedure is written. A playbook decides at run time, but only among the branches its author wrote for the fleet they knew. Instead of encoding assumptions at write time and hoping they remain valid, adaptive automation encodes intent and determines the correct actions at execution time based on actual fleet state. A plan built that way works through the steps an experienced engineer would: 1. **Read the node as it is.** Model, components, [firmware and BIOS versions](https://blog.asama.ai/blog/article-02-asama-where-the-loop-always-starts), kernel and drivers, taken from the node at the moment of the fix rather than from an inventory that was right at install time. 2. **Choose the procedure for that state.** The vendor's procedure for this component at this firmware level, including any intermediate version the update path requires. 3. **Check the preconditions, then drain.** Its peers can absorb the load, the change window is open, and no more nodes are out at once than the service can tolerate; only then is the node drained. 4. **Define the way back first.** Capture the current state, confirm the previous version can be reinstalled, and set the conditions that trigger a rollback before the first step runs. 5. **Roll out in waves.** One canary node, then batches, stopping at the first unexpected result. 6. **Verify against intent.** The version the node reports after any reboot the update needs, link speed and width, error counters and the workload's own health checks, all before the node goes back into service. 7. **Record what changed and why.** The next plan then starts from known state rather than [from memory](https://blog.asama.ai/blog/issue-03-asama-the-tribal-knowledge-tax). >### From Asama > >Asama's agentic remediation workflows are designed to generate execution plans at the moment of the incident, using actual fleet state as the context, so that the remediation adapts as your fleet changes. ## Food for thought How many of your current automation scripts were written for hardware configurations that no longer exist in your fleet? Start with the skips: in your last fleet-wide run, which hosts skipped the tasks that mattered? **Update, October 2026.** Asama's fleet observations put about 18 percent of manual fixes at the wrong procedure for the node's actual hardware state; usually the procedure was right when someone wrote it, and the box changed under it. Asama's fleet visibility is generally available, and detection built on it has been validated; investigation and remediation are expanding. Remediation plans are made in Asama's SaaS, which never touches your infrastructure, and run on your premises by an executor that accepts only signed, in-scope manifests. BMC credentials stay in your own Vault. On day one, your engineers approve every plan. To see your fleet's actual state, node by node, book a live comparison against your stack at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai.