Are you automating a workflow or redesigning work around AI?

September 25, 2026
Dana Vetan

In many organizations, AI Champions are becoming the default answer to a new enterprise question: who should build AI workflows? The answer depends on the kind of workflow work you are asking them to do.

For the last few years, organizations have been building AI Champion networks.

The logic was this: find the people who are curious about AI, give them earlier access, better training, and more room to experiment. Ask them to help colleagues use the tools, share what works, and bring practical examples back into the business.

For AI adoption, this is a strong model. AI Champions make AI feel less abstract. They help people move from “I know we have the tool” to “I can see how this helps me do my job.”

But the AI Champion role is starting to stretch as organizations move from adoption into transformation. Champions are increasingly being asked to do something much bigger:

Find workflows. Build workflows. Scale workflows. Show business impact.

That can look like a natural next step.
Sometimes it is. Sometimes it is a completely different kind of work.

And we need to know the difference because “building an AI workflow” can mean different things to different people.

One is applying AI to a defined part of the work that is already understood.
The other is redesigning an end-to-end process because AI changes what is possible.

Those are two different jobs.

If you are leading an AI transformation initiative, the critical question is: What is the unit of change? Are you trying to improve one part of an existing process? Or are you trying to redesign how the process should work end to end?

When you automate part of the process

A defined part of a process can still contain several steps and use sophisticated AI.

Take an Accounts Payable analyst.

Invoices arrive → information is extracted → entered into the finance system → exceptions are handled → missing details are followed up → a report is prepared.

There is plenty that AI can improve inside that workflow. It can extract invoice data, check fields, classify exceptions, draft follow-up messages, prepare summaries, and help the analyst move through routine work faster.

The workflow may still have several steps. It may use AI in different ways. It may save meaningful time.

But the process is understood. The organization is not questioning how procure-to-pay should work. It is improving how one part of it is performed.

This is a strong place for your AI Champions. They can work with the analyst or team, map that part of the process, configure the workflow, test it against real cases, and improve it.

For them, the core question is:

How can AI help us perform this work better?

That is workflow automation or augmentation.

When you redesign the process end to end

Now change the unit of change.

Instead of looking only at the Accounts Payable analyst's work, look at procure-to-pay as an end-to-end business process.

The process now looks like this:

Purchase request → purchase order created → goods or services delivered → invoice received → invoice matched against the PO and delivery → exceptions investigated → approvals requested → payment released.

Now several teams are involved.

  • Procurement sees one part of the process.
  • The business requester sees another.
  • Accounts Payable sees another.
  • Finance, budget owners, vendors, and sometimes Legal or Compliance become involved at different points.

The work moves across several systems. There are handoffs, waiting times, approval rules, exceptions, and decisions that often depend on tacit knowledge nobody has documented.

AI may create opportunities across all of it. But the question is whether you are trying to make the Accounts Payable analyst's work better or make procure-to-pay work differently because AI now exists.

There is opportunity at both levels. What changes is the unit of change — and with it, the kind of impact you are trying to create.

If the scope is procure-to-pay end to end, you can challenge the process itself — the sequence, handoffs, approvals, roles, systems, and decisions that connect the work.

Should this approval exist?
Should every invoice follow the same route?
Could some exceptions be resolved earlier?
Does this handoff still make sense?
If invoice processing becomes five times faster, does the next approval simply become the new bottleneck?
Which decisions should AI support, which could be automated, and which should remain human-owned?
Where should accountability sit?
Which system should be authoritative?
What happens when the PO, delivery record, invoice, and business owner disagree?

At this level, the work becomes redesign.

And once the unit of change is the end-to-end process, what you expect from an AI Champion has to change too.

End-to-end redesign is a cross-functional job

If the goal is to redesign an end-to-end process around AI, the Champion can no longer be expected to carry the work alone. The work has to be organized around the different perspectives needed to redesign the process well.

The process may have a single owner who is accountable for its performance. But that does not mean one person — or one function — has all the knowledge needed to redesign it.

Procurement understands its part of procure-to-pay.
Accounts Payable understands another.
The people doing the work know where the real exceptions, workarounds, and delays are.
Technology understands what the systems can support.
Data teams know what information exists, where it lives, and how reliable it is.
Legal, Risk, Privacy, or Compliance understand the constraints.
And the business owner understands what can actually be changed and what outcome matters.

Each sees a different part of the process.

Those perspectives also cannot simply be consulted one after another. If Procurement redesigns its part first, then hands it to Technology, then Finance, then Legal, each function can surface constraints that force earlier decisions to be reopened.

The variables interact. The relevant people need to work through them together from the start.

That is why end-to-end redesign is cross-functional work.

The solution is not finding one Champion who understands everything. It is bringing the people who understand different parts of the system together early enough to redesign it as one process.

