A technical team can deliver an impressive AI workflow and still spend its days carrying information between systems. Someone finds the source material, turns the request into a prompt, repairs the output, pastes it into the destination, and checks whether the next person received it. The model does useful work, but a person is holding the rest of the process together.
That is human middleware: people supplying the connections and rules that the system lacks. Manual steps help a team test an idea before investing in integration. Trouble starts when those temporary steps become permanent, and the person who knows all the peculiarities becomes the only person who can keep the process running. Their time goes into moving the work along instead of improving how it gets done.
Follow one item all the way through
Imagine a team preparing a weekly summary of project progress, decisions, and blockers. An AI tool produces a readable draft from supplied updates. The demonstration looks promising. Then you watch what it takes to produce the actual brief.
A technical lead collects updates from several places, notices that two teams use different project names, asks which date is current, and removes an item that has already been resolved. After generating the draft, the lead corrects a misleading summary, copies the brief into the approved document, and asks two owners to resolve conflicting accounts of a project dependency.
Some of this work calls for judgment. Deciding whether a disagreement affects an upcoming decision may need a person who understands the project. Other steps are much more routine: reconciling names, finding the latest update, and copying text to a destination. Calling all of it “human review” hides how much coordination the reviewer is doing.
The model's contribution may be valuable. To understand what the workflow costs, though, you have to include the person collecting, repairing, delivering, and chasing everything around it.
Be clear about what the reviewer is there to do
A useful review gives someone a decision to make. They might confirm that a customer commitment is appropriate, resolve conflicting evidence, or decide whether a recommendation fits the situation. They need the relevant context and the authority to accept, revise, reject, or escalate the work.
Now compare that with renaming the same fields every week, copying text between tools, or checking a queue because nobody can tell whether a handoff completed. Those steps keep the current process alive, but they are also opportunities to improve its design. A reviewer should not have to do them just to reach the part that needs their judgment.
Some checks can move into the system. Required fields, accepted project identifiers, and a confirmed destination are good places to start. A disagreement about what a delay means for a customer may still need a person. Give that person the competing information and a clear question to resolve, so the review has a purpose beyond “make sure everything looks right.”
Find the work that never made it into the diagram
Start with a few ordinary completed items, including one that needed correction. Ask the people doing the work to walk you through what happened. Follow the actual documents and messages; the official process may leave out the steps everyone has learned to do automatically.
For each handoff, record:
- Input and destination: What arrives, where it comes from, and where the result must go.
- Action: What the person does, such as moving information, changing its format, making a decision, checking a requirement, or recovering from a failure.
- Missing rule: What the person knows that the process does not specify, such as which source wins when dates conflict.
- Consequence: What happens if the step is skipped or done incorrectly.
- Owner and frequency: Who does it, who could fix the underlying problem, and how often it returns.
Listen for “I just fix that before sending it.” That small aside may explain why the process appears more reliable than it is. Ask what the person changes and how they know to change it. You may find a simple formatting nuisance, or a check that prevents a serious mistake.
Make it clear that you are examining the process. People who have kept it running need to be able to show the messy parts without being blamed for them. Otherwise, the most useful evidence will stay hidden.
Fix the things people keep fixing
In the status-brief example, the lead repeatedly reconciles project names, chases missing updates, and reformats generated text. Each problem suggests a fairly ordinary improvement. Use consistent project identifiers. Assign update owners and a submission deadline. Match the output format to the destination. None of this requires a smarter model.
The disagreement about a project dependency still needs attention. Show the reviewer the competing source statements and identify who can settle the issue. Keep it marked as unresolved until that happens. A well-written summary should preserve a disagreement that matters to the decision.
Compare the recurring effort with the cost of building and maintaining each improvement. A task that happens twice a year may be sensible to leave manual. Document it, assign it, and account for the time. Focus engineering effort where the same problem keeps consuming attention.
Give the team room to improve the system
Before expanding a pilot, name the manual steps you intend to keep, the ones you plan to replace, and the exceptions you still need to work through. Assign the time and responsibility to maintain the process as well as launch it.
Then look for evidence that it is becoming easier to run. Can another person produce the weekly brief? Does the workflow keep moving when its original builder takes time off? Are fewer items arriving with the same preventable problem? Those changes say more about its reliability than another polished demonstration.
Capable people will find ways to work around imperfect systems. Give them the time and authority to fix the problems they keep working around. Their judgment is too valuable to spend every week repairing the same broken handoff.