How to brief an AI website agent without writing a giant prompt
A useful AI website brief records the page job, buyer moment, evidence, constraints, locked claims, and decisions the agent is allowed to make.
SiteSorted Launch CEO
9 min read
In this note
A brief is a decision record, not a magic paragraph
Name the page job before its sections
Describe the buyer's moment
List the surfaces the website must contain
A brief is a decision record, not a magic paragraph
Long prompts often mix durable facts with temporary preferences, contradictory examples, and instructions written before the team knew what it wanted. Length does not create clarity. A useful AI website brief records the decisions the agent must respect and leaves room for the agent to solve the design problem. It can be one page if the thinking is sharp. The test is simple: could a capable designer read it tomorrow, identify the page goal, find the approved evidence, know what is locked, and explain where judgment is still required? If not, adding more adjectives will not help. Rewrite the uncertainty as a decision or mark it as open.
Name the page job before its sections
Start with the single result the web page must produce. A homepage may need to explain an unfamiliar product and move qualified buyers to a demo. A launch page may need to turn interested visitors into a waitlist. A pricing page may need to help an informed buyer choose a plan without a sales call. This job determines the hierarchy. It tells the agent whether the first screen needs product explanation, proof, a visual demonstration, pricing confidence, or urgency. Avoid a bundle such as “educate, build trust, rank on Google, impress investors, recruit staff, and drive sales.” Choose the primary job, then list secondary outcomes that must not compete with it.
Describe the buyer's moment
Audience labels are too broad on their own. “Startup founders” does not tell the agent whether the visitor has just seen a social post, is comparing three tools during a launch week, or has been sent by a colleague to inspect security details. Describe the moment around the visit. Include what the buyer already knows, what they doubt, what device they are likely using, and what decision they are trying to make. That context changes design choices. A cold mobile visitor needs fast orientation and early proof. A warm desktop evaluator can handle more detail and comparison. The agent should design for a real decision under real attention, not an abstract persona poster.
List the surfaces the website must contain
Tell the agent what it is building in concrete terms. Name the routes, sections, interactions, and information that must exist. For a marketing site, the brief might require a homepage with a product demonstration, proof strip, workflow explanation, pricing preview, FAQ, and final CTA; a full pricing page; and a contact path. State which forms submit, which buttons navigate, and which product visuals are real. This prevents the agent from spending effort on invented features while missing required ones. Do not prescribe every card and column unless the layout is already approved. Define the information and behavior first. Let the composition respond to the content.
Separate facts from suggestions
Agents need to know which inputs are true and which are ideas. Product names, prices, supported integrations, customer quotes, legal wording, and measured outcomes belong in a factual layer. Possible headlines, visual themes, competitor references, and section concepts belong in a suggestion layer until approved. Mixing them encourages confident invention. Mark uncertain claims explicitly. “We think setup takes under ten minutes” should not become a quantified promise on the homepage. Give each fact an owner or source when the cost of being wrong is high. The agent can improve expression, but it should not upgrade a founder hunch into published evidence.
Give the agent proof it can use
“Make it credible” is not an actionable instruction. Supply the material that earns credibility: product screenshots, a recorded workflow, customer language, usage data, founder experience, integration logos you are entitled to show, or a precise explanation of what the product does. Note where each asset came from and whether it is approved for public use. If proof is thin, say so. The agent can choose a structure that relies on demonstration and specificity instead of fabricating social proof. A clean list of available evidence also improves asset fit. The system can match a wide dashboard image to a product section and reserve a portrait quote for a testimonial block.
Set constraints that prevent expensive guesses
Constraints should remove bad branches, not describe every pixel. Record the required platform, responsive widths, accessibility expectations, brand tokens, content limits, technical integrations, and reference boundaries. Explain what you admire about a reference site: perhaps its editorial pacing, dense product demonstration, or restrained typography. Do not ask for “the same design” and leave the agent to decide what copying means. Include negative constraints when they protect the product, such as no invented metrics, no stock photos, no moving background behind body text, and no global rewrite during a section edit. Specific boundaries save more time than a mood-board page filled with unexplained screenshots.
Lock decisions that must survive regeneration
A good brief identifies the parts that are closed. Lock the company name, domain, approved positioning, primary CTA, plan names, compliance copy, supplied logos, and any section the team has signed off. The agent should be free to improve open areas without reopening those decisions by accident. This matters during later edits. A request to shorten the FAQ should not rename a pricing tier or change the hero promise. Keep locks short enough to review at a glance. If everything is locked, the agent has no useful design space. If nothing is locked, each iteration can erase progress. The brief should show both the stable spine and the area currently being explored.
State what the agent may decide
Delegation works better when authority is explicit. Decide whether the agent may choose section order, draft unapproved copy, select from supplied assets, adjust spacing, create responsive variants, or add a common accessibility fix without stopping. Then name the decisions that require approval: publishing, deleting a route, changing a product claim, using a new third-party asset, or replacing an approved reference direction. This avoids two bad modes. An overcautious agent asks about every margin. An overconfident one makes business decisions while the team thinks it is polishing design. Give it a clear operating area and ask it to bring evidence when it reaches the edge.
Use a compact handoff template
The brief can fit under seven labels: page job, buyer moment, required surfaces, approved facts, available proof, constraints, and authority. Add links or files beneath the relevant label instead of pasting everything into one narrative. Finish with a definition of done written in browser terms. For example: the homepage loads on the main route, communicates the product and buyer on the first screen, uses only approved claims and assets, has a working primary CTA, and remains readable at 1440 and 390 pixels. This template gives the agent enough structure to plan while keeping omissions visible. A blank label is useful; it shows what the team still needs to decide.
Update the brief when reality changes
The brief is living product context, not a ceremonial document frozen before design begins. Customer calls may change the objection order. A launch may produce stronger proof. Pricing may move. A mobile check may show that the approved headline cannot fit without losing meaning. Update the relevant decision and mark the old one as superseded. Do not bury the correction at the end of a long chat and expect every later action to infer priority. The agent should work from the current brief plus the current website. Done well, the brief gets shorter over time: resolved uncertainty becomes a clear fact, discarded directions disappear, and each new edit starts from a more trustworthy base.
Launch CEO read
A launch page should make the buyer, promise, proof, and next action obvious. SiteSorted uses this same standard when it turns a brief or reference site into a builder-ready page.
Start your launch build