“Move the launch to Friday.”
There is already a launch in the product. The launch has a date, dependent tasks, owners, a draft announcement, and people who are allowed to change each of them. The request is short because the person expects all that context to do some of the explaining.
An agent can help turn the request into work. But what work? Changing the launch date, moving every dependent task, and sending the announcement are three different commitments. The product has to make the proposed scope clear before the person can sensibly hand the request off.
I use product agent to mean 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 definition is a working one, not an industry standard. The definition describes a relationship between an agent and a product, not a particular model, framework, or interface. The work might produce a changed record, a draft, or an answer grounded in current product data. The work doesn’t have to end with a write.
The model is the engine; the product is the harness
A model can decide what to do next. On its own, a model can’t find the launch, know who may change the launch, show a person what will change, or prove what happened afterward. The machinery around a model that lets the model act (tools, limits, saved state, and the loop that decides the next step) is usually called a harness.
For a product agent, the product is most of that harness. Four parts matter most:
- Context and objects. The launch, the tasks, the owners, and how they relate. The agent works on real records, not a description of them.
- The acting identity and its permissions. Whose access the agent uses, and which changes that account may make on which records. Permission to edit tasks still doesn’t mean the person wanted every task moved.
- The screens where people review. The real schedule, the real order form, the real canvas, where a person can see the proposed change in place.
- Receipts, history, and undo. The record of what actually changed, and an honest way back.
A capable model inside a weak harness is an impressive demo. A capable model inside a strong harness is something people can hand work to.
What each part does for the launch
Follow the launch request through the product. The project model says which tasks belong to the launch. The scheduling service checks the proposed dates. The permission layer decides which changes the acting account may make. The interface shows the proposed result before anything moves. History records what changed, and recovery restores what recovery safely can.
None of those responsibilities disappears because the agent explains its plan fluently. And an existing screen doesn’t prove the guarantees underneath are ready for an agent. A permission check implemented only in a button’s click handler won’t govern a scheduled agent calling the same service.
The useful engineering task is to list which guarantees already exist, which ones the agent can use, and which ones still have to be built. “Add tools” is only part of that work.
When the product holds only part of the harness
The picture isn’t always that tidy. A shared runtime may serve several products at once. An outside host may own the model loop, as when an AI assistant elsewhere calls the product through MCP. In those setups the product supplies only part of the harness, and the partial role is exactly why the product has to own its guarantees: the permission check at the moment of the write, the review of the exact change, and the receipt. The loop can live anywhere. The promises to the people whose records change can’t.
What counts, and what doesn’t
Imagine three features beside the same project:
- A fixed button moves every selected due date forward seven days.
- A text generator writes a suggested launch plan that someone copies into the project by hand.
- An agent investigates dependencies, asks about an ambiguous workstream, prepares a bounded change, and reports the confirmed result.
The first may be excellent automation. The second may save real effort. Neither needs the name product agent to be valuable. The third is the clearest example of what I mean: the person delegates a goal, the agent makes decisions using the product’s context, and the work stays connected to the product’s real data.
“Coding agent” answers a different question. Coding describes the work; being built into a product describes the relationship. An agent inside a code editor can be both. An outside assistant that updates a project through MCP isn’t the project tool’s own agent, but the project tool still governs every change the assistant makes.
Define completion before choosing the loop
For the launch, write down what finished looks like. Which dates should change? Should the announcement stay a draft? What happens to locked tasks? How will the person hear about exceptions?
Then name the evidence. A final message is a claim; changed records, delivery receipts, or an answer tied to real data are how the claim gets checked. When the result is uncertain, keep the uncertainty instead of turning it into “Done.”
Then define recovery. Stopping future work, restoring the previous dates, and correcting an announcement already sent are three different operations. The approval, receipt, and undo patterns follow from those promises.
Defining the category is useful only if it makes the work concrete: the person’s goal, the authority behind the goal, the state that matters, and the evidence that the work happened. The model supplies the judgment. The product, as the harness, has to keep the agreement.