← Articles

Four roles in an agentic workflow

Studio case note · June 2026 · Updated September 2026

A creative workflow needs more than one kind of help. I think about four roles: direction, coding, production, and design. A single agent may cover several roles, or several agents may share one. The responsibilities and handoffs matter more than the product names.

Direction holds the purpose of the work. It brings together goals, constraints, and earlier decisions, then turns them into a brief or specification. A conversational interface is useful here because questions and alternatives can be examined before execution begins. Creative judgment stays with the person directing the work.

Coding turns specifications into working software. Coding agents can work in a repository, implement changes, run checks, and prepare releases. The work is judged by what the software does and what the checks establish. Deployment belongs within the permissions and release process agreed for that project.

Production organizes the material around the software: project files, documents, media, and repeatable processing. Agents with access to the relevant tools can help prepare assets and carry out batch work. Their scope needs to be clear, particularly when several people or agents work in the same project.

Design gives the result its visual and interactive form. The agent works from the project's design system, content, and established layout constraints. Existing typography, navigation, and component behavior are part of the brief; changing them is a design decision, not an incidental consequence of generating a page.

Work moves between these roles through explicit handoffs: the intended outcome, the current state, the approved decisions, and the evidence needed to judge completion. A shared project record lets a later session continue without reconstructing the whole conversation. Stafford Beer described specialized subsystems working through explicit channels (Beer, 1972), while Herbert Simon's near-decomposability offers a way to understand components with clear responsibilities and limited interactions (Simon, 1969). The practical aim is a workflow whose parts can move independently while the whole remains understandable.