How to Map a Workflow Before You Hand It to an AI Agent
· Chris Daily

How to Map a Workflow Before You Hand It to an AI Agent

Before any AI agent can work reliably, the workflow it runs needs to be agent-compatible. Here's the four-anchor test that tells you whether yours is ready.

I've consulted on enough failed AI projects to identify the most common root cause. It's not the model. It's not the platform. It's not even the instructions, though those matter enormously. It's that the workflow the agent was supposed to run was never actually designed.

People take a messy, judgment-heavy process that a skilled person navigates intuitively and hand it to an AI agent expecting reliability. The agent doesn't produce reliability. The team concludes the technology isn't ready. In most cases, the technology was fine — the workflow wasn't agent-compatible.

What Agent-Compatible Actually Means

A workflow is agent-compatible when it's specific enough that each step can be validated on its own, not just the final result. That's the test.

Most professional workflows fail it, not because the work is inherently ambiguous, but because skilled practitioners have internalized the logic and no longer need to make it explicit. An experienced customer service rep knows intuitively when a situation calls for a supervisor, when the policy applies cleanly, and when there's a gray area that needs judgment. They don't consult a decision tree. They just know.

An AI agent doesn't know. It needs the decision tree — or at minimum, it needs explicit instructions for each case. Making a workflow agent-compatible is the work of making that implicit knowledge explicit.

The Four-Anchor Test

Before I hand any workflow to an agent, I run a four-anchor test. If any anchor is missing, the workflow needs more design work before it's ready.

Anchor 1: a testable completion condition. Can you state exactly when this workflow is done? Not 'when the customer issue is resolved' — that's too vague to validate. 'When the customer receives a written response that directly addresses their stated issue, includes the relevant policy section, and is logged in the CRM' — that's a testable completion condition. If you can't define done, neither can the agent.

Anchor 2: ordered steps with single actions. Each step should do exactly one thing. 'Research the customer's issue and draft a response' is two things. Separate them. 'Retrieve the customer's last three support tickets from the CRM' is one thing. Each step needs a clear input — what the agent receives to start the step — and a clear output: what a correct result looks like, specific enough to validate.

Anchor 3: LLM reasoning vs. deterministic logic. For each step, ask: does this require language understanding, judgment, or drafting? Use the language model. Does it require strict rule application, calculation, or database lookup? Use deterministic logic — code that follows a rule, not a model that interprets one.

This distinction matters for reliability and auditability. A rule-based calculation produces the same result every time and can be audited. A language model's interpretation introduces variability. Use each where it's appropriate: language model for the steps that genuinely need it, deterministic logic for everything else.

Anchor 4: human review gate placement. At least one point in the workflow should require human confirmation before the agent proceeds. This isn't about distrust — it's about identifying the step where a mistake would be most costly and making sure a human is accountable at that moment. The gate should have a specific trigger condition and name a specific action: 'if the proposed refund exceeds $500, route to the customer service manager before responding.'

A Practical Walk-Through

Let me make this concrete with a simplified example: an agent that handles routine vendor invoice processing.

As-is, the workflow is: 'Review invoices and pay the ones that are correct.' That's not a workflow. That's an outcome statement.

Made agent-compatible: Step 1 — Receive invoice (input: PDF attachment; output: invoice extracted to structured data with vendor, amount, date, line items). Deterministic: data extraction from a defined format. Step 2 — Match to purchase order (input: structured invoice data; output: matched PO number or flag for manual review). Deterministic: database lookup. Step 3 — Verify line items against PO (input: invoice line items + PO details; output: variance report). Deterministic: arithmetic comparison against policy thresholds. Step 4 — Draft payment recommendation (input: variance report + approval policy; output: recommendation memo). LLM: policy interpretation and plain-language summary. Human review gate: invoices over $10,000 or with any variance outside tolerance route to the finance manager before proceeding. Step 5 — Log outcome in accounts payable system (input: approved recommendation; output: updated record). Deterministic.

Same work. Completely different agent-readiness. The first version produces an unreliable agent. The second produces a reliable one.

Why This Is Professional Work, Not Technical Work

Notice what the four-anchor test requires. It requires deep familiarity with how the work actually happens — what 'done' looks like, where the edge cases are, which steps require genuine judgment versus rule application, where a mistake would be most damaging.

That knowledge doesn't live in a codebase. It lives with the people who do the work. The finance team knows where invoice processing breaks down. The customer service leads know which situations need a supervisor. The operations managers know which steps in their workflows have hidden dependencies.

Making a workflow agent-compatible is professional design work. It produces something valuable even if you never deploy the agent: a documented, explicit version of how the work actually runs. That document is useful for training, for auditing, for onboarding, for process improvement. The agent is a reason to do the design. The design pays off whether or not the agent ever runs.

Key takeaways

  • An agent-compatible workflow has each step specific enough to be validated independently, not just the final result.
  • The four-anchor test checks for: testable completion condition, single-action ordered steps, LLM vs. deterministic designations, and a human review gate.
  • Deterministic logic handles rules and calculations; LLM reasoning handles language, judgment, and drafting. Use each appropriately.
  • Making a workflow agent-compatible is professional design work — the knowledge required lives with the people who do the work, not in a codebase.

Frequently asked questions

What makes a workflow agent-compatible?

A workflow is agent-compatible when each step has a single clear action, a defined input, and an output specific enough to validate independently. The completion condition must be testable — not 'when the issue is resolved' but a precise description of what done looks like. At least one human review gate should exist at the highest-stakes decision point.

When should AI agent workflow steps use LLM reasoning versus deterministic logic?

Use LLM reasoning for steps that require language understanding, contextual judgment, summarizing, or drafting. Use deterministic logic (code following a rule) for steps involving calculations, database lookups, schema validation, or strict policy application. Deterministic steps are faster, more auditable, and produce consistent results. Mixing both in the same workflow — each method at the steps it's suited for — produces the most reliable agents.

How do I know if my workflow is ready for an AI agent?

Run the four-anchor test: (1) Can you state a specific completion condition? (2) Does each step have exactly one action with a clear input and a validatable output? (3) Is each step designated as LLM reasoning or deterministic logic? (4) Is there a human review gate with a specific trigger condition? If any anchor is unclear, the workflow needs more design before an agent will perform reliably.

What is a human review gate in an AI agent workflow?

A human review gate is a deliberate decision point where the agent pauses and routes to a human for approval before proceeding. A useful gate has a specific trigger condition (e.g., 'if the invoice exceeds $10,000') and a named action (e.g., 'route to the finance manager'). Vague gates ('when judgment is needed') don't get implemented consistently — specific triggers do.

Map a real workflow in Session 1

The first session of AI Agent Essentials walks through the four-anchor test and gives you AI-1: Workflow Mapper to structure a real task from your own organization. By the end of the session, you have an agent-compatible workflow map you can build from.

See Session 1