Where an existing product should put its first agent

Start with a bounded job inside a workflow customers already use, where they can check and edit the result before it goes out, and widen what the agent does as you learn where people still step in.

• Pick a bounded job people can review. Rachel Wolan would rank surfaces by whether the job is frequent and painful, whether the agent produces a unit the customer already works with, and whether the customer can review it under the right permissions before publishing. Sam Stone would start with draft-and-review work, like the demand packages EvenUp's legal customers edit before they send them.
• Weigh judgment against verification. Aparna Chennapragada would also score how much judgment the job asks of the agent and how easily the user can check the result, starting from a supervised recurring task such as a weekly digest of customer-issue emails. She suggests writing the spec as the judgment the user wants, then testing it on a small set of real requests.
• Let real demand pick the job. Dennis Yang would rank tasks by request volume, how often the current flow fails, whether the agent has reliable data and tools, and the cost of a wrong action, and keep sensitive account changes behind explicit confirmation. Rachel would look at what people already do with outside agents, as Webflow saw once it exposed its tools through MCP.
• Show up at the moment of need. Shishir Mehrotra would build interventions that recognize what the person is doing and bring the context with them, such as Superhuman's Knowledge Checker catching an out-of-date number before someone sends it, ahead of a broad agent that waits for a prompt.
• Prototype, then give it an owner. Sam would prototype against real inputs and collect 10 to 100 structured evaluations before the final ranking. Rachel would give the first surface a named owner and a decision date, and measure completed jobs, repeat use, human corrections and failed handoffs.