Redesign the Workflow for the Agent, Not the Human

Redesign the Workflow for the Agent, Not the Human

If an agent is failing inside a familiar human workflow, the workflow is usually the problem. Agents compound when the work is rebuilt around states they can verify, not around the tacit judgment a capable employee supplies without being asked.

THE OPERATING SHIFT

Why do human-shaped workflows make agents brittle?

Human workflows are full of invisible recovery moves. A person notices a missing detail, infers what a customer probably meant, asks someone in the next room, and remembers the exception next time. The written process often records the visible steps while leaving the judgment between them unspoken.

In the engagements we run, the deployments that compound are redesigns, not bolt-ons. The workflow was rebuilt around checkable states. A pattern we keep seeing is that an agent inherits the steps but not the judgment, then fails politely by completing a sequence that no longer means the work is right.

That is why adding an agent to a process map can look convincing in a demo and become noisy in operation. The map says “review request” or “confirm details,” but those labels conceal a chain of decisions. Which details are required? What counts as a conflict? Who may resolve it? What evidence shows the result is ready for the next step?

The design question that clarifies the redesign is simpler and stricter: at which points can the system prove the step succeeded, and can the flow route through those points? If the proof is missing, the work has not reached a reliable state. It has merely moved forward.

THE DESIGN STANDARD

What makes a workflow agent-compatible?

An agent-compatible workflow has deterministic checkpoints, explicit state, machine-verifiable outputs, and narrow interfaces. It does not require that every decision be automatic. It requires that the system know which decisions it may make, which it must escalate, and what record it must leave behind either way.

Vista calls this the Harness-Over-Model approach. The framework we use puts more attention on the operating harness than on trying to find a magically smarter model. A capable model inside a vague process is still guessing. A modest model inside a well-designed harness can execute a useful slice of work consistently.

Start with state. “Working on it” is a human update, not a state. “Request received, required fields complete, eligibility checked, exception awaiting review, fulfillment confirmed” are states. Each one tells the system what is true, what remains permitted, and what evidence is needed before a transition.

Then make the outputs inspectable. The agent should not return “handled.” It should produce a completed record, a validation result, a linked artifact, or a clearly labeled escalation. That record gives the next actor, human or machine, something to verify without reconstructing the agent’s reasoning.

Proof before progress. Do not let a workflow advance because an agent says it completed a task. Advance it only when the required evidence exists and the next state is valid.

Narrow interfaces are the third piece. A broad instruction such as “take care of incoming requests” invites hidden assumptions. A narrow interface names the required input fields, allowable actions, output format, ownership, and failure condition. It sounds less elegant, but it creates a seam you can test and improve.

A WORKED PATTERN

How would a request-to-fulfillment flow change?

The conclusion is that the useful redesign is not “put an agent on requests.” It is “create three verifiable gates that turn an ambiguous request into a fulfilled record.” The agent can do real work in that flow because success is observable at each gate.

Consider a generic request-to-fulfillment process. In its human form, a request arrives, someone interprets it, checks what is possible, coordinates the work, and marks it done. Those verbs hide too much. A person can compensate for omissions. An agent needs the omissions brought into the open.

Checkpoint	What the system must verify	Allowed next move	Evidence left behind
Request accepted	Required fields are present and the request can be classified	Route to standard handling or exception review	Structured request record and missing-field result
Fulfillment cleared	Eligibility, dependencies, and constraints have a recorded result	Create the fulfillment task or escalate the conflict	Validation record and named exception reason
Fulfillment confirmed	The promised output exists and matches the request record	Close, notify, or reopen for correction	Linked output, completion status, and timestamped confirmation

At the first checkpoint, the agent can collect, normalize, and flag missing inputs. It does not have to pretend it understands every ambiguous request. It can ask a targeted question, assign a known category, or send the request to the exception path with the ambiguity preserved.

At the second checkpoint, the agent checks explicit constraints against explicit records. If a conflict cannot be resolved by a stated rule, it stops. This is not a failure of autonomy. It is the workflow refusing to manufacture certainty where a human decision is required.

At the final checkpoint, completion is not an agent-authored sentence. It is an output matched against the request record. The difference matters because the organization can audit, sample, correct, and eventually improve the rule that produced the result.

