Most AI agent projects do not fail because the model was bad.

They fail earlier.

They fail in scoping.

A team sees a flashy demo, decides they “need an agent,” grabs one ugly workflow, and starts building before anybody has answered the boring questions:

  • what exact workflow are we changing?
  • where does value actually come from?
  • where can this thing hurt us?
  • what has to stay human?
  • what systems and approvals are in the way?
  • what counts as success in numbers, not vibes?

That is how you end up with a pilot that looks active but never becomes operational.

The fix is not more enthusiasm.

The fix is a real AI agent discovery workshop.

Not a theater meeting. Not a vendor demo with sticky notes. Not a strategy deck full of words like transformation.

A working discovery workshop has one job:

find the specific workflow worth automating, define the control boundaries, and leave with a buildable scope instead of a vague ambition.

If you do that well, the build gets easier. If you skip it, the build becomes an expensive way to discover you picked the wrong problem.

What an AI agent discovery workshop is actually for#

A lot of teams think discovery means “brainstorm some use cases.”

That is too soft.

The point is to reduce uncertainty in five places:

  • workflow fit
  • business value
  • operational risk
  • technical constraints
  • ownership after launch

A good workshop should answer:

  • what workflow should we target first?
  • what part should the agent do versus assist versus not touch?
  • what events require approval, review, or escalation?
  • what tools and data does the workflow actually depend on?
  • what metric would prove this worked in 30 to 60 days?

That gives you something far more valuable than “alignment.”

It gives you a decision-ready scope.

The mistake most teams make#

They start with a capability instead of a workflow.

They say things like:

  • we want an email agent
  • we want an SDR agent
  • we want an AP agent
  • we want an internal ops copilot

That sounds specific, but it usually is not.

Those labels hide the real work.

An “email agent” could mean:

  • triaging inbound support requests
  • routing sales inquiries
  • drafting internal replies
  • following up on unpaid invoices
  • reviewing vendor bank-detail change requests

Those are not the same workflow.

They have different stakes, different approval logic, different data needs, and different economic value.

If you scope at the category level, you build something broad and mushy. If you scope at the workflow level, you can actually ship something useful.

That is why the workshop has to begin with workflow anatomy, not feature wishlists.

What to bring into the room#

Keep the group small.

Usually you want:

  • the operator closest to the workflow
  • the manager who owns the outcome
  • someone who knows the systems and data reality
  • someone who can speak for risk, compliance, or approvals if the workflow has real consequences

If you pack the room with spectators, you get politics instead of scope.

The input material is simple:

  • one real workflow to map
  • example inputs from the last 2 to 4 weeks
  • current tools and handoff steps
  • known exceptions and failure cases
  • baseline volume and timing
  • baseline pain metrics if available

Real examples matter.

Discovery gets fake fast when everyone talks in abstractions. You want actual screenshots, actual tickets, actual emails, actual forms, actual queue states.

Messy evidence beats clean opinions.

Step 1: Map the workflow in plain English#

Before you discuss AI, map the current process.

Ask:

  1. What triggers the workflow?
  2. What information arrives at the start?
  3. What decisions get made along the way?
  4. What systems are touched?
  5. Where do humans intervene today?
  6. Where does the workflow stall, break, or bounce?
  7. What final outcome counts as complete?

Force plain English.

No architecture jargon. No platform buzzwords. No “orchestration layer” until the actual work is visible.

You want a map that sounds like this:

A vendor emails AP asking to change bank details. An AP specialist opens the request, checks whether the sender matches a known contact, compares the requested data to the ERP record, asks for verification if the request is unusual, gets a second approver for changes above policy threshold, updates the record, and logs the change.

That is a workflow.

Now you can discuss where an agent fits.

Step 2: Find the repeatable core and the dangerous edges#

Every workflow has three zones:

  • the repetitive core
  • the ambiguous middle
  • the dangerous edges

The repetitive core is where automation tends to pay.

The ambiguous middle is where assistance often beats full autonomy.

The dangerous edges are where approvals, hard stops, and human review belong.

This matters because not every workflow should be automated the same way.

Sometimes the right design is:

  • agent gathers information
  • human approves
  • system executes

Sometimes it is:

  • agent handles low-risk cases end to end
  • escalates anything outside policy

Sometimes it is:

  • agent does not act at all
  • it just preps the human decision packet faster

If you force every workflow into “full autonomy,” you make the design worse.

The workshop should explicitly mark:

  • what the agent can do alone
  • what it can recommend but not execute
  • what it must never do without approval
  • what it should never touch

That one exercise saves a lot of stupid builds.

Step 3: Identify the real constraint#

Many teams think the bottleneck is labor.

Often it is not.

