A persona review needs an owner who can change its criteria
Freshworks’ demonstrated CPO review and a leadership transition expose a useful design question: who maintains the judgment encoded in a named-person agent step?
A Freshworks product-workflow demonstration includes a step called the CPO review. In the published interview transcript, Srini Raghavan describes the team naming it that way while showing the agent's checklist.
Separately, Freshworks' July 28 announcement said Ryan Manning would join as chief product and technology officer on August 10, succeeding Raghavan.
That juxtaposition is a useful prompt for design. It is not proof that Freshworks left stale policy running: a published interview can describe work recorded earlier, and the public material does not establish what the company later changed.
The question I would take into my own workflow is who can maintain the judgment encoded behind a person's name.
A familiar persona can hide an unspecified policy
“Review this as the CPO would” is legible to a team that knows the person. It may be less legible to the next person maintaining the agent, especially when priorities, responsibilities or organisational structure change.
I would separate the useful review criteria from the persona used to introduce them. Which customer evidence matters? Which tradeoffs should be challenged? What makes a proposal incomplete? Which decisions must still go to an authorised human?
As an illustration, imagine I inherit a hypothetical agent step named after a former head of product. Before replacing the name, I would inspect the prompt, its examples and the outputs it has been producing. A cosmetic rename would not establish whether the criteria still match the organisation's priorities.
I would ask the current owner to approve a written rubric and identify its limits. The old examples might remain useful as historical training material, while a particular priority needs revision. The goal is continuity of understood judgment, not either automatic preservation or automatic deletion.
The distinction also prevents a generated review from impersonating approval. An agent can apply a rubric associated with a role without being the person who holds that role. Its output should make clear what was checked and what remains for the accountable decision-maker.
Reassignment should be a workflow event
A leadership transition is one occasion to review the step. A change in product strategy, regulation or customer commitments can matter just as much even when the same leader remains in place.
For the hypothetical agent, I would give the rubric a version and a named maintenance owner. I would also specify what triggers reconsideration: a role change, an altered decision boundary or a recurring class of review failures. A calendar reminder alone cannot detect every meaningful change.
A small regression set can make that maintenance concrete. Keep examples of proposals the current rubric should accept, challenge or escalate, with the reasons recorded. When the rubric changes, inspect the differences rather than assuming a more polished review is a better one.
I have read the interview's published description and transcript, not reproduced Freshworks' internal workflow. Its measured speed and production governance are separate questions. The artifact is still useful because the name reveals a pattern many teams can recognise in their own prompts.
Before your next agent review, search for instructions that imitate a colleague or executive. For each, identify the current rubric owner and the decision the step is allowed to influence. The names can stay if they help the team, provided the policy beneath them remains explicit.
A persona can make a review familiar; an accountable owner must keep its criteria current.
