A useful AI brief gives you something to judge at the end. You should be able to look at the work and say whether it solved the problem you handed over.
That sounds obvious until the request is “improve this website” or “make the app more professional”. An agent can make a lot of changes under either instruction. Deciding whether those changes helped is considerably harder.
I use agents for development and refine the workflows around them. The most useful briefs connect the intention behind a request to a result someone can recognise. They also leave room for the agent to investigate and choose an implementation. You shouldn’t need to write the solution before asking for help.
Describe the result you want to recognise
On this website, some interactive sections needed to keep their size when the selected content changed. Clicking an option could move everything underneath it, making the page feel unsettled.
“Make the transitions smoother” leaves several interpretations open. An agent might animate the height change, shorten the text or hide the overflow. Each could look like progress while leaving the original problem intact.
A more useful brief describes the experience: switching options should keep the section’s outer height stable, with all the content readable on a narrow phone screen as well as a desktop. Keyboard navigation should still work.
Now the agent has a problem to solve and you have a way to assess the result. The implementation can still vary. Perhaps the content shares a grid cell, perhaps the layout needs a different structure. The brief establishes what the visitor should experience.
This works outside development too. For research, ask for the evidence needed to make a particular decision. For a spreadsheet, describe the calculation and the cases it must handle. A deliverable becomes much easier to review when its purpose is explicit.
Give the agent a working boundary
Useful context is selective. An agent fixing a form needs to know how enquiries currently leave the website, what the business wants to receive and which constraints matter. The entire company history is unlikely to help.
Point it towards the relevant files or examples, then distinguish requirements from suggestions. If you suggest a particular layout but mainly care about readability, say so. Otherwise your proposed solution can become an accidental constraint.
Here is an example brief for the section above:
When someone changes the selected option, the section should stay the same height and the next section should remain in place. Keep all copy readable at 320px, 390px and desktop widths.
Look at the existing component and shared controls before changing it. Preserve the current visual style, keyboard behaviour and reduced-motion support. Choose the layout approach that fits the existing code.
Check every option in a browser. Show which states and sizes you checked, and mention anything you could not verify. Keep this change to the component and any shared styles it needs; leave deployment for a separate step.
The boundary is especially useful when an agent has tools that can change things. Be clear about which actions belong to the task and which need a separate decision. That lets it continue with ordinary work while preserving your control over consequential steps.
Match the evidence to the job
An agent’s completion message is a helpful summary. I also want evidence from the place where the change matters.
For a visual change, that means a rendered page and the states affected by the edit. A build passing tells me something valuable about the code, but it cannot tell me whether a label clips at a small screen size. For a data import, useful evidence includes duplicate handling and what happens to information a person has already edited.
Ask the agent to report the checks it actually performed. “Tested all states” is difficult to review. “Switched through the three options at these widths and measured the section height” makes the result concrete.
The check itself deserves judgment too. A test that insists on one exact sentence can reject a perfectly good rewrite. A screenshot of an empty screen can miss the problem that appears when the screen is full. Choose checks that reflect the outcome, and keep an example of the awkward case that caused the work in the first place.
Leave a useful handover
Long projects accumulate decisions. A font was chosen for a reason. A data source has a limitation. A rejected design may still contain a useful idea. Keeping those details in a short project note saves the next session from rediscovering them.
Record the current decision, its reason, the relevant files and the next unresolved question. Git can preserve the code and earlier versions; a handover explains which version matters and why. Together they make it easier to resume work without treating the whole project as a fresh brief.
There is also a point where a fixed sequence is a better fit than an agent deciding every step. Once a repetitive job is well understood, conventional automation may be simpler to run and check. Anthropic’s guide to building effective agents makes a useful distinction between predefined workflows and systems where the model chooses its route, and recommends starting with the simplest approach that fits the task.
For the next job you hand to an agent, write down the result, the context it needs, the actions it can take and how you will check the outcome. That small amount of preparation gives both of you a much clearer finish line.