Prompts: not longer, but not just the goal either

Compared with chat, which is mostly one-off answers, an agent can read files, search for material, call tools and run commands on its own, then keep adjusting based on the results.

So a prompt really doesn’t need to be an operating manual anymore, arranging everything for the agent: what to do first, what next, and what method to use at each step.

But the opposite extreme is a problem too:

tell the agent only a goal, and let it decide everything else.

An agent can find its own way, but it can’t decide for you:

• what problem you really need solved;
• which result matters more;
• which costs are unacceptable;
• how far it has to go to count as done.

In its official Codex best practices, OpenAI gives a very direct default structure:

“A good default is to include four things in your prompt: Goal, Context, Constraints, Done when.”

That is: the goal, the necessary background, the constraints and the definition of done. This helps Codex narrow the task, make fewer assumptions of its own, and produce results that are easier to review.

Anthropic’s advice on agent context isn’t “the shorter the better” either, but to find the smallest set of high-signal information that’s enough to complete the task, with a specific reminder:

“Minimal does not necessarily mean short.”

Information that should be written still needs writing; just don’t let the key requirements drown in irrelevant background and repeated rules.

So, more precisely:

an agent prompt doesn’t need a complete execution process, but it does need complete key decisions.

Understanding the four through one meeting

Say you hand an agent the recording of a 90-minute meeting and just say:

tidy up this meeting for me.

It will most likely produce a nicely organized summary.

But the summary may not solve the real problem:

• What was finally decided in the meeting?
• Which things are only suggestions, not yet confirmed?
• Who needs to do what?
• What are the deadlines?
• Which questions still have no conclusion?

The agent finished “tidying up,” but not necessarily the work you actually needed.

That’s exactly what Goal, Context, Constraints and Done when each address.

1. Goal: once it’s done, what should be different?

“Tidy up the meeting recording” is just an action.

A clearer Goal is:

turn the meeting into a trackable list of decisions and actions, so that afterwards nobody understands the decisions, owners and next steps differently.

The difference between the two:

• the action tells the agent what to do;
• the Goal tells the agent why, and what change you ultimately hope for.

“Read the documents,” “analyze the data,” “change the page” are usually just means.

When checking a Goal, you can ask:

once the task is done, what should be clearer, smoother or more reliable than it is now?

2. Context: not the project’s autobiography, but the facts judgment requires

Context isn’t stuffing all the relevant history into the prompt.

It should contain only the information that:

the agent can’t reliably guess, and that affects the current judgment.

In the meeting-notes example, useful context might be:

• this is a decision meeting before a product launch;
• what each attendee is responsible for;
• automatic transcription may get speakers wrong;
• the launch date was already confirmed earlier and isn’t up for discussion this time;
• what decisions were made at the previous meeting.

But there’s no need to retell the whole history of the project from its kickoff.

A very practical test is:

if you delete this piece of information, would the agent make a judgment that seems reasonable but is actually wrong?

If so, keep it.

If not, let the agent find it in the material itself, or leave it out of the current prompt.

Context’s value isn’t in quantity, but in whether it changes the agent’s judgment.

3. Constraints: at what cost must the goal not be achieved?

Constraints are the most easily mistaken for steps.

They aren’t:

first process the recording, then sort by time, then generate a table, and finally write a summary.

That’s the path of execution, which the agent can arrange itself.

Real constraints are:

• don’t write suggestions from the discussion up as confirmed decisions;
• don’t fill in owners and deadlines on your own;
• don’t erase disagreements that still exist just to make the notes more concise;
• mark information that can’t be confirmed as pending, rather than guessing;
• the version sent outside must not contain client private information.

The Goal says what you want to get.

Constraints say:

even if the goal is achieved, which costs are still unacceptable?

Meeting notes can’t invent owners to look complete, nor rewrite disputes as consensus to read smoothly.

Common constraints also include:

• what’s in and out of scope this round;
• which product or business principles can’t change;
• which old data and behavior must stay compatible;
• which operations the agent isn’t authorized to perform;
• which security, privacy and cost risks are unacceptable.

So constraints don’t teach the agent how to walk; they fence off the roads it mustn’t take.

The Goal defines what you want to get; Constraints define what you’re not willing to trade for it.

