RevOps, Business Systems, and GTM Engineering: How the Three Build Agents Together

A GTM Engineer is joining teams that already exist, and the people in RevOps and Business Systems are quietly wondering what happens to their jobs. Here is the grounded version: nobody is being replaced, the swimlanes are knowable, and agentic GTM only works when all three build it together. This is how the collaboration actually runs.

By Langley Erickson · CascadeGTM · July 2026

I have spent the last few months talking with people in all three roles at growth-stage companies, and the same tension keeps surfacing. A company decides to hire a GTM Engineer. RevOps wonders whether this is their job being renamed and handed to someone more technical. Business Systems wonders whether an agent-builder is about to route around every control they have spent years putting in place. And the incoming GTM Engineer, often someone whose background spans GTM Ops and Business Systems, wonders how much they are allowed to own without stepping on anyone.

The fear is understandable and mostly misplaced. These three functions are not competing for one job. They are the ideate, build, and run of a modern revenue engine, and agentic GTM makes each of them more important, not less. But that is only true if the collaboration is deliberate. Left implicit, the overlap turns into territorial disputes, shadow agents, and the governance vacuum that is currently adding real money to real breaches. This piece is the grounded version of how the three work together, drawn from those conversations and the best current research.

The three functions, in one breath each

Before the swimlanes, the simplest framing. Nine of ten RevOps responsibilities also show up in GTM Engineer job descriptions, so the confusion is earned. The way to cut through it is to ask what each function is fundamentally for.

How we got three functions: an org-maturity story

These roles did not appear at once, and many early-stage companies still do not have all three. They separate out in a predictable sequence as a company scales, and knowing where you are on this path tells you which conversation you are actually having.

The important nuance: at pre-seed and seed, one technically inclined person genuinely does all three, and that is correct. The functions split not because someone read an org chart, but because the work stops fitting in one head. RevOps typically arrives first, around Series A. Business Systems separates out around Series B as integration and platform load grows. GTM Engineering is the newest layer, added once the systems are clean enough and the outbound motion real enough to build on. If you are adding a GTM Engineer, you are almost certainly Series B or later, and the swimlane question is now unavoidable.

The swimlanes: who owns what

Here is the detailed version of each function's territory: what it owns, and the tools and workflows it should hold. Read these as defaults to make explicit, not laws. The point is that they are written down before the work starts.

The collaboration model across the build lifecycle

Swimlanes describe steady state. The more useful question is who leads and who supports as a workflow moves from idea to production and beyond. The matrix reads in the RACI spirit: for each lifecycle stage, every function is Responsible, Accountable, Consulted or Informed. The one accountable owner per stage carries the ringed cell.

Two worked examples: where the collaboration and the stack diverge

Abstractions are easy to nod at and hard to use, so here are two concrete builds. Both are for the same Series C company making its first all-in bet on centralized agentic systems, with the heads of Revenue Operations, Business Systems and GTM Engineering in the room together, moving from Phase 3 to Phase 4 of the agent adoption curve. The two examples are chosen deliberately to show something the hype usually hides: the right architecture depends on the shape of the work. The first is a supervised, table-shaped workflow that belongs entirely inside a data platform. The second is an autonomous, event-driven system that genuinely needs a custom agent stack. Knowing which is which is the most valuable judgment a GTM Engineer brings.

Example one: usage-based trial messaging, built entirely in Clay

The first build is a free-trial nurture that changes its message based on how each account is actually using the product. It is a single-agent, human-in-the-loop workflow, and the honest answer is that it needs no custom orchestration at all. Every part of it, reading Salesforce and Snowflake, classifying the account, drafting the message, lives inside Clay. This is the more common growth-stage build, and getting it right means resisting the urge to over-engineer.

Why no external stack? Because the work is deterministic and table-shaped. Classifying an account from CRM fields is a formula, not a reasoning problem. Formulas are free, instant and deterministic: they cannot hallucinate, though they are only ever as good as the field underneath, which is why the CRM hygiene has to be real. Clay reads Snowflake product usage natively, holds the canonical account, and drafts the message. Reaching for a custom agent here would rebuild plumbing Clay already owns and add cost for no gain. The one place judgment is needed, a single fresh personalization detail from the open web, is the only place a Claygent runs.

The reference architecture

Four layers, all inside one platform. The labels show who leads each.

What the rep actually does: the end-user workflow

The product is a usage-aware nurture that drafts the right message for each trial account and hands it to a rep to approve. Most of the path is automated classification; the human enters at the end, where judgment belongs.

Notice how much of this is grey, automated and deterministic, and how little is agent reasoning. That is the point. The system is cheap, reliable and fully auditable precisely because it uses an agent only where an agent is needed.

The standard operating procedures that make it safe

The launch playbook: who leads, who supports

Example two: autonomous inbound lifecycle, on a custom agent stack

