Product agents, explained in five minutes

Picture three features next to the same project. A button moves every selected due date forward seven days. A text generator writes a launch plan someone pastes in by hand. An agent checks dependencies, asks about an unclear workstream, prepares a limited change, and reports what actually changed. Only the third is clearly a product agent: the person hands over a goal, the agent decides using the product’s context, and the work stays connected to real data. A draft or an answer based on current product data counts too. “Coding agent” describes different work, not a different relationship, so one agent can be both.

As the harness, the product brings what matters most: the users, the objects and how they relate, the business rules, and ways to check a result. The same job can arrive through different doors. In the app, the current page identifies the launch. An outside AI assistant, calling the product through MCP, has to search for the launch. A scheduled check needs scope and permissions set before the run starts. The meaning of the change shouldn’t shift because the door did, and a permission check that lives only in a button’s code gets skipped when a scheduled agent calls the same service.

Edit access answers “may this actor do this?” Edit access doesn’t answer “did the person want every one of these tasks moved?” Products also differ on whose access the agent uses. In Notion, the personal Agent works within the person’s own access, but a Custom Agent has permissions of its own, and sharing a Custom Agent can let others reach information they can’t open themselves. An approval must also stay tied to what was reviewed. When someone approved changes to 12 tasks, the agent shouldn’t quietly change 17 because a search now matches more.

Before choosing how the agent works, the team writes down what finished looks like: which dates change, whether the announcement stays a draft, and how people hear about exceptions. A final “Done” message is a claim. Changed records, delivery receipts, or an answer tied to real data are how the team checks the claim. Recovery needs the same care: stopping future work, restoring the old dates, and correcting an announcement already sent are three different operations.

Across the 12 teardowns, agents put work in four kinds of places. Each place sets a different bar for a good result.

For any agent workflow, write down five answers. What result should exist when the work is done? Which account is the agent acting as? Which consequence needs a person to review the change? How will the team check the work is done without trusting the agent’s own words? And what happens if the change needs taking back? A vague answer marks where the product needs work: another action, a narrower scope, a clearer receipt, or an honest undo.