---
title: "Dock + Adobe Creative Cloud: brand asset workflows with attributed agent edits"
excerpt: "Adobe Creative Cloud holds the source files (PSD, AI, INDD). Dock is where the brief, the agent's asset variations, the brand-system check, and the reviewer sign-off live, with pointers back to the CC Libraries asset id."
author: mei
category: Use Cases
date: "2026-05-30"
---

A design agent producing brand assets against Adobe Creative Cloud needs two systems. Creative Cloud holds the PSD, AI, and INDD source files plus the CC Libraries that distribute colors, type, and logo lockups. Dock holds the asset request, the variation rationale, the brand-system check, and the reviewer decision. The agent reads the brief from a Dock row, generates variations against the CC source file via the [Photoshop API](https://developer.adobe.com/firefly-services/docs/photoshop/), writes its reasoning back to the same row, and waits for a human reviewer before the asset reaches a Library that production teams pull from.

## Where each system holds state

Adobe Creative Cloud, [Figma](/blog/dock-figma-design-ops), Sketch, Webflow, and Framer stay the system of record for the canvas itself: layers, artboards, components, the binary source files. Dock is the system of record for what the agent and the team interpret around the canvas: the brief, the review thread, the variation rationale, the approval status, the production-asset queue. Each Dock row carries a pointer to the platform record (`cc_library_id`, `psd_file_id`, `ai_artboard_id`), agent identity, decision, reviewer, and timestamp. The agent re-fetches Creative Cloud data via fresh API reads when it needs current state. Dock holds the persistent interpretive layer that survives across sessions and handoffs, which is the foundation of [Dock for design](/blog/dock-for-design).

## The asset-request table

| request_id | brief | cc_library_id | psd_source | variations_generated | brand_check | reviewer | status |
|---|---|---|---|---|---|---|---|
| AR-401 | Summer campaign hero, 3 sizes | lib_94f2 | hero-master.psd | 3 (1200x628, 1080x1080, 1080x1920) | pass | sasha@brand | approved |
| AR-402 | Black Friday banner, animated INDD export | lib_94f2 | bf-banner.indd | 5 (motion variants) | flag: logo clear-space violated on v3 | maya@brand | revision_requested |
| AR-403 | Q3 product launch carousel, 6 frames | lib_b71c | launch-carousel.ai | 6 | pass | sasha@brand | pending_review |

Each row is the durable record. The PSD lives in Creative Cloud. The decision lives here.

## A worked workflow

A request lands in Dock as row AR-402: a Black Friday banner with five motion variants. The agent (a named principal, not a service account, per [agent identity](/blog/agent-identity)) reads the brief, fetches the master INDD via the Creative Cloud API, generates the five variants, and runs a brand-system check against the linked CC Library. One variant fails the logo clear-space rule. The agent writes its reasoning to AR-402: `variant_3_violates_clearspace_rule`, attaches preview renders, and sets status to `pending_review`. Maya, the brand reviewer, opens the row, sees the flag, requests a revision. The agent regenerates variant 3, the check passes, status moves to `approved`, and only then does the agent write the final files to the production Library that downstream teams pull from. The publish step is a [dangerous operation](/blog/dangerous-ops-contract): it requires explicit reviewer approval before the agent touches the shared Library.

## Why it matters

Attribution. Every variation in AR-402 carries the agent's name, the timestamp, the brand-check result, and the reviewer who approved or rejected it. Six months later, when a compliance audit asks why a particular hero image shipped, the answer is in the Dock row, not reconstructed from chat logs. This is the same logging substrate described in [agent audit and compliance](/blog/agent-audit-and-compliance).

Handoff. A brand designer joining the team next quarter opens the asset-request table and reads the last fifty rows. They see which prompts produced clean output, which briefs triggered brand-check failures, which reviewers caught what. The interpretive layer travels with the team, not with whichever agent session happened to run last week.

Daily-driver experience. Designers do not want a new tool to learn. They want their Creative Cloud workflow intact and a table that shows them what the agent did, why, and what needs their eyes. Dock is that table. The canvas stays in Photoshop, Illustrator, and InDesign, which is the right answer for any [brand asset production](/blog/design-brand-asset-production) team that already pays for the Adobe stack and routes finished work through [Adobe Experience Manager Assets](https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/assets/overview).

[Read the full Dock-for-design pillar](/blog/dock-for-design).

## FAQ

**Does Dock replace Adobe Creative Cloud Libraries?**
No. CC Libraries remain the distribution layer for approved colors, type, logos, and finished assets. Dock holds the request, the agent's working notes, the brand check, and the reviewer decision. Each Dock row points to the Library asset id.

**How does the agent edit a PSD without a human in Photoshop?**
Through the Adobe Photoshop API and Firefly Services. The agent submits the source PSD, the variation instructions, and receives rendered outputs. The edits and the rationale are logged to the Dock row before any file lands in a shared Library.

**What if the brand-system check is wrong?**
The reviewer overrides it on the Dock row, writes a one-line reason, and the override is recorded with their identity and timestamp. The next time the agent encounters the same pattern, it reads the override history and adjusts.

**Can I run this against InDesign and Illustrator too, not just Photoshop?**
Yes. The same Dock row schema works across PSD, AI, and INDD source files. The `psd_source` column generalizes to any Creative Cloud file id, and the brand check runs against the same CC Library regardless of which source application produced the asset.
