Aaron Levie described a role emerging in enterprises: someone who maps workflows, designs the future state, and orchestrates AI agents across a function. He called it the agent operator. I agree with the observation. The name is half right. This is not a new role. It is product management. It just does not live in R&D anymore.
R&D figured this out first
For two decades, product management was the discipline of mapping problems, defining workflows, deciding where human judgment mattered, and iterating with engineers to ship something better than what existed. That work was confined to product teams because that was where building happened. That constraint is gone. Every function deploying AI workflows is now, structurally, a product team. Finance is shipping agents. Legal is shipping agents. HR, sales ops, support, RevOps, procurement, all of them are designing systems where the workflow is the product and iteration speed determines who wins. Same problem shape. Same skill requirements. Different org chart.
Name the role properly
The cleaner title is Product Builder who is also an Agent Operator, because the job is not "run agents." The job is ship working systems where humans and agents share the work, in production, with measurable outcomes. Product Builder is the half that ships: they prototype, own evals, reason about cost and latency, take a real outcome to production. Agent Operator is the half that runs the substrate: they map the workflow end-to-end, design which steps are deterministic versus agentic, tune the prompts and routing. Drop either word and the role gets weaker. The role that compounds is both.
The layer underneath all of it
There is one more piece most companies have not started on. Agents are only as good as the context they can reach, and that context is two things: data and business logic. Knowledge bases, records, and reference data on one side; rules, policies, approval chains, and compliance gates on the other. The foundational decision is what to store persistently versus what agents compute at runtime. Get it wrong and your agents are either slow and expensive or stupid and inconsistent. Most companies are deploying point-solution agents in finance, in support, in HR, with no shared substrate underneath. That works for a quarter. It does not work for an operating model. The companies that compound treat context as an architectural problem, not a per-team problem.
Where this is going
R&D already evolved into this model. GTM and G&A are catching up in months, not years. The strongest job descriptions in 2027 will say "Product Builder, [Function]." The product team did not lose product management. The rest of the company finally caught on to what it was.
Pick one this week. Map one workflow outside R&D that your company is automating: finance close, support tier-one routing, legal review. Write down the operator, the developer, the agents, and the cycle time. If there is no developer paired with the operator, that is the gap.