I Built an AI Agent in 10 Minutes. Here's Why That Matters for Process Improvement

Last week I opened up Microsoft 365 Copilot, clicked "Create Agent," and pasted a 10-item checklist for staffing request completeness. Then I tested it with an incomplete request - the kind a busy director would actually submit.

Five seconds later, the “checker” (aka the agent I had created) identified six missing items, explained what was needed for each, and suggested where to find the information. No code. No IT ticket. No weeks of development.

Ten minutes, start to finish.

Why does this matter for process improvement?

Because many Lean practitioners hear “AI agent” and picture a six-month IT project with a steering committee that requires an elaborate, rock-solid, 25-page business case before it can make even the smallest decision. That’s still true in some environments - but it’s no longer the only path. An agent is essentially a set of instructions given to AI that are saved for reuse: you write, test, and refine them at first, and then the agent simply follows the same set of instructions every time someone uses it.

The hard part - the part that actually determines whether the agent is useful - is defining what "good" looks like. What should the 10 items on the checklist be? What counts as complete versus incomplete? What tone should the agent use with a frustrated manager? Those are process improvement questions, not technology questions. And as a Lean practitioner, you already know how to answer them.

The skills that make the agent work for a team’s process are the same skills Lean practitioners teach all the time: clearly defined client outcomes, clear standards, structured thinking, and iterative improvement.

To build my agent, I identified what the AI needed to know - role, checklist, and tone - then wrote a first draft of the instructions.

It wasn’t perfect the first time. I tested and adjusted it using PDCA, just as I would with any improvement idea, until the output met my standard for a good result.

Building an agent isn't a project. It's a Tuesday afternoon.

Start tiny. Build the version of the agent that does one thing. Test it on real data - maybe files that are already closed, to reduce risk. Expand only when the small version delivers consistently and reliably. Using the iterative PDCA testing approach matters more, not less, when building an agent - because small gaps can have big consequences if the agent is launched on a large scale without being adequately tested. If your tiny agent fails, you will learn something. If the enterprise rollout fails, the whole organization will learn something.

If you have an AI instruction (aka a “prompt”) that you reuse every week - and it works well - that prompt is ready to graduate into an agent. The question isn't whether you have the technical skills. It's whether you've defined the standard clearly enough. And if you're a Lean practitioner, that's literally your bread and butter.

The hard part may be getting IT to give you permission to create an agent. But, if you do the homework well, and calculate the cost of not creating an agent, you may be able to make a compelling case that rises in IT’s queue. Plus, you can lead the way by creating “Process-Approved Agents” that follow official procedures, making IT’s job easier, not harder.

Key takeaways:

• An agent is a prompt that persists. You write it once and the AI follows the same process every time.
• In many orgs, you can do this with no code and without IT getting involved - depending on your AI platform, governance, and licensing.
• The hard part is defining what "good" looks like - which is what you already do.
• A prompt you run weekly is a signal it should graduate to an agent.
• Start small. Test with real data. Test the agent with the PDCA approach just like you would any improvement idea.