Where to Split an AI Workflow: Use Human and Waiting Boundaries

A long process can look like one workflow on a whiteboard and still be a poor fit for one agent task. The trouble usually appears at the moments the diagram hides: someone must approve a decision, a client must reply, a payment must clear, or a judgment call changes what happens next.

Those moments are useful boundaries. Split there, and each task becomes easier to explain, test, permit, and repair. Keep one chain, and a late reply or ambiguous decision can leave the run stuck.

Start with the interruptions

Most process maps begin by listing actions in order. For an agent workflow, first mark where continuity breaks:

1. Human handoff: A person reviews, approves, edits, signs, or makes a judgment.
2. Genuine wait: The process depends on a reply, elapsed time, payment, file, meeting, or system event.
3. Permission change: The next action needs different access, especially when moving from reading to writing or sending.
4. Meaningful state change: The work moves from preparation to delivery, or from delivery to follow-up.

A boundary does not automatically require another agent. It suggests that the work on either side should be tested separately.

Map the boundaries in one pass

Write every step in order without improving it yet. Label each step:

• Continue: The next action uses the same information and permissions.
• Human: A person must decide or act.
• Wait: Time or an outside event controls what happens next.
• Permission: The next action changes what the system may do.
• Stop: The process should end or move to review.

Draw a line before and after every Human, Wait, Permission, or Stop label. Combine adjacent Continue steps only when they share one clear purpose.

Name each unit with a verb and an object, such as “prepare welcome packet.” “Handle onboarding” is too broad to test clearly.

Give every unit a contract

For each unit, define four things:

Field	Question to answer
Inputs	Which records, files, messages, and status values must exist before this starts?
Outputs	What must be created or changed, and what proves completion?
Owner	Which person or agent is responsible for this unit?
Permissions	What may it read, create, update, or send? What is forbidden?

Also record the trigger that starts the unit and the stop conditions that prevent it from continuing. This turns a vague handoff into an inspectable agreement.

A familiar client-onboarding example

Consider the process after a new client signs:

1. Confirm the agreement and account details.
2. Prepare and send a welcome message and intake form.
3. Wait for the client to respond.
4. Check the response for missing information.
5. Ask for clarification when needed.
6. Let an account lead approve an unusual scope request.
7. Create the internal brief and kickoff agenda.
8. Wait for the scheduled kickoff.
9. Summarize decisions and assign next actions.

This is not one uninterrupted task. A practical map could produce five units:

• validate the signed client record;
• prepare and send onboarding materials;
• review returned information and list gaps;
• prepare the internal brief after human approval where required;
• recap the kickoff and record agreed actions.

The client reply and kickoff are genuine waits. The unusual scope request is a judgment boundary. Sending a message may require narrower permissions than reading intake data.

For “review returned information,” inputs might be the form and agreement. The output could list complete fields, gaps, and contradictions. An agent could read the client folder and draft a clarification, but not send it. A person owns the send decision if it could alter scope or make a commitment.

That contract is much easier to test than “onboard the client.”

Make every unit work alone

Do not begin with orchestration. Run each unit independently using known inputs and inspect its output.

A useful small test is one low-risk onboarding case with identifying details protected, one missing field, and an ordinary reply. Run only the “review returned information” unit. Check whether it:

• identifies the missing field;
• avoids inventing an answer;
• separates a factual gap from a judgment call;
• produces the expected output format;
• stops before sending anything.

Then try one complete case and one ambiguous case. Fix the unit before testing the next one.

Only after the units work alone should orchestration connect them. The flow should pass explicit outputs forward, preserve status, and pause at marked boundaries. It should not guess that a wait is over or silently cross an approval point.

Use schedules for time-based triggers

A schedule is useful when elapsed time should start a check, such as reviewing incomplete onboarding records each weekday morning. It is not a substitute for an event. If the process should continue when a client replies, use that reply or a verified status change as the trigger.

Every scheduled check needs a recap: what was reviewed, which records moved, what remains blocked, and what needs a person. If no record moved, say so briefly instead of creating another pile of messages.

Set stop conditions before orchestration

Stop the flow when:

• a required input is absent or unreadable;
• two sources disagree on a client detail;
• a request changes price, scope, legal terms, or delivery dates;
• the next action would contact a client without required approval;
• the same unit fails twice on the same record;
• no next owner is defined.

A stop should create a useful handoff with current status, completed work, the unresolved question, relevant evidence, and the person who should decide. “Failed” by itself is not enough.

Measure reliability at the handoffs

Track measures that reveal whether the boundaries work:

• units completed with the required output;
• runs stopped for a valid reason;
• incorrect or missing handoffs;
• waiting time versus processing time;
• human corrections by unit;
• duplicate messages, records, or actions;
• runs started before a prerequisite was ready.

Review these by unit. An end-to-end completion figure can hide one weak handoff that repeatedly creates cleanup later.

Watch for predictable failure modes

A common mistake is splitting by software screen instead of responsibility. Another is making units so small that coordination creates more confusion than the work itself. Broad permissions can erase the safety gained from splitting. Teams also automate the happy path while leaving waits, retries, and exceptions undefined.

One limitation is that boundary mapping cannot remove ambiguity from the process itself. If the team does not agree on who approves scope or what counts as complete intake, the workflow needs a business decision before it needs more automation.

Recap the method

Map the interruptions. Split at human decisions, real waits, permission changes, and meaningful state changes. Give every unit defined inputs, outputs, ownership, permissions, triggers, and stop conditions. Test each unit alone with a small case. Connect them only after they work independently, then add event triggers or schedules and a concise recap.

This approach was inspired by Corey Ganim’s X post and YouTube walkthrough. In his client-onboarding example, he reports turning 24 manual steps into five distinct units, keeping two steps human, and adding orchestration only after the individual units were tested. Those figures describe his example, not a general benchmark.

Audit one workflow and find its safest boundaries.