The second build is the opposite shape, and it is where the external stack earns its keep. A lead arrives at any hour and the system must enrich, qualify, route and respond in under two minutes, 24/7, with no rep awake to help. This is a multi-agent, human-out-of-the-loop system: the agent acts on its own for the standard path and escalates to a person only on the exceptions. The stakes are stark: the median B2B company still takes around 42 hours to respond, while the MIT and InsideSales Lead Response Management study found a five-minute reply makes a lead 21 times more likely to qualify than a thirty-minute one. A table on a schedule cannot close that gap. A custom agent graph can.

Why the external stack here? Every graduation trigger from the first example fires at once. The flow branches (a student, a competitor and an enterprise buyer take different paths), it runs continuously on events rather than a schedule, it holds per-lead state across a conversation, and it acts, replying and booking, rather than drafting for approval. That is a stateful, branching, autonomous system, which is exactly what a custom orchestrator is for and exactly what a data table is not.

The reference architecture

The same five-layer shape as any production agent stack, but built for autonomy: a durable event entry, a multi-agent orchestrator, a governed tool layer, the data foundation, and a governance layer that is heavier because no human sits on the standard path.

This is one robust, current reference stack, not the only valid one. A team standardized on Langfuse would swap it for LangSmith; a shop on Google Cloud would run it on Cloud Run instead of ECS; a team going Anthropic-native might use the Claude Agent SDK in place of LangGraph. What does not change is the shape: a durable event intake, a stateful multi-agent orchestrator, a governed tool layer through MCP, a clean data foundation, and an observability and identity layer wrapped around all of it. For an autonomous system that last layer is not optional, it is the difference between a controlled system and an incident.

Two deliberate choices worth calling out, because they are where teams most often overspend or overbuild. First, model tiering: this system does not run everything on the most capable model. A fast, cheap model classifies and routes, a mid-tier model handles qualification and the prospect-facing reply, and the flagship is reserved for the genuinely ambiguous calls. Routing cheap work to cheap models is the single biggest cost lever in an autonomous pipeline, and it is why the cost model matters. Second, hosting: because the models are called as an API, there is no GPU to run, so the agent lives on a standard managed container service, not a GPU host. Matching the infrastructure to the actual workload is exactly the judgment that keeps a Phase 4 build economical.

What happens on a lead: the end-user workflow

Here the end user is really two people: the prospect, who interacts with the agent directly, and the rep, who is handed a booked meeting. The standard path runs with no human in the loop; a person appears only at the end, or earlier on a flagged exception.

Two honest cautions live in this flow. Speed is not the goal, qualified speed is: a 90-second reply to a junk lead is worse than a five-minute reply to a real buyer, so the agent is measured on quality, not raw latency. And human-out-of-the-loop is earned, not assumed: the autonomy bounds decide exactly what the agent may do alone and what it must escalate, and those bounds are enforced in code, not trusted to good behavior. Be honest with yourself about risk appetite here, too. A fully autonomous, prospect-facing agent is a posture some brands and some regulated industries should not adopt, and the right answer for them is a human-on-the-loop variant where a rep approves the first outbound touch. The architecture is the same; only the autonomy dial moves.

The standard operating procedures that make it safe

An autonomous, prospect-facing system carries more risk than a supervised one, so its operating procedures are stricter. These are agreed before launch, not after:

The launch playbook: who leads, who supports

Same five-stage collaboration, higher stakes at every step. Notice the roles do not change, but the autonomy raises the bar on QA and rollout.

The fears, answered honestly

These are the questions that actually come up in the hallway, so here are direct answers rather than reassurance.

Governance, security and cost: the shared burden

The reason these three functions cannot afford turf wars is that agentic GTM introduces a class of risk none of them can own alone. An AI agent is a privileged non-human identity: it reads the CRM, calls APIs, and acts across systems, and it can change its behavior mid-session based on context. The current numbers are sobering. Only 14 percent of agents go live with full security and IT approval. Just 5.7 percent of organizations have full visibility into their service accounts. And shadow AI accounted for 20 percent of breaches and added roughly $670,000 to average breach costs, with 63 percent of AI-breached organizations having no governance policy at all.

The split that works, drawn from current best practice:

• Security and identity: Business Systems leads. Every agent gets a scoped, expiring credential, permissions matched to its action space rather than inherited from its maker, an audit trail, and a place in the registry. This is the discipline that turns a shadow agent into a governed one.
• Human-in-the-loop design: GTM Engineering builds, RevOps sets the bar. The research says presence is not practice: a human in the loop needs context, authority and a rationale, not just a checkbox. GTME designs where the human sits; RevOps decides which actions require one.
• Cost and ROI: GTM Engineering models, Finance and RevOps review. What a workflow costs to run, what it costs at scale, and whether it beat a holdout. Modeled before the build, not reconstructed from an expense report after.
• Autonomy level: a leadership decision. Whether a workflow is human-in-the-loop or fully autonomous is not a builder's call. RevOps convenes it, and it maps directly to the frameworks now arriving, from the EU AI Act to NIST's agent standards.

Takeaways for growth-stage leaders

Whether these three functions add up to a system or a turf war is a leadership decision. Here is the version for each seat.

Sources

External sources are 2025 and later, with all AI, agent and security claims drawn from the most recent reporting available.