AI agents that keep an infrastructure record current
The oldest CMDB problem — records that drift from reality — solved by making the update part of the work instead of a separate chore.
- Problem
- A configuration record goes stale the moment people stop updating it. Agents doing real work make that worse, unless updating the record is a side effect of the work itself.
- My role
- Designed and built the whole system, on a four-server estate I own and run.
- Key decisions
- The record updates when work closes, not on a schedule; a different agent does the update than the one that did the work; every agent works from one versioned rulebook; deterministic automation first, a model only on the exceptions.
- Outcome
- When a task closes, the configuration record updates on its own, for about twelve cents in model spend.
How the work flows
Work lives on a task board. An agent claims a task, does it under written rules, and reports back. When the task closes, a second agent reads what changed and updates the configuration record for the affected systems. Nobody has to remember to do it, which is exactly why it gets done.
The rules every agent works under
- One source for the rules. The rulebook lives in a git repository and is served to every agent that connects. Nothing cached overrides it.
- Acknowledge before acting. An agent that hasn't confirmed the current revision can't claim work.
- Situational awareness first. Every agent session opens by stating which host it's on, which rules apply, and which revision it's working to.
- Separation of duty. The agent that scopes a change never makes it, and a third agent records it. A person approves the work before it starts.
Rules first, model second
A workflow engine handles anything deterministic, and a model is called only on the exceptions. When a mail-to-task pipeline filed 24 junk items on its first day, the fix was sender-age, bulk-header and role-word rules — not a bigger model. Text from outside is fenced before any unattended agent reads it.
What this has to do with a ServiceNow CMDB
The record here is a lightweight configuration record kept in version control, not ServiceNow — the point is the discipline, not the product. Every CMDB program fights drift between the record and reality. Tying the update to the close of the work is the same principle I'd apply to a ServiceNow CMDB that AI agents depend on: if agents are changing your estate, agents should be keeping the record honest, under governance.