What agentic flow development needs

[dgatti0213]

The human must deploy — that is the problem

Every write lands as an undeployed editor change and stops there. A human has to click Deploy and say so before the agent can see whether anything worked.

That makes the human the transport between every edit and its consequence. One page took six of those round-trips — three of them only to find the change was wrong.

The agent has to deploy its own code. And the deploy has to report readiness, or the agent is still guessing when to look:

• guessing wait_ms before checking a rendered page
• telling a mid-restart 502 from a real failure
• polling the database to see whether a migration ran

Then the two read/write primitives

get_flows

Read the whole config, one call, no browser.

Today: the editor-mirroring flow_building_* tools, or take a snapshot.

set_flows

Write it back, one call.

Today, creating 27 nodes cost:

Rejected add_nodes attempts	5
set_links calls	7
set_wires calls	2
Round trips	~15
Resent payload	~50k tokens

For what is one POST /flows with a JSON body.

[andypalmi]

The decision to go through the Editor was taken, like mentioned above, to get flow validation, schemas and defaults, atomic ops, and debug messages

More info here

On building flows through the editor. Node-RED is a visual tool, so the richest way to build in it is through the editor rather than assembling flow JSON blind. The agent only needs a FlowFuse tab open, and in return it gets:

• native validation before anything is applied: required properties, unknown or misspelled property names, invalid node types, missing config nodes, plus after-the-fact checks for invalid, unused and orphaned nodes.
• schemas and defaults for the common FlowFuse and Node-RED nodes, with live runtime introspection for schemaless or 3rd-party ones, so it doesn't guess.
• atomic, batched operations across nodes, wires, tabs and groups, so the agent works in small verifiable steps instead of one big JSON blob.
• live debug messages to see what the running flow actually does.

The PAT-through-the-API path has none of that. It produces flows that look right but silently might not be.

The tool you suggested, set_flows would again go another route than from the editor again missing on all the advantages of the points above.

Also I would say that this is a great example of errors caught by validation

Rejected add_nodes attempts	5

Is the only difference for this get_flows tool you propose the fact it can be used without a browser tab?

Currently the tool flow_building_get_flow lets an agent get the full flows of an instance when passing full: true as argument.

Otherwise there is tool platform_get_snapshot_full to get the full snapshot of an instance, see.

We already have the tools to allow reading a full flow or creating a full flow on an instance, so what exactly is missing? Is the issue that it's a different way of working (no more local JSON files) or is there a missing capability or feature?

About deploy action: I believe it could be available by opt-in by the user on either a team/application/instance/device (I would pick a level of granularity either as team or application) making sure the risks are clearly outlines.

[andypalmi]

Rather than going through the backend for deploying flows, I would find a middle ground on the deploy button that satisfies both requirements of security and agentic development

Steve outlines pretty clearly the risks associated with agentic deployment of flows https://flowfuse.slack.com/archives/C03FAUBPPJ7/p1788252720352169?thread_ts=1787897004.711409&cid=C03FAUBPPJ7

[andypalmi]

Currently I do not see gaps highlighted in functionality for flows creation, simply a different way of doing things from how you were used to and a manual step (Deployment) that is manual (still) and could not be anymore (if the right middle ground is found).

I would suggest finding a middle ground and going forward with the planning of the remaining tools, as the ones still missing are documented in this epic #7667 or summarised in this canvas on Slack

[dgatti0213]

Not asking to bypass the editor, asking for the editor-equivalent of four things.

Agentic development needs READ, WRITE, TEST, and DEBUG.

READ. get_flow with full: true returns everything, you're right. Worth saying why it didn't get used, because it's the pattern and not a misread. The description says:

Get a slim summary… Pass full: true only when you genuinely need every property of every node (rarely needed, prefer get_node for targeted inspection).

The AI followed it. That's good advice for an assistant answering a question about one node on a canvas someone is watching. It's the opposite of how an agent works: an agent wants the document once, then works offline. "Rarely needed" describes a Copilot. It's the normal case for us.

WRITE. No way to submit a full flow, or a full tab.

Node-RED admin API	MCP equivalent
GET /flows, read everything	get_flow with full: true ✅
PUT /flow/:id, replace one tab	none
POST /flows, replace everything and deploy	none

On validation. Validation isn't the problem. The problem is that I can't submit the full flow and have that validated, only pieces of it. Same checks, same rejections, but against one document instead of 15 partial ops.

TEST. The test is running the flow and seeing what happens: trigger it, read what came out, compare that to what was expected. That needs two things: a way to probe readiness after deploy, so the agent knows the runtime is actually up rather than waiting a guessed interval, and a way to fire a flow and get the result back without a human clicking inject and pasting the debug pane.

DEBUG. Seems fine as long as the user sets this up right but the tool call should be able to to pull what it needs regardless of the user's window.

[ZJvandeWeg]

@dgatti0213 the more I read the more it feels like these are nice to haves and not real blockers for adoption. Can you please provide an example of the contrary?

