Skip to content

Agentic Flows Implementation in Langflow

Overview

This use case explores how Langflow can be used to implement agentic network automation flows in the GP4L environment. The VLAN management scenario is used as a practical test case because it requires the agent to interpret a user request, retrieve authoritative data from NetBox, validate the requested change, ask for human approval, apply the change, and verify the result.

The focus is not only on whether the VLAN workflow can be implemented, but on identifying which agentic workflow patterns are viable in Langflow and which platform constraints need to be taken into account when designing guarded automation flows.

Several implementation patterns were considered, ranging from a simple single-agent orchestrator to more guarded designs where deterministic Python tools handle validation and patch preparation.

Why Langflow

Langflow was tested as an alternative visual environment for building agentic automation workflows. It provides a canvas-based interface, support for LLM agents, tool calling, custom Python components, and integration with OpenAI-compatible model endpoints.

This makes it interesting for GP4L-style experimentation, where network automation workflows often need to combine:

  • natural-language interaction;
  • structured tool calls;
  • access to a source of truth such as NetBox;
  • human approval before execution;
  • deterministic validation before applying changes.

The goal was therefore to understand how far Langflow can support safe and practical agentic flows for network automation, and which design patterns are most appropriate for this platform.

Test Scenario

The test scenario is VLAN management on a router interface. A user asks the agent to add or remove a VLAN from a tagged interface, for example:

Add VLAN 20 to ge-0/0/0 on rtr-lab-01

The workflow must then:

  1. identify the requested action;
  2. look up the device in NetBox;
  3. look up the interface on that device;
  4. verify that the interface is in tagged mode;
  5. look up the VLAN;
  6. check whether the requested change is valid;
  7. prepare the full PATCH payload;
  8. ask the user for approval;
  9. apply the change only after approval;
  10. verify the result and roll back if needed.

This scenario is small enough to test quickly, but complex enough to expose important issues around tool use, validation, state handling, and human-in-the-loop execution.

Agentic Workflow Patterns Considered

Four Langflow patterns were considered:

Pattern Description Result
Plain orchestrator One agent performs NetBox lookups, validation reasoning, proposal generation, and patching Working, but relies too much on the LLM
Guarded orchestrator One agent calls Python tools that handle lookups, guard checks, and patch ID computation Recommended
Multi-agent pipeline Planner, lookup, and patch agents are chained on the canvas Abandoned
Tool-guarded agent Most logic, including approval handling, is moved into Python tools Abandoned

The main outcome is that Langflow is well suited to a guarded single-agent orchestrator, but not to agentic patterns that require deterministic routing between multiple agents.

Design Requirements

The same safety requirements were used across all Langflow variants:

  1. NetBox must remain the authoritative source of truth.
  2. The agent must not invent device, interface, VLAN, or ID values.
  3. The workflow must validate the requested change before any write operation.
  4. A human approval step must be required before applying the PATCH.
  5. The PATCH payload must use NetBox database IDs, not display VLAN numbers.
  6. The result must be verified after execution.
  7. Rollback must be possible if verification fails.
  8. Errors must be explicit and visible to the user.

These requirements guided the selection of the final Langflow pattern.

Langflow-Specific Questions

The experiment was designed around several Langflow-specific questions:

  • Can Langflow support a guarded network automation flow where validation is enforced in code?
  • Can a single Langflow agent handle a two-turn approval workflow reliably?
  • Can multiple Langflow agents be chained into a guarded pipeline?
  • Can Python tools prevent the LLM from bypassing safety checks?
  • How does Langflow's agent execution model affect human approval and routing?
  • Which parts of the workflow should be handled by the LLM, and which must be handled by deterministic tools?

Relationship to the n8n Implementation

The earlier n8n implementation provides a useful comparison point because it used the same VLAN management scenario and similar guarded automation requirements.

However, the purpose of this section is not to describe a direct port from n8n to Langflow. The main purpose is to identify which agentic flow patterns work naturally in Langflow.

The comparison with n8n is useful because the two platforms differ in how they control execution. n8n uses graph-based routing, wait nodes, and deterministic node-to-node flow control. Langflow uses a LangChain-based agent loop, where the LLM decides whether to call another tool or return a final answer after each tool result.

This difference has a strong impact on which guarded workflow patterns are practical in each platform.