A lot of bad AI agent projects start with the wrong question.

The wrong question is:

“Where can we put an agent?”

That question produces demo-brain. It produces tool sprawl. It produces weird little automations nobody fully owns. And eventually it produces the sentence every operator hates:

“The agent kind of works, but it created a bunch of cleanup.”

The better question is:

“Which workflow is actually a good fit for bounded autonomy?”

Because not every workflow should get an agent. Some should stay manual. Some should get normal software. Some should get a draft-first assist layer. And some should absolutely not be touched until the underlying process stops being chaos.

If you want AI agents to make money instead of making messes, you need a workflow fit test before you build.

This is the practical version.

The expensive mistake#

A lot of builders overestimate model capability and underestimate workflow ugliness.

They see one painful job and think:

  • lots of repetition
  • lots of text
  • humans are doing it now
  • seems annoying
  • agent time

Not so fast.

A workflow can be repetitive and still be a terrible candidate. A workflow can be text-heavy and still be too politically sensitive. A workflow can be annoying and still be full of edge cases, stale data, hidden approvals, and unwritten rules.

That is why so many early agent builds feel impressive in week one and expensive by week three.

The problem was not always the model. Often the problem was fit.

What a good first agent workflow usually looks like#

Good first workflows are boring. That is a compliment.

A strong starting workflow is usually:

  • repetitive enough to matter
  • narrow enough to control
  • valuable enough to justify the work
  • structured enough to validate
  • low-to-medium risk if wrong
  • full of obvious handoff points
  • painful enough that humans actually want help

Examples:

  • triaging inbound leads before assignment
  • summarizing calls before CRM entry
  • drafting first-pass follow-ups for review
  • classifying support tickets before routing
  • checking documents against a known checklist

These workflows have something important in common:

the agent can propose or process work without being the final unchecked authority.

That is the sweet spot.

The five-part workflow fit test#

Before you build an agent, run the workflow through these five questions.

If the answers are weak, do not force it.

1. Is the process already stable?#

If the human workflow is still a mess, an AI agent will not fix it. It will scale the mess.

Ask:

  • do people agree on the steps?
  • do people agree on what “done” means?
  • are escalation rules at least somewhat explicit?
  • is there a real owner for the workflow?
  • do exceptions have a known path?

If the answer is basically “everyone does it differently,” you do not have an agent problem. You have a process problem.

Fix the operating logic first. Then automate.

This is one of the most common self-owns in AI projects: using an agent to avoid cleaning up the workflow design.

That is not leverage. That is denial with API keys.

2. Can the agent’s output be checked?#

If you cannot validate the output, the workflow gets risky fast.

A good agent workflow has some form of verification outside the model. That might be:

  • schema validation
  • policy checks
  • live state checks
  • comparison to a source of truth
  • human approval on risky cases
  • downstream success/failure receipts

A bad fit usually looks like this:

  • correctness is subjective
  • errors are hard to detect quickly
  • success is only obvious after damage happens
  • nobody can tell whether the output was truly right

If the only validator is “hopefully a human notices later,” that is not a strong first workflow.

I already covered the operational side in AI Agent Output Validation: How to Stop Bad Actions Before They Ship. The short version is that if you cannot check it, you should not automate it aggressively.

3. What is the downside if the agent is wrong?#

This should be obvious, but people still skip it because the upside is exciting.

A workflow is a much better fit when the cost of a wrong action is annoying, not catastrophic.

Good early-fit examples:

  • wrong tag on an internal draft
  • imperfect first-pass summary
  • misrouted ticket that is easy to recover
  • lead score that still gets reviewed downstream

Bad early-fit examples:

  • sending money
  • deleting records
  • changing permissions
  • making promises to customers in high-risk situations
  • legal or compliance decisions without human review

If the blast radius is high, autonomy should be lower. That does not mean “never automate it.” It means the design should shift toward:

  • proposal mode
  • draft mode
  • approval gating
  • narrow policy scopes
  • explicit escalation

The goal is not maximum autonomy. The goal is survivable autonomy.

4. Is the data good enough to support the decision?#

A lot of workflows fail because the model gets blamed for garbage inputs.

