A Product Manager's Guide to Agent Workflows

Product managers do not need to become agent framework experts.

They do need to stop writing agent requirements like this:

Build an AI agent that helps with customer support.

That sentence is a fog machine.

A useful agent spec names the outcome, the boundaries, the tools, the approvals, and the metric.

Start with the job#

Write:

The agent drafts support replies for billing questions by reading account state, invoices, support history, and refund policy. It requires approval before promising credits or issuing refunds.

Now engineering has something real.

Define what the agent owns#

Every workflow needs an ownership line:

• What the agent decides.
• What the agent drafts.
• What the agent routes.
• What the agent cannot do.
• What a human must approve.

Without that, the scope will drift.

Tools are product requirements#

If the agent needs tools, say which ones:

• CRM.
• Support desk.
• Billing provider.
• Docs.
• Repo.
• Observability.
• Slack.

Also say whether access is read-only, write-approved, or forbidden.

Evals are acceptance criteria#

Agent acceptance criteria should include eval cases:

• Correct classification.
• Missing context.
• Conflicting policy.
• Sensitive data.
• Approval required.
• Low confidence.
• Tool failure.

This is better than "the answer should be good."

Launch metrics#

Good metrics:

• Time to first useful draft.
• Human edit rate.
• Correct routing rate.
• Source coverage.
• Approval rejection rate.
• Unsafe action blocked.
• Cost per useful run.

Bad metric:

• Number of AI messages sent.

More messages is not automatically more value.

Build it in Codelit#

Try this:

Create a product requirements workflow for an AI support agent. Include user outcome, agent responsibilities, tools, permissions, approval gates, eval acceptance criteria, launch metrics, architecture, and repo handoff.

Create the agent workflow PRD

The PM job is not to ask for an agent. It is to make the agent's job impossible to misunderstand.