What process automation taught me about AI solution development

In late 2015, I completed my first RPA project for a customer.

It took me about a month from start to finish. At which point it was a functional, user imitating pilot, running in production. 

The concept of RPA was still brand new to everyone, there were nearly no established best practices or methodologies, and the learning happened on the job. What you learned straight away was just how meticulously detailed everything had to be. And I’ll always remember how seeing those first RPA solutions come to life bit by bit felt - amazing. 

With RPA, and the tools’ graphical programming interfaces, automation development changed. You did not have to be a programmer to get going. While some more business-minded people were able to make the leap just fine, most really couldn’t. Regardless, it was a powerful message - you don’t need deep automation or coding expertise, you just need to understand your business process. It’s no coincidence, though, that the most brilliant RPA developers still came from a technical background. 

Then, as the gold mine of FTE-heavy processes within the scope of RPA capability was starting to get exhausted, along came the concept of citizen development.

With the promise that THIS time, business users can develop their own automations for their own purposes. And how many citizen development initiatives succeeded? Not many. Then, due to a lack of real impact, and nothing noteworthy to report, the hype died down, the initiatives were quietly scrapped, and all organisations were left with effectively was the cost of licenses. But one thing was true; this time, the business users could really build their own solutions. But comparing those solutions - and their cumulative impact - to what RPA developers were building with the more advanced tools they had at their disposal… they were two worlds apart. 

Fast forward seven years to 2026, and thanks to GenAI and a heavy push of no-code AI Agent development platforms, we are finally at the point where everybody is actually getting that rush of excitement, seeing their AI Agents come to life. But just like years before, the governance of these contemporary citizen development programs is often lacking, and the initiatives are again at danger of withering away - but I think that topic warrants its own blog post altogether.

I built my first AI Agents in 2024. And the development process taught me something important.

To explain it, I’ll break it down into four learning phases. 

In the first, most simple phase, when working with LLMs for the first time, the developer puts all information, all instructions into the system and user prompts, and then keeps bloating the prompts to try and fix the issues relating to, say, the LLM hallucinating, or not following all steps consistently. The developer will quickly realise this is highly inefficient, and very frustrating.

-Why isn’t this AI thing working like everyone said it would?

In the next phase, the developer realises that actually, shortening the prompts by writing tools for the Agent makes it far more efficient. Now the solution no longer hallucinates whilst calculating (num1+ num2+num3), as all it actually does is pass those values to a tool that gives it the correct outcome as the output.

-Much better, but still not perfect!

In the third phase, the developer realises that the prompts can be shortened even further by writing the rules for handling different scenarios into their own files - knowledge files, as they are called. Imagine having thousands of customers with individual customer handling rules. An index file guides the agent towards the right knowledge file, which then contains the detailed run-down of what to do, and which tools to call.

-Finally, it’s coming together - almost there…

In the final phase, the developer reaches ascension, and understands that structure is what makes GenAI reliable, and that LLMs should be seen just as a system component, rather than anything else. Structure has been the key all along.

-All. Hail. Structure.

There are, roughly speaking, two ways of building solutions at this point. In the agent-centric way, a single large agent becomes a network of smaller ones, each of which is called to action only if necessary. This brings the token usage heavily down, and makes the solution more modular, and much easier to maintain. The other way is to create a workflow, where as many steps and operations as possible are deterministic - often written in code - with LLMs only handling the parts where they are actually needed. 

In both cases…

…the role of GenAI is a system component, not a silver bullet.

As LLMs keep evolving, the former approach will become more and more common place, and an Agent can be trusted to act as the process orchestrator. But currently, the latter is what makes many successful large-scale solutions actually tick, with zero hallucinations, zero inconsistencies, and 100% user trust.

Coming from a process automation background gave me a foundation many seemed to be lacking; to keep things structured. LLMs can do many amazing things, but you need to know what to use them for and how. A software developer will understand what parts in their work can be accelerated with GenAI. But someone without that expertise is not going to get to the same outcome because they do not know how to (T)ask the right things.
For myself, being able to utilise large language models, not only as automation system components to elevate the capabilities of process automation, but also to accelerate process rule mining, as well as automation development, review, and even testing, has made it possible to create complex process automations that would have been impossible before - with precision that would have been unachievable before, with speed that would have been unfathomable before. 

Anyone can nowadays build their own AI agents - and fast. Just remember that in business processes, errors can be very costly; precision matters. And to have that precision, you need structure. That structure often comes with a well-designed, pro-code approach.

Embrace the speed. Respect the structure.

The author is a process automation veteran with extensive experience with RPA, BPM/BOAT, IDP and GenAI - you can contact him at niko(.)lehtonen(at)(this domain).