B2B AI Agent落地：路线图、审批流与上下文成本

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.