Skip to content

Agentic AI Orchestration Workflows

This work was presented at the 6th SIG-AI for NRENs Meeting in Madrid, Spain (March 2026), as part of GÉANT's exploration of AI-assisted network automation within the NRENs community.

Network operations teams deal with a constant stream of low-level but high-risk configuration tasks. Adding or removing a tagged VLAN on an interface sounds trivial, but it requires looking up the right IDs in the inventory, validating pre-conditions, applying the change via API, and verifying the result — all while keeping a human in the loop before anything is actually written to the network.

This work explores whether that full cycle can be reliably automated using n8n as the workflow engine, NetBox as the single source of truth, and AI agents as the natural-language interface and reasoning layer. Rather than committing to a single design, three distinct implementations were built for the same task, each reflecting a different philosophy about where intelligence should live in the pipeline.

Why Guarded Agentic AI?

Current AI-assisted tools tend to fall into one of two patterns: fully manual ChatOps, where an operator provides intent and an LLM suggests what to type, or fully autonomous pipelines, where the AI makes changes without human review. Neither is satisfactory for production network operations.

The approach explored here sits deliberately between the two. AI agents handle the parts of the workflow where natural-language understanding is genuinely valuable — parsing intent, reasoning about inventory, explaining a proposed change. Deterministic code handles everything that must not vary.

This is what makes it guarded agentic AI — not just agentic AI. Crucially, the guarded philosophy is not limited to the moment before a write operation. It is applied at every stage of the pipeline:

Layer When What it does
🔄 Normalise After every agent A deterministic code node canonicalises the agent's output into a known structure before anything downstream reads it
✅ Validate After every agent A structured output parser or code node checks the output against a declared contract; errors surface immediately
🚦 Guard Before every action Dedicated nodes evaluate whether the requested action is valid given the current network state
🔍 Verify After every write The result of every change is independently re-queried from NetBox; the workflow rolls back automatically if verification fails

Each of these layers catches a different class of failure. Together they form a defence-in-depth pipeline where no single failure mode — a misbehaving LLM, a malformed API response, a stale assumption, or a wrong intermediate value — can silently produce a wrong result.

⚠️ Important: LLM-based workflows are not deterministic. Under identical conditions with the same input, an agent may produce slightly different output on different runs. It may decide to ignore a prompt rule, invent a value it was told not to invent, or format its response differently than it did the previous time. The guarded architecture does not eliminate this probabilistic behaviour — it ensures that when it happens, the workflow fails visibly and safely rather than proceeding to write something wrong to the network.

Why This Is Not "Just ChatOps"

A ChatOps interface lets an operator type a command into a chat window and get a response. It is a convenience layer on top of manual work. The agentic approach here is different in several important ways:

  • the agent reasons across multiple steps — it queries NetBox, interprets the results, evaluates guards, and builds a complete proposed change before asking the operator anything
  • the approval step is structured — the agent presents a formatted change table with before/after state, not a free-text suggestion
  • the workflow continues after approval — it applies the change, verifies it independently, and rolls back automatically if verification fails
  • the agent remembers context across turns where needed — in the orchestrator implementation the approval token pattern means the agent knows exactly what it proposed, without the operator having to repeat anything

The operator's role shifts from executing changes to reviewing and approving them.

The Three Approaches

🔧 No Agents 🛡️ Multi-Agent Guarded 🤖 Single Orchestrator
Trigger Webhook (REST API) Chat UI Chat UI
Guards Deterministic IF nodes Deterministic code nodes Prompt rules only
Supports Add only Add + Remove Add + Remove
Node count ~20 ~40+ 8
Stability Highest High Model-dependent
Best fit Structured API-driven callers Chat plus operational rigour Chat plus rapid iteration

All three workflows do the same thing. The differences lie in where decisions are made, how failures are caught, and how much the user needs to know about the underlying system.

  • Implementation 1 — No Agents: use when the caller is another system and the input is already structured.
  • Implementation 2 — Multi-Agent Guarded: use when the interface is conversational but infrastructure writes must remain auditable and failure-safe.
  • Implementation 3 — Single Orchestrator: use for rapid experimentation and demos, where simplicity of the canvas matters more than deterministic visibility.

Agentic Contracts

A key design principle in the multi-agent implementation is the use of agentic contracts — structured JSON schemas that define the exact interface between agents and between agents and deterministic nodes. Rather than letting agents produce free-form text that downstream nodes must parse loosely, each agent is required to output a document that matches a declared schema.

The plan contract produced by the Planner agent is a representative example:

{
  "type": "plan",
  "version": "1.0",
  "request_id": "req-20260303-0007",
  "ok": true,
  "errors": [],
  "action": "add_tagged_vlan",
  "params": {
    "device": "rtr-lab-02",
    "interface": "ge-0/0/0",
    "vlan_vid": 40
  },
  "lookups": [],
  "guards": [],
  "approval_required": true,
  "explanation": "Plan to add VLAN 40 as a tagged VLAN on rtr-lab-02 interface ge-0/0/0."
}

If the agent's output does not match the schema, a structured output parser retries with a correction prompt before the workflow continues. This makes schema violations explicit and recoverable rather than silent. In practice, however, the structured output parser should still be treated as a first pass rather than the final guarantee; deterministic normalisation and validation remain necessary afterwards.

Design Requirements

Every implementation was built around five non-negotiable constraints:

  1. NetBox is the source of truth — all IDs, interface modes, and VLAN assignments come from NetBox via the MCP adapter; nothing is invented or hardcoded
  2. Human approval is always required — no PATCH is sent to the NetBox API without an explicit human confirmation
  3. Rollback on failure — if post-change verification fails, the interface is restored to its previous state automatically
  4. Input validation before execution — the interface must be in tagged mode, the VLAN must exist and be active in NetBox
  5. No silent failures — every error path returns a clear, actionable message to the user

These requirements hold across all three implementations, even though the mechanisms used to satisfy them differ.

Reusable Skill

The patterns developed in this work — guarded pipeline design, agentic contracts, prompt structure, approval flows, and the trade-offs between architectures — have been packaged as a reusable Claude Code skill: n8n-guarded-agent-workflows.

The skill is available from the project repository:

https://bitbucket.software.geant.org/scm/gplor/agentic_workflows_with_n8n.git

It can be used by anyone building n8n workflows that combine LLM agents with infrastructure write operations, without needing to rediscover these patterns from scratch. See Setup for installation instructions.

For a fuller narrative background, see the public GP4L documentation page on this topic:

https://geant-netdev.gitlab-pages.pcss.pl/gp4ldocs/guides/playground/agentic_workflows/idea/