Build at agent speed. Run on one operating layer.

UiPath for Coding Agents now supports more of the automation lifecycle. UiPath Maestro™ Flow gives agent-built work one durable, governed path from prototype to production.

Since we opened the UiPath Platform™ to any coding agent in May, I have had a version of the same conversation in a lot of customer meetings.

Somebody opens a laptop and shows me what their team built. Onboarding across four systems. They described the outcome they wanted, a coding agent wrote the first version, and after a few passes it ran clean on test data.

I ask when it goes live.

It usually already works. It has usually worked for weeks. And it is usually still on the laptop. The holdup is never the code. It is that nobody in the room has agreed to be the person the phone rings for at two in the morning.

Different industries, different teams, different processes. Same stall, in the same place.

That is the gap we are closing today.

We’re expanding UiPath for Coding Agents to support more of the automation lifecycle and introducing UiPath Maestro Flow, orchestration designed for developers on the UiPath Platform. Troubleshooting and operating with UiPath for Coding Agents are already generally available. Maestro Flow is in public preview.

Together, they change what happens after a coding agent produces something that works. The goal is to keep the speed that made the prototype possible and add the visibility, control, and governance that make a team willing to put it into production. An automation shouldn't stay on a laptop just because that is where it started.

The backlog was an ownership queue

The consensus right now runs something like this. Automation has always been limited by engineering capacity. Coding agents remove that limit.

Enterprises can finally work through the backlog they've been carrying for a decade.

Look at what was actually sitting in those backlogs. A meaningful share of those items were not just waiting on a developer. They were waiting on someone to volunteer for a new permanent job.

Every automation that touches a real process comes with commitments attached. Exceptions need to be adjudicated by a person with the authority to do it. Credentials expire. Approval chains go stale when people change roles. Something fails overnight and a phone rings. Eighteen months in, an auditor asks what the thing did in March, and somebody has to have enough history to be able to answer.

Writing the first version was rarely the hardest part on that list, even before coding agents showed up.

So I'd push back on how my own industry is framing this moment. Faster generation, on its own, lets an enterprise create obligations faster than it can find people willing to accept them. That is how an estate ends up with hundreds of automations and a handful of people who can speak to any of them.

I spent enough of my career in security to have strong opinions about unowned inventory.

I've seen this movie before. I ran product marketing for Exchange through the launch of Office 365, and in the early years everyone agreed the bottleneck was provisioning. Everyone was right. Provisioning was miserable.

Then self-service arrived, and within about two years, the hard meetings were about something else entirely. Who owns this. What is running. What is it costing us. The work had moved to the other side of the deployment, and most organizations spent the following decade building the operating model they had skipped on the way in.

Cheaper building does open up work that was never viable before, and I'll come back to that. But the same relocation is underway now, and it is moving faster than it did with cloud.

The coding agent stays with the work

When we opened the UiPath Platform to any coding agent in May, we introduced our vision that coding agents are not only meant to build automations. Automation isn’t a one-and-done project—it moves through a repeating lifecycle. You build it, test it, run it, and fix it when something breaks, then do it again, a little better each time, for as long as it’s in use.

That’s why being able to hand off the heavy lifting to a coding agent is so important—because managing that entire lifecycle is complex, and requires continuous development resources. UiPath for Coding Agents now extends across more of that lifecycle.

Troubleshooting with UiPath for Coding Agents means that when an automation fails, a coding agent can read the workflow, work out what went wrong, and propose a fix that’s grounded in the actual implementation. This way, builders get help when debugging failed runs, chasing down errors, and tuning workflow performance.

Similarly, operating with UiPath for Coding Agents means administrators and governance teams get the same coding agent assistance for the work of running the platform—deploying, adjusting, and optimizing the configurations that keep automations up and running.

And UiPath Autopilot™ itself is now one of the coding agents you can use across the UiPath Platform. Because Autopilot now reaches the platform through the same skills, tools, and commands available for all coding agents, it’s no longer constrained to one task at a time - you can plan and execute any workflow end to end. Now also included in Studio Desktop, it’s the out-of-the-box option for developers who want enterprise-grade governance and capable help without leaving where they build.

Managing the entire lifecycle no longer requires surface-switching: you can build, deploy, and troubleshoot from where you already are. Less context disappears in the handoff between building and operating, because a coding agent can help a team understand what changed and diagnose a failure after the first version is complete—closing the gaps where context and time tend to go missing.

That helps. But it does not, by itself, tell anyone who owns the thing.

Speed isn't impossible...it's unaccountable

