# The CPOs of Harvey, Glean and Rubrik on What It Actually Takes To Ship a Category-Winning Agent > Source: > Published: 2026-09-02 16:07:40+00:00 For about ten years, chief product officer was the best job in B2B. You brought your mug to the office, told the team what you were shipping this year, moved a few things to next quarter, and when an investor asked for a feature you said it was coming. And sometime, later, it was coming. That was the job through 2024. Every product leader in B2B is now under the gun to ship agents ASAP someone will pay for. Atlassian finally monetized its AI and the stock jumped roughly a third in a single day. Most of the rest are still in the middle of it. We banned panels at ** SaaStr AI** for a year because they’re boring. The exception is when the people on stage know each other, so at SaaStr AI I put together a group who do: **Anneka Gupta, CPO at Rubrik**, **Emrecan Dogan, CPO at Glean**, **Anique Drumright, CPO at Harvey**, and **Rachel Wolan**, then CPO at Webflow. Anneka sells to security teams who can’t tolerate a wrong action. Emrecan sells the context layer other agents run on. Anique sells to law firm partners who pay for software out of their own distributions. Three buyers, one shared problem. The five things that came out of it: **An agent roadmap is a second build of your entire product.** That’s why so many of them have slipped, and it’s why you start with the agents that can’t break anything.**The plan is what gets reviewed now, not just the output.** Rubrik and Harvey arrived at this independently: the agent proposes a plan, a human approves or edits it, and the execution underneath stays deterministic.**Half of a heavy AI user’s day goes into feeding context**, which is why Glean is now growing faster inside Claude Code and Cursor than in its own UI.** Agents don’t have seats and they don’t have identities.**Once an agent writes into Salesforce for a whole department, “who did this” becomes a product requirement.** You are responsible for agent behavior you did not design and cannot predict**, including whatever your customers build headless on top of you. ## #1. An agent roadmap is a second build of your whole product. Start with the agents that can’t break anything. Rubrik sits in cyber recovery. Customers rely on them to get data, applications and identity back after they’ve already been hacked, so nothing Rubrik ships can take that service down. Anneka’s read on how the agent work went: “It’s been actually a much more challenging problem to build agents within our product than I think I thought it was going to be a year ago.” The reason is in her own requirement, stated later in the session: everything possible through the UI should be possible agentically, and eventually you operate all of Rubrik through chat without the dashboards at all. That is building the product a second time, in chat, with new ways to get it wrong, for customers who can’t absorb a wrong answer. **Count the workflows before you commit to a date.** Not “we’re shipping agents in Q2.” How many workflows exist in your UI, which ones a customer would ever hand over, and in what order they get rebuilt. Most agent roadmaps that slipped this year were scoped like a feature and priced like a rewrite. **Start with the agents that can’t break anything.** Rubrik’s first real agentic workflow is forward-looking capacity planning, a job that takes a customer at least a day by hand. It reads, analyzes and recommends, and never touches production. The ones that do touch production come later, and only run after a human approves the plan. Sort your list by what happens if the agent gets it wrong, ship the ones where the worst case is a customer ignoring a recommendation, and hold the rest until the approval step works. Rubrik also didn’t hand-build a set of anticipated workflows. They built a platform generative enough to cover onboarding, troubleshooting, planning and whatever else customers do, because the alternative is guessing which ten workflows your customers want and shipping ten wrong ones. ## #2. In a cyber recovery, Rubrik won’t let the model improvise the steps Ruby started as a RAG application. Rubrik fed in the docs on setup and troubleshooting, customers asked questions, and the answers were, in Anneka’s words, okay answers based on whatever was in the documentation. What changed this year is the split between what the model does and what the system does. The agent pulls insights out of the customer’s own systems, marries that with Rubrik’s domain expertise, and produces the plan. Then the plan gets executed deterministically: “In a recovery scenario you don’t want to be guessing and you don’t want to be using like a probabilistic mechanism for recovery.” The model generates and explains the plan. The recovery steps themselves are fixed and auditable, which is what let Rubrik put an agent in front of a recovery workflow at all. ## #3. There is no central agent team at Rubrik The common instinct is to stand up an AI team, staff it with your best people, and have it build the agentic features for everybody. Rubrik went the other way: “How do we democratize this so that we don’t have a central team that is building all of the use cases and optimizing all of the use cases, but every PM and every engineering team within our company is thinking from an agent first mindset.” Go back to the workflow count in section 1. No central team absorbs that volume. It becomes an eval problem, an architecture problem and a training problem for every product team at once. ## #4. Half of a five-hour AI day goes into building context Emrecan’s number from Glean: “Most folks I talk to, if they are spending let’s say five hours per day in front of an AI assistant, they are spending half of that time in quote unquote building context.” Feeding documents. Feeding decisions. Feeding patterns. Updating memories. Writing skills. Glean started seven years ago when retrieval was the whole job. Retrieval is now a component, and the job moved from getting informed to getting AI to perform. Performance is still capped by context: the tested knowledge, the idiosyncrasies, the unwritten stuff everybody at your company understands and nobody has written down. For your own roadmap: count how much setup a user does before your AI feature produces anything useful. If they’re pasting in the same documents every session, that setup time is the real price of your product, and it doesn’t show up anywhere in your funnel. ## #5. Glean inside Claude Code and Cursor is growing faster than Glean’s own UI Glean runs two ways now: as the assistant you use directly, and as a single MCP server that Claude Code, Cursor or Codex tap into instead of wiring up individual MCPs. Emrecan on the mix: bundle the Claude, Cursor and Codex usage together and that path is one of the fastest growing parts of the business, growing faster than Glean’s own UI, which is still by a large margin the higher daily engagement driver. It also pushes usage back the other way, since people working through Claude come back into Glean’s own agents for other parts of their job. He drew a hard line between MCP and what Glean does underneath: “MCP, as much independence as it brings, it’s a very runtime fetch of information. You are bound by whether latency or you are bound by the search APIs under the hood.” The other half is high-compute offline processing: connecting employees, teams, projects, subsidiaries and companies you acquired a decade ago, and building the context before anyone asks for it. Shipping an MCP server gives an agent a way in. It doesn’t give the agent anything it couldn’t have queried itself. ## #6. One Gong call, three settings, and a write into Salesforce The Glean demo was the builder view, and the clearest picture of where departmental agents are heading. Glean’s own sales team generates 300 to 800 Gong calls a day. The agent reads a call, applies the instruction set, and proposes updates to Salesforce. The three settings Emrecan laid out: - A human drops in one call to test the agent. - The agent runs on every Gong call and tells the AE what it recommends updating. - Humans come out of the loop and the agent writes to Salesforce autonomously. In the demo, the AE pushed back: the call mentioned more technology-stack items than the four the agent extracted. The agent revises its answer, and the correction persists, so the next hundred runs behave differently. At that point it stops being one AE’s productivity tool and becomes a revenue operations agent running for the whole team, with updates that trigger downstream Salesforce workflows. I asked Emrecan the obvious question: Gong already pushes into Salesforce natively, so what is the agent adding? Put it on a spectrum. At one end you grab a generic call-analysis skill off the internet and apply it to everything. At the other, your CRO reviews every call herself with all of her expertise and context, which she will never have time to do. The agent’s job is to move you toward the second end. “The worst thing that you can do is to get a skill from the internet to say hey give me a call analysis skill and then apply it to all these things.” When someone says “use our sales framework,” Glean doesn’t need the document handed to it. It knows the source of truth, and the conversations around that framework: where it fails, where it needs updating, how it applies by segment and geography. Your competitors can download the same skill you did, and they will. How your CRO judges a call, built up over years of running the team, is the part nobody can download. Then the open questions start. If the agent is writing into your system of record, what is its identity? How do you keep a trace rich enough to investigate what went wrong, and who evaluates it? Those are product requirements now, and almost nobody has shipped them. A version of this runs in my own portfolio. Owner.com has a couple hundred reps doing 40 to 50 SMB calls a day. Their CTO built an agent that reads every call and produces a daily win/loss and competitive-loss read, rolled back through the day, the week and the month. No human could process that much qualitative data before. ## #7. Harvey ships 180 legal engineers who practiced law for 8 to 10 years The whole Harvey platform is agentic rather than one agentic feature. Prompt the chat interface and you get multiple documents, and a PowerPoint built on your own template off your own analysis. The deployment model is the part most B2B companies can’t match. Harvey has around 180 legal engineers building bespoke agents with law firms and in-house teams, on the firm’s own playbooks, precedent and best practices. Most of them practiced law for 8 to 10 years. The agent builder serves two levels, per Anique. At the firm or legal-ops level, agents encode the organization’s bar: most major firms have a knowledge team or innovation office that owns best practices, and those lawyers train Harvey and build the agents the whole firm uses. At the individual level, an agent learns how one lawyer likes repetitive work done and repeats it. Forward deployed pods exist for the customers that need them, with a PM, one or two actual lawyers and software engineers. Legal engineers are in every deployment. So when you buy Harvey you get someone who spent a decade doing the work, on top of the software. Very few agent companies can hand every customer a subject matter expert. Most of us need forward deployed engineers and don’t have them. ## #8. Law firm partners pay for Harvey out of their own distributions When you sell to a typical company, the money comes out of a budget line. Sell to a law firm at real contract sizes and it either displaces another tool or the partners pay out of what would otherwise be their own distribution. That’s the house on the Cape, or the car they’re not supposed to drive to the office. Technology has been sold into law firms for decades against exactly that resistance. Harvey is inside more than 60% of the Am Law 100 and across the Fortune 500 anyway, with 700+ customers in 58 countries. Scaling against partner-pocket economics is harder than scaling against a CIO line item, which is why I’d rate Harvey’s curve above the ARR number alone. The client side pulls it along too. As Anique put it, if she asked someone to review an employment contract for her today, she’d expect them to use AI on it. ## #9. Partners now review the associate’s agent plan, not just the draft The demand at Harvey has moved past “can we use agents.” Assume we’re using it. What does it mean to coach with it, performance manage with it, and verify it? The workflow Anique described: a partner gets work product from an associate, and wants to see the prompt, the plan the agent wrote from it, and whether they agree with the process that produced the output. Harvey is also working with law schools on how you grow into a great lawyer while leveraging AI. Senior partners at elite firms, some of the last holdouts on the ThinkPad and the red nub, are editing their associates’ agent plans before those plans execute. Two years ago they were reviewing a marked-up draft. That change in what gets reviewed is doing more to disrupt legal than any single feature. Verification is also where most of my own build time goes at SaaStr. It’s the bottleneck for me, for law firms, and soon for your customers. ## 5 more things from the CPOs: **Anique ran a listening tour with 60 customers in her first six weeks at Harvey**, not before she started. My rule hasn’t changed: if your head of product isn’t out talking to customers, show them the door.**Harvey’s agent builder ships in two modes.** One is natural language over selected skills and datasets. The other is deterministic: when this scenario comes up, follow these exact ten steps in this order. Most B2B companies build only the first, and the second is what enterprise buyers ask for.**Rubrik is giving the agentic experience to its GSIs and partners too**, so a partner delivering a program to a Fortune 2000 customer can run it on the customer’s behalf without the guesswork and the support calls. If you have a channel, your agents have a second audience.**Evals are the gate, and they’re still the unsolved part.** Anneka named eval design as an open question alongside the architecture question. Pushing agent building out to every product team only works if every team can also prove their agent is right.**Innovation in legal is roughly 50 times what it was three years ago.** Harvey came out of a small, sleepy market and disrupted it, and now frontier model providers ship features into the same space. Coming out of nowhere buys no protection from the next company coming out of nowhere. ## Who owns it when the customer’s agent breaks something I asked Anneka this directly. When a customer’s agent, or a GSI’s agent, takes an action that breaks something, whose fault is it? “At the end of the day we’re still responsible. Even when a customer makes a mistake and something isn’t working, they blame us. And rightfully so, they should. It’s our responsibility to make it obvious what the right choices are.” Her bet is that agents with the right guardrails will make fewer mistakes than humans do today, because there’s so much complexity in configuring enterprise software that people already get it wrong. She’s probably right about the error rate, and the job still gets harder, because there is now ten times more of your product that can do something you didn’t intend. We had the CEO of Replit on stage the day before, and we build things in Replit his own team didn’t know were buildable. Your customers will do things with your agents you didn’t plan for and didn’t know were possible, headless and in the UI both. You own the outcome either way. Security teams already live here, pulling hard for agents and refusing to cede control at the same time. Attackers run at machine speed, so defenders have to. Anneka’s read on whether teams can patch the vulnerabilities Mythos-class models are now surfacing: no. Four things to hold at once, then. Agents that take real actions. Products where a wrong action ends the account. A verification loop the customer trusts. Accountability for everything downstream of it. That’s the roadmap conversation in every B2B product org right now, and why I’d call this the hardest job in B2B today.