What a design agent must hand over before its work is usable
AI product and design workflows
Published Updated 4 min read
A design agent finishes a flow. The screens look consistent, the components have sensible names, and the team can click through the main task. Then an engineer asks which states are real, which data is invented, and what should happen when the request fails.
If nobody can answer, the work is still waiting for someone to define the product.
Teams introducing AI agents into a design process need a handoff contract: a compact description of the task, constraints, outputs, and checks that make a result usable by the next person. It should travel with the design, especially when another agent will continue the work.
What does the next person need to know?
For an illustrative expense-approval flow, the agent might produce a request form, a review screen, and a success state. That leaves several consequential questions open. Can an employee approve their own expense? What happens when the approver is unavailable? Does the success screen mean submitted or paid?
Write the answers as product decisions, with an owner. Mark unknowns explicitly. A designer can propose an interaction while leaving a policy decision unresolved; the handoff should make that boundary visible.
A useful contract can fit on a page:
| Item | What the handoff should contain |
|---|---|
| Task | The person, situation, and outcome the flow serves |
| Source | Approved requirements, components, and data examples |
| Boundaries | What the agent may change and what needs a decision |
| States | Main path, empty, loading, restricted, and failure states relevant to the task |
| Checks | Conditions the result must satisfy before acceptance |
| Owner | Who accepts the design and resolves each remaining question |
This is a proposed working format. A simple copy change needs less detail than a flow that changes access or money.
How do the checks become useful?
Make each check observable. “Follow the design system” is a goal. “Use the existing input and error components, and identify any new variant” is something a reviewer can inspect.
Some conditions belong in automated checks. Others require human judgment or a participant trying the task. Keep those responsibilities separate. An agent reporting that its output is accessible does not establish that somebody tested it with a keyboard or assistive technology.
The GOV.UK guidance on service teams describes the different disciplines needed to develop a service. Introducing automation does not remove the need to assign that work. A design agent can help produce an artifact while a researcher, designer, and engineer remain responsible for different aspects of its quality.
What happens when the first handoff is wrong?
Deliberately give the receiving person a version with one unresolved state. Ask them to identify the gap and send a precise correction back.
In the expense example, the receiver might find that rejection erases the employee’s explanation. The correction should say which information must survive, why it matters, and how to verify it. “Make the rejection flow better” leaves the agent to guess again.
After the revision, check the rest of the flow as well as the changed screen. The ability to fix one issue without losing earlier requirements is part of the workflow’s value.
This test also reveals whether the handoff depends on one person’s memory. If the engineer needs a private conversation to understand every state, the contract is missing information that should accompany the artifact.
What should an agency leave behind?
If an agency sets up design agents for an internal team, agree on the materials that remain after the engagement. These can include the task contract, approved examples, evaluation cases, operating instructions, and a process for updating them when components or product rules change.
Establish ownership and access for the tools as part of the scope. Do not assume a workflow demonstrated in an agency’s environment will run in yours with the same permissions or cost.
Ask the agency to complete a transfer exercise with a member of your team. Have that person assign a task, review the output, request a correction, and hand the result to engineering using the supplied materials.
Humbleteam’s guide to evaluating AI design infrastructure covers broader provider selection. Use this contract to examine the small but decisive question underneath it: what must be true before another person can rely on the agent’s work?
Start with one recurring task. If its next owner can explain the assumptions, find the unresolved decisions, and verify the result without reconstructing the whole conversation, the handoff is doing its job.