Sometimes the real constraint is:

  • poor input quality
  • scattered data across systems
  • unclear ownership
  • approval bottlenecks
  • policy ambiguity
  • too many exception paths
  • no service-level expectation for review queues

If the workflow is held together by missing data and tribal knowledge, an agent will not magically fix it. It will surface the disorder faster.

That is still useful signal. But the output of discovery might be:

Do not build the agent first. Clean the intake form, define approval rules, and standardize the handoff packet. Then automate.

That is a good workshop outcome.

Discovery is not supposed to justify building at all costs. It is supposed to protect you from building the wrong thing.

Step 4: Define the economic case#

If nobody can explain why this workflow matters, it is not ready.

You do not need a giant ROI spreadsheet. But you do need a sane economic frame.

Ask:

  • how much volume runs through this workflow per week?
  • how long does it take today?
  • what delays or errors are expensive?
  • what downstream revenue, cash, compliance, or customer impact depends on it?
  • what would a 20 to 30 percent improvement actually be worth?

This keeps the workshop out of toy-land.

A workflow is attractive when it has some combination of:

  • high frequency
  • ugly coordination
  • costly exceptions
  • measurable delay
  • measurable business consequence

That is why proposal go/no-go, support triage, onboarding coordination, AP approvals, and exception-heavy internal ops workflows keep showing up.

They are not glamorous. They are economically legible.

Step 5: Design the control layer before the agent behavior#

This is the part most teams leave until later.

Bad move.

Before you decide how smart the agent should be, decide how controlled it needs to be.

That means defining:

  • approval thresholds
  • escalation rules
  • who owns override decisions
  • audit trail requirements
  • acceptable failure modes
  • rollback or recovery path
  • what evidence must travel with each decision

In other words, design the brakes before the accelerator.

If the workflow touches money, customer communications, regulated data, vendor records, contracts, or anything customer-facing, this is not optional.

A lot of failed pilots are really control failures wearing a model hat.

The agent might be technically capable. But the organization has no safe way to let it operate.

Discovery should solve that early.

Step 6: Pick the first slice#

Do not leave the workshop trying to automate the whole department.

Leave with a first slice.

A good first slice is:

  • narrow enough to ship in weeks, not quarters
  • valuable enough to matter
  • controlled enough to be safe
  • measurable enough to evaluate honestly

Examples:

  • triage inbound leads and route only qualified demo requests
  • draft proposal intake summaries before go/no-go review
  • pre-check vendor bank-detail change requests and assemble the verification packet
  • classify support tickets and route only the high-confidence cases automatically
  • prepare onboarding checklists and flag missing prerequisites before human review

That is how you create momentum.

Not by promising an “AI employee.” By making one ugly workflow materially better.

The deliverables a discovery workshop should produce#

If the workshop is real, it should leave artifacts.

At minimum:

  • workflow map
  • decision points and exception paths
  • system/data dependencies
  • control boundary definition
  • first-slice recommendation
  • success metrics for pilot phase
  • unresolved risks or blockers
  • clear owner for next step

That becomes the input to an audit, implementation sprint, or pilot design.

Without artifacts, discovery was probably just a meeting.

Questions that make a discovery workshop useful#

If you are running one, these are the questions worth asking:

  • What exact workflow are we trying to improve?
  • What is the trigger, and what does “done” look like?
  • Which steps are repetitive versus judgment-heavy?
  • What goes wrong today, and how often?
  • What kinds of exceptions appear most often?
  • What decisions are reversible, and which are expensive to get wrong?
  • What systems or people create delay?
  • Where does tribal knowledge currently sit?
  • What must be visible in logs or receipts?
  • What is the smallest slice worth shipping first?

These questions are not sexy.

They are profitable.

When discovery says “not yet”#

This is underrated.

Sometimes the best outcome is discovering the workflow is not ready.

Maybe the inputs are too messy. Maybe nobody owns the process. Maybe the rules change daily. Maybe there is no volume. Maybe the real issue is management indecision, not workflow mechanics.

That is fine.

A good discovery workshop should be allowed to conclude:

  • not this workflow
  • not this quarter
  • not before process cleanup
  • not without a stronger control model

That is not failure.

That is expensive confusion avoided.

The real point#

The point of an AI agent discovery workshop is not to generate excitement.

It is to answer one hard question:

what is the right workflow, with the right boundaries, for a build that can survive contact with the real business?

If you can answer that, you are no longer buying a fantasy.

You are buying a scoped operational improvement.

That is where useful agent work starts.

And it is why discovery is not fluff.

It is the thing that stops you from burning time on the wrong automation story.

If you want help turning a messy workflow into a decision-ready scope, that is the work I do.

See services if you want an outside operator to map the workflow, find the control gaps, and define the first slice worth shipping.