What gets in the way
Most companies do not have a prompting problem. The work has not yet been made explicit enough for either a person or an AI to execute it reliably.
My starting point
I do not think effective use of AI is about writing clever prompts. A prompt can ask for an output. It cannot decide what a good outcome is.
A specification is where a person makes that decision explicit: the problem, the inputs, the boundaries, the decisions that remain human and the tests the result must pass. This is not administration before the real work. It is where an initial idea becomes something that can be questioned, improved and verified.
AI can help expose what is missing, challenge assumptions and carry out much of the execution. The person still owns the intent. That is true whether we are building software, designing an operational process, creating a review method or deploying an AI agent.
Eight problems we keep finding
01
What it looks likeThe team keeps rewriting a prompt and comparing outputs, but nobody has written down the result the business actually needs.
What is actually wrongThe missing part is not a better instruction to the model. It is a shared specification of the problem, inputs, boundaries, owner and acceptance tests.
First useful move
Describe one real piece of work from input to accepted result before choosing a model or building an agent.
02
What it looks likeThe AI produces something plausible, but reviewers disagree about whether it is correct, complete or ready to use.
What is actually wrongThere is no acceptance contract. Quality remains an opinion because the required fields, evidence, thresholds and failure conditions were never made explicit.
First useful move
Turn the expected result into checks that can pass, fail or wait for a named reviewer.
03
What it looks likeThe documented process looks simple until the person who does the work explains the exceptions, shortcuts and judgement calls.
What is actually wrongAutomating the diagram would automate an incomplete process. The operational knowledge sits with people and only appears when a real case is walked through.
First useful move
Map representative cases with the people doing the work, including what makes them stop, ask or refuse.
04
What it looks likeThe answer depends on an email, a document, a CRM record and a status in another system, but the AI sees only one of them.
What is actually wrongThe model is being asked to reason without the evidence people use today. Copying more data into a prompt does not create a dependable operating context.
First useful move
List the exact reads the task needs, expose only those operations and keep a source next to every material fact.
05
What it looks likeA prototype cannot do useful work because it is isolated, or it receives a broad account that can reach far more than the task requires.
What is actually wrongA prompt telling an agent what not to do is not a permission boundary. Identity, allowed tools, budgets and refusals must be enforced outside the model.
First useful move
Start read-only with a separate identity and a short allow-list. Add one class of action only after its controls pass.
06
What it looks likeThe design says a person approves the result, but it does not say who, at which point or what that person actually sees.
What is actually wrongApproval is not a button at the end. The reviewer needs the exact message, change or record that will take effect, together with the evidence and a clear right to refuse.
First useful move
Name the approver and show the exact action at the moment before it changes the real world.
07
What it looks likeThe prototype worked, but nobody owns model changes, permissions, incidents, cost, backups or the next version.
What is actually wrongThe project delivered a capability without an operating model. An agent in production is a service that changes over time, not a finished presentation.
First useful move
Assign one operational owner and agree the runbook, limits, monitoring, change path and retirement path before launch.
08
What it looks likeThe team can show that the AI produces an answer, but not whether the real task became faster, safer or easier to review.
What is actually wrongA fluent output is not an operational result. The useful measures are cycle time, exceptions, corrections, accepted work and the effort people still spend checking it.
First useful move
Run a fixed-scope pilot on representative work and measure the agreed outcome before discussing scale.
Direct answers
Yes. A prompt is useful for starting and steering a task. It becomes unreliable when it is expected to replace a definition of the result, the available evidence, the operating boundaries and the tests the work must pass.
At minimum: the problem, representative inputs, expected output, allowed data and tools, decisions that remain human, known exceptions, acceptance tests, owner and evidence that must be retained.
No. Start with one bounded task and enough representative cases to expose its normal path and important exceptions. The pilot should improve the specification as well as test the implementation.
When a clear rule, a simple integration or a better screen solves the problem more reliably. AI earns its place when the work needs interpretation across messy inputs and the result can still be checked.
A useful place to start
Show us one recurring task that takes too long, fails too often or keeps waiting for somebody. We will map the work first—and tell you honestly whether AI belongs there.
Bring me what is not working