One of the most revealing moments in an AI project happens before anything is built.
You ask a group of people to explain the work they want the agent to do.
At first, everyone agrees. The process sounds straightforward. A request comes in, some information is collected, a decision is made and an output is produced.
Then you start asking specific questions.
What does a good result look like? Which rules can bend? What happens when the information is incomplete? Who can approve an exception? Which team owns the result when something goes wrong?
Suddenly, there are three versions of the process in the room.
This is often described as an AI problem. The agent needs a better prompt. The workflow needs more detail. The system needs another integration.
But quite often, it is a management problem.
The organisation has never agreed on how this part of the business should operate. People have learned to work around the gaps, interpret the politics and bring the difficult cases to someone senior.
AI did not create that ambiguity.
It exposed it.
The calculator contained the official rule
I saw this clearly while working with an organisation on its quotation and proposal process.
The sales team shared a pricing calculator. Leadership had set the assumptions and numbers inside it. On paper, it represented the commercial rules of the business.
In practice, the sales team believed they could not win enough work using the calculator as designed.
So they overrode it.
Different salespeople used different numbers. Custom approvals became normal. Scope was added to make the proposal more attractive, because adding scope often felt easier than defending the price.
Then the work moved to delivery.
Delivery inherited commitments it could not comfortably meet for the price that had been agreed. The sales team was rewarded for winning the work. The delivery team carried the margin and execution risk after the contract was signed.
Every team had a reasonable explanation for its behaviour.
Sales needed to get the deal over the line. Delivery needed the work to be feasible. Leadership wanted the revenue and had approved the calculator in the first place.
The calculator contained the official rule.
The approval behaviour contained the real one.
A valuable contract reveals how the business really works
The disagreement becomes sharpest when there is real money on the table.
It is easy to support pricing discipline in a workshop. It is harder when a customer is ready to sign a $50,000 contract and one exception might close the deal.
In that moment, leadership often sides with sales.
That decision may be right. The problem is not that an exception was made. The problem is that the organisation has not said what the exception means.
Was the calculator wrong? Was this customer genuinely unusual? Was delivery expected to absorb the additional scope? Should the margin target change? Was the exception an experiment, or simply the result of pressure?
Without an explicit answer, each team leaves with a different lesson.
Sales learns that the calculator is optional when the opportunity is valuable enough. Delivery learns that commercial discipline disappears near the signature. Leadership may still believe the standard process is broadly being followed.
The ambiguity allows all three beliefs to coexist.
Why can’t the AI just learn from what people do?
It is tempting to train an agent on the organisation’s previous quotations and approvals and let it reproduce the patterns it finds.
That would be technically neat and commercially dangerous.
The historical data contains both the written rule and all the ways people worked around it. It contains good judgement, necessary exceptions, inconsistent decisions and unresolved conflict.
The agent cannot know which behaviour represents the strategy simply because it happened more often.
If it follows the calculator, sales will say it is too rigid.
If it copies the sales team’s overrides, delivery will say it is making unprofitable commitments.
If it sends every unusual case to leadership, it has automated the preparation but preserved the same approval bottleneck.
Automating an unclear process does not resolve the disagreement. It gives the disagreement speed and consistency.
This is why more data is not always the answer. Data can show what the organisation did. It cannot, by itself, decide what the organisation intends to do next.
Sometimes ambiguity is doing a job
Not every unclear process is the result of poor documentation.
Ambiguity can preserve flexibility. It can allow capable people to respond to unusual circumstances. It can help teams move while competing priorities remain unresolved.
It can also protect people.
If the expected outcome is unclear, accountability is unclear. If an exception policy is informal, nobody has to state which team should carry its cost. If leadership can decide case by case, it never has to commit to a rule that others can depend on.
This does not mean people are acting in bad faith. Often the work has evolved gradually and the organisation has become skilled at managing around the tension.
But the tension becomes impossible to ignore when an AI agent needs an answer it can apply repeatedly.
Sometimes a workflow is unclear because clarity would force the organisation to decide who owns the result.
Delivery was not resisting automation
From outside the room, delivery’s objections could look like resistance to change.
Why not let an agent generate the proposals? Why does the process need so much discussion? Why are we making a simple automation difficult?
But delivery was not resisting automation.
It was resisting the automation of an unresolved commercial conflict.
Once an agent is producing quotations quickly and consistently, any weakness in the underlying decision scales with it. A single awkward handover becomes a stream of work arriving with the same hidden problem.
This is an important distinction for leaders.
The person asking difficult questions about the workflow may not be blocking progress. They may be identifying the decision that makes safe progress possible.
The specification forces useful decisions
A spec-driven organisation does not ask AI to infer the real policy from a mixture of documents and behaviour.
People decide what the business is trying to achieve, what must be protected and who has authority when those things come into tension.
For the quotation process, leadership would need to settle questions such as:
- Is the calculator a rule or a starting point?
- Which margins must always be protected?
- What can sales change without asking?
- When can scope be traded for price or risk?
- What information must accompany an exception?
- Who can approve it?
- What is delivery committing to when that approval is given?
- Who owns the whole commercial outcome, rather than one team’s local target?
These are not fields for the implementation team to fill in.
They are management decisions.
Once they are made, the organisation gains more than an automatable workflow. Sales, delivery and leadership begin operating from the same commercial logic.
A specification turns a management decision into repeatable organisational behaviour.
What if leadership cannot answer everything yet?
That is normal.
A specification does not need to pretend the organisation has reached perfect agreement. It needs to distinguish what has been decided from what has not.
“We have not decided whether sales can trade margin for a longer contract” is useful operating guidance.
The agent can stop at that boundary, collect the relevant information and bring the decision to its owner. What it should not do is quietly invent a policy because the specification looked incomplete.
Explicit uncertainty is safer than false completeness.
It also lets work begin without turning every unanswered question into a six-month transformation programme.
Five questions to ask before building the agent
Before discussing tools, models or integrations, bring the people who do the work and receive its output into the same conversation.
Ask five questions.
1. What result is the whole business trying to produce?
Not the sales output, the delivery output or the manager’s approval. What outcome must the organisation be able to stand behind?
For a proposal, that might be a sale the customer values, the business can deliver and the organisation can make acceptable money from.
2. Where do the official rules and actual behaviour differ?
Look for repeated overrides, side conversations, personal spreadsheets and approvals that are described as exceptional but happen every week.
The gap is valuable. It shows where the written process has stopped representing reality.
3. Which trade-offs are already decided?
Be clear about the room people and agents have to move. Can they reduce scope, adjust timing, offer a standard concession or select between approved packages?
A decision that has already been made should not keep travelling back to management.
4. Which questions are genuinely open?
Name them. Give them an owner. Decide whether the work must stop there or can continue around them.
Do not let silence look like permission.
5. Who owns the outcome across the handoff?
An agent working inside one team can easily optimise that team’s target at somebody else’s expense.
Ownership has to reach far enough to include the consequences of the decision.
The two returns on clarity
This work creates two benefits.
The first is the obvious one: the agent becomes easier and safer to build. It has a goal, boundaries and clear points of escalation.
The second may be more valuable: the organisation becomes better aligned even before the agent is switched on.
Sales knows which promises it can make. Delivery knows what it is expected to honour. Leadership can see where exceptions are happening and decide whether the commercial model needs to change.
The AI project has forced a conversation the business was already paying for through rework, approvals, tension and lost margin.
That is why I no longer see specification as a technical step at the start of automation.
It is a piece of organisation design.
Bottom line
Your AI problem may actually be a management problem when the organisation has not agreed on the goal, rules, trade-offs or ownership behind the work. An agent cannot safely resolve that ambiguity for you. It can only reproduce one version of it at greater speed.
AI is useful here because it makes the disagreement visible.
The answer is not to document every existing behaviour. It is to bring the right people together, make the unresolved decisions explicit and capture the current organisational commitment in a living specification.
Then the agent has something real to work from, and the people do too.
BusyWork Dispatch helps businesses turn AI ideas into working software, automations and agents by first making the purpose, boundaries and open decisions clear. The Workbook preserves that durable context while Dispatch connects it to work that gets built and shipped. See how BusyWork works or book a call with Ben.
