Automation Series

jdoyle@agn.tech (Jeff Doyle) — Tue, 22 Sep 2026 20:34:11 GMT

Most network teams don’t lack the will to automate. They lack a map. A script here to push a config, a scheduled job there to grab a backup, and before long every automation effort is a one-off, understood only by the person who wrote it. That person automated a few of his or her own mundane tasks, but there’s no widespread organizational benefit. As ambitions grow from automating a task to automating a whole workflow — or even watching, deciding, and correcting the network itself — that ad-hoc approach stops scaling. What separates automation that lasts from automation that quietly becomes tomorrow’s liability usually isn’t the tool a team picks first. It’s whether they started with an organized framework that defines the various functions of an automation solution and how those functions interact. A well-defined automation framework not only helps you think clearly about how an automation solution should work, but also helps you select or design the tools that best fit your needs.

That’s not a small distinction. Teams that skip the framework tend to rebuild the same building blocks project after project, discover best practices the hard way, through outages, drift, and rewrites, and end up with knowledge trapped in one engineer’s head instead of a design anyone can pick up. An organized framework is what turns “we automated something” into “we built something we can trust, understand, and safely evolve.”

Enter the Network Automation Framework

That’s exactly the gap the Network Automation Framework was built to close. Created by practitioners through the Network Automation Forum (NAF), the framework is a community-built, vendor-neutral reference model: Full credit to the Forum for developing it and continuing to refine it in the open. It’s worth being clear about what Network Automation Framework is and isn’t: it’s not a reference architecture, and it’s not a protocol. There’s no prescribed product list and no mandatory sequence of steps. Instead, it offers a shared vocabulary and a clear division of responsibilities: six functional building blocks, sitting above the network infrastructure, that describe what an automation solution needs to do, independent of how you choose to do it: Collector, Observability, Intent, Orchestrator, Executor, and Presentation.

The Forum didn’t arrive at this by theorizing. When its working group first sat down to compare notes, everyone was biased by their own tools and habits, and the conversation went in circles. The missing piece wasn’t a tool, it was a shared lexicon. Once the group started talking about functional blocks instead of products, everyone suddenly spoke the same language. That’s the quiet power a good framework brings: It gives an entire team, and every vendor or partner they work with, one map to navigate by.

What an organized framework does for design and deployment

A framework only earns its keep when it changes how you build. In practice, the Network Automation Framework helps at nearly every stage of a real deployment:

Surfaces gaps early. A handful of framework-aligned questions — how will I document intent, trigger the workflow, determine state, manage the running workflow, collect data, and execute changes — quickly reveal which parts of a solution are missing, weak, or overloaded, before you’ve committed budget to the wrong one.
Maps cleanly onto real workflows. Lay an everyday change — like updating an ACL across campus switches — next to the framework’s blocks, and you can see exactly which tool is doing which job at each step, and where the gaps sit.
Keeps responsibilities separate and safe. The Orchestrator coordinates a workflow; the Executor is the only block that actually touches devices. That separation is what keeps complex, multi-step automation understandable instead of a black box.
Puts design and documentation first. Requirements, research, high-level design, low-level design, with decisions captured along the way, so the reasoning behind an automation solution survives staff turnover instead of leaving with whoever built it.
Works with any build approach. Whether a team goes pro-code, low-code, no-code, or leans on AI, the framework describes the functions that need covering, not how you deliver them, so it doesn’t lock you into one path.
Scales down as easily as up. You don’t need every block on day one; many good solutions start with just one or two, in whatever order the problem calls for.

Automation platforms are ecosystems — design them like networks.

— Christian Drefke, “Plan First,” AutoCon 5

The common thread is discipline. Automation platforms behave like ecosystems, not scripts, and the teams that treat them that way — planned, documented, and built on a solid architecture — are the ones whose automation still works, and is still understood, long after the first project wraps.

Where AGN fits in

Alchemy Global Networks fully supports the Network Automation Framework and builds every engagement around it. We’re vendor- and product-agnostic by design, so the framework gives both us and our clients an objective way to judge whether a solution is complete and to design against proven building blocks rather than guesswork.

Whether you’re looking to automate a handful of routine, well-understood tasks or move toward fully automating your network operations, AGN can help you every step of the way, assessing where you stand, designing the solution, and carrying it through to a deployment your team can own.

For a deeper look at AGN’s Network Automation Services, visit our website [embed link to the automation servies page when up]. And for more information specifically about using the NAF’s Network Automation Framework, see our whitepaper, “A Framework and Methodology for Network Automation,” available at [link not available yet].

Field Note #1

An Alchemist — Fri, 04 Sep 2026 20:23:48 GMT

Hello from the Frontier of Cyber...

Every industry has its shorthand for the people who do the unglamorous, technical work that keeps everything else running. In cybersecurity and network engineering, that work rarely makes headlines, but it is the difference between an organization that operates with confidence and one that is one incident away from a very bad week. At AGN, we call the people who do that work Alchemists, and this is their notebook.

Who We Are

AGN, Alchemy Global Networks, is a cybersecurity and network engineering firm built around a simple premise: complex problems deserve precise solutions, not generic ones. We work across Federal, State and Local, Education, Healthcare, and Enterprise environments, which means our team spends its days moving between very different sets of requirements: compliance frameworks, procurement cycles, legacy infrastructure, modern threat models, and the everyday reality of keeping networks secure and operational under real budget and staffing constraints.

We call our work the Gold Standard of Cybersecurity and Network Engineering, not as a slogan but as a working standard. It means we hold our proposals, deployments, and partner relationships to the same bar we would apply to our own networks. We are certified partners with many of the leaders of our industry, and we treat those partnerships as extensions of our own team's capability, not just logos on a slide.

Who the Alchemists Are

Alchemy, historically, was the discipline of transformation: taking raw material and turning it into something more valuable through a careful, repeatable process. That is a fair description of what our team does every day. Raw requirements become secure architectures. Disconnected point solutions become integrated network defenses. Vague compliance mandates become concrete, auditable outcomes. The Alchemists are the engineers, architects, and strategists at AGN who do that transformation work, and this is their notebook.

What This Blog Is For

The Alchemist's Notebook exists to share what we are actually seeing and learning, not to publish marketing copy dressed up as insight. Expect Field Notes on the technical realities of securing Federal, SLED, Healthcare, and Enterprise networks: how procurement and technology decisions intersect, what we are learning from deployments with our partners, where common network engineering assumptions break down in practice, and how the threat landscape is actually changing for the organizations we serve, as opposed to how it is described in vendor decks.

This is meant to be a working notebook, not a highlight reel. Some Field Notes will be technical deep dives. Others will be shorter observations from the field. All of them will be written by people who did the work, not by someone summarizing it secondhand.

What Comes Next

This is Field Note #1, and it is intentionally an introduction rather than a deep technical entry. Starting with Field Note #2, we will get into specifics: the problems our team is solving, the lessons learned from live engagements, and the shifts we are tracking across Federal, SLED, Healthcare, and Enterprise cybersecurity and network engineering.

If that is useful to you, subscribe to The Alchemist's Notebook. We intend to earn a place in your inbox, one Field Note at a time.