Template architecture
Jinja2 structured so a vendor addition is a new template, not a rewrite. Configuration derives from source-of-truth data, never from hand-editing.
Foundation layer
Config pipelines that deploy intent and leave a trail worth reading
Templated, tested, version-controlled change — and a change record precise enough that the agent can tie a 2 a.m. fault back to the commit that caused it.
Most serious network incidents are change-induced. That is not an argument for changing less; it is an argument for changing in a way that is reviewable, reversible and machine-readable.
A config pipeline does three jobs at once. It renders intended state into vendor configuration, it validates that configuration before it touches anything, and it records exactly what changed, where, and when.
That third job is the one teams skip, and it is the one the agent depends on. A change log with diffs, timestamps and device scope turns 'something broke' into 'change #8842 touched four devices on this path six minutes ago'.
Deliverables
What we build
01
02
Execution layer
Ansible for declarative, agentless change; Nornir where you need Python control and parallelism; NAPALM and Netmiko underneath for multi-vendor reach.
03
Infrastructure as code
Terraform for cloud networking, DDI and network services, so the boundary between on-prem and cloud stops being a manual handoff.
04
Pre-deployment validation
Batfish and policy checks that catch reachability breaks, ACL mistakes and route leaks in the pipeline instead of in production.
05
CI/CD and review
GitLab CI or GitHub Actions with peer review, dry runs, staged rollout and a rollback path that has been tested rather than assumed.
06
Change telemetry
Every deploy emits a structured event — what, where, by whom, with the diff — to the store the agent queries during an incident.
Agent
What the agent does with this layer
Change correlation is the agent's fastest route to a root cause, and it only works if the pipeline tells the truth.
Change correlation
Tying faults to commits
When a signal goes bad, the agent asks what changed on that path recently. With a structured change log the answer takes milliseconds.
Diff reading
Understanding what actually changed
The agent reads the rendered diff, not just the commit message, so it can spot the dropped MTU line rather than trusting a summary.
Fix proposal
Writing the change back into the pipeline
A proposed fix arrives as a pipeline change with a rollback plan, reviewed the same way any other change is. No out-of-band console sessions.
Stack
Tools we use here
Ansibleagentless configNornirparallel PythonTerraformIaCJinja2templatingNAPALM / Netmikodevice driversBatfishpre-deploy checksGitLab CI / GitHub ActionspipelinespyATStest framework
Questions
Questions about config automation & ci/cd
Do you replace our existing playbooks?
Rarely. Working playbooks represent real institutional knowledge. We usually restructure how they get their data and how they are invoked — pulling variables from the source of truth and running them through a reviewed pipeline — rather than rewriting the logic inside them.
How do you handle a multi-vendor estate?
Through an abstraction layer. Intent lives in vendor-neutral data in the source of truth, templates render it per platform, and NAPALM or Netmiko handles the device-level differences. Adding a vendor becomes a template and driver exercise rather than a new automation programme.
What stops the agent pushing a bad configuration?
Several things, deliberately layered. The agent proposes into the same pipeline your engineers use, so its change gets the same validation and review. Approval gates are on by default. Blast-radius policies cap what a single action may touch. And every step is logged for audit.
Can this work in a change-controlled enterprise with CAB approval?
Yes, and it usually improves the process. A pipeline produces exactly what a change advisory board wants — a precise diff, a tested rollback and a validation report — which tends to shorten approval cycles rather than conflict with them.
Book a 30-minute automation readiness consultation
In 30 minutes, we’ll evaluate your infrastructure maturity, identify operational risk areas, and highlight high-impact automation opportunities.
No scripts. No invasive discovery. Just clarity.