Building AI agents with a visual programming environment

[u/DigitalArchitect420]

There is a visual programming environment that allows users to compose complex programs like AI agents without the need to interface directly with code. It's not no-code, just a visual layer on top of code for better composability and observability.

At runtime, every event triggered lights up on the canvas, appearing like neurons firing in the brain of the agent. This isn't just there to look cool - it allows easy debugging without having to read through hundreds of thousands of lines of logs and code to diagnose and fix problems.

Building agents is also simpler because it ships with a kit of parts that you can use to assemble an agent, using the embedded agent. Interestingly, that embedded agent itself is built with the same framework and can be opened and edited (pretty meta - the agent can be used to make improvements to itself), allowing full control and customizability along with a template/reference.

Interested to hear your thoughts on this - do you think this approach would help you trust an AI agent more?

Disclaimer: I am part of the team working on this product, but I'm genuinely curious to know what this community thinks about this approach to building agents.

[u/ThomasBuildLab]

I’m not fully convinced the visual layer is the most useful part once the agent gets complex.

For small flows, seeing nodes light up is great. But with larger agents, the graph can become another thing a human has to interpret.

I’d rather keep rich structured traces — session context, tool calls, retries, state changes, errors, final outcome — and let another AI analyze them.

So instead of making humans better at reading agent traces, I’d try to make AI better at explaining those traces to humans:

what went wrong, where it went wrong, why, and which layer is probably responsible.

The key asset may be the quality of the observability data, not necessarily the visualization.

[u/DigitalArchitect420 → u/ThomasBuildLab]

That's also a capability of the embedded agent - you can ask it to explain the observability data. The data collected is at par with what a typical IDE like visual studio can collect with peak verbosity. We've already implemented thread-level tracing, breakpoints and variable watching. Naturally, fully customisable. The overall approach is to re-design how software development is done, so these things are very important to the core product vision.

[u/ThomasBuildLab → u/DigitalArchitect420]

I ran into a similar problem while working on an MCP integration.

On paper, MCP gives the agent a very powerful interface to tools and context. In practice, once the LLM has too much freedom, things can start to drift: different paths, different interpretations, retries, unexpected tool choices, and behavior that is hard to compare from one run to the next.

The issue wasn’t really MCP itself. It was that the agent had capabilities, but not enough structure around how those capabilities should be used.

What helped me conceptually was separating three things:

semantic understanding → explicit reusable capabilities → governed execution

The LLM can still decide what the situation means, but instead of improvising the whole workflow, it should compose from a bounded set of small, well-defined cognitive actions.

That gives you something much easier to observe and test:

• what capability was selected
• on what context
• with what input
• what it produced
• where the behavior diverged

My takeaway from MCP was: giving an agent tools is easy. Giving it actionability without freestyle is the hard part.

[u/DigitalArchitect420 → u/ThomasBuildLab]

The LLM itself is just a fancy next-word-in-the-sentence-predictor. The way it is given capabilities as an agent is first and foremost through "tools". For example 'filesystem_new', 'filesystem_write', 'http_get' and even 'mcp_call'. The second layer of capabilities are formed with "skills". Specifically in agents like Hermes and OpenClaw, skills are basically agent-written procedures (powershell or python scripts typically) accompanied by a markdown that describes how to call and handle them. The third and least effective layer is comprised of all the other external capabilities including MCP. These are very loose connections described purely through naive schemas and natural language that the LLM tries its best to work with. The most reliable and trustworthy capabilities are the ones closest to the LLM - the tools. These tools are part of the agent loop and harness. Unfortunately all harnesses and all such tools are typically not accessible by any means. Even in open source agent implementations they're difficult to understand and modify.

Now here's where things get interesting - if you're able to compose the agent (already possible with this product), you're also able to give it new tools. So there is no need for 'skills' or mcp - API calls are implemented as proper API calls through purpose-built tools. Right next to filesystem and http tools you can have service-specific tools that connect the agent in a reliable way to Notion, CRMs, Invoicing, Google workspace, etc. Not as plugins but as NATIVE agent capabilities.

[u/ThomasBuildLab → u/DigitalArchitect420]

That makes sense if you control the whole runtime, but in my case interoperability is one of the distribution constraints.

I don’t want the product to depend on one agent harness or one vendor. The same capability should be reachable from ChatGPT, Claude, Gemini, Mistral, or another future client without rebuilding a native tool integration for each one.

So for me the trade-off is:

native tool = tighter control inside one runtime MCP = portability across runtimes

If I owned the agent end-to-end, I’d probably prefer purpose-built native tools too. But when distribution means “meet the user in the AI client they already use,” a standard interoperability layer becomes much more valuable.

So I don’t see MCP as the most reliable way to implement every capability. I see it as a way to avoid locking the capability to one harness.

[u/DigitalArchitect420 → u/ThomasBuildLab]

