An AI agent product manager workflow on one shared prototype

The AI agent product manager workflow that holds up in practice has one shared prototype at its center. The developer’s coding agent produces and updates the screens as prototypes; the product manager reviews them state by state, chooses between variants, requests changes by pointing at one screen, and approves a numbered version; the agent codes only what was approved, and asks before production changes. The prototype, not the chat log or the ticket thread, is where the team agrees.

Why product managers get lost when an agent writes the UI

Coding agents are fast, and that speed creates new problems for anyone who is not reading the code:

• Changes land before review. A request in the morning is a merged pull request by lunch.
• Diffs are unreadable. A 400-line change to a component tells a PM nothing about how the screen looks.
• Screenshots go stale. The image in the ticket shows version 2; the app is on version 5.
• Decisions are implicit. Nobody wrote down which option was chosen, so the agent picks one.

The fix is not to slow the agent down. It is to give the team a place where every screen state is visible, versioned and chosen before it becomes code.

Split the roles clearly

Most friction comes from unclear ownership. A simple split:

Task	Product manager	Developer	Coding agent
Decide scope and priorities	Owns	Advises
Describe the change	Writes the request	Refines it into a prompt
Produce prototypes and variants		Asks for them	Does it
Choose a variant or version	Owns	Advises on cost	Never
Small visual adjustments	Can do by hand	Can do by hand
Code the chosen version		Reviews	Does it
Approve for production	Owns	Owns the merge	Asks first

The agent’s column is short on purpose. It produces options and code, but choosing is a person’s job.

One shared prototype as the place of agreement

For the prototype to work as the contract, three properties matter:

1. Every screen state has its own address. “Checkout, error state” is a link, not a paragraph. Tickets and messages point at it.
2. Every change is a numbered version. Decisions become “ship v4”, not “the one from Thursday”. This is the reason every prototype change should be a version.
3. The chosen version is explicit. There is one active version per state, and it is what the agent will build.

With those in place, a review meeting is a walk through links, and a decision is a version number.

In each state, a product manager’s review is most useful when it checks what the developer is least likely to question:

• Is the copy right, including error messages and button labels?
• Does the empty state tell a new user what to do next?
• Is the primary action the one the business cares about?
• Do the numbers, dates and statuses match real cases, including the long and awkward ones?
• Is anything missing that a customer would expect on this screen?

Change requests a PM can hand over

A good request points at one state and says what must stay. Use a short template:

Screen: Checkout, error state (link to the frame)
Change: show the error above the form, in red, with the field name.
Why: users miss the error at the bottom on small phones.
Keep: the button label and the order of the fields.
Done when: the error is visible without scrolling at phone size.

The developer can paste this almost as is into the agent’s chat, next to the frame link. Requests shaped like this leave little to guess; how to write a change request an AI agent gets right goes deeper on wording.

Decisions: variants, versions and approval

When a direction is unclear, ask for variants instead of debating in the abstract. Two to four options of the same state, same data, differing on one decision. The PM chooses, and writes down why in one sentence. Comparing design variants before writing code describes how to run that round.

Then keep a small decision log, next to the prototype or in the ticket:

• “Home, empty state: v3 approved. Chosen over v2 for the single call to action.”
• “Checkout, error state: v5 approved, pending copy review.”

The agent should never pick a variant or decide that production follows a new version. If someone changes the chosen version of a screen that is already built, the right behavior is for the agent to stop and ask.

Doing this with agentappbuilder

agentappbuilder is built around this split. Claude Code runs on the developer’s machine and prototypes the app’s screens as HTML frames on a canvas; the people of the project’s organization review them in the browser.

What a product manager who is a member of the organization can do on the canvas today:

• Browse every state of every screen, linked by the actions between them, and copy a frame link into a ticket. A frame link only opens for members of the organization.
• Choose a variant when the agent proposes 2 to 4 of them, and Compare any two versions side by side.
• Make an older version active again from the right panel.
• Edit a frame directly: fill, stroke, corner radius, padding, auto layout and text properties. The edits become a version signed by that person.
• Duplicate a state or a screen to explore an idea; the agent starts from the copy and asks before replacing it.
• Copy as PNG to paste a state into a ticket or a document.

The app never contacts the agent on its own. The agent reads the project when it calls one of its tools, including the version that was chosen. If the PM makes another version active on a screen that is already implemented, the agent asks the developer at its next request whether production should follow, so a PM choice never reaches production silently.

Two limits to know. The web app is designed for desktop screens, and it does not have a screen to invite members yet, so check the concepts page for the current state of organizations and roles. The canvas documentation describes each control listed above.

A weekly rhythm that works

• Monday: the PM writes change requests against frame links; the developer turns them into prompts.
• During the week: the agent adds versions and variants; the PM reviews them asynchronously and chooses.
• Before coding: the PM and the developer walk the states that changed, and confirm the approved version numbers.
• After coding: the developer asks the agent to implement the approved versions, reviews the code and runs the checks; the PM checks the running app against the approved versions.

This workflow keeps the speed of the agent and puts the decisions where they belong. The PM stops chasing screenshots, the developer stops guessing which option won, and the agent builds exactly what the team chose.