--- title: "The Network Automation Framework: A Common Blueprint Instead of Six Different Guesses" description: Discover the Network Automation Framework, a collaborative approach to building automation solutions, ensuring clarity and efficiency in network management. image: https://agn.tech/hubfs/JPEG%20image.jpeg --- [![AGN-AlchemyGlobalNetworks-LogoOnWhite-June2026](https://agn.tech/hubfs/AGN-AlchemyGlobalNetworks-LogoOnWhite-June2026.png)](https://agn.tech) - [Home](https://agn.tech) - [About](https://agn.tech/about) - [Contract Vehicles](https://agn.tech/contract-vehicles) - [SEWP VI](https://agn.tech/sewp6) - [GSA MAS](https://agn.tech/gsa-mas) - [Careers](https://agn.tech/careers) - [Alchemy Global Foundation](https://agn.tech/alchemy-global-foundation) - [Services](https://agn.tech/services) - [Professional Services](https://agn.tech/professional-services) - [Managed Services](https://agn.tech/managed-services) - [Network Automation](https://agn.tech/networkautomation) - [Alliances](https://agn.tech/alliances) - [Events](https://agn.tech/events) [The Alchemist's Notebook](https://agn.tech/the-alchemists-notebook) [CONTACT US](https://agn.tech/contact-us) # The Network Automation Framework: A Common Blueprint Instead of Six Different Guesses Discover the Network Automation Framework, a collaborative approach to building automation solutions, ensuring clarity and efficiency in network management. [Jeff Doyle](https://agn.tech/the-alchemists-notebook/author/jeff-doyle) Oct 23, 2026 --- Put six experienced network engineers in a room and ask them to design an automation platform from scratch, and you’ll likely get six different starting points, six different vocabularies, and six different opinions about which tool matters most. None of them is wrong, exactly — they’re just each optimizing for the part of the problem they’ve personally been burned by before. That’s the exact situation the Network Automation Forum found itself untangling, and the result of that work is the Network Automation Framework: a free, vendor-neutral map of what an automation solution actually needs to do, built by practitioners rather than handed down by a vendor. It helps to say plainly what the framework is not. It isn’t a reference architecture you’re supposed to copy, and it isn’t a protocol you implement. There’s no required shopping list and no mandated order of operations. What it offers instead is something deceptively simple: a common set of names for the jobs any automation solution has to cover, so that two engineers from two different companies can compare notes without first spending twenty minutes agreeing on terminology. The framework is still young, and it’s being refined in public. The working group behind it — practitioners like Damien Garros, Christian Adell, Claudia de Luna, Dinesh Dutt, and Wim Henderickx, among others — has been presenting updated versions of the model at conferences across NANOG, SwiNOG, ITNOG, and CHI-NOG throughout the past year, each time refining the diagrams and the language based on real feedback from the room. That’s a healthy sign for a framework: It’s being pressure-tested by the same engineers who have to live with it, not handed down once and left to go stale. # Think of it as a construction site, not a piece of software ![](https://reference.networkautomation.forum/Framework/images/naf-automation-framework-v1-dark.png) A useful way to hold the framework in your head is to picture a construction project rather than a piece of software. A construction site has a foundation everything is built on — in our case, that’s the actual routers, switches, firewalls, and cloud fabric doing the real work. Above that foundation sit six distinct jobs, each with a different owner, that together turn a set of blueprints into a finished, functioning building. The Network Automation Framework simply gives those six jobs names: Intent, Observability, Collector, Orchestrator, Executor, and Presentation. ## Intent — the blueprint Every construction project starts with a blueprint: what the building is supposed to be, down to the wiring diagrams and load calculations. Intent plays that role for your network — the single, structured, vendor-neutral record of addressing, topology, policies, services, and secrets that says *what the network is supposed to look like*. It’s written once, in plain terms, and translated later into whatever dialect each device actually speaks. ## Observability — the site diary and the inspector A good foreman keeps a daily site log and calls an inspector out when something doesn’t match the plans. Observability is that log and that inspector combined: a running, queryable record of what the network is actually doing, enriched with context like upcoming maintenance windows or known vulnerabilities, that raises a flag the moment reality drifts away from the blueprint. So while Intent describes what you *want*, Observability describes what you *hav*e. ## Collector — the surveyor Before the inspector can compare anything to the plans, someone has to go out and take measurements. The Collector is that surveyor: it reaches into the network over protocols like SSH, NETCONF, and gNMI, pulls in telemetry from SNMP, syslog, and flow data, and — just as importantly — translates each vendor’s particular way of reporting things into one consistent format that the rest of the framework can actually use. ## Orchestrator — the foreman The foreman never swings a hammer, but nothing gets built without one. The Orchestrator sequences the work — what happens first, what waits for approval, what triggers automatically — and owns the parts of the job that keep a project from becoming a disaster: dry-runs before anything real happens, a clear way to back out of a bad change, and a paper trail of who did what and when. Crucially, the Orchestrator directs the crew; it never touches a device directly. That boundary is what keeps a complicated, multi-step change understandable instead of a black box. ## Executor — the crew Somebody has to actually do the work, and that’s the Executor: the block that logs into devices and makes the real change, whether that’s pushing a configuration or triggering a reboot. Two things matter enormously here. First, the work should be *idempotent* — running the same instruction twice should leave the network in the same correct state, not a worse one. Second, changes should be *reversible* and *testable* before they’re final. The crew builds exactly to the blueprint and the inspector’s findings; nothing about their work should be improvised. ## Presentation — the site office Every construction site has a place where people check in, sign off on decisions, and get updates — a trailer with a whiteboard, a sign-in sheet, a phone line. Presentation is that site office for automation: it might be a dashboard, a chat-based approval flow, a ticketing system, or a simple button in an internal portal. NAF deliberately doesn’t mandate one single interface, because the right one depends entirely on who’s using it — a network engineer needs something very different from a help-desk agent submitting a routine request. Put those six roles together and two natural rhythms appear. There’s a checking rhythm — the Collector takes measurements, Observability compares them to the blueprint and raises a flag on any mismatch — and a building rhythm — Intent states what’s wanted, the Orchestrator sequences the work, the Executor carries it out, and the Collector checks the result. Presentation sits alongside both rhythms so people can watch and steer. That’s the entire framework, and it’s the reason a shared vocabulary turns out to matter so much. # Four ground rules that make it easy to adopt - You don’t need to build all six blocks on day one — plenty of solid solutions start with just one or two. - There’s no required starting point — where you begin depends entirely on the problem in front of you. - Tools and blocks don’t line up one-to-one — a single platform might cover three blocks, and a single block might be split across two tools. - Judge any candidate tool on two dimensions at once: what role it plays, and what real capabilities it brings — version control, testing support, a safe lab to try things in, and genuine audit visibility. # Watching the framework work on a real change Abstractions are easier to trust once you’ve seen them handle something mundane, and the NAF community itself likes to teach the framework this way. One of their own published walkthroughs asks you to picture rolling out a new subnet across 50 branch sites at once — deploying it, confirming it actually works on every single device, and automatically flagging and fixing any site that falls out of line. It sounds simple until you’ve tried to do it by hand across 50 sites and realized that “confirming it works everywhere” is the part that actually takes all week. Run that scenario through the six blocks and the shape of the solution appears on its own: Intent holds the new subnet as a single, structured definition rather than 50 separate configs; the Orchestrator sequences the rollout across sites, in batches, with a plan for what happens if a site fails; the Executor pushes the actual configuration to each device; the Collector immediately reads back the real state from all 50 sites; Observability compares what came back against what Intent asked for and raises an alert on any site that doesn’t match; and Presentation is where someone watches the rollout happen and gets notified if remediation is needed. Nothing about that sequence is exotic — it’s the same read cycle and write cycle running at 50x scale, which is precisely the point: the framework doesn’t change shape just because the job got bigger. The same exercise works on smaller, everyday changes too — decommissioning a single branch router, rotating a credential across a device fleet, opening a new VLAN for one site. Whatever the change, laying its real steps next to the six blocks shows you exactly which block is doing which job, and just as usefully, exactly where you don’t currently have a tool covering a step at all. That gap-finding is arguably the single most practical thing the framework does for a real project. # Let the design come before the code Teams that get the most out of the framework treat design as its own phase, not something that happens implicitly while someone types. A workable sequence is: nail down requirements, do a little research into what’s worked elsewhere, sketch a high-level design, then a detailed one — and only then start building. Along the way, write down why you made each significant decision, not just what you decided; a short note explaining the reasoning behind a choice saves the next engineer from re-litigating it, or worse, reverse-engineering it. Lightweight tools like the C4 model for sketching a system at different zoom levels, or diagram-as-code tools such as Mermaid that keep your diagrams checked into the same repository as everything else, go a long way without turning into bureaucracy. *Treat your automation platform the way you’d treat the network itself: something you design on purpose, not something that accumulates.* *— AGN* # A stack built one block at a time Because you don’t need every block from the start, the practical move is to pick one real use case and see which tools genuinely cover which blocks. A representative stack might use Nautobot as the Intent source of truth, Argo Workflows to handle Orchestration, a lightweight internal portal for Presentation, Terraform and Ansible as the Executor, and InfluxDB with Grafana covering Collector and Observability. The specific brands matter far less than the discipline behind them: every block has an owner, and nothing is left to chance. # Where AGN fits in Choosing tools without a shared map is how teams end up with six different automation efforts that don’t talk to each other. AGN builds every engagement around the Network Automation Framework because it gives both us and our clients an honest, vendor-neutral way to check whether a solution is actually complete — not just whichever platform happened to be pitched hardest. Whether you’re mapping your first use case or trying to make sense of a patchwork of tools you’ve already accumulated, AGN can help you apply the framework to your network and turn it into a plan your team can execute. Learn more on our [Network Automation Page](https://agn.tech/networkautomation) *Alchemy Global Networks — Vendor-neutral network automation, done by design.* ## Similar posts ### Subscribe to The Alchemist's Notebook Get The Alchemist's Notebook delivered straight to your inbox: the Alchemists' latest thinking on cybersecurity and network engineering for Federal, State and Local, Education, and Enterprise organizations. [![AGN-AlchemyGlobalNetworks](https://agn.tech/hubfs/AGN-AlchemyGlobalNetworks-Logos.svg)](https://agn.tech) AGN | Alchemy Global Networks *The Gold Standard of Cybersecurity and Network Engineering* ### Resources - [The Alchemist's Notebook (Our Blog)](https://agn.tech/the-alchemists-notebook) - [SEWP VI Contract Vehicle](https://agn.tech/sewp6) ### Services - [Professional Services](https://agn.tech/professional-services) - [Managed Services](https://agn.tech/managed-services) - [Contract Vehicles](https://agn.tech/contract-vehicles) ### Company - [About](https://agn.tech/about) - [Alchemy Global Foundation](https://agn.tech/alchemy-global-foundation) - [Careers](https://agn.tech/careers) © 2026 AGN | Alchemy Global Networks. All rights reserved. [Powered by Atlas - a B2B SaaS HubSpot theme](https://www.kalungi.com/atlas-hubspot-theme-for-b2b-saas-software) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Jeff Doyle", "url" : "https://agn.tech/the-alchemists-notebook/author/jeff-doyle" }, "dateModified" : "2026-10-23T20:00:00.306Z", "datePublished" : "2026-10-23T20:00:00.000Z", "headline" : "The Network Automation Framework: A Common Blueprint Instead of Six Different Guesses", "image" : [ "https://agn.tech/hubfs/JPEG%20image.jpeg" ], "mainEntityOfPage" : { "@id" : "https://agn.tech/the-alchemists-notebook/the-network-automation-framework-a-common-blueprint-instead-of-six-different-guesses", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://agn.tech/hubfs/AGN-AlchemyGlobalNetworks-Logos.svg" }, "name" : "AGN | Alchemy Global Networks LLC" } } ```