[dgatti0213]

I view these as technical blockers to agentic dev not using the tool... (Clicked save early lol)

The reason is that the write path only accepts fragments, so one logical change becomes 15 calls. Each of those is a call and a response, which means most of the agent's context ends up being bookkeeping about its own edits rather than the app it's building, and partway through it loses the plan.

That part I can engineer around. An orchestrating agent plans the work and hands each small edit to a subagent that makes it and reports back, so no single context window fills up with bookkeeping. It burns a lot of tokens, but it works. Context isn't what I'm calling the blocker.

What no amount of orchestration fixes is that the sequence can stop anywhere and leave the flow in a state nobody asked for. Mid-refactor, one call timed out and the tab was left holding new link call nodes wired to nothing while the old path was still connected. Not the old flow, not the new one, and everything before it had already committed. An import can't half-apply like that, and a subagent can't unwind it either, because there's nothing to unwind to.

Failures aren't even the whole of it, because nothing checks the whole. Every call passes on its own terms, so nothing rejects, and a mistake that only exists between the pieces sits there until something runs or until I read the flow back and spot it. Delegation makes that worse rather than better: more agents each making individually valid edits, and still nothing looking at the document. I'm not asking for less validation. I'm asking to submit the document and have that validated.

All of that assumes the agent is allowed to deploy in the first place. Adding this requirement back makes the issue even worse.

So what did I gain over manual export and import, if I have to watch every call, click deploy randomly, and direct every stage of the build?

[dimitrieh]

Linking this to the thread on slack: https://flowfuse.slack.com/archives/C09QS57R8AD/p1788963422877479

Adding from the meeting yesterday with Kris, Drew, and me:

• The Problem: Current Tooling Blocks Demo Progress
  • Building demos with the current MCP tool is 10–15x slower than with direct API access.
• Primary Blocker → No Auto-Deploy:
  • Requires manual approval for every change, breaking the agentic workflow.
  • Forces developers to babysit the process for hours or days, causing significant delays.
• Secondary Blocker → MCP Primitives:
  • Requires multiple API calls for simple changes (e.g., 3 calls for 3 nodes), slowing down execution.
• Root Cause → One-Size-Fits-All Persona:
  • The MCP tool tries to serve both cautious production users and rapid developers.
  • Proposed Fix: Create distinct personas with different access levels (e.g., read-only for production, full access for dev) to enable faster iteration.

I'll paste the JTBD from the slack thread:

As a user of our "AI MCP tooling", I want to setup a "FlowFuse Usecase/Application/Solution" from start to finish as fast as possible, so I can iterate faster until it is ready to move it to a production environment.

Ultimately, we are deciding currently for the user if we give them the ability to adjust things in production or any instance a specific way or not without giving them an option to decide for themselves. Is it our prerogative or theirs?

[cstns]

A few of these read as gaps but are the design working as intended, so let me go through them.

On the staged buffer. The timeout that left link nodes wired to nothing didn't leave that state anywhere that matters. It left it in the editor buffer, which is what the buffer is for. The running instance was untouched. And there is always something to unwind to: the last deployed state. Discard the undeployed changes and you are back on known ground. That boundary is exactly what a direct POST /flows gives up, because there the half applied state would have been live.

On bulk write. The 5 rejected add_nodes calls are the strongest argument for the incremental path, not against it. Each rejection landed at the moment the mistake was made, scoped to that call, with schema feedback the agent could act on immediately. That is what error correction looks like for an agent: catch it, fix it, move on, and everything already on the canvas is known good. The flow grows from verified pieces. Build the same 27 nodes as one blob and correction only starts after the whole document exists, as one coarse rejection of 50k of JSON where the agent now has to diagnose an inconsistent document as a whole, then resubmit all of it every fix cycle. The token math flips against you there, and a stack of atomically validated nodes beats a blob that looked right until something ran. There is also no headless validation engine to point a raw flows POST at. Node-RED validates in the editor because the editor is where the node definitions live, so set_flows would not be "the same checks against one document", it would be no checks until runtime. When you genuinely have a complete document in hand, the editor import path covers that case and validates every node on import.

On "nothing checks the whole". That is a workflow concern, not a missing primitive, and it is manageable with the skills scaffolding we already have: after a batch of edits, read the flow back and run the editor's whole flow checks for invalid, unused and orphaned nodes.

On TEST. Readiness is not a guess today. platform_get_hosted_instance_status reports instance state and platform_get_hosted_instance_logs returns the runtime logs, so there was never a need to poll a database or pick a wait_ms. What I will push back on is the agent firing inject nodes. That is the same category as deploy: it produces real consequences on live systems. Observation should come from status and logs, and it can.

On DEBUG. Here you have a fair point. The first party agent can read the live debug entries from the editor, and the third party MCP integration currently cannot. That is not an architectural problem though, it is a missing tool, and adding it is planned for next week.

