I want an AI agent to build my website or app — what goes in my brief so the delivered work matches it?

November 11, 2026 · 5 min read

SentX SI

The brief that works is not the longest one; it is the checkable one. Photon's reference page says one sentence is enough to start, and that you add files or details when you have them. The gap between that sentence and work that matches what you meant is filled by four things: what the thing is for, who uses it, what it must do, and what it must not do. If you can write those lines down, you can hold the finished work to them, and that last part is the whole point.

First, what is documented and what is my suggestion. The reference page, updated November 10, 2026, describes the machinery: you describe the result in plain language, a lead agent plans the work and assembles a team of AI agents, the agents write, run and check the code in your workspace, a Watcher steers any task that stalls, repeats itself or drifts from the request, and finished work lands in Results, where you open it, preview it, download it or publish it. The page does not document a spec format for the brief, and nothing in it gives a match rate for any way of writing one. The structure below is an editorial suggestion — my proposal for using features the page does document — not a Photon requirement, and I have no measured result to attach to it.

Source: Photon AI Coding Agent — Describe It, Get It Built | SentX SI

Start from the one sentence the page says is enough

The sentence should name the result, not the machinery. For illustration, "a booking site for a two-person physio practice that takes online appointments for two therapists" is a result; "build a React app with a database" is an implementation choice. The page's division of labor points the same way: a lead agent plans the work and assembles the team, and the page does not document the user editing that plan. Keep the brief at the level of the outcome and let the plan happen where the documentation says it happens.

Add the four lines that make it checkable

Purpose: the job the site or app does for its user — take bookings, collect leads, show a menu, process a file. Who uses it: a client booking from a phone, a staff member checking a dashboard, a visitor looking for contact details. What it must do: behaviors you can point at in the preview — a working contact form, prices in AED, opening hours that match the practice, a booking that lands somewhere someone checks. What it must not do: the constraints you would otherwise discover after publishing — no blog, no payment collection, nothing above three pages. Each line is short, and together they turn "does it match?" from a feeling into a list.

Attach what you already have

The page says add files or details when you have them: a logo, existing copy, a screenshot of a site whose tone you like, brand colors, a list of the pages. These are the spots where an agent is most likely to substitute its own taste for yours — placeholder text, a generic palette, an invented price list — and every file you attach replaces one guess with your material.

Pre-answer the questions Photon will ask

Photon asks when a decision is yours to make, and can send a browser notification when a question is waiting. Decisions you can settle in advance — tone, language, currency, how many pages, where form submissions should land — cost one line each in the brief and save a round trip. The notification is the safety net for the rest.

Set the guardrails before the work starts

You can set a daily, weekly or monthly spending limit, and you can write team instructions and reusable skills that the lead agent and every worker follow. For a solo practitioner with no team to review the output, the spending limit is the cheapest protection available, and team instructions are how a requirement you repeat every project — check every form works before a task is marked done — becomes standing rather than something you retype.

Re-read the finished work against the spec, line by line

A page is visible only to you until you publish it, so the review costs nothing and happens on your schedule: open the result in Results, preview it, and check each line of the spec against what you see. The Watcher is documented to steer drift, stalling and repetition, but the page gives no rate for that, and your own pass is the check the documentation puts in your hands. Fix what is off, and publish when every line holds — publishing puts the folder online at its own address on sentx.site, which is the moment the spec stops being a private checklist.

One more line on what goes in the brief, and what should not

The Privacy Policy states that submissions are not confidential and may enter training or shared memory, and the model card advises sharing only material you are allowed to submit under the Terms. If your project carries client data, an unpublished business plan or credentials, the brief is the one place in this whole process where you should be deliberate: it describes the product, not the contents of your vault.

Source: Victoria AI Model Card | Capabilities, Evidence and Limits | SentX SI; Privacy Policy | SentX SI (sentx.ai)

The reason to try it is the one the page hands you: a new account without a paid plan gets a one-time Photon trial. Write the one sentence, add the four lines, attach what you have, and you will know in Results whether the work matches — before anyone else does.

Source: Photon AI Coding Agent — Describe It, Get It Built | SentX SI