A better prompt can improve an answer. It cannot decide who owns the result, whether the source material is current, or what happens when the answer is wrong.
I care about prompt quality, but I do not want the quality of my work to depend on remembering the perfect wording every time I start a conversation. I want a repeatable way to define the work, give AI useful context, inspect the result, and decide what can happen next.
That is a system, even when it consists of nothing more than a short brief, a shared document, and one person responsible for review.
This is the first article in Human Systems for AI Work, a six-part series about the human arrangements around AI-assisted work. The opening three articles cover working practices, judgment, and accountability at the interface. The focus is not how to operate a particular tool. It is how to keep useful work connected to purpose and responsibility as producing it becomes easier.
A prompt is only one part of the work
Consider a team preparing a customer update about a delayed delivery. Someone asks AI to write a clear, empathetic message. The draft is readable and professional. It also promises a new delivery date that nobody has approved.
A more careful prompt might prevent that promise. But several other things could have prevented it too: a source document that distinguishes confirmed dates from estimates, a rule against making new commitments, or a review that explicitly checks promises before sending.
The problem is not necessarily that the person failed to discover the right sentence to put in the prompt. The work may never have had an agreed boundary between explaining a decision and making one.
My starting question is therefore not “How do I ask this better?” It is “What would have to be clear for this work to be done responsibly?”
Sometimes the answer is better wording. Often it is a missing decision, missing evidence, or missing owner.
Start with the use, not the requested output
“Write a summary” describes an artifact. It does not explain what the summary must help someone do.
A summary for deciding whether to renew a vendor contract needs different information from a summary for onboarding a new colleague. The first may need unresolved service failures, alternatives, and costs. The second may need contacts, routines, and responsibilities. A fluent summary can fail either purpose while remaining accurate sentence by sentence.
Before using AI, I want to establish the reader, the decision or action, and the conditions that would make the result useful.
For the customer update, that might mean: existing customers need to understand what changed, what remains uncertain, and when they will hear from us again. The message must not create a commitment beyond the approved plan.
That brief gives the writer and reviewer the same target. It also makes unnecessary work easier to reject. We do not need six tones, a campaign concept, or a new explanation of the company's values. We need one accurate message that customers can act on.
Separate standing expectations from current facts
Some instructions should survive across tasks. Others should expire as soon as the situation changes.
“Do not invent commitments” is a standing expectation. “The next update is scheduled for Thursday” is a current fact. Combining both in an enormous reusable prompt makes maintenance difficult. Someone eventually reuses an old date because it sits beside instructions that still apply.
I prefer a short working agreement for recurring behavior and a separate brief for the current task.
The agreement can describe how uncertainty should be reported, which actions require permission, and what counts as reviewed work. The brief supplies the audience, source material, current constraints, and intended use.
Neither needs to be elaborate. The separation matters because they change for different reasons. A deadline changes because the project changes. An approval rule changes because responsibility or risk changes.
If a standing instruction needs a paragraph of exceptions for every task, it probably belongs in the task brief or needs to be narrowed.
Make context usable, not merely available
Giving AI more documents does not resolve contradictions between them.
Suppose the customer update draws on an old project plan, recent meeting notes, and a message from an account manager. The plan contains the original date. The notes describe a possible replacement. The account manager says a customer has already been told something else.
The useful preparation is to identify which information is authoritative, what remains disputed, and who can resolve the discrepancy. Asking for a confident synthesis before doing that encourages a clean answer to an unsettled question.
I would rather provide a small set of relevant material with explicit status than a large collection labeled “context.” Confirmed facts, proposals, and unresolved questions should remain distinguishable.
This also creates a privacy boundary. A writing task does not automatically justify sharing every customer record or internal discussion. Use only material the task requires and the organization permits the tool to handle. Convenience is not permission.
Decide what AI may do before it does it
Drafting a message, approving its commitments, and sending it are separate actions.
Natural conversation can blur those distinctions. “Handle the customer update” may mean prepare a draft to one person and send a finished message to another. The ambiguity becomes consequential when a tool can act outside the conversation.
A working agreement should identify which decisions are delegated and which remain with a person. For this example, AI can organize the approved facts and propose wording. The project owner confirms the commitments. The account owner decides whether the message fits the customer relationship and authorizes sending.
Small teams may assign all of those responsibilities to one person. They still benefit from recognizing the separate decisions.
The point is not to require permission for every sentence. It is to avoid treating a request for assistance as unlimited authority. Routine, reversible preparation can move quickly. External promises need a more deliberate boundary.
Design review before generating the draft
Review is more useful when it has a purpose beyond “make sure this looks good.”
For the customer message, the important checks are concrete: does it match the approved facts, distinguish estimates from commitments, and tell the customer what happens next? Is every promise owned by someone who can keep it?
Those checks should exist before the draft. Otherwise the review can become an exercise in improving the answer already on the screen rather than asking whether it meets the need.
I also want unresolved issues to survive the writing process. If a delivery estimate has not been approved, a draft should flag that gap rather than quietly choose a date. An incomplete draft with a clear question may be more useful than a polished message that conceals the decision still required.
Review effort should follow consequence. A private outline needs less scrutiny than a message announcing a contractual commitment. Applying the same approval ritual to both wastes attention that the more consequential work needs.
Keep a small record of consequential decisions
A chat history is not a reliable substitute for a decision record. It mixes proposals, corrections, rejected ideas, and final choices. A colleague should not have to reconstruct the conversation to discover which date was approved.
For consequential work, keep the final decision, its owner, the evidence it relied on, and any unresolved condition beside the finished artifact. The record can be a few sentences.
This is particularly useful when work changes hands. The next person needs to know whether they are receiving a draft, a reviewed recommendation, or something approved for release. They also need to know what would invalidate that approval.
If the delivery estimate changes after review, the old approval should not silently apply to the revised message. Approval belongs to a particular version and set of facts, not to the general topic forever.
Improve the system from specific failures
When an AI-assisted task goes wrong, rewriting the whole prompt is an easy response. I prefer to locate the failure first.
Was the purpose unclear? Was the source wrong? Did the model ignore an explicit boundary? Did review miss an unsupported claim? Did someone act on a draft before approval?
These failures need different corrections. Another instruction cannot repair an outdated source. A better source cannot give a reviewer time they do not have. A review checklist cannot prevent an unauthorized action if the tool already performed it.
Change the smallest part of the process that plausibly addresses the failure, then watch whether the change helps. Avoid turning every unusual mistake into a permanent rule. An agreement that nobody can read or maintain is not a dependable agreement.
Success deserves inspection too. A result may be correct because the process worked, or because an experienced person quietly repaired it. Those are different foundations for repeating the work.
Do not build more process than the task needs
There are cases where a better prompt really is the appropriate fix. If I am exploring headings for a private note, I do not need an approval record or a formal evidence review. I need to describe the purpose more clearly and choose a useful result.
A system also cannot compensate for every model limitation. If the task requires knowledge or reliability the tool cannot provide, adding instructions may only make the output more convincing. The right decision may be to narrow the task, involve a qualified person, or stop using AI for that part of the work.
Nor does documentation create agreement where people disagree. If two teams have conflicting goals, AI cannot resolve the authority question by producing a balanced paragraph. Someone still has to decide.
The test for process is whether it improves decisions or prevents a meaningful failure. If a step does neither, remove it.
Start with one recurring task
Choose one task you expect to do again. Write down its purpose, the material it can rely on, the authority AI has, and the evidence you need before using the result.
Try that arrangement on the next few instances. Notice where you still have to clarify, repair, or intervene. Improve those specific points.
The goal is not a prompt that anticipates everything. It is a way of working that makes the next important question visible before the answer becomes a commitment.