WHERE PEOPLE STAY

Does checkability remove human judgment?

No. It gives judgment a clean place to live. Human operators remain responsible for defining the rules, deciding which exceptions deserve discretion, and revising the process when reality exposes a bad assumption. The agent executes the bounded work and returns the cases that exceed its authority.

This is the Agent-Does-the-Work model, not the agent-does-everything fantasy. The point is to move repetitive, evidence-producing work out of the operator’s attention while keeping consequential judgment visible. A good design makes escalation feel ordinary, not embarrassing.

Teams often resist explicit states because they fear bureaucracy. The opposite is usually true. A clear state model removes status-chasing, makes handoffs easier to inspect, and reveals which conversations are really decision points. The burden exists already. It is simply carried in people’s heads.

The practical test is this: when an agent stops, can a person see why in one record and make the next decision without replaying the entire interaction? If not, the workflow is still asking the agent to carry hidden context.

THE HONEST COST

Why are bolt-ons so tempting, and so disappointing?

Bolt-ons are attractive because they preserve the current operating story. You can announce an agent without reopening ownership, exception rules, data quality, or handoffs. But the unresolved parts do not disappear. They are shifted into prompts, hidden fallbacks, and awkward human cleanup.

Redesign is real work. Someone has to name the states, choose the checks, clarify authority, and decide what evidence counts. That is operational design, not a configuration chore. It can expose disagreements the team has managed to avoid because people were quietly compensating for one another.

Still, that work is why the result compounds. Every checkable checkpoint becomes a place to measure quality and improve a rule. Every explicit exception becomes a candidate for a future policy. A bolt-on gives you activity. A redesigned workflow gives you an operating asset.

For operators working through which work belongs in the first place, our AI Lab working sessions are built around real workflows and their constraints. The useful starting point is not an agent demo. It is a process whose success can be proven.

THE VERDICT

What should you redesign first?

Choose a workflow that is frequent enough to matter, bounded enough to map, and painful enough that people already notice the cleanup. Then trace it from request to outcome and circle every place someone says “you just know.” Those are not edge details. They are the redesign backlog.

Begin by defining the first verifiable state, not by selecting a model. Give the agent one narrow transition to own, define the proof it must leave behind, and make its failure path explicit. Once that transition is reliable, extend the harness to the next one.

The hard verdict is that agent adoption is process work disguised as software work. Operators who accept that early will build systems that get more dependable with use. Operators who skip it will keep debugging the same invisible judgment in a different interface. For related context, see why AI architecture should build rather than run and what AI agents are for operators.

COMMON QUESTIONS

Frequently asked questions

What is an agent-compatible workflow?

An agent-compatible workflow defines clear states, permitted actions, required inputs, and verifiable outputs. It gives an agent a bounded slice of work it can complete or escalate with evidence. The design does not eliminate human judgment. It makes the moments requiring judgment explicit and routes them to the right owner.

What is a deterministic checkpoint in an agent workflow?

A deterministic checkpoint is a point where the system can test whether a condition is true using defined evidence. For example, a required record may be complete or incomplete. The workflow should not move onward based only on an agent’s assertion. It advances when the evidence supports the transition.

Should an agent handle exceptions by itself?

An agent should handle only the exceptions covered by an explicit policy and a documented authority boundary. When an exception depends on unstated context, tradeoffs, or discretion, the agent should preserve the facts and escalate. Reliable escalation is a sign of sound design, not a shortcoming.

How do I find the right first workflow for an agent?

Start with a recurring workflow that has a clear outcome, recognizable handoffs, and visible cleanup pain. Map the current steps and identify where people rely on memory or informal judgment. A strong first candidate has one narrow transition that can be verified before you automate additional work.

Do I need a complex system before using agents?

No. You need enough structure for the agent’s job to be bounded and checked. A simple process with clear inputs, outputs, and escalation rules is a better starting point than a complex process full of hidden assumptions. Add sophistication after the first checkpoint proves dependable.

Why do agent pilots often disappoint?

Many pilots drop an agent into a workflow designed for people who carry context, recover from ambiguity, and recognize exceptions. The agent receives the visible steps but not the hidden judgment. Redesigning the flow around explicit state and proof changes the operating conditions, which is why it produces more durable results.