On deploy. I also do not think opt in flags at team or application level are the right shape. The exposure is not about which team the instance sits in. A deployed flow can make outbound http or mqtt calls to anything the network reaches, and no token scope or team boundary fences that. The deploy click is where a human takes responsibility for what goes live against systems the platform cannot see or protect. If we want agents deploying autonomously, the honest version is an instance type that is DMZ'd by construction, with egress restrictions enforced at the driver level, where auto deploy is safe because the blast radius actually is contained. That is worth designing. Checkboxes on ordinary instances just move the blame.

On READ. Fair point on the description steering, it is tuned for the copilot case. That is a wording change, not a missing capability. Slim by default stays right though, because real world flows balloon to sizes that would eat an agent's entire context, and full: true is there when the document is what you need.

[cstns]

Linking this to the thread on slack: https://flowfuse.slack.com/archives/C09QS57R8AD/p1788963422877479

Adding from the meeting yesterday with Kris, Drew, and me:

* The Problem: Current Tooling Blocks Demo Progress
  
  * Building demos with the current MCP tool is 10–15x slower than with direct API access.

* Primary Blocker → No Auto-Deploy:
  
  * Requires manual approval for every change, breaking the agentic workflow.
  * Forces developers to babysit the process for hours or days, causing significant delays.

* Secondary Blocker → MCP Primitives:
  
  * Requires multiple API calls for simple changes (e.g., 3 calls for 3 nodes), slowing down execution.

* Root Cause → One-Size-Fits-All Persona:
  
  * The MCP tool tries to serve both cautious production users and rapid developers.
  * Proposed Fix: Create distinct personas with different access levels (e.g., read-only for production, full access for dev) to enable faster iteration.

I'll paste the JTBD from the slack thread:

As a user of our "AI MCP tooling", I want to setup a "FlowFuse Usecase/Application/Solution" from start to finish as fast as possible, so I can iterate faster until it is ready to move it to a production environment.

Ultimately, we are deciding currently for the user if we give them the ability to adjust things in production or any instance a specific way or not without giving them an option to decide for themselves. Is it our prerogative or theirs?

I think this conflates two different jobs. What it takes to showcase the product is not what users need to create and maintain flows.

A demo optimizes for speed to a working impression: deploy constantly, nothing downstream matters, throw it away after.

Someone building and maintaining real flows optimizes for the opposite: changes that are validated as they are made, a staged buffer, and a deliberate line before anything goes live, because their flows touch systems that matter.

The JTBD as written is the first job wearing the second job's clothes. Reshaping the deploy boundary around it optimizes the product for demos and calls it a user persona.

[cstns]

A correction is needed:

On DEBUG. Here you have a fair point. The first party agent can read the live debug entries from the editor, and the third party MCP integration currently cannot. That is not an architectural problem though, it is a missing tool, and adding it is planned for next week.

both expert and 3rd party can get debug messages from the editor

[dimitrieh]

A demo optimizes for speed to a working impression: deploy constantly, nothing downstream matters, throw it away after.

Iteration matters for all use cases.

I think this conflates two different jobs. What it takes to showcase the product is not what users need to create and maintain flows.

The case here to be made is:

• What do users need to create flows
• What do users need to maintain flows

Are we solving each need well enough? Can we make improvements without giving up control and increasing observability and velocity?

Yes, our sales team are not our users (which then also would make the case for them dogfooding our MCP tooling not giving us the right feedback). Then how are our ICP users experiencing our product? True user feedback is where this hinges on. We have options to reach out to trial users and customers using the product now.

[dgatti0213]

I think this conflates two different jobs. What it takes to showcase the product is not what users need to create and maintain flows.

Agreed, and that's the right distinction to draw.

A demo optimizes for speed to a working impression: deploy constantly, nothing downstream matters, throw it away after.

That's the part I'd push on, and it's the whole disagreement.

What I'm doing isn't that. It's real code on a deadline with the resources we have, which is why it has to be agentic rather than approve-each-suggestion. The constraint is speed, not standards, and the output isn't disposable. There are devs today who write code this way. I know that's a contentious topic right now, with passionate people on both sides.

The axis isn't demo versus production. It's how much of the work the human watches:

1. Teach mode. Someone who doesn't know Node-RED yet, learning as they go.
2. Copilot. A developer moving faster, watching every change.
3. Managing agents. I scope the work, they do it, I review the output when it's finished.

The expert serves 1 and 2. 3 isn't built. Everything else we've been arguing sits downstream of that: whether the staged buffer is a feature or a blocker, whether incremental validation beats whole-document, whether deploy should ever be automatic. Each has a different answer depending on which of the three you're building for, and we've been trading them without settling that first.

Taking your corrections on the buffer, readiness and debug. I'm not saying these things don't work. I'm highlighting gaps in serving the third persona.

I'm not claiming what I proposed is the right shape. I'm asking that the third be part of the conversation, and that the expert be tailored to it too.

[dgatti0213]

This guy is a prime example of this: https://app-eu1.hubspot.com/contacts/26586079/record/0-1/4072651
@dimitrieh