The Job Beneath the Prompt

Someone on a support team types “Write a response.” The model returns a polished draft.

A polished draft can still promise the angry customer something the team can’t deliver. Who is this customer, and what already went wrong? What can the team actually commit to? When should the system ask instead of guessing? Those three words carried none of that.

Prompts are requests, not context

“Summarize this account.” “Build a launch plan.” “Tell me what to do next.”

Each prompt names an output. None explains why the person needs it, what changed, what risk they’re managing, or how they’ll judge whether the result is useful.

The account summary may be for a routine check-in or a renewal rescue. The response may be a low-stakes acknowledgment or a message to an angry customer. The launch plan may be for an internal experiment or a public commitment the company can’t easily reverse.

The words look similar. The stakes, evidence, tone, and right level of autonomy are different.

The job gives the prompt a world

For product design, the difference decides adoption. Most AI tools are built around a functional job like draft faster, answer questions, summarize meetings, write emails. That’s table stakes. But teams don’t adopt tools on functional output alone, because work is never purely functional. One embarrassing mistake can outweigh ten helpful wins.

Job context begins before the request, in the moment that triggered it.

What happened that caused the person to ask? What are they trying to move from and toward? What have they already tried? What constraints can’t be violated? What would make the result feel safe to use? Who else will see it? What happens if it’s wrong?

That context lives across three layers:

• Functional progress: what needs to get done.
• Emotional progress: what the person needs to feel to move forward.
• Social progress: what they need to signal, protect, or defend in front of other people.

“Draft the response” is functional. “Help me resolve this without sounding evasive, promising something we can’t deliver, or making the customer repeat the story” is the job.

The second description gives the system a standard for judgment. An agent can finish the task and still miss the job. When it does, the gap lands on the person who shipped its work.

Chat history isn’t job memory

Give a team a new AI capability and the product almost builds itself. The model answers questions—add a chatbot. So chat boxes get bolted on everywhere, with the same rookie mistakes. The first is treating the obvious interface as if it understands the situation. It doesn’t. No one is hiring a chatbot. They’re trying to get an answer they can act on.

The second is mistaking more conversation for more context. A long transcript can contain useful clues, but it doesn’t automatically organize them around the job. That’s why AI without job context keeps behaving like autocomplete.

The system needs to know which facts are current, which preferences are stable, which correction was a one-time exception, which source is authoritative, and which outcome the user is pursuing now.

Memory of the chat is chronological. Memory of the job is structured. It connects the trigger, the object being changed, the constraints, the evidence, the desired progress, and the decisions already made.

It also knows what not to remember. A warmer tone requested for one customer shouldn’t rewrite every future message. Useful context has scope, and scope is a permission question.

Knowing the job changes the interface

If the product makes the user prompt their way into that context every time, it’s pushed too much of the job back onto them. Once the product knows the job, the interface stops acting like a blank box.

It can surface the relevant customer, document, workflow, or decision before the user explains everything again. It can ask one focused question when the stakes are unclear. It can know whether to draft, prepare, recommend, or act.

The response also becomes easier to evaluate. The user can compare it with the job, not with an abstract idea of “good AI output.”

Did it reduce the burden? Respect the constraint? Preserve authorship? Make the next move clearer? Keep the user from looking careless in front of someone else?

The job has to outlive the prompt

Before an AI performs meaningful work, the product should be able to represent the job. That doesn’t need to appear as a giant form. Much of it can come from the product’s existing state. But it needs to exist somewhere more durable than the latest prompt.

Authority states what the AI may suggest, prepare, or do. Handoff states when a person must take over. If you ever plan to automate the tedium with a workflow tool like n8n, it just so happens these are the same decisions a job spec for an agent needs.

The test

If the team can’t fill in the card, the AI is producing against a request with no job beneath it. It may sound polished. It may even be correct. It still won’t know what relief it was supposed to create.