Questions and brief changes

Every asset has a conversation beside its brief. The brief is the current instruction; the conversation is how the people who request, review and make an asset agree on it. Use it whenever a brief is unclear, or a review note asks for something the brief doesn't say, before anyone makes another file.

Ask before you make

A fulfiller who isn't sure what is wanted asks on the asset:

agh ask hero.hero_3.concerned "The brief still asks for a connected braid. Only this portrait, all three expressions, or the reference and icon too?"

On the web page, open Ask a question about this request (or Conversation) on the request, under Open requests or My claims, and tick Ask as a question. Over MCP, call post_asset_message with question true.

A request with an open question is on hold: agh next, Claim next and claim_next_request skip it, and it leaves the open requests list. A claim you already hold stays yours, and you can still claim the request by its id. The question counts in the inbox of the people who request assets, under Questions on the web page and questions to answer in agh inbox, until someone other than you writes on the asset.

When someone answers, the request opens again, and your inbox counts it under Questions (replies to your questions) until you write back or the request moves on.

Attach files

A question or an answer can carry up to five files, so you can show what you mean instead of describing it: a reference sheet or a rough model with "does this match what you want?", or a marked-up image in the answer.

agh ask char.npc.lantern_keeper "Does the proportion match before I start the full model?" --file turnaround.png --file blockout.glb
agh reply char.npc.lantern_keeper "Close. Bigger lantern and a longer coat, see the marks." --file turnaround_marked.png

On the web page, choose Attach files under the message box. Over MCP, upload each file with start_upload, giving attachment the file's name, then list the uploads in post_asset_message's attachments. Guests attach files the same way on their link's page.

• A message takes images, models, audio, video, text and PDF files, up to 100 MB each. Other kinds, such as programs and archives, are refused.
• Pictures, models, audio and video show in the conversation in the same viewers as review. agh show lists each file with its id; agh attachment get <asset-id> <file-id> or get_file_link with attachment downloads it.
• Files never change the request, its claim or its deliveries, and they are never published or counted in the AI disclosure. To deliver the real thing, deliver it as usual.

How long files are kept

• While the asset is open (requested, claimed, delivered or accepted), its files are kept.
• Once the asset is published or cancelled, its files are kept for 90 more days, then deleted. If a revision reopens the asset, the 90 days start again the next time it closes. The page shows the date a file is kept until.
• The person who posted a file, or an admin, can remove it at any time (Remove file on the web page, agh attachment remove, or remove_attachment over MCP). It is deleted for everyone.
• A removed or expired file leaves its name in the conversation, with who removed it or "File expired", so the conversation still reads. The message's text always stays.
• When a guest link expires, the guest can no longer see the files. Nothing is deleted.

Answer, then change the brief

Anyone who can see the asset can reply:

agh reply hero.hero_3.concerned "Only this portrait for now. Keep everything else the same."

A reply doesn't change the brief. Fulfillers, and the next fulfiller in particular, work from the brief, so once you agree what is wanted, change it (admins and developers):

agh mark hero.hero_3.concerned --brief "Hero 3, concerned expression, hair loose with no braid" --reason "Client: no braid, this portrait only"

On the web page, Change brief under Questions does the same. Over MCP, it is change_brief. Change each asset the decision covers. A change to one asset never spreads to related ones by itself.

An agent can change its own requests the same way until a person approves them: while they sit in its draft batch, or in a batch waiting for approval. Once a request is approved, the agent's change to its brief, spec or notes is *proposed* instead, with the reason required. The request keeps its brief, and fulfillers keep working from it, until an admin or developer decides:

• On the web page, proposals wait under Approve > Brief changes, with the current and proposed brief side by side, and the Inbox and the asset show that one waits.
• From the CLI, agh brief-change list, then agh brief-change approve <asset-id> or agh brief-change decline <asset-id> --note "...".
• Over MCP, review_brief_change.

Approving replaces the brief like any other change. Declining keeps it, and the note is posted in the conversation, where the agent reads it. A newer proposal replaces one still waiting. Tags and used_in stay with admins and developers.

The old brief, spec and notes are kept in the asset's brief history with who replaced them and why, and the reason is posted in the conversation. agh show lists both, and get_asset returns them as briefHistory and conversation.

Reject: doesn't meet brief, or change brief

A rejection says which it is:

• Doesn't meet brief (the default): the file doesn't do what the brief asks. The brief stays, and your note tells the next fulfiller what to fix.
• Change brief: the file may be fine, but the person who asked now wants something different. Give the new brief, spec or notes with the rejection, and your note is kept as the reason.

agh review hero.hero_3.concerned --reject --note "Too dark; keep the face lit"
agh review hero.hero_3.concerned --reject --changes-brief --brief "Hero 3, concerned, hair loose (no braid)" --note "Client dropped the braid"

On Review these are Reject: doesn't meet brief and Reject: change brief…. Over MCP, review_delivery takes reason misses-brief or changes-brief.

If what a change covers is unclear, ask in the conversation first rather than rejecting with a note that contradicts the brief. A rejection note from before a later brief change is shown as history ("before the brief changed"), so it doesn't override the brief.

Accepted and published assets

To change an asset that already has an accepted or published file, ask for a revision (agh guide revise). The revision's note is posted in the conversation, any brief change is kept in the brief history, and a published file stays in use until its replacement is accepted and its pull request merges.

For agents: this page as Markdown is at /docs/conversations.md, and the CLI prints it with agh guide conversations.