AI & Automation: The Thinking Behind Our Framework

For the past few months, I have been sharing pieces of our approach to AI and automation projects alongside my videos. Sometimes the topic was a question to ask before choosing a tool. Sometimes it was prioritization, human approval, or what to watch once an AI agent is in production.

Each piece addresses a practical problem. Read together, they also express a consistent philosophy: understand the work, make the next decision explicit, and keep checking whether the change is useful to the people doing that work.

With the Automathing team, we decided to make that connection visible. The Automathing AI & Automation Delivery Framework brings those ideas into one journey: Diagnose → Prioritize → Design → Pilot → Deploy → Operate.

The articles, videos and tools we have already shared still belong in that journey. This article explains the thinking that connects them. The public framework page is the practical reference, with questions, client deliverables and a decision gate for each phase.

Automathing AI & Automation Delivery Framework

Explore the six phases, with key questions, client deliverables and decision gates from diagnosis to operations.

Why bring these ideas into one framework?

A useful piece of advice can still leave an important question unanswered: what comes next?

You might identify a bottleneck without knowing whether it deserves priority. You might choose a good use case without deciding who can approve the actions an AI system proposes. You might produce a convincing prototype without knowing how to evaluate it or support the people who will use it.

The framework connects those decisions. It gives a business owner, an operations team and a technical team a shared way to discuss the same project, from the initial problem to everyday use.

Its scope is deliberately wider than building software. It includes the process, the data, the expected outcome, the responsibilities and the conditions for moving forward. The depth of the work and the deliverables are agreed for each engagement; six phases do not mean six fixed packages or a guaranteed delivery schedule.

Structure before automation: clarify what should change, how you will recognize progress, and who owns the decision to continue.

The principles behind our AI and automation approach

Three ideas connect the six phases.

Start with the work. A request for “an AI agent” is a starting point for a conversation. Which task should change? Where does information get lost? What does the person handling an exception need to know? A clearer handoff or a simpler rule may solve part of the problem before AI is needed.

Use evidence to decide what comes next. Define a baseline and an outcome before testing. Compare the result with the original situation, including review time and corrections. A technically successful demonstration is one piece of evidence, rather than the entire business case.

Keep people responsible for the outcome. Identify the process owner, the users and the people who approve consequential actions. Include their feedback while designing and piloting. Monitoring, fallback and adoption belong in the conversation from the beginning.

These ideas run through our earlier four questions before an AI project. The framework carries those questions through the rest of delivery.

AI in Business: 4 Questions to Ask Before Any AI Project

Clarify the business problem, strategic alignment and governance before choosing an AI solution.

Six phases, with a decision at each transition

A decision gate is an explicit review of whether there is enough evidence to proceed. The people responsible can also choose to revise the approach, pause or stop. It makes the reason for advancing visible to everyone involved.

1. Diagnose: understand the work before choosing the solution

Diagnosis connects a business concern to a specific process. Map the current flow, the handoffs, the recurring exceptions and the available data. Agree on the problem and identify the person accountable for improving it.

The APO Diagnostic, built around Analysis, Planning and Operations, helps establish the broader business context. A focused process review then connects that context to a measurable objective.

APO Diagnostic: Assess Your Business Health in Minutes

Understand your business through Analysis, Planning and Operations to establish the context for improvement.

Useful outputs include a current-process map, an initial measurement plan and an inventory of constraints. The decision to move forward depends on a shared understanding of the problem and the evidence still missing. If the team cannot describe the process clearly, clarifying it is useful progress.

2. Prioritize: choose a bounded first opportunity

Finding several automation opportunities does not make all of them equally valuable or feasible. Our published three-factor prioritization method considers volume, time per execution and business stakes.

That method keeps its place. The framework adds the surrounding delivery questions: can the team access the required data? What effort and ongoing cost are involved? What happens if the system makes a mistake?

Use the automation priority calculator to compare candidates, then examine feasibility and risk. Its score helps inform a choice; it is not a forecast of realized savings. The output is a selected use case, explicit assumptions and a testable hypothesis. The sponsor and process owner agree on the scope and a budget boundary before proceeding.

How to Choose What to Automate First (in 3 Factors)

Compare automation opportunities using volume, time per execution and business stakes.

3. Design: make the operating boundaries explicit

Design describes how the future process will work. It covers data flows, integrations, permissions, exception handling and the division of responsibility between people and systems.

Use rules where the expected behavior can be defined. Consider AI where interpretation is useful. Decide what the system may prepare, what it may execute and what must wait for a person.

Our article on human-in-the-loop checkpoints explores that boundary in more detail. A solution design should also state how quality will be evaluated and what happens when a dependency fails. Before the pilot begins, the process owner, technical lead and relevant data owner agree on the design, acceptance criteria and fallback.

Human-in-the-Loop: The Checkpoint Missing From Your AI Agents

Explore where human review and approval belong in an AI agent’s workflow.

4. Pilot: test a useful hypothesis on representative work

A pilot creates a bounded opportunity to learn. It needs an agreed scope, duration and budget, together with examples that resemble the work the team actually receives.

