Agent Builder: Business Enabler?

Agent Builder: Business Enabler?

You may have noticed the recent launch of OpenAI's agent builder—a no-code visual interface to build agentic workflows.

Well, apart from the fact they stole the name from my very own agent exploration tool (so imaginative, I'll start filing the cease and desist order very soon), it's the latest in a slew of drag-and-drop platforms that allow businesses to connect their workforces to an AI chat-based system to automate workflows.

I find this solution a bit strange, a bit of an abomination—a Frankenstein. To help unpack why, here's a glossary of terms to try and open up this argument.

Glossary

• Agent: An AI system that can take actions autonomously toward achieving a goal, rather than just responding to single prompts
• Builder: A tool or platform for creating something (in this case, AI agents) without writing code from scratch
• No-Code: Development platforms that allow users to create applications through visual interfaces rather than traditional programming, often aimed at non-technical users
• Visual Interface: A graphical way of interacting with software using drag-and-drop elements instead of text commands
• UI: User Interface—the space where humans and computers interact
• Chat-based: Systems that use conversational messaging as the primary interaction method
• Agentic: Relating to agents; systems that exhibit agency and can act independently, using tools and their environment to respond to their inputs
• Drag and Drop: A UI paradigm where you move visual elements around with your cursor to build functionality
• Automate: Make processes run automatically without human intervention
• Workflow: A sequence of tasks or steps that complete a business process
• Cease & Desist: A legal order to stop allegedly illegal activity

Why This Feels Wrong

So in context of this offering from OpenAI, I ask, why?

It's Not Actually "No-Code"

OpenAI's agent builder is definitely not aimed at your non-developer. You need development skills to integrate it into a chat interface or other system. That does not make it no-code.

Chat Isn't Always the Answer

And why oh why is the interface of choice, chat? Whilst it enables engagement and is great for testing prompts and getting answers and using as a code interface—is this the most efficient way to get real business stuff done?

Visual Abstractions Create New Problems

The workflow builder actually tries to abstract the complexity of the written word into a user interface to simplify the 'control' of the behaviour of the agent. 

This seems nonsensical. Not only is that creating a layer between the user and the LLM, it's restricting the usefulness of the instruction set given to the LLM by constraining it with the limited scope of the workflow builder component. 

A benefit of using natural language to converse with LLMs is by it’s very nature more accessible to many more people than just developers.

Abstraction was always an issue for no-code visual builder tools that smoothed away the complexities of the code, but removed the flexibility and built in opinionated ideals about how things should work.

The Workflow vs Agent

A workflow by definition is a sequence of tasks to perform a job. 

An agent is a system that can take actions by itself.

If agents can sequence steps themselves based on the situation, why are we forcing them into rigid workflow boxes? 

Isn’t it just creating the limitations of the old system with expensive new technology.

The Determinism Problem

Businesses of course do need certainty. They need software that behaves consistently, produces predictable outputs, and follows defined processes—especially in regulated industries or when dealing with critical operations.

LLMs are fundamentally non-deterministic and probabilistic. The same prompt can produce different outputs. Agent behaviours can vary. This unpredictability is precisely what makes businesses uncomfortable with fully autonomous AI systems.

So perhaps the workflow builder isn't just limiting agents—it's just trying to impose structure and predictability onto inherently unpredictable technology. It's an attempt to make LLMs behave more like traditional software.

This is a real problem that needs solving. But is a visual drag-and-drop workflow builder the right answer? Or are we just creating the illusion of control while introducing new complexity?

To Be Fair: Some Use Cases Make Sense

I can see that this is a great way to get to prototyping tools much more quickly. You can build the 'workflow' and extract the code and put it into your codebase of a product. This might make your team quicker and it might make things more consistent with software development patterns.

I could imagine that a business user could use the agent builder to recreate their activities into a 'workflow' and test it, before potentially handing it over to a developer to integrate.

The Problem is in the Solution

So we've established what agent builder is and why it's problematic. But this points to a bigger issue.

I can't help thinking that we're still not making it easy for business leaders and users to understand how and where and indeed why they should augment their business with AI.

Whilst this is all technically sound, is it what we really should be promoting to engage businesses with AI? Are we solving the right problems, or just creating shinier hammers to hit the same nails?

Do we really need another no-code workflow tool? Are chat interfaces really the most productive way to get AI to do our tasks for us?

No, I don't think so.

Start with the Problem, Not the Tool

No business should be investing in AI—or any capability—into their organisation without understanding:

1. What is the problem you're trying to solve?
2. Who is feeling the problem and why?
3. If the problem was solved, would it matter?
4. If so, by how much. What impact are you making?

If you can answer these questions, then you can move on to figuring out the best way to solve the problem, maybe even with a tool like OpenAI's agent builder.

But what if you don't or can't answer these questions?

Problem-Splaining (Or: How to Actually Find What Needs Fixing)

If you're observant and regularly listen to your customers and users, you're already on to a great start.

If you're not, this is a great way to understand the areas around your business that could be slowing you down, causing frustration, losing you money or letting customers go.

NB: To be clear, when we say problem, we also mean unfulfilled need, opportunity, risk or any other challenge somebody may face that your business could be able to solve.

So here are some steps to take that might help you identify real problems worth solving:

1. Map a part of your business as a step-by-step workflow of activities, tasks and decisions. Perhaps this is an area of your business that you have a feeling something might be wrong. Keep it small to keep the problem area contained and manageable.
2. Overlay onto that map the people that do the work or receive the benefit of the work that gets carried out. Maybe it's a data entry clerk or lab researcher doing the activity and it's the general manager, lead scientist or customer that sees the outcome of that activity.
3. Now you know who does the work and who receives it. Talk to them about their role: what works, what doesn't, their frustrations, and their ideas for improvement.
4. With this you now have the ability to augment your map with potential areas of pain you may or may not have known existed. With this you have a visualisation of what problems exist within the workflow.
5. You now have a view of your problem space.
6. Next, try to quantify the cost or impact of those problems. Does a specific problem in the workflow slow you down by hours or days? Does it leave your customers waiting, unsure what's going on? Does the delay or messy uncontrolled process cost you way more than it should? Record these on the map.
7. Further, there might be reputational or regulation or trust problems that exist. These may well be issues that cost you more than money alone. Capture these too.
8. Now you can make decisions on which of these problems are the highest priority to fix.
9. Choose one, understand it well and find ways to solve the problem through simple, low-cost experimentation.

These nine steps work regardless of whether AI ends up being part of the solution. In fact, you'll often find that the real solution is simpler than you expected.

Once you've prioritised your problems, here's where tools like agent builder might actually help—but only as part of a broader experimentation approach:

Experimentation can happen in many forms—by people, through non-technical capabilities, by stitching together existing tools and processes, mocking up tools that work but not entirely, writing new software or using artificial intelligence, machine learning or large language models.

The trick is to learn how these solve a problem for your user or customer. Or, indeed don't, and move on to the next potential solution through a new experiment.

The point is, all these techniques are tried and tested. They are designed to seek out true problems to ensure a business can identify them and solve them as quickly, efficiently and cost effectively as possible. 

And were always true, even before AI and its friends became so prominent in our lives.

The Annoying Reality

The reality is that most businesses don't have an "I need a no-code AI agent builder" problem. 

They don't even have an "I need a [insert new solution here]" problem. They have problems like:

• Customer support takes too long to respond
• Sales teams spend hours on manual data entry
• Onboarding new employees is inconsistent
• Report generation eats up analyst time

These are real problems that might benefit from AI—but the solution might not be a visual workflow builder. 

It might be a simple automation script. It might be better process documentation. It might be hiring another person. It might be better communication. Just as solutions are not where you should look first, not all problems are solved by technical solutions.

Tools Are Not Strategies

The proliferation of these platforms reveals something troubling: we're still confusing solutions as the starting point. We're still letting the technology dictate the approach rather than letting the problem guide us to the right tool.

OpenAI's agent builder might be brilliant. It might enable amazing things. But if you're adopting it because it exists, not because you've identified a specific problem it solves better than alternatives, you're doing it backwards.

Start with the problem. Always start with the problem.

Because no amount of visual drag-and-drop interfaces will fix a solution in search of a problem. And that's exactly what most of these tools are.

So, Is Agent Builder a Business Enabler?

The answer is: it depends entirely on what you're trying to enable.

If you've identified a real problem, mapped your workflows, talked to your users, quantified the impact, and determined that rapid prototyping of agent-based automation would help you experiment with solutions—then yes, agent builder could be a useful tool in your toolkit.

If you're adopting it because it's new, because competitors are talking about AI, or because you think you should be doing something with agents—then no, it's not an enabler. It's a distraction wrapped in the illusion of progress.

The proliferation of platforms like this just deepens the divide: we're still starting with solutions and working backwards to find problems they might solve. We're still letting technology dictate the approach rather than letting actual business problems guide us to the right tools.

Tools don't enable businesses. Understanding problems enables businesses. Tools just help you implement solutions faster—but only if you know what you're solving for.

So before you spin up another no-code workflow builder or drag-and-drop agent interface, ask yourself: what problem am I actually trying to solve? Who's suffering from it? How will I know if I've fixed it?

Answer those questions first. Then choose your tools, AI or otherwise. Not the other way around.

‍