Try a small experiment. Pick a piece of work that took too long last week. An invoice that could not be matched. A new starter who arrived without the right access. A customer request that came back for the third time. Now follow it from beginning to end.
My guess is that the interesting part is not the task itself. It is the waiting in between. Someone needs a reference from another system. Someone else has to interpret a rule. The person with the answer is not the person with permission to act.
This is the part of AI implementation I keep coming back to. We can make a task look remarkably clever in a demo and still leave the actual process almost unchanged.
Start at the finish line
Before choosing an agent, finish this sentence: the work is done when… Not when a summary has been generated. Not when a ticket has been categorized. When the business outcome has actually happened.
For an invoice exception, that might mean the discrepancy is explained, the right person has approved the correction and the record is ready for payment. That single outcome touches documents, purchasing, finance and an approval policy. A faster summary helps. It is not the whole job.
Once the finish line is clear, the design becomes more useful. Which information is needed? Which system is authoritative? What can be automated safely? Where does a person need to decide? Those questions tell you more than a list of departments ever will.
Keep the boundaries that protect people
Working across a process does not mean giving an agent unlimited access. Quite the opposite. The broader the workflow, the more precisely we need to define its permissions.
An agent may be allowed to read a purchase order, prepare an explanation and request approval. That does not mean it should be allowed to change bank details or release a payment. Connecting the work and removing control are very different things.
The same applies to people. A clear handoff is not a failure of automation. A person receiving the right evidence, with a specific decision to make, is a much better outcome than a confident system guessing its way through an exception.
Build one useful loop
I would rather see one complete, well-owned workflow than a long list of disconnected assistants. Start small enough to understand the exceptions. Put engineers beside the people doing the work. Test the ordinary day and the awkward day. Then measure the whole journey.
A useful review asks whether the work is completed sooner, whether quality holds up and whether another team has quietly inherited the effort. If the answer is good, expand from there. Reuse the connections and controls instead of starting again.
The organization can keep its boxes. The implementation needs to follow the work between them. That is where a lot of the opportunity lives.
Sources & context
An original Pedalion perspective on the workflow-first discussion. The examples and wording here are not customer claims.
