Build the asset request queue

You probably already automate parts of your work in Photoshop. A recorded action or a script repeats the same clicks in the same order on every file. It doesn't know what it's looking at. If the canvas is a different size or a layer has a different name, it either fails or does the wrong thing without telling you.

An agent works differently. It follows a written method, so it can handle a request or an image it has never seen. It asks about what it doesn't know and brings back what it couldn't settle.

Take an example. A request arrives: "square social crop of the olive-oil bottle, with the producer's logo". An action has no way to tell whether the logo file exists. An agent following your method can check, see that the logo is missing, and put that on a list for you.

John Maeda, a designer and computer scientist who writes the annual Design in Tech Report, said in his 2025 report that the era of agents has arrived. He also said agents work better from manuals and command lines than from drop-down menus. That is why this course has you write your method as a manual first.

An agent can only follow a method that's written down. If the method lives in your head, the agent fills the gaps by guessing, and guessing is the main thing you're trying to stop.

Version 1 of your method manual needs these sections:

• Inputs: what the agent receives. For example, request emails in one folder, the supplied asset manifest and the delivery matrix.
• Steps: what it does, in order.
• Checks: what it confirms before moving on, such as "source appears in the manifest".
• Stop conditions: when it stops and asks you, such as "source not listed" or "permission unknown".
• Approved connections: the folders and tools it may use, and nothing else.
• Agreed report: what it reports, when, and in what form.
• Human review points: the decisions that come back to you.
• Pause and retire: who can stop it, and what state it leaves the records in.

Write it in plain sentences, the way you'd brief a careful new assistant on their first day. Flip the cards to test whether you can say what goes in each section.

Give the agent a named role with a clear job. In this course the role is Production Desk. Production Desk logs requests, chases missing inputs and keeps records. It does not approve images, resolve permissions or contact the client. Those stay with you.

Adobe's CTO Ely Greenfield has said that professional customers want repetitive production work automated without losing control. Treat that as the vendor's view, but it's a sensible way to divide the work: the agent handles the logging, sizing and chasing, and you keep the image decisions.

Next, choose the tool. The course teaches Dots (OpenAI) and Claude Duet (Anthropic) as equals. Both of them:

• run on their own cloud computer
• connect to the apps you allow
• keep working toward a goal over time
• check with you before sending, paying, signing or deleting

Pick the one you already have access to. The manual is the same either way. Before you trust any setting, check its exact name and behaviour in your tool's own documentation.

Match each task to the role that owns it.

There are two ways to run the role.

• A single run processes one batch and then stops. It suits a one-off job, or a first test.
• A continuing brief keeps running. It processes approved requests as they arrive or on a schedule, for example every weekday at 8:00. It suits work that repeats.

If you're new to this, start with a single run. Move to a continuing brief once the manual holds up.

Whichever you choose, write these into the manual before the agent starts:

• Approved connections: for example, read access to /practice/requests and /practice/manifest.xlsx, and write access to the queue file only.
• Agreed report: for example, "each morning: the queue table, then a short list of anything paused".
• Human review: where its work waits for you.
• Pause and retire: who can pause it (you), how to resume it, and how it ends. When it stops, every open request should be left marked with its current status, never half-written.

A continuing brief with no way to retire it can keep running long after the job is over.

The request queue is the table Production Desk keeps up to date. Each approved request becomes one row with five fields:

1. Asset ID: a unique label, for example OLV-003.
2. Request as received: the original wording, copied exactly and not paraphrased. For example, "Square for Instagram, bottle on stone table, logo bottom right".
3. Source (from manifest): the file as listed in the supplied asset manifest, for example bottle_studio_v2.psd.
4. Permission status: cleared, not cleared or unknown.
5. Current status: for example queued, paused: input missing or ready for review.

The manifest is a list you supply of the files available for the job, with their sources and permissions. Because of it, the agent can identify sources without access to your private production systems or the client's servers. If a file isn't on the manifest, as far as the agent is concerned it doesn't exist.

Put the intake steps in the order the agent should follow them.

Production Desk records the permission status. It doesn't decide it.

• Unknown stays unknown. If the manifest doesn't say whether a source is cleared, the queue says unknown. The agent never treats unknown as approval, and a person resolves it.
• Not cleared is a stop. The request stays in the queue, but nothing is produced from that source until you decide what to do.
• Practise with sample or cleared files only. Your practice batch should contain files you're allowed to use.
• Keep confidential client assets out of unapproved cloud tools. Dots and Claude Duet both run on cloud computers. Before you connect any real client folder, confirm that the client and your own agreements allow it. If you aren't sure, don't connect it.

This course gives practical checks, not legal advice. Questions about copyright or usage rights go to whoever handles rights for the job.

Match each situation to the right record.

A proactive agent starts work without you prompting it each time: it picks up a new request on arrival or on schedule. The films behind this course don't include a recording of one of these agents starting on its own, so you test it yourself. In the live class a trainer would watch this with you. Here, the tutor walks you through it and reviews what you find.

Run the test:

1. Load your practice manifest and the approved request folder.
2. Drop in one sample request, for example "OLV email banner, 600 px wide, bottle on stone table".
3. Wait for the agent to pick it up, or for the next scheduled run.
4. Open the queue. Check all five fields, and check that the source comes from the manifest.
5. Check that the report arrived in the agreed format.
6. Pause the agent, then confirm the records are in a clear state.

If something is wrong, change the manual, not just the result.

Lesson outputs: version 1 of your method manual, and a filled request queue for your practice batch. Paste both to the tutor for review.