There is a point in almost every AI project when someone asks, “Can we build it now?”
Usually, the technology can.
The agent can read the documents. It can connect to the system. It can generate the output. It may even produce an impressive demonstration in the room.
That does not mean the process is ready.
I have seen teams spend weeks trying to improve an agent when the real problem was that the organisation had not agreed what the agent was supposed to do.
Sales thought one thing. Delivery thought another. The manager believed an exception was obvious. The team receiving the work expected something nobody had included in the brief.
The agent was ready to execute.
The organisation was not ready to be specific.
A working demo is not the same as a ready process
An AI demonstration usually proves that the technology can perform a task under friendly conditions.
It does not necessarily prove that the business is prepared to depend on the result.
A proposal agent might be able to turn a discovery-call transcript into a polished document. That is a useful demonstration.
But before it begins sending proposals, someone still needs to answer:
- Which pricing assumptions are authoritative?
- What margin has to be protected?
- What can be changed to win the work?
- Who decides when an exception is justified?
- What must delivery confirm before the proposal becomes a commitment?
- Who owns the outcome if the project cannot be delivered as sold?
If the people involved have different answers, more prompt engineering will not make the process ready.
It may make the disagreement harder to see by wrapping it in a convincing output.
A successful demo proves the agent can act. Readiness proves the organisation can stand behind what it does.
Readiness is one of three tests
Readiness sits inside a larger selection question. When I help organisations choose where to start, I test candidates against three categories: valuable, ready and safe to learn with.
Readiness asks whether the work can be delegated. Prioritisation asks whether this is the work the organisation should delegate first.
This article is about the readiness test. The full selection method, including the value and safety tests and a simple scorecard, is in how to choose your first AI loop. The short version of the design principle appears later in this piece: make the first version small and whole.
Readiness is partly social
We tend to assess AI readiness as if it were a technology checklist.
Does the data exist? Can the systems connect? Is the model capable? Have access and security been addressed?
Those questions matter. They are not the whole test.
The people who carry out the work and the people who receive its output need to agree on what is being introduced.
Not the whole future state. Not every possible exception. The part that will actually go live.
For a proposal agent, that might include the salesperson who owns the relationship, the sales manager who can make commercial decisions and the delivery team that has to fulfil what is promised.
They need a shared understanding of:
- where this part of the process begins;
- what the agent will produce;
- what quality looks like;
- what each person is expected to do;
- what the agent may decide;
- where it must stop; and
- what happens at the handoff.
Agreement does not mean everyone loves every decision.
It means the organisation has made a commitment that the people affected can understand and work from.
If delivery is expected to accept a proposal it had no part in defining, the agent is not ready. If sales believes the agent’s price is a suggestion while finance believes it is a rule, the agent is not ready.
The workflow may run. The business will still pull it apart.
The affected people are not only the users
This is an easy group to define too narrowly.
The people using the agent are obvious. The people receiving the consequences can be less visible.
A recruitment agent may be used by talent acquisition, but hiring managers receive its shortlist and candidates experience its communication.
A marketing agent may be used by a campaign team, but sales handles the leads and customer service handles the promises.
A proposal agent may save sales hours while quietly transferring risk to delivery.
That is why the readiness conversation has to follow the output.
Ask: Who has to trust, use, fulfil or live with what this agent leaves behind?
Those people do not all need to design the agent. They do need to agree on the handoff they are being asked to depend on.
“We have not decided” is a useful answer
Teams often think a specification must appear complete before an agent can use it.
That creates pressure to fill every gap.
Sometimes a person invents a rule in the workshop. Sometimes the AI writes something plausible. Sometimes careful but vague language hides the fact that nobody actually agreed.
False completeness is dangerous because the agent cannot tell the difference between a deliberate decision and confident-looking filler.
A living specification does not need every answer.
It needs to be honest about which answers exist.
“We have not decided whether the agent may approve a discount above this level” is usable guidance.
The agent can stop there. It can present the options. It can send the decision to the sales manager. It can continue with the parts of the work that do not depend on the answer.
What it should not do is infer a new commercial policy from three previous exceptions and apply it to every future customer.
Explicit uncertainty is safer than false completeness.
An open decision is not a failure of the specification. It is a visible boundary around the agent’s authority.
Small is not enough. It also has to be whole.
The usual advice for introducing AI is to start small.
That is right, but it is incomplete.
A small piece can still be useless if it stops before producing an outcome anyone can use.
Imagine the first version of a proposal agent only drafts the opening page. It is small. It also leaves a person to collect the customer context, calculate the price, assemble the scope, find the right case studies, check the margin and move everything into the final document.
The agent has automated a fragment while the person remains the integration layer.
A better first version might:
- begin with an approved discovery-call transcript and opportunity record;
- produce a complete draft using standard pricing and current brand material;
- check it against agreed commercial and delivery boundaries;
- flag anything that needs human judgement; and
- leave behind a proposal ready for a named person to approve.
It still does not negotiate with the customer. It does not approve unusual discounts. It does not rewrite the commercial model.
But it is whole. It begins in a known state, creates something valuable and ends at a dependable handoff.
Start small and whole, not broad and rough.
Broad and rough spreads uncertainty across the organisation. Small and whole gives you something real that people can use, test and improve.
Define the edges before filling in the middle
Traditional process design often begins by mapping every step.
For agentic work, I would begin with the edges.
What must be true before it starts?
What information, permission or prior work must exist before the agent can begin safely?
For example: the customer has consented to a discovery call being recorded, the transcript is available, the opportunity owner is known and the product catalogue is current.
What must be true when it finishes?
What does “done” mean in a way the next person or system can check?
For example: the proposal reflects the customer’s stated needs, uses the current offer, meets the standard margin, identifies every exception and is ready for commercial approval.
What can never be crossed?
Which boundaries protect the customer, the organisation or another team?
For example: do not invent a capability, do not expose confidential customer information and do not commit delivery to unapproved custom work.
Who receives the result?
Name the owner of the handoff. Avoid ending with “send for review” when nobody knows who must review what.
Once those edges are clear, the agent can often choose an efficient path through the work without a thirty-step procedure.
A practical readiness test
Before putting an AI agent into real work, bring together the owner, someone who does the work and someone who receives its output.
Then answer these eight questions in plain language.
1. What useful outcome will this first version produce?
Describe the result, not the technology. If the answer is “use AI to improve proposals,” the outcome is not yet clear enough.
2. Where exactly does its responsibility begin and end?
Name the entry point and the handoff. A fuzzy boundary becomes a human cleanup job later.
3. What must always be true?
Identify the small number of rules or quality conditions that cannot be traded away.
4. What may the agent decide by itself?
Autonomy should be explicit. Do not make the agent ask about decisions it already has authority to make.
5. What has the organisation not decided?
Write the unanswered questions down. Name who owns each one and what the agent should do until it is answered.
6. Do the people receiving the output accept the handoff?
Ask them directly. A technically valid output is not useful if the next team cannot depend on it.
7. Who owns the result?
The agent can carry out work. Accountability still belongs to a person with the authority to change the specification.
8. Can this slice run from beginning to end?
If it only automates a fragment and leaves someone copying, reconciling and repairing around it, make the slice smaller or more complete.
If these answers are clear, you probably know enough to begin.
If the meeting produces several competing answers, that is useful too. You have found the decisions that stand between a demonstration and a dependable way of working.
Do not wait for perfect agreement
Readiness does not mean predicting every edge case.
The first live version will teach you things the workshop cannot. People will use the output differently than expected. A customer will ask for something new. A boundary will turn out to be too tight or too loose.
That is why the specification is living.
The aim is enough clarity to run one valuable slice safely, plus an honest way to handle what remains unknown.
Waiting for total certainty turns readiness into a planning programme. Moving ahead with hidden disagreement turns it into expensive rework.
The useful middle is a clear commitment over a small surface area.
How this fits a spec-driven organisation
A spec-driven organisation does not attempt to document the whole company before AI can do anything.
It makes one part of the business clear enough for people and agents to work from the same understanding.
The specification records the outcome, boundaries, owner and open decisions. The work tests that understanding against reality. What the organisation learns flows back into the specification deliberately.
Then the useful surface expands.
One small, dependable Loop becomes two. One reliable handoff connects to the next. The organisation grows its ability to delegate without scaling uncertainty at the same time.
Bottom line
A process is ready for an AI agent when the affected people agree on the slice going live, the agent can distinguish decided rules from open questions, and the work has a clear beginning, valuable outcome and dependable handoff.
Do not mistake a capable agent for a ready organisation.
Start with the smallest piece of work that can run properly from beginning to end. Make uncertainty visible. Put real decisions in front of their owners rather than allowing AI to guess.
Start small and whole, not broad and rough.
BusyWork Dispatch helps organisations turn one useful piece of work into a clear Loop, supported by a Workbook that preserves its purpose, boundaries and open decisions. See how BusyWork works or book a call with Ben.
