Natural language processing in software tools is not a new idea. Search engines have done it for years. CRMs have had "smart search" features that understand intent rather than exact keywords. Business intelligence tools let you type questions like "show me revenue by region last quarter" and get a chart back. None of this is novel.
What Agenno does is different in one specific way, and it is worth being precise about what that difference is, because the marketing language around "plain-English" and "conversational" interfaces has become so loose as to be nearly meaningless. So: here is what we mean when we say plain-English automation, and here is what actually happens technically when you describe a process to Agenno.
What most tools mean by "natural language"
In most workflow tools that advertise natural language features, the language is a supplement to a visual interface, not a replacement for it. You might type a description and the tool generates a starting-point flowchart. You then edit that flowchart — moving nodes, configuring triggers, setting conditions — before the automation is complete. The natural language got you to a starting point. The configuration still happens in the visual editor.
This is a reasonable design choice. Flowchart editors are a well-understood paradigm for a reason: they make the structure of a process legible, they handle branching logic cleanly, and they give users a visual artifact they can inspect and modify. We are not dismissing this model.
But for the users we are building for — operations managers and business analysts who think about their processes in terms of what should happen, not in terms of how a system should model those processes — the flowchart is a translation step they should not have to do. Our claim, which is what "plain-English as primary interface" means, is that a well-described process in natural language contains enough information to produce a working automation without the user ever touching a node editor.
How Agenno parses a process description
When you submit a description, Agenno's parsing layer does several things in sequence. Understanding this is useful not because you need to know it to use the product, but because it helps you write better descriptions and troubleshoot when something is not working as expected.
The first step is trigger identification. Every automation needs a starting condition — something that happens that causes the automation to run. In a description like "when a new row is added to our Leads sheet," the trigger is a spreadsheet row addition event. Agenno identifies this and maps it to the correct event in the Google Sheets API. In "when a customer submits the contact form on our website," the trigger is a form submission event, which in practice usually means a webhook from your form provider or a polling check on your CMS.
The second step is action sequencing. After the trigger, what should happen? Actions are usually verifiable in the description because they contain verbs: "send an email," "add a row," "post a message," "create a record." Agenno identifies the action verbs, maps them to the appropriate integration capabilities, and sequences them in the order described.
The third step is data mapping — figuring out what information from the trigger event needs to be passed to each action, and in what form. This is where ambiguity most commonly arises. If you say "send the customer an email with their order details," the system needs to know: which email field from the trigger event contains the customer's address? What constitutes "order details"? These ambiguities are resolved through clarifying questions rather than assumptions, which is why descriptions that are more specific tend to produce automations that require less back-and-forth to get right.
What "good" descriptions look like
We have noticed a pattern in how people write their first automation descriptions. Most people start too high-level: "When we get a new lead, follow up with them." That description contains a trigger (new lead) and an intent (follow up) but does not contain enough to produce a working automation. Follow up how? Via email? A Slack message? To whom? What does the follow-up say?
The right level of specificity is what you would tell a new hire who was doing this process manually for the first time. "When a new row appears in the Leads tab of our Pipedrive Leads spreadsheet, send an email from [email protected] to the email address in column B with the subject line 'Thank you for getting in touch' and body text that includes the person's first name from column A."
That is a complete description. It contains the trigger, the source of the trigger data (specific sheet, specific columns), the action, the actor (which email address to send from), and the content parameters. An automation built from that description will work on first run, assuming the sheet and email connection are active.
This is not a criticism of people who write high-level descriptions first — it is a natural starting point. The important thing is knowing that the iteration path is "add more specificity" rather than "switch to a flowchart editor." Every question Agenno asks when a description is ambiguous is a prompt to add specificity. The answers to those questions become part of the description, which is how the system learns what you intended.
The limits of natural language as interface
We want to be honest about what this approach does not handle well. Complex branching logic — automations that have multiple different paths depending on condition X, Y, or Z — is harder to describe in prose than to model visually. "If the order value is over £500 and the customer is in the UK, send the premium shipping confirmation; if it is under £500, send the standard confirmation; and if the customer is outside the UK, flag it for manual review" is a clear description but a relatively complex one. Agenno handles this, but it requires more clarification dialogue to get right than a simple linear flow.
Very long, multi-step automations with five or more actions also benefit from being broken into smaller, separate automations that chain together, rather than described as a single long flow. This is actually good automation practice regardless of the tool you are using — smaller, individually-tested automations are more maintainable and easier to debug — but it does mean that the "describe your whole process in one go" promise has a natural ceiling.
What plain-English as a primary interface genuinely solves is the access and ownership problem. When the automation is defined by a description rather than a flowchart configuration, the person who owns the business process owns the automation. They can read it, modify it, explain it to someone else. That is a different relationship with automation than most ops teams currently have, and we think it is the more valuable one — not because prose is technically superior to a flowchart, but because it keeps the process understandable to the people who are responsible for it.
What this means for how you should think about building automations
The practical implication is that the skill you are developing when you build automations in Agenno is not a tool skill — it is a process description skill. Getting good at describing processes precisely enough to produce working automations is also getting good at understanding your own processes. Many ops teams find that the act of writing out a process description surfaces assumptions and ambiguities in the process itself that were invisible when the process was just something a person was doing from memory.
We built around plain English because we think most ops teams already have the knowledge they need to automate their processes. What they have lacked is an interface that takes that knowledge seriously as the starting point, rather than requiring a translation into a technical vocabulary first.