We map the real workflow and close the context gaps between its steps. Then we create the instructions and artifacts that people and AI need to get consistent results.
People carry part of the process in their heads, and documents hold only fragments of it. When AI repeats that process, the missing context turns into guesswork. The same request can get a different answer tomorrow.
A goal-oriented reference process gives people and AI enough structure to work consistently, with room for legitimate variations.
This is process documentation that is used in the work itself, on every run of the process. Together, these assets carry its context, instructions and quality criteria.
The process goal, scope, phases, roles, inputs, outputs, decisions, variants, exceptions and quality gates.
Step-by-step procedures for the routine tasks in the process, with the inputs and sources of each step stated.
Intake forms, output formats, decision records and checklists with embedded prompts and context parameters.
Clear task-level guidance for people, assistants and future agents.
What context each step needs, where it comes from and how it moves on without getting lost.
Walkthroughs and working demonstrations that test the redesigned process with the people who use it.
Results stop depending on who happens to be doing the work, because every step has defined inputs, a clear owner and a checkpoint. Automation then runs on that structure instead of on guesswork. Agents inherit a process that is already correct, and quality holds as volume grows.
AI Process Reengineering is business process reengineering for AI. It fits a priority workflow that is worth improving but isn't yet clear, consistent or complete enough for AI to support it reliably.
When the workflow isn't written down, every person and every AI run has to work it out again.
Once the process carries its goals and context, its instructions and its quality criteria, the business gets process improvement now and automation step by step later.
We start from how the process really runs, not from what an old document says.
Map the real work with the people who do it. This process mapping covers handoffs, decisions, information, exceptions, hidden expertise and what counts as good quality.
Define the shared structure and the legitimate variants that different outcomes and phases of work need.
Write the SOPs, templates, embedded prompts, instructions and checks, then test them in real use.
Cut the coordination, corrections and rework you can avoid.
Complete information moves through the process, with fewer delays and fewer repeated questions.
Cases and teams work to the same goals, context and quality criteria.
Assistants and agents get a process they can follow without making up the missing logic.
Process mapping records how a piece of work actually runs: the steps, who performs each one, the inputs and outputs, the decisions, the handoffs and the exceptions. A conventional map stops there. For AI execution, it also has to capture what usually stays invisible. When a person moves from one step to the next, most of the context travels in their head, and the documents carry only a piece of it. Because nobody checks whether the next document can actually be produced from the previous one, information gets lost between steps. Those gaps matter because AI that repeats the process has to invent the missing piece, and the result varies from day to day. We map the real process together with the team that runs it, and we mark the control points: which functions and information are sensitive and who controls them.
Business process reengineering means redesigning a process from its goal, for consistent execution by people now and by AI later. For AI, the work is making the implicit explicit. That covers the goal of the process, its roles and flow, and its key decisions and control points. It also covers the inputs, outputs and artifacts, the instructions and reference materials and the legitimate variations by outcome and by phase. It matters because a process that exists only as habit gives AI nothing to follow, and a process that exists on paper but was never designed for AI runs badly on it. The guiding question is which work people carry today could be controlled at a new level or carried by AI, rather than which features to add. The result is written down as a Process Definition Document that both people and AI can execute.
Process improvement optimizes inside the existing design: fewer steps, less waiting, fewer errors. Reengineering changes the design: which work needs to happen, who or what performs it and where the information must be when it is needed. AI needs the second kind. Work moves from people to AI, and the context people used to supply themselves becomes visible. Adding AI features on top of a partial solution only makes it more complex. At the same time, we usually work with established companies whose managers don't want revolutions in high-stakes areas. We redesign around what already works: we automate what works and keep the good parts. Improvement methods and their measurements apply afterwards, inside the new structure.
For each process, we write the standard operating procedures (SOPs) for its routine tasks, define the artifacts the process produces, build a template for each artifact and write worker instructions for the typical operations. The instructions live inside the templates. A template carries the steps, the prompts for the steps that use AI and the context parameters where a person enters their input. In effect, the template is the instruction. This matters because a person reads a narrative SOP once, while an executable template is used on every run. The same artifact later becomes the specification an assistant or an agent follows. Here is one such instruction, for a document. Analyze the available information against the template, ask the questions needed to write it well, one at a time, then draft chapter by chapter when the material is uncertain.
Yes, where every step is recorded in a system. There, process mining and discovery tools help analyze the existing flow and point to automation opportunities. Knowledge-intensive processes mostly run through email, documents, meetings and individual judgment, and their logs show only fragments. The usual situation is stale or missing documents next to working systems. We reconstruct the process from the people and the systems. We run structured interviews, which an AI interviewer can hold by chat or voice and turn into documents, and we reverse engineer systems and code when that is where the knowledge lives. Each company breaks its work down differently, and the mapping shows what has been skipped.
No. We go step by step and area by area, starting with one priority workflow that deserves the effort but isn't yet clear or consistent enough for reliable AI execution. In our own company, different areas sit at different levels at the same time. Some processes are defined but not yet built, some run with assistants and some with agents. The first workflow matters more than its size suggests, because the structure of its SOPs, templates and quality gates is reused. The following processes then take less effort to define. The redesigned process is run by hand several times, cleaned up and confirmed to give a consistent result before anything is automated.
First, people run the redesigned process with AI support, following the instructions and copying the prompts. This validates the process and shows what is still unclear. Once the result is consistent, the instructions are wrapped into skills and assistants. You no longer follow the instructions yourself: the assistant asks for your inputs and follows them. When the main flow and the edge cases are proven, turning a skill or an assistant into an agent is largely a repackaging step with no new code. The order matters because the long part is defining the process, the instructions and the artifacts. Once that's done, automation follows the structure.
A goal-oriented reference process is defined around the result it must produce rather than around a fixed sequence of steps. It states the goal, the structure, the information flow, the decisions and the quality gates, and it allows explicit variations by outcome and by phase. We define processes this way because AI is not procedural. Making it follow steps one, two, three exactly is close to impossible, since it adapts to context and varies. Driving it by explicit goals gives repeatable, predictable results, while a rigid procedure breaks on the first exception. The structure is a reference, not a cookie cutter: a prototype, a release and a fix share the same frame and legitimately skip or add steps. Goal orientation and standardization predate AI in our practice. With AI, they became necessary.
They find out how the work really runs, see where time, quality and context get lost and redesign the process around its goal. When AI will run part of the process, there's more to write down: each step needs its inputs, instructions and quality criteria. A person can fill a gap from experience, and an AI run can't. As business process reengineering consultants who prepare processes for AI, we map the real workflow with the people who run it and close the context gaps between steps. Then we write the execution assets: SOPs, templates, checklists and the instructions that people and AI follow. You can improve execution now and automate it step by step later.
Bring us a workflow where context gets lost, quality varies or automation keeps breaking. We'll show you what has to be made explicit before AI can run it reliably.