If the data is stale, contradictory, partial, or buried across six systems, the agent may still sound confident while making the wrong call.

Ask:

  • is the source data complete enough?
  • is there a canonical source of truth?
  • does the workflow depend on fields people barely maintain?
  • are key states current and accessible?
  • does the agent need context that only exists in someone’s head?

This matters because a workflow that looks perfect on a whiteboard can collapse the moment it meets real operating data.

If the system depends on tribal knowledge, inbox archaeology, and half-filled CRM records, your first win may not be an autonomous agent. It may be a data cleanup sprint and a smaller assist layer.

Unsexy. Profitable.

5. Will the humans actually trust the setup?#

A workflow can be technically possible and still be politically dead.

If the people who live inside the workflow think the agent creates extra cleanup, hidden liability, or approval theater, adoption will quietly die.

Ask:

  • does this make the human role better or just weirder?
  • are handoffs clear?
  • is there a visible escalation path?
  • can operators see what the agent did and why?
  • is the system easy to override when needed?

If the rollout turns humans into janitors for machine mistakes, people will hate it for good reason.

That is why some of the best early agent wins are not full replacements. They are:

  • draft-first systems
  • triage systems
  • prioritization systems
  • summarization systems
  • pre-check systems

These reduce work without demanding blind trust on day one.

The simple scoring model#

If you want a quick filter, score the workflow from 1 to 5 on these dimensions:

  1. process stability
  2. output verifiability
  3. downside if wrong
  4. data quality
  5. human trust / operational adoption

Then use this rough read:

21-25: strong candidate#

Good first workflow for bounded autonomy. Likely worth building now.

16-20: decent candidate with constraints#

Buildable, but probably needs draft mode, approvals, or a tighter scope.

10-15: weak candidate#

Do not sell full autonomy here. Maybe sell an audit, cleanup sprint, or assist layer instead.

Below 10: bad fit right now#

Do not force an agent into this just because the category is hot. Fix process, ownership, or data first.

This is not academic precision. It is a cheap way to avoid expensive nonsense.

What to do when the workflow is a bad fit#

This is where a lot of builders get stubborn.

They already want the project. The buyer wants “AI.” So they push ahead anyway.

Bad move.

If the workflow is a bad fit, you still have options that make money and create trust.

Option 1: Sell the audit#

Map the workflow, identify the failure points, score the automation fit, and recommend the right control model.

This is exactly why Sell the Audit Before the Agent is such a strong offer. The buyer often needs clarity before they need software.

Option 2: Sell the assist layer#

If full autonomy is too risky, sell:

  • summarization
  • drafting
  • classification
  • prioritization
  • recommendation support

That still creates value while lowering the downside.

Option 3: Sell the cleanup before the agent#

Sometimes the right project is:

  • data normalization
  • workflow redesign
  • approval policy design
  • handoff clarification
  • validation and receipt infrastructure

That does not sound as sexy as “autonomous AI agent deployment,” but it is often the work that makes the later agent deployment actually succeed.

The money is in workflow judgment, not agent enthusiasm#

A lot of people are still selling “AI help.” That is too vague.

The stronger position is:

I can tell you which workflows are good candidates, which ones are traps, and how to structure autonomy so it does not become operational debt.

That is more useful. That is more credible. And honestly, that is where a lot of the real value lives.

Because the biggest risk in early agent work is not just building badly. It is building the wrong thing with confidence.

A better way to think about AI agent opportunity#

Do not start with the model. Start with the workflow.

Do not ask:

  • what can the agent do?

Ask:

  • what step is repetitive?
  • what step is verifiable?
  • what step has survivable downside?
  • what step has enough structure to control?
  • what step creates visible ROI if improved?

That is how you find the first wedge.

Usually the best first wedge is not a fully autonomous employee replacement fantasy. It is a narrow, controlled, economically obvious system that removes one annoying category of work.

That is enough. That is how trust starts. And that is how agent projects turn into revenue instead of postmortems.

If you want help figuring out whether a workflow is a real AI agent candidate or just a shiny trap, start with Erik MacKinnon: erikmackinnon.com.