Most organisations are full of processes that almost nobody would design today, if they were starting from scratch.
For example, a typical supplier onboarding process might have evolved to include information arriving through multiple streams, checks carried out across different systems, spreadsheets maintained to keep track of progress, emails chasing incorrect or missing information and a only handful of people who know what to do when something falls outside the normal path. Companies rarely bite the bullet and design a better workflow from scratch once they become used to process spaghetti and it more or less works.
The people doing the work usually know where the problems are - they know which steps add value and which have gradually accreted over time; they know where work routinely gets stuck, which exceptions genuinely require judgement, and which apparently simple decisions depend on context that has never made it into the process documentation. They tend to have a pretty good idea of what should change, but.they are rarely given the tools and techniques to change it themselves. Instead the company might purchase yet another expensive SaaS platform that promises to solve the problem.
A decade ago, citizen development started to narrow that gap with the introduction of low-code and no-code tools that allowed people outside traditional IT teams to build applications, automate repetitive tasks and solve some of the problems they encountered in their everyday work. Someone who understood a process no longer necessarily had to wait for a developer to make every small improvement. But citizen development didn’t scale beyond early enthusiasts who were willing to roll their sleeves up and do the work.
Adding agentic tools to the mix can push that idea much further.
Instead of automating a step within the supplier onboarding process, we can increasingly start with the process itself:
What information actually needs to be gathered?
Which checks could an agent perform?
Where is human judgement valuable?
What should happen when information is incomplete or contradictory?
Which systems need to be updated?
What could happen automatically once a decision has been made?
Those are not really questions about building an application. They are questions about how the work should operate, and increasingly, the people who understand that work can participate directly in answering them and then rapidly experiment and iterate with the result.
This looks superficially like the next stage of citizen development, but I think something more interesting is happening. Whereas citizen development democratised the ability to build technology, agentic AI offers a tantalising opportunity to democratise the redesign of work itself.
From Building Tools to Redesigning Work
Citizen developer tools could be transformative, but in most cases the underlying operation remained recognisable. The technology was typically inserted into an existing process, while its roles, decision points, assumptions and boundaries remained largely unchanged. Permission for full transformation was neither sought, nor offered.
This is one reason why so much digital transformation has ended up digitising the organisation it inherited … we have become very good at replacing paper forms with digital forms, emails with workflow notifications and manually updated spreadsheets with dashboards, without necessarily asking whether the work still needs to happen in the same sequence or involve the same people.
Agentic AI creates an opportunity to start somewhere different because an agent is not limited to performing a single predefined action. It can interpret information, gather additional context, use tools, follow a reasoning pattern, interact with other agents or people and choose what should happen next within defined boundaries. Once those capabilities are combined, the design question shifts from which part of this process could we automate? towards how would we design this work if people and agents were both available to do it?
Consider something as commonplace as preparing a monthly management report. A traditional automation approach might automatically extract figures, populate a template or send reminders to the people responsible for submitting commentary. These are useful improvements, but the monthly reporting process remains essentially the same.
Starting from an agentic perspective opens up different possibilities. An agent could continuously watch the relevant measures, identify material changes, investigate contributing factors across different sources and assemble the evidence needed to understand what is happening. Instead of every business unit producing commentary according to a fixed monthly timetable, people might only be drawn in when there is something that requires explanation, judgement or action. The output might no longer need to be a standard report at all.
None of this necessarily requires removing people from the work. In many cases the opposite is true. By taking on the gathering, checking, coordinating and routine decision-making surrounding an activity, agents can make it possible to concentrate human involvement at the points where experience, negotiation, creativity or judgement genuinely matter.
This means that designing an agentic workflow is partly an engineering exercise, but it is mostly an exercise in understanding work. You need to know why a particular decision exists, which exceptions matter, what information can be trusted, where authority sits and what a good outcome actually looks like. The process diagram alone rarely tells you these things.
Democratisation Does Not Mean Doing It Alone
We have already seen a version of this story with citizen development, and releasing the tools to all created familiar challenges around security, maintainability, duplication and ownership. Agentic workflows raise some of the same questions, but what is being created is no longer necessarily a piece of software sitting alongside the operation. It may become part of the operation itself.
An agent that gathers information for an employee to review is relatively easy to understand. But imagine that same agent begins assessing the information against organisational criteria, deciding whether additional evidence is required, initiating follow-up actions and determining which cases need human attention. At that point, decisions about how the agent is designed become decisions about how the organisation operates.
Someone has to decide what the agent is allowed to do, what evidence it should trust, how confident it needs to be before acting and when a person must become involved. These are partly technical questions, but they are also questions of operational design, risk and accountability.
This suggests that citizen operations may need a rather different model from the most decentralised versions of citizen development. The goal is not necessarily for every employee to become an agent engineer. It is to make it much easier for the people who understand the work to participate directly in rebuilding it together, while giving them access to the engineering, architecture and organisational support needed to turn a promising experiment into something the organisation can rely on.
Building With Teams, Not For Them
The people working inside an operation know things that rarely appear in formal process documentation. They know that one particular data source is technically authoritative but frequently out of date, that a certain type of request nearly always requires additional investigation, or that an approval step exists because of a problem that occurred six years ago and nobody is quite sure whether the control is still necessary. They also know which parts of their work are frustrating for good reason and which are simply frustrating.
Traditional approaches to transformation have had to find ways of extracting this knowledge. Business analysts conduct interviews, process specialists run workshops, consultants observe teams at work and requirements are documented for technology teams to interpret. All of these approaches can work well, but every hand-off creates the possibility that some of the richness of the original understanding is lost.
The ability to build agentic workflows quickly creates the possibility of a much tighter loop between understanding and changing the work. Instead of spending weeks trying to capture every requirement before development begins, a team can start with an outcome and a real workflow, build enough to make the proposed change tangible, and discover through using it what they had failed to articulate.
This matters because much of what makes someone effective in their work is tacit. Ask an experienced employee to document every factor they consider when deciding whether something looks unusual and they may struggle to produce a complete list. Put an early agentic workflow in front of them and let it make the wrong call, and they can often tell you immediately what it failed to notice. The prototype becomes a way of surfacing expertise, with knowledge emerging through the process of building, testing, challenging and improving something together.
We are already starting to see small operational teams working intensively alongside agentic engineers to replace a real existing workflow, and I think this trend will continue.
Where to start?
The starting point is not a generic request to identify AI use cases, nor a technology team arriving with a catalogue of agents and asking where they might be deployed. Instead, the team brings a piece of work that is worth changing: perhaps it is slow, frustrating, expensive or heavily dependent on manual coordination; perhaps demand has grown beyond what the existing process can comfortably support; or perhaps it is simply an important capability that could operate fundamentally differently if intelligence were available throughout the workflow.
Together, the team and the agentic specialists can unpack what the work is trying to achieve, how it actually happens today and where judgement, information and action sit within it. The operational team is not there simply to provide requirements. Its members are actively making choices about the future operation:
where human judgement should remain,
which decisions could be delegated,
which steps might disappear entirely, and
how the redesigned workflow should respond when reality does not match the expected path.
Agentic engineers bring a different set of capabilities:
understanding how agents should interact with existing systems,
how context should be provided,
how actions can be constrained,
how performance can be evaluated
where reusable components or patterns already exist, and
how to distinguish between something that is impressive in a demonstration and something robust enough to become part of everyday operations.
Because agentic systems can increasingly be prototyped quickly, these conversations do not have to remain abstract for very long. A team can see an early version working, challenge its assumptions and change it. An exception that nobody thought to mention becomes visible. A decision that initially looked suitable for automation turns out to need human judgement. A five-stage process turns out to exist mainly because the old technology required five stages.
What the First Workflows Teach You
A supplier-risk workflow might reveal a useful pattern for combining automated investigation with human escalation. A finance workflow might establish a reliable way of giving agents controlled access to a particular system. Another project might discover that a particular form of human approval adds very little value, while a seemingly minor judgement point needs considerably more protection than expected.
Individually, these are project lessons. Captured and reused, they start becoming organisational capability.
The important question therefore becomes not only whether a lighthouse project succeeds, but what should be easier the next time?
The next team should not need to rediscover from scratch how to authenticate an agent against a common enterprise system, how to log a delegated decision or how to structure a human escalation. Proven agent patterns, evaluation methods, integrations, guardrails and design principles can gradually become reusable building blocks.
The same applies to operational knowledge. Building a workflow can expose decision rules, exceptions and reasoning patterns that previously existed only in the experience of individual employees. Once surfaced, these can be tested, refined and made available beyond the original process.
A lighthouse that saves several thousand hours is useful. A lighthouse that also makes the next ten workflows faster and safer to redesign has begun to create a compounding capability.
From Transformation Programmes to Transformation Capability
For much of the last few decades, transformation has been organised as something separate from everyday operations. A programme is established, opportunities are identified, processes are mapped, new technology is implemented and employees are supported through the resulting change. Even when operational teams are deeply involved, there is usually still a distinction between the people running the organisation and the machinery responsible for changing it.
There have been good reasons for this separation. Changing enterprise systems has historically been expensive, technically difficult and risky. If altering a workflow requires a major software implementation, specialist development resources and months of testing, it makes sense to concentrate that capability and carefully prioritise where it is used.
If a small team can work with agentic specialists to rebuild a meaningful workflow in weeks rather than waiting for a multi-year transformation programme, the economics of organisational change start to shift, so that improvements that were previously too small, too local or too awkward to justify a conventional technology project become viable. More importantly, teams can become involved in transformation as an ongoing part of operating the business rather than something that happens periodically when a programme arrives.
This does not remove the need for enterprise architecture, transformation expertise or central technology teams. In fact, distributed redesign probably makes some of those capabilities more important. Someone still needs to create common infrastructure, establish boundaries, identify duplication and make sure hundreds of local improvements do not produce an organisation that is impossible to operate as a whole.
But the role of central transformation can begin to change. Instead of owning every change, it can increasingly enable the organisation to change itself: providing specialist expertise, reusable infrastructure, proven patterns and enough governance to allow teams to experiment safely.
From Citizen Developers to Citizen Operators
The opportunity is no longer only to give more people the ability to create technology around their work. It is to give the people who understand the work a much more direct role in deciding how it should operate.
A citizen developer sees a frustrating part of a process and asks whether they could build something to make it easier. A citizen operator can begin with the outcome and ask why the process needs to work this way at all. Which activities still need to exist? What could an agent take responsibility for? Where does human expertise make the biggest difference? What would we build if we were not constrained by the assumptions embedded in the current system?
Not everyone will want to do this, and not every workflow should be locally redesigned. Citizen operations should not become another mandate that expects employees to add amateur process engineering and AI development to their existing jobs.
But organisations contain thousands of people who already notice where work could be better. Until now, there has often been a considerable distance between seeing those possibilities and having the means to act on them. Agentic AI is beginning to close that distance.
The most interesting question may therefore be less about how many people we can teach to build agents, and more about what happens when the people closest to the work gain a meaningful role in rebuilding it.
If the people closest to your most frustrating workflows could now help redesign them, what would you want them to tackle first?