Who owns the agents: RevOps as the management layer of the fleet
On this page
The agent fleet belongs to RevOps. Agents read from the systems RevOps already governs, write to the records RevOps already reconciles, spend against budgets RevOps already reports, and escalate to the queues RevOps already staffs, so fleet management lands there, planned or by default. This playbook maps six functions the fleet requires, two org patterns that work, the permission graph that keeps agents out of politics, and a worked example with three live agents.
The ownership question is being answered elsewhere, and answered badly for revenue teams. Workday announced an Agent System of Record in February 2025, framed around HR and IT. Harvard Business Review published research from BCG and Boston University in May 2026 finding that treating AI agents like employees "reduced individual accountability, increased unnecessary escalation, lowered review quality" without improving adoption. And Salesforce's April 2026 account of Asymbl describes roughly 200 digital workers running beside 170 humans, carried as labor on the P&L and reviewed weekly, line by line, because "thumbs-up and thumbs-down buttons won't get the job done."
Read together, they mark out the problem. Somebody must run the fleet, and Workday is right about that much. Running it as ceremonial HR process fails, and HBR measured the failure. Asymbl's version works because it is genuine line management with real attention behind it. None of the three says where the function sits inside a revenue organization. The answer follows from what agents touch: the fleet runs on the systems of record that revenue operations already owns.
The window for deciding is short. In RevSure's January 2026 study of 306 senior US and UK GTM leaders, The 2026 State of Agentic AI in B2B GTM, 90 percent called agentic AI critical to their GTM goals within two years, and 76 percent were already deploying or implementing. RevSure's vision memo puts the end state at more than 100 agents running across GTM by 2030, sharing one brain. A fleet that size does not get managed by whoever happens to hold admin rights.
Why revenue operations holds the fleet
The jurisdictional argument is boring and decisive. The average company runs 22 GTM tools. RevSure's vision memo counts about 7 handoffs across GTM teams for a typical motion, and one enterprise deployment it describes spans 64 systems. RevOps exists because that sprawl needed a referee for humans: one function accountable for the definitions, the routing, the fields, and the reconciliations that every other team's work depends on. Agents multiply the traffic on those same roads. They do not build new ones.
The market has already conceded the underlying point. When analysts downgraded expectations for agent adoption in July 2026, they pointed at customers' data readiness, describing customer data that "lacks sufficient organization for meaningful AI deployment." Readiness work, organizing what agents will read and act on, is RevOps work by any name. The function that prepares the ground is the natural function to manage what gets planted in it.
Ownership also cannot sit with IT, and the HR framing fails for a different reason. IT can govern access and uptime; it cannot judge whether a reallocation proposal fits the quarter's strategy. HR frameworks manage people through motivation and development, and the HBR research above shows what happens when that apparatus is pointed at software. The fleet needs line management by a function that understands the revenue consequence of every action class. That function exists, and it is already on the org chart.
The stakes of running the layer well are now measured. ICONIQ's 2026 study of more than 150 B2B software GTM organizations found high-AI-adoption companies generating about $640K of net-new ARR per GTM FTE against $370K at low adopters, with top performers running 20 to 30 percent leaner. A fleet managed well changes the shape of the organization that runs it. A fleet managed badly is tooling sprawl under a newer name.
Six functions of fleet management, mapped to owners
Managing a fleet decomposes into six functions. Each has a human-workforce analog, and each needs a named owner before the fleet grows past a handful of agents.
Acquisition: build or activate
Every agent enters the fleet through one decision, made per agent: build it in-house or activate a managed one. Deepinder Singh Dhingra, RevSure's founder, states the real terms: "Build vs Buy is not a technology debate. It's a timeline debate." The timeline facts are unfriendly to reflexive building. RevSure's problem frame counts 3 to 4 months to build an agent in-house, 2 to 3 full-time engineers for a DIY build, and more than 3,000 open GTM engineering roles in the market, with GTM engineer compensation running $99K to $310K (Revnu, 2026). A CMO at a field service management software company put the buyer's version plainly: "I'd much rather buy than build. I'm not a blocker here. I just want to understand what we would be buying if we did." Acquisition is a RevOps decision made with GTM Finance in the room and the function head specifying the job, the same triangle RevSure productizes as Build or Activate. The per-agent grain matters: a fleet acquires the way a portfolio invests, activating the commodity workflows and reserving in-house build for the rare agent that encodes a genuinely proprietary motion.
Onboarding: context provisioning
A new hire gets an onboarding plan. A new agent gets a context graph: the systems it reads, the entities resolved across them, the definitions it must treat as canonical, and the permissions it inherits, which is the work the Context Layer exists to do once instead of per agent. Day-one provisioning can be fast; one published RevSure founder story records 7 data sources connected in under 30 minutes on day one. The honest counterweight comes from the same field record, from a marketing leader at a healthcare benefits company: "we are almost more than halfway through our contract for the year and we're still in setup mode." That is the concession this playbook owes you. Provisioning is real work, it is where fleets stall, and ownership without allocated capacity is how contracts sit in setup mode. RevOps owns provisioning; the function head is accountable for specifying what good context is and for the time-to-first-run.
Goal setting
Function heads set the goals because they own the outcomes, and RevOps enforces one rule without exception: every volume goal ships with a quality guard metric. Agents pursue targets literally. Published 2026 analyses of reward hacking in agent benchmarks found hacking on up to 100 percent of attempts, with explicit warnings reducing it only to 70 to 95 percent of runs. Goal design carries the control burden that good intentions cannot.
I want to get the team away from thinking that the more pipeline we have, the better we are, because actually you want to see it convert and then replenish.
a marketing leader at a supply chain risk company
That sentence, said about a human team, is the exact design spec for an agent goal: conversion and replenishment in the objective, never raw volume alone.
Performance management
The working cadence is weekly, and the review artifact is the decision trace: a sample of the agent's decisions read by a human who judges the reasoning, the way Asymbl reviews its roughly 200 digital workers line by line every week. Gong Labs found in December 2025, across 7.1M opportunities, that 70 percent of enterprise revenue leaders already trust AI for regular business decisions. Trust at that level stays deserved only under review discipline. The weekly review reads four artifacts: sampled decision traces, guard metrics against goals, spend against credit budget, and the escalation rate. It produces one verdict per agent from a menu kept deliberately short: promote, hold, demote, or retire. The vocabulary matters because it wires the review to consequences; a review that cannot demote is a newsletter. RevOps runs the mechanics; the owning function judges whether the outcomes are worth the budget.
Compensation: credit budgets
An agent's compensation is its credit budget, and the analogy is more useful than it sounds because it forces the two questions compensation always forces: what is this work worth, and who approves the raise. In RevSure's pricing model a credit is $0.02, an agent run costs $0.25, and each workflow carries a monthly budget set by expected volume. The chart below shows what a real package's monthly budgets look like per workflow.
What a month of agent work costs
Example monthly credit budgets by agent workflow, from a 200,000-contact package with 10 managed agents
Source: RevSure pricing model, example run volumes, 2026
The review is a monthly spend-against-output meeting with GTM Finance present, because GTM Finance is the rising influencer in every agent purchase and because agents-as-labor is becoming an accounting reality: Asymbl carries its digital workers on the P&L, and Deloitte issued DART guidance in June 2026 for outcome-based pricing of agentic software. RevOps proposes the budgets. GTM Finance approves them. The function head defends the output.
Offboarding: kill criteria and the context estate
Kill criteria get written at acquisition, before anyone is attached to the agent: a guard metric breached for a sustained period, a failed regression after a model change, a workflow that no longer exists, or a cheaper substitute clearing the same evaluations. The harder question is the estate. If accumulated context lives inside the agent, killing it burns institutional memory, so nobody kills anything and the fleet accretes zombies. If context lives in the company's graph, the pattern the Full Funnel Data Graph implements, then the agent is disposable and the knowledge survives the kill. Offboarding discipline is downstream of a data architecture decision made long before any kill. RevOps executes the kill; the function head signs it.
| Fleet function | What it decides | Accountable owner | In the room |
|---|---|---|---|
| Acquisition | Build or activate, per agent | RevOps | Function head, GTM Finance |
| Context provisioning | What the agent reads on day one | RevOps | Data owners of source systems |
| Goal setting | Targets and guard metrics per agent | Function head | RevOps enforces guard metrics |
| Performance management | Weekly trace review, evaluation cadence | RevOps | Function head judges outcomes |
| Compensation | Credit budget per agent workflow | GTM Finance | RevOps proposes, function head defends |
| Offboarding | Kill criteria and the context estate | RevOps | Function head signs the kill |
Two revenue operations patterns that work, and the failure between them
The centralized pattern is the agent desk: one team inside RevOps configures, owns, and reviews every agent in the fleet. It delivers consistency cheaply: one queue and one tiering standard, run by a desk that can still know every agent by name. Its costs arrive with scale. The desk sits far from the motion, so use-case discovery slows, and every new agent waits behind the desk's backlog until the desk becomes the reason the fleet stops growing.
The federated pattern moves ownership to the functions: marketing owns its agents, sales owns its agents, and RevOps runs the control plane they all operate inside, which holds the permissions per action class, the approval routing, the credit budgets, the evaluation cadence, and the kill switch. This is where agent orchestration becomes an operations job rather than a diagram. The pattern keeps owners close to the work and scales past what any desk can review. Its failure mode is drift: without a real control plane, federated ownership decays into every function running its own standards, and the plane must be actual software with actual authority, plus RevOps headcount assigned to it, or it is a slide.
Two org patterns that work
Where agent ownership sits, and what each pattern trades away
Centralized: the agent desk in RevOps
Federated: functions own, RevOps runs the control plane
Source: RevSure deployment patterns at $200M+ ARR B2B companies
Between the two sits the pattern that fails, and it is the one most companies are drifting into: everyone owns one agent, no one owns the fleet. Marketing activates an outreach agent inside its automation platform, sales switches on a CRM copilot, growth wires a scraper to a sequencer, finance trials a forecasting bot. No shared context, no shared tiering, no single queue, no kill switch, and two agents contact the same buyer in the same week with different messages. The founder's warning describes exactly this state, and it is worth reading slowly:
Your context graph becomes what your agents see. Your permission graph becomes what your agents can do. If both are ambiguous, your agents will fight the same fight your humans are fighting now, without anyone in the room to slow them down.
Deepinder Singh Dhingra, founder of RevSure
The practical sequencing: start centralized while the fleet is small, because standards are cheapest to set when the desk can see everything. Plan the federated handoff from the start, and move ownership outward function by function as each one demonstrates review discipline. The switch signal is mundane: when the desk's backlog, rather than context provisioning, becomes the constraint on the next agent, the desk has outlived its pattern. The control plane never moves. It is the part that stays in RevOps permanently, whatever the fleet's size.
The permission graph: who may change what
Agents inherit the organization's ambiguities and execute them at machine speed, which is why the permission chapter is the one a CRO should read twice. Dhingra's line about the stakes: "No company dies from lack of data. They die when data becomes political instead of analytical." A CFO once told him that marketing is the only department that grades its own homework, and he could not laugh at it. The permission graph is how the grading stops being self-administered: authority over a number gets separated from interest in the number. Three changes generate most of the politics in a revenue organization, and each needs a written answer before agents touch the systems that encode them.
Who may change attribution logic. RevOps administers the change process; the CMO and CRO co-approve; and changes land on a published schedule with notice, never mid-quarter, because targets are built on the number and moving it under people reads as sabotage.
If we change that all of a sudden, and it's out of their control, holding them responsible to that number is also hard.
a marketing leader at a cybersecurity company
No agent changes attribution logic. Agents read it and cite it, and route around none of it.
Who may re-categorize an opportunity. The record owner proposes, sales management approves, and RevOps owns the definitions being applied. An agent may flag a miscategorized opportunity with its evidence; the commit follows the same approval path a human edit would, and every change lands in the log with a trace.
Who may define a marketing-influenced renewal. This is a treaty term, defined jointly by the CMO and CRO and administered by RevOps. The field pattern that keeps the peace, observed across multiple working sessions: renewals held in the influence view and excluded from the ROI view, so the definition informs planning without inflating anyone's claimed number.
The closing rule of the permission graph: no agent holds a permission its owner lacks. Publish the graph on one page, and enforce it at commit time rather than in the employee handbook, which is what the GTM Harness does for every agent action that reaches the Approve step.
The worked example: three live agents and their owners
RevSure runs three named agents in production. The ownership map below is a real deployment shape under the federated pattern, and it is the level of specificity an org design needs to reach before go-live.
| Agent | Reads | Commits on its own | Requires approval for | Owner |
|---|---|---|---|---|
| Campaign Reallocation agent | Spend, campaign performance, full-funnel conversion | Research briefs, staged reallocation plans | Every budget move, as irreversible spend | Demand gen leader; budget owner approves commits |
| Deal Risk agent | Pipeline, engagement signals, deal history | Risk flags on opportunities, with prior state kept | Anything that changes a rep's next action | Frontline sales management, with RevOps running the queue |
| Deanonymization agent | Anonymous visitor traffic, identity providers | Account matches into a staged layer | Writing identities to CRM records, adding people to audiences | Marketing ops, with a standing privacy review of the configuration |
Two details in that table carry most of the doctrine. The Campaign Reallocation agent has no autonomous path to moving money, which is what blast-radius tiering looks like when applied honestly. And the Deanonymization agent, which resolves anonymous visitors through integrated providers such as RB2B, People Data Labs, and 5x5, commits nothing to a CRM record without approval, because an identity written into the system of record is a claim of fact the whole org will act on. All three escalate through one queue in the GTM Harness with the Decision Trace attached. That single queue, more than any org chart, is what owning the fleet means day to day.
What to do next quarter
- Census the fleet, including the shadow fleet: every agent-shaped automation running inside your automation platform, your CRM, or somebody's browser tab. The count is usually a surprise.
- Name the fleet owner in writing. One RevOps leader accountable for the control plane, whatever the ownership pattern for individual agents.
- Publish the permission page: attribution logic, opportunity categories, influenced-renewal definitions, and who approves changes to each.
- Give every agent a credit budget and a monthly spend-against-output review with GTM Finance at the table.
- Stand up the weekly review: sampled decision traces, read by a human, with findings logged against each agent.
- Write kill criteria for the next agent before it ships, and answer the estate question in the same document: what the company keeps when this agent goes.
Where this comes from
Built from our work inside enterprise GTM teams: indexed, verbatim working sessions with marketing, RevOps, and revenue leaders, quoted here at descriptor level with permission discipline. The ownership maps reflect deployments at $200M+ ARR B2B companies and RevSure's own three production agents, so the worked example is the map we run rather than a neutral survey of the market. Earlier-stage companies collapse several of these roles into one person, and the two org patterns described are the two we have seen work, from a small census.
Frequently asked questions
Who should own AI agents in a revenue organization?
RevOps should own the agent fleet as its management layer. Agents read from and write to the systems RevOps already governs, so tiering, permissions, budgets, and reviews belong there. Individual agents can be owned by the function closest to their work, marketing or sales, while RevOps runs the control plane every agent operates inside.
What is an agent control plane in revenue operations?
An agent control plane is the shared surface through which revenue operations governs every agent regardless of who owns it: permissions per action class, approval queues, credit budgets, performance reviews, and kill switches. RevSure ships this surface as the GTM Harness, where agents propose actions, humans approve them, and every commit records a Decision Trace.
How should companies budget for AI agents?
Treat each agent workflow as a line item with a monthly credit budget tied to expected run volume, the agent's version of compensation. In RevSure's pricing model a credit is $0.02 and an agent run costs $0.25, so a personalized-email workflow at 4,000 runs a month budgets about $1,600. GTM Finance reviews spend against output on a set cadence.
When should a company retire an AI agent?
Retire an agent when its guard metrics breach for a sustained period, when it fails regression after a model change, when its workflow no longer exists, or when a cheaper substitute clears the same evaluations. Offboarding costs little when context lives in the company's data graph rather than inside the agent, so accumulated knowledge survives the kill.