Before we started building Agenno, Priya and I spent about three months talking to operations managers. Not product discovery in the formal sense — just conversations. We wanted to understand what they actually thought about the automation tools that existed, and whether "ops teams struggle with no-code tools" was a real phenomenon or a story we were telling ourselves to justify building something.
We talked to roughly forty people. Operations managers, business analysts, office managers who had grown into ops roles, a few executive assistants who were effectively running operations for small companies without the title. The picture that came back was consistent. And it was not quite the story we expected.
The actual complaint is not complexity
We went in expecting to hear "these tools are too complicated." That is not what people said. What they said was closer to: "I got it to work once, and then I could not touch it again." Or: "I tried it, got stuck on one specific thing, and just went back to doing it manually."
There is a difference between a tool being too complex and a tool being fragile at the edges. The existing workflow builders — and we are not saying they are bad products, they clearly work for a large number of people — are built around a visual metaphor that makes sense to developers and technically-minded users who can model processes as flowcharts. The node-and-connection editor is genuinely powerful. For the ops managers we spoke to, the problem was not the power. It was that the interface made them feel like they were configuring software rather than describing a business process.
One person put it particularly well: "I can describe what I want in thirty seconds. Making the tool understand what I want takes three hours, and it still might not work." That gap — between knowing what you want and being able to express it in the tool's language — is the actual design problem.
Where people got stuck, specifically
When we asked people to describe the specific moment they gave up, the answers clustered into a few patterns.
The first was authentication. OAuth flows, API keys, webhook URLs — these are concepts that have no analog in how operations people think about their tools. They know they use Slack. They know they use Google Sheets. The idea that "connecting" these involves understanding what an OAuth scope is, or finding a webhook URL in a settings menu four clicks deep, is genuinely alienating. Not because people are not smart enough — these are professionals who manage complex business processes daily — but because this technical plumbing has nothing to do with the thing they are trying to accomplish.
The second sticking point was debugging. When a workflow broke, most people had no way to understand why. The error messages in most tools are written for people who understand what a 400 Bad Request means. For someone who is not a developer, "Execution failed: TypeError: Cannot read properties of undefined" is meaningless. Several people told us they ended up just deleting the workflow and rebuilding it, hoping the problem would not recur. This is not a good relationship with your automation infrastructure.
The third was maintenance. Workflows built in node editors are hard to read back three months later. Even the person who built it often cannot remember which branch does what. When apps update their APIs — as they do constantly — something quietly breaks, and it can be weeks before anyone notices.
The "no-code" label is part of the problem
Something that came up several times in our conversations was frustration with the marketing. "They said no-code but you still need to understand what a webhook is." That sentiment — the feeling of being mis-sold on the accessibility promise — is its own distinct source of frustration, separate from the tool itself.
We are not saying "no-code" tools are dishonest. They genuinely require no code in the programming sense. But they do require a conceptual vocabulary that many ops practitioners simply do not have and should not need to acquire. The abstraction level is wrong for the audience. The tools abstracted away writing code, but they left intact the mental models of software development: triggers, actions, conditionals, data schemas, API authentication.
What ops people actually have is a different vocabulary: process descriptions, business logic in plain language, a clear sense of what should happen when. Agenno's starting premise is that this vocabulary is the right one to build around, not an obstacle to overcome with training material.
What we are doing differently
The interface design choice we made early was to make the plain-English description the primary, not secondary, interface. Not a helper box that supplements a flowchart. Not a natural language query that generates a starting-point flow you then edit visually. The description is the automation. You do not need to touch a node editor to build something that works.
This has costs. There are things that are harder to express in prose than in a graph. Multi-path branching logic, for instance, is genuinely more visual by nature. We have spent a lot of time thinking about how to handle that in a way that still feels like writing rather than configuring. The answer we have landed on — for now — is to let people describe branching in conversational if-then terms and have the system clarify with targeted questions when the branch logic needs more precision. It is not perfect. But it is closer to how people actually think about their processes than a branch node in a flowchart editor.
We also invested heavily in making the authentication setup a one-time thing that does not require understanding what OAuth is. You connect your apps once. After that, describing an automation that uses those apps does not surface any authentication complexity. The system handles scope management as it becomes relevant, surfacing only what it needs and explaining it in plain terms when it does.
The thing we are still figuring out
The honest part: debugging. When an automation misbehaves, communicating why in a way that is actually useful to a non-technical user is hard. We have made progress on run logs — showing what happened, in what order, with what data — but the gap between "here is what the system did" and "here is why that was different from what you intended" is genuinely difficult. Bridging it requires understanding user intent well enough to compare it to actual execution, and we are not fully there yet.
What we know from those early conversations is that this is the right problem to be working on. Every ops manager who gave up on automation gave up at exactly this point: something went wrong, they could not understand why, and the path of least resistance was to stop relying on the automation. Fixing that is not a feature — it is the thing that determines whether automation is trustworthy enough to use for processes that actually matter.
If you are an ops manager who has bounced off workflow tools before and is curious whether the plain-English approach actually works differently in practice, we would like you to try it. Not because we think you will find it perfect — we know there are rough edges — but because the feedback from people who have been burned before is the most useful signal we can get right now.