Itential workflows have long been able to execute Python through IAG services. Platform 6.4 takes the next step: writing Python directly inside a task on the Workflow Canvas, no separate service required. It’s a change customers have been asking for, and it meaningfully reshapes how workflows get built.

The new Run Code task lets builders write and execute Python directly on the Canvas. Data manipulation, conditional logic, computational operations, all of it can now live inside the workflow itself. Python code is stored in the task, testable at design time with live inputs and outputs, and executed securely through IAG 5’s isolated runtime.

This is one of the most broadly requested capabilities from our enterprise customer base, and it’s not a small change in how workflows get built.

If you’ve ever built a production workflow in Itential, you know the pattern: a clean orchestration flow, interrupted by a chain of JST transformation tasks doing work that Python would have done in four lines. For heavier lifting, the right answer has been an IAG Python service, and it still is, when the logic needs to be shared across workflows, maintained independently, or carry the weight of a real service.

But a lot of what gets pushed to JST chains, or out to a service it didn’t really need, is just inline workflow logic. Run Code gives builders the option to handle that logic on the Canvas, in a single readable task, without leaving the workflow. And because Python execution runs through IAG 5’s isolated runtime, you get the flexibility without giving up the guardrails.

Agentic operations only works when AI reasoning connects to deterministic execution. Python on the Canvas makes that connection tighter.

For teams using Itential’s Agentic Builder Skills and spec-driven development, the impact is immediate. When the builder-agent delivers a workflow from an approved spec, any requirement for custom data processing or conditional logic has historically meant one of two options: a chain of JST tasks, or a separately deployed IAG Python service via the /iag skill.

Run Code gives the builder-agent a cleaner third option for logic that belongs inside the workflow. Embed it directly as a Run Code task, no separate service deployment needed. IAG Python services remain the right call for shared or heavier logic. But for the inline case, the workflow, its logic, and its documentation now live together. The As-Built handoff gets simpler. The delivered artifact becomes something any Python-fluent engineer can read, modify, and own long-term.

That’s what agent-delivered automation should look like when it’s built for production.

Platform 6.4 and IAG 5.4 also deliver substantial additions for specific customer segments:

• Visibility for Configuration Manager teams running compliance at scale
• Proxy support for enterprises that have been blocked from deploying Integrations in production
• A set of capabilities focused on operational visibility, AI-readiness, and making life meaningfully better for teams running gateway clusters

If your team runs compliance checks across hundreds or thousands of devices, you’ve probably had this experience: a plan runs, something fails, and you spend the next hour combing through raw outputs trying to figure out what actually happened. Configuration Manager now includes a dedicated reporting dashboard with plan-level compliance scores, connection success rates, device coverage, and trend data across configurable time windows. Operators can drill from a fleet-wide overview into individual plan runs, into device-by-device results, into specific connection errors. A redesigned step-by-step plan creation wizard ships in the same release. This was the most-requested gap in Configuration Manager. It’s now closed.

For enterprise customers with established security architectures (financial services, public sector, healthcare, anyone with a corporate proxy in the path), deploying Integrations in production has been blocked by a basic missing piece. Platform 6.4 introduces centralized proxy configuration: administrators set HTTPS proxy settings once at the feature level, and integrations inherit those settings by default, with per-integration overrides available where needed.

Integration execution now routes through IAG 5 rather than directly from the platform layer. Routing execution through IAG 5 aligns integration traffic with the customer’s existing egress posture: outbound API calls originate from the customer environment and flow through their proxy controls rather than arriving from Itential’s cloud. Proxy credentials stay inside the customer-controlled environment. For cloud-managed customers running integrations against on-premises systems, it also eliminates the VPN tunnels previously required to bridge the two worlds. This is also the architectural pattern future IAG 5–dependent capabilities will follow, including Run Code on Canvas and FlowAI.

When something goes wrong in a production workflow, time to resolution is everything. 6.4 makes the execution path immediately visible on the Canvas: completed steps light up green or red based on outcome, skipped steps recede into the background. Operators can see exactly what ran, what failed, and where, without digging through logs. Faster diagnosis, faster recovery.

Consistent description fields across adapters, integrations, and applications. It sounds quiet on the surface; it’s foundational underneath. Teams managing hundreds of integrations finally have a way to know what each service does and how it connects. And AI agents can only work effectively in environments they understand. This is groundwork for FlowAI.

Inspecting a specific task in a large workflow now automatically centers and highlights it on the Canvas. What used to require scrolling and searching in dense workflows is now instant.

Two new commands give operators complete visibility into a gateway cluster before performing maintenance. iagctl inspect cluster activity shows all in-flight and recently completed work across runner nodes. iagctl inspect cluster health checks whether all cluster components are reachable and ready. A combined iagctl inspect cluster command displays both together. Maintenance windows no longer require the guesswork of whether something in-flight is about to get interrupted.

Configure retention policies to clean up idle Python virtual environments on a schedule. No more logging into nodes to reclaim disk space by hand.

A common Python scripting pattern, boolean flags via argparse’s store_true, is now fully supported in IAG 5. It was available in IAG 4 and its absence was a real migration friction point. It’s back.

Multiple named profiles in a single configuration file. Switching between dev, staging, production, or multi-region gateway clusters is now a one-flag operation.

The init command now supports remote backends and partial config options, unlocking more sophisticated infrastructure-as-code patterns through IAG 5.

The through-line here isn’t features. It’s what the platform is becoming.

Python on the Canvas is the most visible piece, but Service Configuration Descriptions, Job Execution Path Visibility, and the new proxy configuration architecture are cut from the same cloth: a platform that’s more transparent to the humans running it, more legible to the AI agents building on it, and more deployable in the security architectures real enterprises actually run.

That’s what agentic infrastructure operations needs to look like in production. This release moves us closer, and it sets the stage for what we’ll be showing at Cisco Live in June, where FlowAI, Agentic Builder Skills, and the VibeOps community all come together in the VibeOps Lounge.

Click here to see the schedule and meet with our team →