The first user session I watched was painful. Not because our product crashed — it worked fine. It was painful because the user, an operations coordinator at a growing logistics firm, spent four minutes on our onboarding screen trying to work out what "trigger" meant. We had used the word without explanation because we thought it was self-evident. It was not self-evident. It was developer vocabulary that had leaked into a product that had promised to speak plain English.
That session was about nine months ago. We have learned a lot since then, most of it by being wrong in increasingly specific ways. This is a write-up of the main lessons, including the ones that required us to rethink assumptions we had been holding since before we wrote a line of code.
Mistake 1: Assuming "no-code" and "non-technical" mean the same thing
When Priya and I started building Agenno, we talked about it as a "no-code automation tool." That framing was a mistake, not because it is inaccurate but because "no-code" has a specific connotation in the market. It suggests that the product has removed the requirement to write code, but retained the conceptual model of code — triggers, actions, conditions, loops. You just drag instead of type.
The users we were building for did not struggle with typing. They struggled with the conceptual model. They had never thought about their work in terms of triggers and actions. They thought about it in terms of what happens when, and who needs to know about it, and what system it ends up in. Their mental model for a business process is narrative, not schematic.
Once we understood that, we stopped optimising for "no code required" and started optimising for "no new mental model required." Those are different things, and the second one is harder to build.
Mistake 2: Treating plain-English input as a one-shot problem
Our original architecture treated the plain-English description as a complete specification. User types description, system interprets it, automation runs. We thought the challenge was purely in the NLP layer — make the interpretation good enough and the rest follows.
What we missed was that a process description written by someone who has never specified an automation before is almost always incomplete. Not because the user does not know the process — they know it in detail — but because they naturally omit things that are obvious to them. "When a new client is onboarded, send them the welcome pack" assumes that we know where the welcome pack is stored, what format it is in, what "onboarded" means in their system, and where to find the client's email address. None of that is in the description.
The fix was to make the interpretation step conversational rather than one-shot. Agenno now parses the description, identifies the implicit assumptions, and asks clarifying questions in plain language — not "what is the webhook endpoint for your CRM?" but "where is your client's email address stored?" That feels obvious in retrospect. It took us several months to implement it well.
Mistake 3: Building the failure mode wrong
Early versions of Agenno handled ambiguous descriptions by defaulting to a best-guess interpretation and running. The theory was that seeing the automation run incorrectly would prompt the user to refine their description. The practice was that users lost confidence in the tool when it did something unexpected, even if the description was genuinely ambiguous.
We flipped this. Agenno now pauses and asks when it encounters ambiguity rather than guessing. The tradeoff is slightly more friction upfront. The benefit is that users trust the automation once it runs, because they understand it ran on an interpretation they explicitly confirmed. We are not saying guessing is always wrong — for genuinely low-stakes outputs it can be fine — but for business processes that touch real data, a wrong guess is worse than a pause.
Mistake 4: The vocabulary problem is deeper than we thought
We audited our interface text about six months in and found nineteen instances of developer vocabulary that had no business being there. "Trigger." "Payload." "Endpoint." "Webhook." "Schema." We had used these words because they are the natural vocabulary of our engineering team and we had not been sufficiently disciplined about translating.
But the harder problem was not the words we had imported from engineering. It was the concepts that do not have good plain-English equivalents. How do you explain to a non-technical user that an automation can run once per trigger event and not retroactively on historical data? How do you explain that an automation that failed silently three weeks ago is not the same as one that never ran? These are genuinely complex ideas, and "plain English" is not a sufficient answer when the underlying concept has no everyday analogy.
Our current approach is to use concrete examples rather than abstract definitions. Instead of explaining what a "trigger" is, we say: "This automation will run the next time a new row is added to your spreadsheet." Instead of explaining what "historical data" means in this context, we say: "This will only work on new responses from now on, not on the 200 responses already in the sheet." These are longer. They are more specific to the user's situation. They are more understandable.
What finally clicked: ownership language
The thing that shifted how users related to their automations was a change in the language we used to describe what Agenno was doing. We had been describing the product in terms of what it did — "Agenno will send the email when the order ships." We shifted to describing it in terms of what the user had set up — "Your automation will send the email when the order ships."
That small change in pronoun had a measurable effect on user confidence and activation. When users felt like they had created an automation — rather than delegated to a tool — they were more likely to extend it, more likely to describe a second process, and more likely to stay engaged when something went wrong (because it was their thing to fix rather than a product failure).
We did not expect this to matter. Priya was sceptical when Tom first raised it. We ran it as a small change and the signal was clear enough that we applied it consistently across the product.
What we are still getting wrong
Error messages. We know our error messages are still too technical in a significant proportion of failure cases. When an automation fails because a downstream system returns a 422 status code, translating that into plain English requires context that we do not always have. We are working on it, and we have made progress, but it is an ongoing problem rather than a solved one.
Onboarding for people who do not know what to automate. A meaningful number of users arrive at Agenno knowing that manual processes are costing them time, but without a specific process in mind. The current onboarding assumes you have a process to describe. We have not yet built a good "where do I start?" path for users who need help identifying the right first automation before they can describe it.
Explaining why something is not possible. Occasionally a user describes a process that touches systems we do not yet integrate with, or requires logic that our current description model does not support. Being clear and honest about that — without it feeling like a dead end — is something we are still working out.
A year in, the central insight is that building for non-technical users is not primarily a technical problem. It is a translation problem — between how people naturally describe their work and how automation systems need processes to be specified. The technology has to be good enough to meet people partway. Beyond that, the gap is closed by language, not algorithms.