"Review this tender and tell me if we should bid."
That is a reasonable thing to say to a colleague, because a colleague brings a decade of shared context to it. They know what your firm does, what you have lost before and why, which departments are difficult to work with, and that "should we bid" really means "is this worth three weeks of somebody's life".
Said to an agent, the same sentence is a request to invent a methodology. It will invent one. It will invent a slightly different one tomorrow.
The difference is reviewability
Both instructions are written in English. The distinction is not formality or length, it is whether a person who was not in the room can check the work.
With a vague prompt, the output arrives as a single verdict. If you disagree with it, you have nowhere to put the disagreement. You cannot say the reasoning was wrong at step four, because there were no steps. The only available responses are to accept it, reject it, or ask again and hope for something better.
With a spec, disagreement has an address. The deadline extraction was right, the capability comparison was wrong because it did not know about the certification we got in March, and everything downstream of that is therefore suspect. That is a conversation a bid lead can have, and it is the conversation that improves the system.
What a spec looks like
Eight steps, for tender qualification. Nothing exotic.
The steps themselves are the obvious part. The discipline is in what each one carries, which is three things: what it takes as input, what it produces as output, and what it does when it cannot answer.
That third element is the one teams leave out, and it is where hallucination enters. A step that says "extract the submission deadline" with no failure branch will always produce a date. A step that says "extract the submission deadline; if the document states more than one, or none, list what you found and stop" will tell you the truth about an ambiguous pack. The difference in output quality is dramatic and it costs one clause.
Natural language as a specification language
This is a genuinely new thing, and it is worth naming.
For most of software history, a specification had to be translated into code before a machine could act on it. The specification was documentation and the code was the system, which is why they drifted apart, and why every organisation has a folder of requirements documents that describe a system nobody has been running for years.
With agents, the natural-language spec is the executable thing. There is no translation step to drift through. That has an interesting consequence for who can write one: a domain expert who could never write the code can write the spec, and it will run.
It also raises the standard for how the spec is written. If a step is ambiguous, the ambiguity is not caught by a compiler. It is resolved by the model, silently, differently each time. A spec that reads well and specifies nothing is worse than no spec, because it produces confidence without control.
The useful test is to read it as an instruction to a competent new colleague on their first week. Would they know what to do? Would they know what to do when the document is unusual? If not, the agent will not either.
Specs worth writing down
A handful of workflows repay this treatment quickly, because they are done often and done inconsistently.
Tender qualification. The eight steps above. High volume, high cost of a wrong call, and currently held in the heads of two or three people.
RFP architecture review. Extract the stated requirements, identify what is unstated but implied, name the assumptions the response depends on, flag which of those assumptions a reviewer must confirm.
Lead triage. Determine the buyer, determine whether budget exists or only interest, identify whether there is an architecture decision in scope, rate fit, recommend a next action.
Cloud cost review. Identify the top spend lines, compare to the previous period, separate growth from waste, list the three changes with the largest effect and what each would break.
AI readiness assessment. Establish where the data lives, what the governance position is, which workflow is the candidate, what would have to be true for a pilot to be safe.
Each of these is currently done by an experienced person applying an unwritten method. Writing the method down is valuable even if no agent ever runs it, which is a reasonable secondary argument for doing this work.
Where specs and defaults meet
A workflow spec is what sits behind the button described in smart defaults. The user presses "check compliance"; the spec is what runs. That is the whole relationship, and it is why the two ideas belong together: a default with no spec behind it is just a shorter way to be inconsistent.
It also means the spec inherits the governance the button implies. One version, one owner, changed deliberately, tested against known cases before release.
What good looks like
Numbered steps, in the order a person would do them.
Every step naming its input, its output, and its behaviour when it cannot answer.
An explicit uncertainty step at the end, so that "I am not sure" is a valid and expected outcome rather than a failure.
A named owner and a version, because this is production configuration.
A set of known cases the spec is tested against before any change ships, which is the eval discussion.
Practical checklist
- Write the workflow as numbered steps before writing any prompt
- Give every step an input, an output and a "cannot answer" branch
- End with an explicit escalation step
- Read it as instructions to a new colleague and fix what they would get wrong
- Version it, and put one person's name on it
- Test it against known cases before every change
How CloudNala can help
Writing the spec is usually the engagement, and it is more of a facilitation task than a technical one. The method exists already, in the heads of the two people who do this work well; the job is to get it out, resolve the parts where they quietly disagree, and write it down in a form that both a colleague and an agent can follow. The technical work afterwards is comparatively straightforward.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za