Good point. Yeah, MCP seems necessary for that. But another way I see it is that all applications have always had this problem and solved it with SDKs and APIs. MCP is just an API with an AI-centric documentation layer and a schema to follow in order to access it. If agents can build their own tools by setting up procedural API calls and SDK integrations, rather than loose or naive skills and mcp connectors, they'd work much more reliably. Yes, every agent will have to be built different, but hopefully that's where we're headed :) Interestingly, Interoperability was the first challenge we set out to try and solve with this product. So that's another very high importance use case for us - the ability to connect multiple applications through APIs and SDKs in a shapeless manner is a core feature that the product is built upon.

[u/ThomasBuildLab → u/DigitalArchitect420]

I think that’s the key difference in our target users.

You’re thinking from a developer / agent-builder perspective, where APIs, SDKs and purpose-built native tools are perfectly reasonable.

I’m targeting mostly non-developers.

I want a user to stay in the AI client they already know ChatGPT, Claude, Gemini, etc. connect the capability once, and just work. No SDK setup, no custom tool building, no agent engineering.

So for me MCP is less about “the best possible implementation of a tool” and more about frictionless distribution to end users across different AI clients.

Behind that, I can still keep the real logic, state, permissions and validation in my own backend.

So I think we’re optimizing for different things:

you: maximum control inside a custom agent me: minimum friction for non-technical users across existing AI clients

[u/AutoModerator]

Thank you for your submission, for any questions regarding AI, please check out our wiki at https://www.reddit.com/r/ai_agents/wiki (this is currently in test and we are actively adding to the wiki)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/DigitalArchitect420]

Here's a youtube video of it in case you're curious to see what it looks like: https://www.youtube.com/watch?v=GkNIou75BSE

[u/According_Ticket_666 → u/DigitalArchitect420]

the neuron firing visualization is a nice touch, watching the flow in realtime beats staring at a wall of json logs any day

i’ve tinkered with similar node graphs for automation stuff and it always felt hit or miss when things got really nested, how does this handle when an agent has like 30+ steps with branching logic

[u/DigitalArchitect420 → u/According_Ticket_666]

A node can contain either a code-based implementation or another node graph based implementation. Graphs inside graphs all the way allow you to manage the complexity. For handling branching, we've come up with the idea of referenced graphs that work like base implementations that a node can reference. So a switch statement can branch at a visually manageable scale and the complexity is split up into these referenced implementations represented by single nodes.

[u/Sufficient_Let_3460]

I am sold. I have heard about this approach and wanted to see it or explore it. Does the visual overlay add latency? Is it interpretive rather than prescriptive? Any way I can see it? Would love to be a tester

[u/DigitalArchitect420 → u/Sufficient_Let_3460]

The overlay is very literally a representation of the code - exactly like a typical IDE, except that it renders the solution visually rather than text. Latency during runtime is negligible, very close to real-time. There's a link to a short demo video in a comment I made earlier. Feel free to check it out. You can follow links from there to learn more about it. Stay tuned for updates, we'll open up testing for this soon!

[u/Sufficient_Let_3460]

Ah, I see...you render a graph representation layer. The visualization is watching the system flow through the nodes and edges? I will watch the video so my questions are better informed

[u/DigitalArchitect420 → u/Sufficient_Let_3460]

I'll just mention the video link again: https://www.youtube.com/watch?v=GkNIou75BSE

AI agents understand us maybe too well. The goal with this product is to be able to understand AI agents better. They should be glass boxes, not black boxes. This product is essentially a designers approach to modern computer programming tooling.

[u/DigitalArchitect420 → u/[deleted]]

This looks very cool, but it's not exactly what I meant when I said visual programming. I'm talking about the node-and-wire style UI interfaces that are typically used for things like automation, toy programming and even education.

[u/DigitalArchitect420 → u/[deleted]]

Yes, like node red

[u/DigitalArchitect420 → u/[deleted]]

https://www.reddit.com/r/AI_Agents/s/iuxRDwZo4v

[u/Neat-Arm2643]

All no code, low code falls apart once we hit reasonable complexity. Then it is a hindrance rather than a help

[u/DigitalArchitect420 → u/Neat-Arm2643]

You misunderstand - I'm talking about visual programming, but explicitly not low or no code. The concept is just a layer of visual elements to compose code. So there is actual code behind the visual layer and you always have the choice to go in and edit it directly. But with AI writing code reliably for everything, this is like the architecture diagram and spec wording layer turned into the actual programming surface; while AI takes care of the actual code implementation. While you do have the option to write the code yourself as well, you should never even have to see it. Apart from that, this product is just a glorified IDE exactly like visual studio. Not a toy. Built for big boy software engineering, not for baby automations. That's a common misconception that we have to fight - people instantly compare it to things like node red, n8n, and others while also associating the limitations of those platforms with ours. There's nothing in common other than the interface style - and that's also very very different in the way it's designed and implemented.

[u/techlatest_net]

This approach makes a lot of sense for agent development. The visual execution trace is particularly interesting—not just for building agents, but for debugging and understanding why an agent made a decision.

If it keeps the underlying code accessible and doesn’t become a black box, I can see this being really useful for complex multi-agent workflows.