4. Done when: how do you prove it’s really done?

Goal and Done when look alike, but they solve different problems.

This task’s Goal is:

to make the meeting’s outcome clear, trackable and actionable.

But “clear and trackable” is still fairly abstract.

Done when turns it into results that can be checked:

• every confirmed decision can be traced to a point in the original recording;
• every action has an owner and a deadline, and those that can’t be confirmed are clearly marked pending;
• unresolved questions are listed separately;
• suggestions, discussion and formal decisions can be clearly told apart;
• sensitive information has been removed from the external version.

So:

the Goal defines the direction of success; Done when defines the evidence of success.

The Goal is “make the kitchen easier to use.”

Done when is “two people can work at the same time, the fridge and the sink don’t get in each other’s way, and every cabinet door opens properly.”

Without Done when, an agent easily treats “I’ve produced something” as “the problem is solved.”

GitHub’s official advice for the Copilot coding agent also stresses that tasks should not only be clear and well scoped, but include complete acceptance criteria; at the same time, the agent can usually search the codebase itself, so people don’t necessarily need to specify every file in advance.

A complete prompt could look like this

Goal

Turn this meeting into a trackable list of decisions and actions, so that afterwards nobody understands the decisions, owners and next steps differently.

Context

This is a decision meeting before a product launch.

Attached are the meeting recording, the automatic transcript, the list of attendees, and the record of decisions from the previous meeting.

The automatic transcript may get speakers wrong. The launch date has already been confirmed and is not up for discussion this time.

Constraints

• Don’t write suggestions or personal opinions up as confirmed decisions.
• Don’t guess owners and deadlines.
• Keep disagreements that haven’t been resolved.
• Mark information that can’t be confirmed as “pending.”
• The external version must not contain client names or contact details.

Done when

• All confirmed decisions are listed, with timestamps in the original recording.
• All action items have an owner and a deadline, or are clearly marked pending.
• Unresolved questions are listed separately.
• Suggestions, discussion and formal decisions can be clearly told apart.
• Both a complete internal version and a de-identified external version are provided.

This prompt isn’t especially short.

But it doesn’t dictate which file the agent must read first or what order to work in, nor does it design each step of the workflow for it.

It only spells out the parts a person has to decide:

• what you ultimately want;
• what it needs to know to judge;
• which ways of handling things are unacceptable;
• what counts as evidence that the task is done.

The rest of the path can be left to the agent.

Which details should be written, and which can be left out?

What should be written carefully is information the agent can’t reliably get from the environment, and that affects trade-offs:

• the real goal;
• necessary business background;
• priorities;
• product or working principles;
• scope and permissions;
• unacceptable risks;
• compatibility requirements;
• acceptance criteria.

What can usually be written less is information the agent can find on its own through investigation and verification:

• which file to look at first;
• in what order to search;
• which internal function to change first;
• which specific implementation to use;
• which routine check to run first.

Of course, this isn’t absolute.

If a certain implementation is already a firm decision, or involves security, compatibility, cost or irreversible risk, it’s no longer just an implementation detail and should go into Constraints.

A prompt isn’t better for being shorter, but for being harder to cut

Complex tasks may well need long prompts.

What’s really worth checking isn’t the word count, but:

does every sentence change the agent’s judgment?

If, after deleting a passage:

• the goal hasn’t become vaguer;
• the agent won’t misunderstand the current situation;
• the acceptable solutions haven’t changed;
• the risk hasn’t increased;
• the acceptance criteria are still clear;

then that passage probably doesn’t need to be in the current prompt.

So a prompt isn’t better for being longer, nor more sophisticated for being shorter.

A better standard is:

in a good prompt, everything left is information you can’t easily cut.

Once it’s written, you can check just four questions:

• Does the agent know what should change once it’s done?
• Does it have the facts needed to judge correctly?
• Does it know which costs, risks and changes are unacceptable?
• Does it know what evidence shows the task is done?

The agent can be responsible for exploring the path.

Direction, trade-offs, boundaries and acceptance still need a person to decide.

References

OpenAI, Codex Best Practices.

Anthropic, Effective Context Engineering for AI Agents.

GitHub, Best Practices for Using GitHub Copilot to Work on Tasks.