I'm building a product agent, so I started ProductAgents.com

I lead the Agents team at Owner, where we’re building Owner Agent. It’s a product agent: an AI agent that lives inside a software product and does work for the people who use it.

Building one made me want to study how other teams do it. What does a good agent look like when it’s part of a product, and not a chat box sitting next to one? I started reading everything I could find from companies shipping agents today: help docs, developer docs, changelogs and recorded demos. My notes got long, so I turned them into a site. It’s called ProductAgents.com. It’s where I talk through what a product agent is, and where I’m compiling what I learn as I go.

What I mean by a product agent

My working definition is an AI agent built into a software product that uses its context and capabilities to carry out work for users, within the product’s permissions and controls.

The idea I keep coming back to is that the product is the harness around the model. The model is the engine. It can decide what to do next. On its own, it can’t find the right record, know whose access it’s using, show someone what’s about to change, or prove what happened afterward. The product supplies all of that: the context and objects the agent works on, the identity it acts as and what that identity may do, the screens where people review a change, and the receipts, history and undo.

A strong model in a weak harness makes a good demo. People hand real work to a strong model in a strong harness.

Two things other products taught me

So far I’ve written teardowns of 12 products, including Shopify Sidekick, Notion, Intercom Fin, Linear and Zapier. Two findings stuck with me.

The first is from Shopify’s official Sidekick tutorial. The merchant asks for 15% off for the weekend. Sidekick fills in Shopify’s real discount form, and the dates run from Saturday through the end of Monday. Maybe Monday is what the merchant meant. The recording doesn’t say. But a chat reply saying the discount was ready would have hidden the question. The form puts the end date on screen, where the merchant can catch it. When an agent turns a loose request into a real object, show the object’s own fields, not a summary of them.

The second is from Zapier. Its Human in the Loop approval step can be set to keep running when the reviewer declines, or when nobody answers before a timeout. Zapier’s docs list all three cases, approved, declined and timed out, under the same status: Success. A separate Decision field tells them apart. So a run history full of green Success steps can include runs that nobody approved. Approved, declined and timed out are three different outcomes, and a product should show them that way.

Neither lesson is about the model. Both are about the product around it.

What’s on the site

• What is a product agent? The definition and the harness idea, in more detail.
• Teardowns of 12 real products, drawn from each vendor’s own docs and recorded demos, with the sources linked.
• 9 design patterns, like “Show the exact change before it happens,” “Be honest about what undo can undo” and “Leave a receipt, not just a chat message.”
• Ask Pip, an assistant that answers questions from the site and cites the pages its answers come from.

A work in progress

The site is a work in progress, and I’ll keep adding to it. I’m learning as I write, the products change often, and I’ll get some things wrong. When I do, I’ll fix them.

If you’re building an agent into your own product, I hope it’s useful. Start with “What is a product agent?” on ProductAgents.com.