Most enterprises already have trouble producing a straight answer to three questions: what is running across the business, who owns each piece of it, and whether each piece is operating inside policy.

Add a wave of agent-built software spread across disconnected tools and runtimes, and those answers get harder to produce. The estate keeps growing in exactly the places the enterprise cannot see.

A generated automation is a starting point. Production depends on the business rules, the exceptions, the approvals, and the judgment arranged around it. None of that went away because the first draft arrived on a Thursday afternoon.

One Maestro Flow from prototype to production

Business orchestration decides what happens next when work crosses systems, agents, robots, and people. It holds state when a step fails, sequences the API calls and human approvals a real process depends on, and keeps the operating and audit record intact.

This is the substance of the category we're building for: business orchestration and automation. An agentic enterprise runs on that layer. Agents reason through the work capably, and they still need something underneath them that is accountable for state, controls, and outcomes.

That is why we built UiPath Maestro Flow.

When I introduced Maestro Case, I wrote about work where the path only reveals itself as it runs. Flow is another module on the same Maestro layer pointed at the other kind of work: a known, repeatable path, designed and built in one place by developers and by the coding agents now doing much of the building. That’s where the stall I described at the top of this blog tends to happen, which is why Maestro Flow is built to take a prototype to production on the same engine.

Maestro Flow is orchestration designed for developers, on the UiPath Platform. A coding agent generates a real, versioned Flow. A person opens that same Flow on a canvas, sees exactly what the agent built, and changes whatever they want.

Agents, robots, APIs, documents, data, and human approvals are all coordinated inside that single artifact. The builder still defines the outcome and still owns it.

A prototype shouldn't have to be translated, reconstructed, or rebuilt on a different engine before it can become a production system. The same Flow and the same underlying engine carry the work toward production with state, execution history, and controls intact.

Ownership is expensive mostly because it's undefined. Agreeing to own an automation means agreeing to whatever its failure behavior turns out to be, and to whatever you can piece together later about what it did.

A Maestro Flow that arrives carrying its own state and execution history changes what's being asked for. You can see the edges of it. That is the difference between a request a person will accept and a request that sits on a laptop for six weeks.

Every Flow deployed through UiPath enters the same operating and governance model.

One process, one lifecycle

Take a vendor tax-exemption request, the kind that normally crosses three systems and two handoffs.

A developer describes the outcome. The coding agent builds the Flow.

Maestro Flow runs it, coordinates the work across systems and people, holds state when something breaks, and preserves the record an auditor will eventually ask for.

Then comes the question that decides whether it ever goes live: who owns this now? In this case, the controller in accounts payable.

She can open the Maestro Flow and see what ran, where it stopped, and who signed off. That is a thing a person can reasonably say “yes” to. The coding agent stays involved and the builder keeps control of the outcome.

What changes for the enterprise

Connecting, building, and running inside one lifecycle changes the business case in three ways.

Smaller opportunities become viable, with a caveat.

When the cost of building drops, work that never justified a developer's time becomes worth pursuing. That only holds if the cost of owning the result drops alongside it. Those smaller opportunities are usually the manual handoffs, departmental processes, and operational gaps that create daily friction and never rise high enough on an engineering roadmap, and they are also the ones least likely to get a dedicated owner. A shared operating model is what makes them safe to say yes to.

The owner inherits the artifact that was tested.

A working prototype often proves only that the core idea holds. Production then triggers another round of work: rebuild it on a supported engine, wire up monitoring, get the controls in, work through the failure cases. What gets lost in that round is not just time. The thing that finally goes live is not the thing anyone watched run.That is a hard position to put an owner in. You are asking someone to accept responsibility for a version with no history behind it, on the strength of a prototype that no longer exists.

When the same versioned Maestro Flow moves from generation into governed execution, teams can skip that second build. The path gets shorter because the artifact stops changing underneath them, and the person who eventually owns it in production inherits the same artifact the builder tested, along with everything it did along the way.

Growth in the estate stays visible.

Every Flow enters one operating and governance model, so adoption expands the set of things the enterprise can see, operate, and govern. Enterprises can automate more valuable work while holding onto visibility and control as it moves into production.

What I'm actually left with

For years, the limit on automation was engineering capacity. There was always more worth automating than there were people available to build it. Coding agents forever changed that limit and allowed more builders into the work. UiPath for Coding Agents lets the coding agent not just build, but stay with the work past the first draft. Maestro Flow gives that work a durable place to run.

Every one of those stalled projects I’m hearing about in customer meetings is waiting on the same person: whoever agrees to be the one the phone rings for at two in the morning. That was true long before coding agents, and writing the first version faster does nothing for it.