This is where the AI Discovery Pod comes in

An AI Discovery Pod is a temporary, cross-functional team assembled around one specific AI challenge.

The Pod is temporary by design. It forms around one challenge, brings together the perspectives that challenge requires, works through the key decisions with the accountable decision-maker in the room, produces the evidence and artifacts the next team needs, and then disbands.

For one challenge, that may mean strong legal and data representation. For another, operations and employee experience may matter more.

The composition follows the problem.

Instead of creating a permanent team that tries to contain every form of expertise an AI initiative might need, the organization assembles the expertise required for the challenge in front of it.

The AI Discovery Pod is not the delivery team

The Discovery Pod exists to reduce uncertainty before serious investment.

Its job is discovery and validation: understand the challenge, redesign the process around AI, build a working AI Agent MVP, put it in front of the employees who would actually use it, and generate enough evidence to make a decision.

The AI Agent MVP is a prototype, but not in the sense of a static mock-up or a few screens showing what the future might look like.

It should behave like the redesigned process is expected to work end to end.

Using test or representative data, employees should be able to experience the new flow under realistic conditions: what information comes in, what the AI does, where a person reviews or decides, how handoffs work, what happens when something is unclear or exceptional, and what output is produced.

The point is not only to test whether the AI can generate the right answer.

It is to test whether the redesigned way of working actually works for the people inside the process.

Do employees understand what the AI is doing?
Do they know when to trust it and when to question it?
Are the handoffs clearer?
Do the new decision points make sense?
Does the redesigned process remove friction, or create new friction somewhere else?
Would people actually use it as part of their real work?

These questions are important because an AI solution can be technically impressive and still fail if the people expected to use it do not understand it, trust it, or see how it fits into their work.

That is what the prototype is there to reveal before the organization commits to production. Scale. Iterate. Stop.

The Pod may build enough to reproduce the redesigned process convincingly and test it with real employees, but it does not own production engineering, integration, deployment, or long-term operation.

Once there is evidence that the redesigned process and AI solution work technically, operationally, and for the people using them, engineering teams, product teams, IT, vendors, or other delivery structures can take over.

The Pod exists to make that decision well. Once the decision is made, the Pod disbands and its members return to their normal roles.

Some AI Champions can run Discovery Pods

For organizations that already have an AI Champion network, a selected group of Champions can be trained to run AI Discovery Pods.

In this role, they become AI Facilitators.

This is a different job from being the person with the best prompts or the strongest workflow-building skills.

Their job is to assemble the right Discovery Pod and make the collective intelligence in that Pod work.

We all know that putting six or eight smart people in a room does not automatically produce alignment. The workflow owner, technical lead, legal partner, data expert, and employee representative all arrive with different information, priorities, incentives, and language. Without structure, the conversation can easily become a sequence of presentations, a debate between functions, or a rush toward the first solution that sounds plausible.

Someone needs to design how the group moves through the problem. Someone needs to make sure the current workflow is understood before the team starts automating it. Someone needs to surface assumptions, balance voices, keep the Decider involved, and stop one function from solving only the part of the problem it can see.

That is facilitation.

The AI Facilitator does not represent one functional perspective in the Pod either. Their role is to structure how those perspectives work together — creating the conditions for the group to understand the problem, surface assumptions, work through trade-offs, and reach a decision.

Not every Champion needs to become a Facilitator. But a smaller group of people with the right facilitation skills, cross-functional credibility, and interest in process redesign can be trained to assemble and run Discovery Pods when the work requires it.

The Champion network can then develop two distinct capabilities without pretending they are the same job. Some people stay close to everyday adoption and workflow automation within a defined part of the process. A smaller group develops the capability to orchestrate cross-functional, end-to-end process redesign.

Start with what you are trying to change

The most important question is: What kind of change do you want?

At one end of the spectrum, you are improving a defined part of an existing process.
For that work, develop Champions who can spot opportunities, map how the work happens today, build and test AI workflows, and help teams put them into practice.

At the other end, you are redesigning how a process works end to end.
That is cross-functional work. A smaller group of Champions can be developed into AI Facilitators — people who know how to assemble the right Discovery Pod, bring the necessary experts and decision-makers together, guide the group through redesign, prototyping, and employee testing, and help it reach a decision.

Both capabilities matter. And both can exist inside the same Champion program.

But they are not the same job. The mistake is expecting every Champion — or any one person — to cover the whole spectrum.

Before training more people to “build AI workflows,” first understand where the opportunity sits on that axis. Are you using AI to improve part of an existing process? Or are you using AI as an opportunity to redesign how the work should happen end to end?

Once that is clear, it becomes much easier to decide which Champions to develop, who else needs to be involved, and what structure the work requires.