Builder-Agent Has a New Tool: What the Run Code Task Means for Spec-Driven Workflows

We recently released Itential Platform 6.4, a release shaped by what enterprise teams have asked us to make easier. The headline feature is one of the most broadly requested capabilities we’ve shipped in some time: writing Python directly inside a workflow task on the Canvas, through a new Run Code task.

That capability is going to matter for a lot of teams. But for anyone using Itential’s Agentic Builder Skills to deliver workflows from approved specs, it changes something specific about what the agent delivers – and it’s worth a closer look.

If you’re running spec-driven development with Itential’s Agentic Builder Skills, you’ve lived the workflow: you write the spec, you review the spec, you approve the spec, and the builder-agent hands you back a production-ready Itential workflow. That handoff – that moment where an agent-delivered artifact lands in your environment ready to run – is the whole point.

Platform 6.4 doesn’t change that loop. But it changes what’s inside the artifact the agent delivers.

Two Paths, & Now a Third

Here’s the pattern every spec-driven delivery has run into: somewhere in the workflow, you’ve got logic that isn’t a straight orchestration step. Custom data processing. Conditional branching based on a computed value. A payload transform that’s three lines of Python but four nested JST tasks.

Until 6.4, the builder-agent had two places to put that logic.

Option 1: A chain of JST tasks. Works fine for simple transforms. Gets gnarly fast when the logic isn’t simple. Anyone who’s inherited a workflow with eight stacked JST tasks knows the feeling of staring at it and thinking “this should have been Python.”

Option 2: A Python service delivered via the /iag skill. The right call when the logic is heavier, shared across workflows, or needs to live as a real service with its own lifecycle. But for a one-off piece of workflow-specific logic, it’s heavier than the job requires. You end up with a separately defined, separately deployed service that only one workflow calls.

Run Code gives the agent a third option: put the Python directly in the workflow, as a task on the Canvas.

That’s it. That’s the change. But it reshapes what the builder-agent delivers in ways that matter.

When the Agent Picks Run Code vs. the Other Patterns

Worth being specific about this, because the agent isn’t replacing anything. It’s getting better at picking the right tool.

JST still wins for simple, declarative transforms. If you’re mapping one JSON structure to another, JST is the cleanest expression of that. No Python needed.

An /iag skill-delivered Python service still wins when the logic needs to be shared, reused across workflows, or maintained as a real service. Production-grade Python that multiple automations depend on belongs in a service. That’s not changing.

Run Code wins for the middle: inline logic that’s specific to this workflow, more complex than JST handles cleanly, and not something you need to share or maintain separately. The kind of logic that was always supposed to live inside the workflow, and now finally can.

If you’re writing specs, this is worth internalizing. You’ll start seeing the shape of your own workflows differently once you know the agent has this option.

What the As-Built Deliverable Actually Looks Like Now

This is where the practical impact shows up most clearly.

Before Run Code, a spec-driven delivery with non-trivial inline logic usually came back as a workflow plus a separately deployed Python service. Two artifacts. Two deploy steps. Two places to go when something changes. The As-Built documentation had to explain both, and the engineer owning the automation long-term had to hold both in their head.

With Run Code available, a lot of those deliveries come back as one artifact. The workflow. The logic. The docs. All in one place, all legible in the Canvas, all editable by any Python-fluent engineer on the team.

That’s not just cleaner. It’s a fundamentally different handoff. The team receiving the automation can read the whole thing, modify it without learning where the companion service lives, and extend it without context-switching out of the workflow. The automation becomes something they own instead of something they inherit and hope they don’t have to touch.

Why This Matters for Spec-Driven Development as a Methodology

Spec-driven development only works if the thing the agent delivers is something a human can confidently own long-term. That’s the whole premise. Spec in, production-grade workflow out, and the workflow is readable to the engineers who now own it.

Everything that makes the delivered artifact more self-contained strengthens that premise. Everything that fragments it weakens it.

Run Code is firmly in the “strengthens it” column. It gives the builder-agent a way to honor the spec’s logic requirements without splintering the delivery across multiple artifacts. It shrinks the cognitive surface area of what lands on the owning team’s plate. And it keeps the workflow legible – both to humans reading it and to AI agents down the line that might be asked to modify, extend, or audit it.

As agentic operations matures, the artifacts our agents deliver today will be the artifacts other agents read, modify, and act on tomorrow. Self-contained, readable workflows aren’t just better for humans. They’re better for the next wave of agents too.

A Worked Example

Picture a spec: “Given a list of devices from the source of truth, filter to the ones in a specific region, sort by last-configured timestamp, and kick off a compliance check workflow for the oldest ten.”

Pre-6.4 delivery:

1. Workflow with a GET from the source of truth
2. JST task to filter by region
3. JST task to sort (getting ugly)
4. JST task to slice the top ten (really ugly)
5. Child job call for each

Or alternatively:

1. Workflow with a GET from the source of truth
2. A call to an /iag-delivered Python service that handles filter-sort-slice
3. Child job call for each
4. Plus the service itself, deployed and maintained separately

Post-6.4 delivery:

1. Workflow with a GET from the source of truth
2. One Run Code task with ~8 lines of Python doing the filter, sort, and slice
3. Child job call for each

Same outcome. Readable in one glance. Modifiable by anyone who can read Python. No separate service to keep in sync.

Multiply that across a customer’s portfolio of spec-driven deliveries and you can see the shape of what changes.

What This Unlocks for Builders

If you’re building with Agentic Builder Skills today, this is one of those updates that doesn’t look flashy on a release notes page but meaningfully moves the needle on what your agent delivers. Fewer fragmented deliveries. Cleaner handoffs. Workflows that read like workflows instead of scavenger hunts.

We showed this in action at Cisco Live US 2026. The VibeOps Lounge was where the spec-driven development methodology came alive with real builds, real specs, and real deliveries. Watch all the VibeOps sessions on-demand at any time.

Come see what the builder-agent can do now.

Platform 6.4 is now available to on-premises customers and to cloud customers. Agentic Builder Skills are available on the Anthropic Marketplace.