---
title: "AI agents in a company that cannot describe its own process"
url: "https://vucale.com/blog/ai-agents-and-undefined-processes"
description: "Automation applied to a defined process removes work. Applied to an undefined one it produces confident output nobody can check, faster than anyone can review it."
---

# AI agents in a company that cannot describe its own process

August 4, 2026·2 min read·VUCALE

A company decides to put AI agents into a process. The first workshop asks how the process currently works, and three people describe three different things — all of them accurate, because each department genuinely does it differently and the differences were never reconciled.

This is not a failure of the workshop. It is the normal state of most business processes, and it is the thing that determines whether the project has any chance.

## Why undefined processes defeat automation

**There is nothing to check the output against.** Automation is judged by whether it did the right thing. If the right thing is contested, nobody can evaluate it, and the system is adopted or rejected on impressions.

**The exceptions are the process.** In most real processes the documented path covers half the cases and experienced people handle the rest by judgement. Automating the documented half moves all the difficulty into the exception path, which is now larger and less staffed.

**Confident output is worse than no output.** A model producing a plausible answer to a question the organisation cannot answer itself will be believed, because it is fluent and it is fast. Errors propagate at the speed of the automation.

**Nobody owns it.** An undefined process usually has no single owner, which means when the agent gets something wrong, there is nobody whose job it is to notice.

## What has to exist first

Less than a full process-mapping exercise, and more than nothing.

**One agreed definition of the outcome.** What a good result looks like, in terms somebody outside the team can evaluate. Not the steps — the outcome.

**A named owner.** One person accountable for whether this process produces good results, including when a machine is doing part of it.

**A record of what was decided.** What came in, what was concluded, what was done. Without this, improvement is impossible and incidents are unresolvable.

**A defined exception path.** What happens when the system is unsure, and who handles it. This is where the real design effort belongs, not in the happy path.

## The version that works

Pick one process where the outcome is genuinely agreed and measurable. Automate the drafting, not the deciding. Keep a person approving anything irreversible. Log everything. Measure whether the drafts are being heavily edited, because that is the signal that it is costing time rather than saving it.

That is unglamorous and it works. The alternative — agents across an undefined process — produces a pilot that demos beautifully and is quietly abandoned two quarters later, which is currently the most common outcome in this category.

## The uncomfortable consequence

Sometimes the honest recommendation is that the AI project should be a process project first, and that is a harder thing to get budgeted because it is less exciting and the benefit is deferred.

But the sequence is not optional. Automating a process nobody has defined does not define it. It encodes one person’s version of it, at speed, with an authority nobody intended to grant.

-   AI agents
-   process
-   automation
-   readiness

## Keep reading

-   [The constraint is change capacity, not strategy](https://vucale.com/blog/the-constraint-is-change-capacity)
-   [A consultancy that resells cannot advise you](https://vucale.com/blog/a-consultancy-that-resells-cannot-advise-you)