Include ordinary cases, incomplete information, duplicates and difficult exceptions. Compare quality, total effort and reviewer workload with the baseline. Ask the users whether the proposed process helps them complete the job.

The output is an evidence-based recommendation: proceed, revise or stop. The sponsor and process owner review the agreed criteria and unresolved risks. A pilot that shows why an approach should change can still provide a useful answer; expansion depends on the evidence.

5. Deploy: prepare the people as well as the system

Deployment introduces the approved process into daily work. A staged release gives the team a chance to observe it within an agreed scope before considering expansion.

Prepare access, monitoring, support, training and a tested way back to the previous process. Make sure users understand both normal operation and exceptions: when to review, when to escalate, and when to use the fallback.

The deliverables include a release plan, operating guidance and a transfer of responsibilities. Business and technical owners authorize the release once readiness, known limitations and rollback have been reviewed. Deployment is a decision about operating readiness, as well as technical completion.

6. Operate: keep measuring after the launch

Operations connect system behavior to business outcomes. Track quality, costs, incidents and actual use. Review whether people complete the work more effectively, including corrections and approval delays.

For AI agents, our article on observability in production emphasizes the complete run: actions, tool calls and recorded decisions in context. A successful technical response alone does not establish that the process achieved its purpose.

Use operational reviews to decide whether to maintain, improve, expand, suspend or retire the process. Changes to data, business rules or models may require renewed evaluation. What the team learns here feeds the next diagnosis.

AI Agent Observability: Your Agent Doesn't Crash, It Drifts

Follow complete agent runs to understand actions, tool calls and changes in behavior after launch.

A practical example: preparing a quote for human review

Consider a service business that receives quote requests by email. Staff extract the details, search for missing information and prepare a draft. This is an illustrative scenario, with no client results or measured savings claimed.

A sensible first scope could be preparing the draft while keeping pricing and sending under human control. The six phases help make that scope concrete:

For this example, an acceptance condition could require that no quote can be sent without the designated approval. A separate criterion would compare total handling effort, including review and rework, with the baseline. The team would agree on targets before testing.

If drafts arrive faster but take longer to correct, that matters. If the reviewer cannot trace a price to an approved source, that matters too. Those findings should shape the next decision rather than disappear behind a count of generated drafts.

Measure what changes for the team

The framework connects with our earlier discussion of AI and automation value: time, quality, speed and capacity all deserve attention. Choose the measures that match the problem rather than collecting every available metric.

For a first pilot, a useful measurement discussion might cover:

• Handling effort: time spent completing the task, including review and corrections.
• Cycle time: elapsed time between the request arriving and the work being completed.
• Quality: errors, missing information and exceptions that need intervention.
• Operating cost: the resources required to run and maintain the process.
• Adoption: whether the intended users actually use it, and where they work around it.

Define each measure consistently before comparing results. Time released for other work is a capacity gain; whether it becomes a cash saving depends on what the business actually changes. The framework does not guarantee ROI, and a priority score does not replace measurement.

Where the earlier resources fit

The framework gives the overall journey a shape. Earlier publications deepen specific decisions within it:

• The APO Diagnostic and four questions before an AI project help clarify context, alignment and governance.
• The prioritization method and calculator help compare opportunities.
• Human approval and observability explain complementary controls for design and operations.
• Our article on the organizational risks of AI keeps ownership, judgment and adoption in view throughout the project.

You can enter through the question that matters today and use the framework to understand what surrounds it. Someone already operating an AI workflow may need to revisit evaluation or ownership before considering a wider rollout.

The Real Risks of AI Are Not Technological

Explore how ownership, judgment and adoption shape the outcome of an AI project.

Frequently asked questions

Does this framework replace the APO Diagnostic?

No. APO provides a structured view of the business through Analysis, Planning and Operations. The delivery framework connects that context to a specific process and follows the work through prioritization, design, pilot, deployment and operations.

Does every automation project need AI?

No. The solution should fit the task. Rules, simpler workflows or an integration may be enough when the expected behavior is clear. The design phase identifies where interpretation is useful and what level of oversight is needed.

Do the six phases have to be followed only once?

No. They provide a decision structure, and their depth depends on the engagement. A pilot may reveal missing data that sends the team back to diagnosis or design. Operational changes may require another evaluation before expansion.

How do you know when a pilot is ready to deploy?

Review the criteria agreed before testing, the comparison with the baseline and the unresolved risks. Required approvals, access, monitoring, fallback and user readiness must also be addressed. A working demonstration alone is insufficient evidence.

Bring one process. Start with clarity.

If you have followed my content for a while, you will recognize the ideas behind this framework. You can now see the thread connecting them, from the first question to the decisions that continue after launch.

Explore the Automathing AI & Automation Delivery Framework for the full phase-by-phase reference. Our artificial intelligence and process automation services put the relevant expertise around that journey.

Have one process in mind? Book a consultation to discuss where the work gets stuck, who is involved and what evidence would help you choose the next useful step.