This post is where the framework gets concrete.

A modern revenue system is a system of loops. Each loop covers one stage of the revenue lifecycle. Loops are self-contained, versioned, and measurable. They chain together. Ten of them cover the full lifecycle, end to end.

This is the framework I have been developing, implementing in parallel, and will continue to refine alongside the readers of Ship Revenue. It is not a finished theory. It is a working model of how revenue infrastructure looks when you take the thesis seriously.

The claim

A revenue loop is a self-contained, composable execution unit covering one stage of the revenue lifecycle.

Each loop has six things: config that defines its behavior, logic that executes against that config, inputs that trigger it, outputs that chain to the next loop or humans act on, metrics that describe how well it is working, and feedback that closes it.

Loops are named. Loops are versioned. Loops are reviewable. Loops chain together through well-defined interfaces. Loops can be owned by different teams without stepping on each other, because the interfaces between loops are as important as the internals of any single one.

Ten loops are the canonical set. They cover the revenue lifecycle as most modern SaaS companies experience it: two for planning, three for demand, two for acquisition, two for retention, one cross-cutting. The grouping is not arbitrary. It reflects how revenue work actually clusters at scale.

The framework is also extensible. A company with a significant channel motion may want a Partner loop that manages indirect pipeline and co-selling. A product-led company may want a Product Qualified loop that reads from product telemetry rather than inbound forms. A community-led motion might warrant a Community loop. The canonical ten are the starting point. The structure that makes them composable (anatomy, chains, archetypes) is what lets additional loops plug in without destabilizing the rest.

This is what it looks like when the GTM system is built as a product.

What a loop is

Every loop has the same anatomy. That is not a coincidence. It is what makes loops complete and composable.

Config. Every loop has structured, versioned configuration that defines its behavior. Scoring weights. Routing rules. Play definitions. Threshold values. Quality rubrics. The config changes frequently, is owned by ops, goes through review, can be tested, and can be rolled back with a single commit. The loop’s config does not change what it does; it changes its behavior. This separation is what operations as code actually looks like in execution. Anyone on the team can see, at a glance, what the loop is currently configured to do.

Logic. Every loop has code or agents (or both) that execute against the config. Code handles the deterministic work. Evaluating rules. Running math. Writing to the surfaces of work. Triggering downstream chains. Agents handle the semantic work. Researching prospects. Composing outreach. Classifying unstructured data. Inferring values from ambiguous signals. Evaluating edge cases where deterministic rules cannot produce a clean answer. The logic is engineering-owned and changes rarely. The code does not know what the thresholds are. It reads the config at runtime.

Inputs. Every loop is triggered by something. An event (a new lead is created, an opportunity is saved). A schedule (a weekly scan runs, a daily evaluator kicks off). A chain from another loop (Qualify hands off to Route). An external force (a major attrition event triggers a replan). The trigger defines when the loop runs and what it receives. Different loops are triggered in different ways, which is part of why the framework accommodates multiple loop archetypes.

Outputs. Every loop produces something. A decision. A CRM write. A task. A notification. A downstream chain. An escalation to a human. Outputs are logged. Outputs are explainable. Every decision the loop makes can be reconstructed, after the fact, with its reasoning trail intact. No black boxes.

Metrics. Every loop produces observable signals about its own behavior. How often did it run? How often did it succeed? How long did it take? What was the quality of the decisions it made? These metrics are what lets the team govern the loop without sitting in the loop itself. Monitor the aggregate outcomes. Adjust the config when outcomes drift from intent.

Feedback. Every loop closes. The loop’s outputs become observable through its metrics. Its metrics drive adjustments to its config. Those adjustments change how the next execution runs. Each cycle produces evidence about how the loop should behave, and that evidence shapes the next cycle. The closing happens at three levels. Sometimes the loop closes itself: a scoring model retrains on conversion outcomes, a routing rule auto-tunes based on assignment quality. Sometimes humans close it directly: ops sees grade distribution drifting and updates the scoring weights. And sometimes (increasingly) agents do the interpretive work: they read the metrics, identify patterns, compare current behavior to intended behavior, and propose specific config changes with the evidence to back them up. Humans review the agent’s recommendation, accept or revise it, and merge. The agent does the analysis; the human does the governance. The loop closes faster than humans alone could close it, but the human stays in the loop where it matters: in the policy decisions, not in the per-record approvals.

A loop with all six elements is a first-class primitive. Without any one of them, it is something less. A script. A workflow. An automation gluing systems together. The anatomy is what makes a loop the building block of a coherent system rather than a one-off piece of plumbing.

The chains

The ten loops organize into four chains and one cross-cutting loop. Each chain represents how work actually flows through the system.

The Planning chain. Design and Deploy. The chain plans the architecture of the revenue organization: the ICP, target accounts, audience segments, segment investments, capacity, territories, and compensation that everything else runs against. Design produces the architecture as scenarios. Deploy materializes the scenarios in surfaces of work. The output of the Planning chain is the architecture every other loop reads from.

The Demand chain. Generate, Qualify, Route. Demand-creation activities produce leads. Leads enter the system and get qualified, then routed to an owner. The chain produces demand the rest of the system can act on: qualified, scored, routed records ready for sales engagement.

The Acquisition chain. Engage, Pursue. Engage runs the full prospect engagement arc: outreach composition, the resulting meeting, discovery, and opportunity qualification. Confirmed opportunities move into Pursue, where deal execution runs to close. The chain produces closed customers from qualified demand.

The Retention chain. Onboard and Expand. A customer moves from signed contract through implementation to first value, then through the expansion and renewal lifecycle. Retention is where most modern SaaS revenue actually comes from. It is also where most modern revenue systems have the weakest loop infrastructure.

The cross-cutting loop. Coach. Coach does not chain with the others and does not own a specific stage of the lifecycle. It operates on the outputs of the other chains, aggregating activity and outcomes into development signals for each field team member.

A healthy revenue system runs all four chains and the cross-cutting loop in coordination. Most modern systems have strong Demand and Acquisition chains, weak Retention chains, patchy Planning chains, and almost no cross-cutting capability. This imbalance was tolerable in a seat-based pricing world, where expansion was mechanical and retention was largely a renewal-date event. It is a liability now. As the industry shifts to consumption-based pricing, revenue grows or shrinks continuously with usage, and the Retention chain becomes operationally as critical as the Demand and Acquisition chains. The tools to instrument this shift are arriving. Revenue loops are how you use them.

The ten loops

The Planning chain

Design. ICP definition. Target account lists. Audience and persona segments. Strategic investment allocation across segments and channels. Capacity planning and territory design. Compensation design. Target productivity per role and segment. Ramp curves for new hires. Roster of existing and planned people. Annual targets per territory per measure. The Design loop answers questions like what does our ICP look like for the upcoming year? and which segments are we investing in and at what level? and how much new ACV can we produce next year given this roster and these ramp assumptions? Design operates on scenarios. A scenario is a complete, shareable plan that downstream loops read from. Scenarios can be compared side by side, promoted to active, or retired. Promoting a scenario changes a single line of configuration and becomes the source of truth every downstream loop reads from. Design runs are usually scheduled (annual, quarterly), but they can also be triggered by events that force a replan: a macro shift, significant attrition, a funding round that changes investment capacity, a strategic decision to enter a new segment. In a mature implementation, Design also supports what-if queries driven by agents, where a question like what if we added two enterprise AEs in AMS East next quarter? returns a structured comparison against the current active scenario without writing any files.

Design also runs continuously in a lighter mode, watching whether the active architecture is holding under operational drift. When workload distribution skews (one rep is overloaded and pipeline is starting to go stale, another is underutilized and territory is producing less than it should), Design surfaces rebalancing actions. Reassign these leads. Split this territory. Escalate this pool’s overflow to a backup pool. The continuous mode operates on the outputs of Route and Pursue rather than on customer records directly. Its purpose is to prevent “the routing rules worked correctly” from becoming “one rep has twice the pipeline they can work and another has a territory producing below plan.” Rules that were right at design time can produce bad outcomes under drift, and Design’s continuous mode is how the system catches that drift.

Deploy. Territory management. Quota setting. Comp plan issuance. Deploy takes the architecture from Design and materializes it in surfaces of work. The territory hierarchy. User-to-territory assignments. Role cascades (what happens when a lead matches a territory whose AE seat is open). Account-to-territory assignment. Pool membership for shared coverage. Deploy is a materialized loop, not a per-event loop. It runs when the architecture changes. It reads the declared state from configuration and makes it real in downstream systems, applying the changes in the right order (parent territories before children, structure before assignments). When accounts cannot be matched deterministically (billing data is incomplete, geography is ambiguous, the account’s address is a multi-tenant building that could belong to three different reps), Deploy hands the ambiguous cases to an agent, which resolves them with higher confidence than rules alone. The accounts the agent cannot confidently resolve go into a review queue rather than being guessed. Deploy is where architectural work becomes operational infrastructure.

The Demand chain

Generate. Demand creation. Generate runs the activities that produce the conditions for leads to exist: multi-touch campaigns across channels, account-based programs targeting named accounts, events from field gatherings to large-scale conferences, content programs spanning editorial and SEO, paid media across search and social, partner and community programs, PR and analyst relations. The loop’s outputs are the activities themselves (campaigns running, audiences reached, content published, events held) and the leads those activities produce (form fills, registrations, downloads, conversations). Generate reads from Design (ICP definition, target account lists, audience segments, segment-level investment levels) and from downstream loops (which lead sources are converting, which campaigns produce highest-quality pipeline, which content themes drive engagement). Generate runs in multiple archetypes: campaigns are scheduled (running on cadence), high-intent signals trigger event-driven plays (an ABM motion fires when a target account shows engagement), and campaign planning is itself a modeling activity (segment analysis, channel mix optimization, budget scenarios). Its feedback cycle is long: a campaign launched today might not produce attributable revenue for six months, and the signal-to-noise ratio in attribution is famously poor. This is one of the loops where agent-assisted feedback has the most room to mature, because the interpretive work of “which patterns in our marketing activity actually drove pipeline?” is hard for humans to do at scale and harder still to do in time to act on.

Qualify. Lead qualification. Every new lead enters the system through Qualify, whether it came from an inbound form fill, an outbound signal at a target account, a webinar registration, or any other lead source. Enrichment from third-party providers fills in the firmographic and technographic gaps in the raw lead record. A weighted scoring model evaluates the enriched lead against a defined rubric and produces a score. A grade (A, B, C, D, usually) bucketizes the score into tiers that downstream loops can act on. The enriched, scored, graded lead is written back to the CRM for the field to see. Qualify runs hundreds of times a day at most modern software companies. It is the loop most directly exposed to data quality problems. Bad enrichment produces bad scores, and bad scores produce bad routing. The team governs Qualify by monitoring grade distributions over time (if the A-grade percentage is drifting up, either the product-market fit is improving or the scoring model is losing discrimination) and by reviewing the factor contributions on individual leads that look wrong. The scoring model itself is pure code because the logic is deterministic. The enrichment call is code too. The one place where semantic work appears in Qualify is when the enrichment provider returns ambiguous results and an agent has to decide which of several possible matches is the right one.

Route. Lead assignment. The Route loop takes a scored, graded lead and matches it to the right owner. A rep. A pool of reps. A queue. Route walks a priority-ordered rule set. The first rule that matches fires. Rules can reference territory, segment, lead score, existing account ownership (so that a lead from an existing customer’s domain goes to that customer’s AE, preserving continuity), or any other attribute. Most leads are resolved by a structured rule set. The interesting cases are the ones where the deterministic rules do not produce a clean answer. An agent handles those. The agent has access to the same rules and the same territory structure as the deterministic engine, but it can reason across ambiguous inputs. It reads the lead’s billing city, the company’s headquarters per its own research, the industry vertical, the lead’s own claims about location, and makes a judgment. When the agent’s confidence is high, the assignment fires. When confidence is lower, the lead goes into a review queue with the agent’s reasoning attached. When confidence is very low, the lead lands in a triage queue for human review. The same route engine powers multiple callers in a working implementation: the live routing endpoint that fires on new leads, a simulation tool for testing rule changes against historical leads, and a batch account-to-territory matcher used by Deploy.

The Acquisition chain

Engage. Prospect engagement, end to end. Engage owns the relationship with a prospect from outreach through opportunity qualification, in two phases.

The first phase is outreach. An agent researches the prospect company using available sources. It drafts a personalized email sequence (typically three to five emails, spaced appropriately). It scores the quality of what it produced against a multi-criteria rubric (relevance, personalization, specificity, calls to action, tone, length, formatting). The sequence lands in a review queue. The assigned rep reviews it. The rep approves or rejects it or makes revisions. The approved sequence gets deployed to the engagement platform. The rep is not doing the composition. The rep is governing the composition. That is the separation of concerns from v0.05 in production.

The second phase is discovery and qualification. When the outreach produces a meeting, the rep leads the conversation. The rep listens for the qualification dimensions that matter (problem fit, urgency, authority, decision process). Call intelligence platforms listen alongside, capturing the conversation, structuring it against the team’s framework (BANT, MEDDIC, MEDDPICC, custom), and in many cases populating the qualification dimensions directly from what was said. Agents support the rep further by flagging dimensions still uncovered and suggesting follow-up questions for the next meeting. The rep reviews, adjusts, and commits the qualification. The output of Engage is either a confirmed sales-qualified opportunity ready for Pursue, or a disqualification with reasoning that returns the prospect to a nurture state.

The config for Engage spans both phases. Plays, research prompts, and quality thresholds shape outreach. The qualification framework, disqualification rules, and handoff criteria to Pursue shape discovery.

Pursue. Deal lifecycle and health. When Engage hands off a confirmed sales-qualified opportunity, Pursue selects a deal play based on account characteristics and context from the discovery conversation. A small deal gets a fast-track play with minimal structure. A large deal gets a multi-thread play with stakeholder mapping, champion development milestones, and executive engagement steps. The play creates milestone tasks, aligned to the sales methodology, with staggered due dates. The rep works the tasks. Alongside the event-driven side of Pursue, a scheduled evaluator runs daily against every open opportunity. It looks for staleness (no activity in N days), close-date risk (the deal’s close date is within a window but key milestones are unmet), pipeline health problems (the stage duration does not match the velocity target), and other signals of trouble. When a signal fires, the evaluator delivers a nudge through preferred channels (Slack, email, CRM notification). Pursue is the loop that owns the longest, hardest stage of the revenue lifecycle. It is also the loop most directly consumed by managers, who see the aggregate behavior of their team’s deals and use it to coach and forecast.

The Retention chain

Onboard. From close to first value. The Onboard loop takes a new customer from signed contract through implementation, training, adoption milestones, and first value. It drives the tasks that the account team owns (kickoff call, data migration, first workflow deployed, team trained, first outcome achieved). It tracks the milestones against a timeline and flags when the customer is falling behind. It monitors health signals during ramp (login frequency, feature adoption, support ticket volume, sentiment from calls). It hands off to Expand when the customer is live, healthy, and realizing value. Onboard is the least-built-out loop across most modern revenue systems. Most companies run onboarding as a set of checklists owned by a CS manager with little programmatic infrastructure. The tasks and milestones live in a project management tool. The health signals live in a BI tool. The handoffs happen through Slack messages. This is not a stage where loops cannot work. It is a stage where the business model made it less urgent. Under seat-based pricing, revenue was largely decoupled from first-value time. Under consumption pricing, first-value time determines when revenue starts. The infrastructure to instrument Onboard has been arriving. The urgency to use it is arriving now. Onboard is a frontier. The team that builds this loop well will have a meaningful structural advantage over teams that do not, because first-value time drives retention and retention drives the rest of the business.

Expand. Renewal management and growth. Expand manages the customer through the renewal cycle and the full range of expansion plays: upsell, cross-sell, seat growth, product adoption, multi-year conversion. It applies the same rigor as Qualify, but to expansion opportunities rather than net-new ones. An account’s expansion potential reflects usage trajectory, adoption depth, engagement with the account team, signal strength from product telemetry, and commercial context (time to renewal, current contract shape, known buying-committee changes). When expansion signals are present, plays fire: executive business reviews, upsell motions, risk intervention, multi-year negotiation. When renewal approaches, the loop surfaces the risks and opportunities to the account team with enough lead time to act. Expand is where the thesis meets business reality. Most modern SaaS revenue is expansion, not new logo. A team that treats expansion as “the CS team handles it, we’ll see how it lands at renewal” is leaving the biggest lever in the business unmanaged. A team that runs the Retention chain with the same rigor applied to the Demand and Acquisition chains gets compounding returns.

The cross-cutting loop

Coach. Rep development. Coach aggregates structured signals from call intelligence, activity patterns, deal outcomes, and conversion metrics into coaching signals for each team member. It identifies patterns. Reps who discover well but close poorly. Reps whose deal velocity is faster than average but whose deal size is smaller. Territory-level skill gaps. Pipeline quality drift. The loop surfaces the patterns to managers, who use them to direct their coaching conversations and to decide where to invest training time. Coach does not replace the manager. It gives the manager better situational awareness than “I watched this rep’s last three calls and here’s what I think.” The inputs are structured, consistent, and longitudinal. A manager with Coach sees patterns they could not see from sampling. Call intelligence platforms produce the per-call signals (discovery quality, technical demo effectiveness, objection handling, qualification rigor). Agents extend this work by reading across many calls and many reps, surfacing coaching themes and skill-development trajectories that no single call could reveal. Coach is where the semantic work of the agentic RevStack pays off as leverage for the people who manage the field

How loops compose

Loops are useful because they compose. A loop in isolation is just an automation. Loops chaining together are a system.

Every handoff between loops is a well-defined interface. The sending loop produces a specific shape of output. The receiving loop expects that shape as input. When Engage changes its research approach, Route does not need to know. When Route adds a new rule, Qualify does not need to know. The chain is a contract between loops.

A worked example helps. A new lead comes in from an inbound form fill on the company’s website, produced by a Generate campaign that put a piece of content in front of the prospect. Qualify enriches and scores the lead, which lands at 91 (an A grade). Qualify hands off to Route. Route walks the rule set: the lead doesn’t match rule 1 (existing customer’s domain) but matches rule 2 (A-grade commercial in North America), and gets assigned to the North America commercial pool, which routes to the rep with the fewest open opportunities. Route hands off to Engage. Engage’s agent researches the prospect, finds the company just raised a Series B, and drafts a three-email sequence positioning the product against the scaling challenges a newly-funded growth company faces. The sequence passes all seven criteria of the quality rubric and lands in the rep’s review queue. The rep reviews it the next morning, makes a small tweak, approves. The sequence deploys to the engagement platform. The whole flow took ten seconds of compute and sixty seconds of rep attention. That is three loops chained through well-defined interfaces, with code, agents, and humans each doing the work they are best at. The flow also crosses a chain boundary at the Route-to-Engage handoff, where automated lead processing gives way to sales-led prospect engagement.

The same chain handles outbound. Instead of a form fill triggering Qualify, an outbound signal does: a target account raised a Series B, a key executive changed roles, a competitor’s customer showed churn signals. Qualify scores and qualifies the signal the same way it scores inbound leads. Route assigns it to the right territory. Engage composes outreach with a signal-specific play. The framework does not prescribe how the signal is detected: scheduled scans, intent-data webhooks, or agent-driven research all work. It prescribes how the resulting signal flows through the Demand chain into the Acquisition chain.

Loop archetypes

Not every loop fits the same shape. The framework works at scale because it allows for different loop archetypes, each suited to a different kind of work.

Event-driven loops. Most of the Demand and Acquisition chains. Triggered by a record event (a new lead is created, an opportunity is saved). Runs once per event. Produces outputs that chain to the next loop. Qualify, Route, the outreach side of Engage, and the deal play side of Pursue all follow this archetype. Fast. High volume. Per record.

Scheduled loops. Run on a schedule against a population of records. Generate’s campaigns run on cadence. Design’s continuous monitoring mode runs against workload distribution to surface rebalancing actions. Pursue’s daily nudge evaluator runs against every open deal. Scheduled loops do not react to events. They observe state and decide whether to act.

Materialized loops. Deploy is the main example. Runs on demand to make a declared architecture concrete in the live system. Not per record. Not scheduled. Triggered when the declared state changes (a new scenario is promoted, a new user is added, the territory structure is revised). Reads the desired state from configuration. Computes what needs to change. Applies the changes in the correct order.

Modeling loops. Design’s primary mode. Runs interactively rather than automatically. Each run executes a model against a set of inputs to produce a shareable artifact (a scenario, a forecast, a capacity projection). The output is not a per-record decision but a complete, reviewable plan that downstream loops read from. Modeling loops are where humans do the most hands-on work, because setting direction is human work.

Naming the archetypes matters because it prevents readers from collapsing “loop” into “webhook automation.” The framework is richer than that. Different work needs different loop shapes. A healthy revenue system runs all four archetypes. Some loops run in multiple archetypes within their own work: Design runs in modeling for full planning and scheduled for continuous rebalancing; Generate runs in scheduled for campaigns, event-driven for ABM plays, and modeling for campaign planning; Engage runs in event-driven for outreach and human-led for discovery. Multi-archetype loops are a feature of the framework, not a contradiction.

Build versus buy

Worth clarifying, since I have been getting questions. This framework does not imply that every loop must be custom-built.

A loop is defined by its anatomy. What matters is that all six elements are present. Not where the code came from.

Vendor tools can be loops, if they expose their configuration as reviewable artifacts, log their decisions in auditable detail, chain cleanly into other loops through stable interfaces, and surface their behavior in ways that let humans or agents close the feedback cycle. A vendor CRM can be the surface where Qualify’s outputs live, as long as the scoring logic is versioned and the decisions are auditable. A vendor workflow engine can run the Route logic, as long as the rules live in structured, reviewable configuration. A vendor engagement platform can deploy sequences, as long as the composition and quality-scoring layer produces explainable outputs. An off-the-shelf planning tool can run Design, as long as scenarios are first-class and the promoted scenario becomes the source of truth for downstream loops.

Custom code can be loops too, if it holds to the same principles. Most working systems are hybrids. The framework is about what loops look like, not about where they come from.

Engineering capacity is scarce. Apply it to unsolved problems. A team that rebuilds what vendors already do well is burning cycles that should go to the frontier. The frontier is the loops and capabilities the market has not yet commoditized: pipeline health intelligence that actually works, cross-tool observability, conversational surfaces over the whole revenue stack, the coherent data fabric that lets loops chain without fragile glue. These are where custom engineering creates structural advantage.

The other side of the rule matters too. Some vendor categories exist because the vendor provides something you genuinely cannot build: a data graph, a network effect, specialized infrastructure like call intelligence or an engagement platform, or a compliance surface that would take years to replicate. Buying there is not about convenience. It is about the fact that the vendor’s product is their data, their network, or their accumulated expertise, and your engineering team cannot conjure those things.

Between the frontier and the genuine-vendor-value category sits a lot of work that is neither. Scoring logic. Rule evaluation. Simple workflow orchestration. API calls against a handful of data providers. These are trivial code. A single revenue engineer with modern tooling can build a working scoring-and-routing engine in a week. The question for these layers is not “which vendor do I buy?” but “is this worth owning?” Building takes a week. Owning takes years. Someone has to maintain it, patch it when the upstream API changes, document it when the original builder leaves, and carry the context forward. The vendor does all of that in exchange for a subscription fee. Sometimes that trade is worth it. Sometimes the vendor is adding a UI and a subscription fee on top of code so simple that the maintenance cost is negligible and the ownership benefits (full control of logic, first-class agent access, no per-seat tax on programmatic usage) are worth paying for. The decision is per-loop, per-team, and often per-year.

The questions that matter when evaluating a vendor for a loop position are not “does it do the thing?” but “does it hold the principles?” Does its configuration live somewhere you can version and review, or is it buried in a UI where every change is lost to history? Can you reconstruct the reasoning behind any specific decision it made? Will it chain into your other loops through a stable API, or will you be writing fragile glue between it and the rest of the system? Can agents query and act on it through MCP or equivalent, or is it a walled garden? Does it surface its behavior in ways that let you close the feedback cycle, or is the feedback layer locked away from you? These are the build-versus-buy questions worth asking. Most vendors fail several of them today. Over time, fewer will.

What this unlocks

When the revenue system is built as a system of loops rather than a tangled mess of tools and tribal knowledge, five things change.

Change cycles shrink. A change to scoring is a change to one configuration file in one loop. A change to territory structure is a commit to Design. A change to outbound plays is a change to Engage’s play definitions. The team is not hunting through five tools to find where the behavior lives. The behavior lives in the loop. A routing rule change that used to take two weeks (find the logic in three tools, test by hand, coordinate across ops and engineering, hope nothing else breaks) takes twenty minutes (edit the configuration, run the simulation against recent leads, commit, deploy). That is the operations-as-code compounding effect from v0.03 made concrete at the loop level.

Interfaces stay clean. Each loop reads from well-defined inputs and writes to well-defined outputs. When the Route loop changes, Qualify does not need to know. When Engage changes its research approach, Route does not need to know. This is classic software engineering discipline applied to revenue infrastructure. It is what makes the system maintainable as it grows. A company that adds a new loop to the system (say, a Partner loop that manages indirect pipeline) does not have to touch the existing loops. The new loop plugs into the chain through the standard interface.

Experimentation becomes cheap. A new scoring model is a new branch of a Qualify configuration. A new routing rule is a new entry in Route’s rule set. A new play is a new entry in Engage or Pursue. Experiments are scoped to a single loop, testable against historical data before deployment, and reversible with a commit revert. The cost of trying something new drops by an order of magnitude. A team that runs one scoring experiment a quarter under the old model can run one a week under the new one.

Teams scale without chaos. As the team grows, new people own new loops or new configuration within existing loops. The loop boundary is the team boundary. One team can own Generate, another can own Qualify, a third can own Engage. Each team ships at its own pace. The chains give the teams a shared contract. A RevOps team of three running a few loops looks different than a RevOps team of fifteen running the full set, and the framework scales across that range because the units of ownership are clear.

Governance becomes structural, not procedural. The governance layer (humans) operates on loops, not on individual records. Threshold settings. Escalation rules. Quality rubrics. Scenario approvals. Policy changes. These are the artifacts of governance, not approval queues. When governance is healthy, humans are writing specs and reviewing drift, not clicking approve on every agent output. This is the operationalized version of the v0.05 claim: governance is authorship.

The compounding effect is real. Each loop that gets built makes the next loop cheaper to build. Each interface that gets cleaned up makes the system more navigable. Each experiment that runs produces evidence that improves the framework. The framework is not a destination. It is a direction of travel.

What comes next

Revenue Loops is the framework. Future posts will go deeper.

This framework is not finished. We have two decades of refinement behind the Demand and Acquisition chains, with mature patterns for demand creation, lead qualification, routing, sequencing, discovery, and pursuit. The Retention chain is genuinely earlier, particularly under consumption-based pricing, where the operational requirements are still emerging. We have learned a lot in the last few years, but Onboard and Expand have meaningful maturation ahead. I am developing the framework and implementing it in parallel, working those questions out as I build. The readers of Ship Revenue who are building in this direction are welcome, encouraged, to push back, question the framing, and contribute to the evolution.

The GTM system is a product. RevOps is the product team. Revenue engineering is the discipline. Revenue loops are how the system actually gets built.

If any of this resonates, if you are building this or wishing someone would, subscribe. Or reply to this post and tell me what you are working on. I read everything.

– Andrew

The agentic RevStack gives you three ways to do work. Code can do work. Agents can do work. Humans can do work. Each is best at different things. Each is the wrong tool for the others. The architecture of a modern revenue system lives or dies on getting this split right.

This is separation of concerns applied to revenue operations. The engineering discipline has known for decades that systems scale when responsibility is clearly allocated. Revenue operations is about to learn the same thing, faster than most teams are ready for.

The claim

Code executes. Agents reason and generate. Humans govern.

Three layers. Each with a specific kind of work it does well. Each with a specific kind of work it does badly. The principle is simple. The execution is where most teams get it wrong, because the temptation is always to run everything through whichever layer is currently easiest. Three years ago, every ops team wanted to build more workflows. Today, every ops team wants to run more through agents. Neither instinct is correct on its own.

The right answer is structural. Match the work to the layer. Route the layer’s decisions back to the next layer cleanly. Keep humans where judgment belongs and out of where the system should have handled it. That’s the architecture. It’s also the hardest thing to get right, because it requires someone to decide, deliberately, what each layer does and doesn’t do.

What each layer is actually best at

Code is best at deterministic work at scale. If the input is well-defined and the output can be produced by rules, code is the right answer. Scoring math. Rule evaluation. Territory matching from billing fields. CRM writes. Workflow orchestration. Scheduled automations. Anything where the same input should always produce the same output, where the logic can be specified in advance, and where the volume is high enough that consistency matters more than cleverness. Code is fast, cheap, and predictable. It’s the foundation of everything else.

Agents are best at semantic and generative work. Anything requiring natural language understanding, inference from ambiguous signals, synthesis across sources, or generation of prose. Researching a prospect company from public sources. Composing a personalized email sequence. Classifying an unstructured lead note into a category. Inferring territory when billing fields are incomplete. Summarizing a call transcript into CRM-ready activity. Answering a natural-language question about pipeline health by navigating data and rendering a response. Agents handle the work that used to require a human reading and writing. They’re slower than code, more expensive than code, and wrong often enough that you have to plan for it. But they handle work that would require brittle, unscalable code to approximate.

Humans are best at judgment and authorship. Defining what good looks like. Writing the specs that code and agents execute against. Setting the thresholds that determine when an agent’s confidence is too low and a human needs to step in. Handling genuine novelty, the situations that don’t match any existing pattern. Deciding strategic direction. Reviewing aggregate outcomes and adjusting the rules. Humans bring values, context, and accountability that neither code nor agents have. The human layer isn’t a fallback or a gap filler. It’s where the system gets its direction.

Three layers. Three kinds of work. The skill is matching the work to the right layer.

How to decide

The question every ops leader faces, dozens of times a quarter, is where a new piece of work belongs. Here’s how to think about it.

Is the output deterministic, or does it require semantic judgment? A lead’s numerical score from a weighted sum of attributes is deterministic. Code. The decision about whether a specific lead’s note (”talked to them at Dreamforce, seemed warm but non-committal”) is a buying signal is semantic. Agent. If you can write down the rule precisely, code can run it. If you’re reaching for examples to explain what “good” looks like, the work belongs at the agent layer or above.

What’s the cost of being wrong? Agents are wrong some of the time. That’s fine for tasks where a wrong answer is recoverable. Classifying a lead note incorrectly costs you a minor routing error. Composing an email with a slightly off tone costs you rep time to revise, or a prospect’s attention if it gets sent. But some decisions are expensive to get wrong. Firing a customer-facing communication at the wrong audience. Pricing a deal with an incorrect discount. Reassigning a book of business. The higher the cost of a mistake, the more the decision belongs in code (deterministic and testable) or humans (judgment and accountability), not agents (probabilistic, and only as auditable as your instrumentation).

What’s the frequency? A decision that runs a thousand times a day needs to be cheap per execution. That’s code. A decision that runs once a quarter can afford the cost of an agent invocation or a human review. A decision that runs once ever is almost certainly a human call. Frequency drives economics. The split can’t ignore economics.

Does the work require context code wasn’t built for? Code operates on structured data. Agents can navigate unstructured context (call transcripts, email threads, web pages, internal docs). If the work requires reading and synthesizing across multiple sources with natural language content, code isn’t the tool. The work either goes to an agent or to a human. And the choice between agent and human comes back to cost-of-wrong and frequency.

Is this work about the system’s direction, or the system’s execution? Execution work (scoring a specific lead, routing a specific prospect, generating a specific email) can go to code or agents. Direction work (deciding what scoring should reward, deciding what routing should optimize for, deciding what tone the emails should have) belongs to humans. The best systems have sharp boundaries here. Humans set direction. The other layers execute against it. That’s product management, applied to the GTM system.

These criteria don’t resolve every case. Sometimes the right answer is that a workflow spans multiple layers. A lead comes in. Code enriches and scores it. An agent classifies the note and infers intent. A human reviews the low-confidence cases. Code routes based on the composite result. That’s one pipeline, three layers, clean interfaces between them. The split isn’t per-task. It’s per-step. Design the pipeline, then place each step in the right layer.

What breaks when you get the split wrong

Three failure modes, each common, each avoidable.

Over-indexing on agents. Tempting, because agents are the exciting layer and because they can technically handle almost anything if you’re willing to burn enough tokens. The problem is that you burn enough tokens. Running deterministic work through an agent is slower by orders of magnitude, more expensive by orders of magnitude, and less auditable than running it through code. A scoring pipeline that sends every lead through an LLM to compute a weighted sum is a pipeline that will cost you ten thousand dollars a month to do work that ought to cost ten cents. Agents belong at the semantic layer. Using them as general-purpose compute is a category error.

Over-indexing on code. The legacy RevOps instinct. Everything becomes a rule, and the rules get ugly fast. Try to write a deterministic rule for “is this lead note a buying signal.” You’ll end up with a regex soup that fails on any sentence structure it wasn’t designed for. Try to infer territory from an enrichment record with conflicting fields. You’ll end up with a cascade of fallbacks that gets it right seventy percent of the time and produces confident garbage the other thirty. Code is powerful within its domain. Pushing it past its domain produces systems that are rigid, brittle, and unable to handle the messiness of real GTM data.

Over-indexing on humans. The failure mode most teams slide into without noticing. Every agent output requires human approval. Every config change requires a meeting. Every routing decision gets escalated. What looks like governance is actually a bottleneck. The system can’t run faster than the humans reviewing it, which means it can’t run fast at all. And the humans doing the reviewing are usually senior people whose time is better spent writing the rules than approving the outputs. Approving isn’t governing. Approving is the work you do when you don’t trust the system enough to let it run. Fix the system. Don’t sit in its loop.

The split is structural. Get it wrong and the system fails in specific, diagnosable ways. Get it right and the system compounds.

The governance layer

Humans govern. This is the third layer, and it’s the one most conversations about AI in the enterprise get wrong.

Governance is not approval. Governance is authorship.

Humans write the specs that code and agents execute against. Nate Jones has been arguing this for software engineering under the banner of spec-driven development: the idea that specs force comprehension before code exists, and without them you end up with “dark code” that nobody understands. The same principle applies to revenue operations. They define what a good routing decision looks like, what an acceptable lead score distribution looks like, what the system should do when it’s uncertain. They set the thresholds that determine when an agent should proceed versus when it should escalate. They make the strategic calls that require values and context the system can’t generate on its own. They review the aggregate behavior of the system and adjust the rules when it drifts. They handle the genuine exceptions, the novel situations that don’t match any pattern the other layers were designed for.

None of this is fallback work. All of it is load-bearing. A system without humans doing this work is a system running without direction. It’ll still produce output. The output will get worse over time because nobody is adjusting the rules as the world changes. The pipeline health model that worked last year won’t work next year. The routing logic that fit the old org won’t fit the new one. The tone that worked for last quarter’s buyer personas won’t work for this quarter’s. Systems degrade without human authorship. Not slowly, either.

The thing to get clear about is the difference between authorship and approval. Authorship means you wrote the spec. You defined what good looks like. You set the thresholds and the escalation rules. Approval means the system produced an output and you’re deciding whether to let it go. Authorship scales. Approval doesn’t. A team doing authorship is a team that gets more leveraged every quarter. A team doing approval is a team that gets more overloaded every quarter. That’s the difference between a product team and a help desk.

The failure mode isn't "too many humans." It's humans doing the wrong work. If you're approving AI-composed outreach sequences one at a time, you're not governing. You're a bottleneck in front of a system that's already running. Nobody needed you to approve each one. Write a quality rubric. Define what "good" looks like. Set the confidence threshold below which sequences escalate. That's the work only you can do. That's the human layer.

What comes next

Separation of concerns is how the system runs. The next posts go into what happens on top of it.

The loop framework. The full revenue lifecycle as self-contained, composable automation units. Plan, deploy, generate, route, engage, pursue, onboard, expand. How to design each one and how they compose into a coherent system.

The field experience. The UX discipline applied to internal GTM users. Why “enablement” as a category is due for a rename. How to design the interfaces the field actually uses so they get the benefits of the system without having to understand it. This one will land as the first Pull Request, with a guest voice who’s lived this deeper than I have.

If any of this resonates, if you’re building this or wishing someone would, subscribe. Or reply to the welcome email and tell me what you’re working on. I read everything.

— Andrew

The GTM system is a stack. Six layers, each doing different work, wired together into something that produces revenue. Most companies have all six layers today in some form. What they don’t have is a stack designed to be built on, extended, and automated against. They have a stack designed to be clicked through.

The agentic RevStack is the programmable version. First-class APIs at every layer. Agents and humans as equal citizens at the interface. Nothing hidden behind a proprietary UI that can only be reached by opening another tab.

This post is about what the stack is, what’s wrong with the current state of it, and what “programmable” actually needs to mean for the category to work at the next scale.

The claim

The agentic RevStack is the GTM stack, designed for programmatic access.

Every layer exposes a first-class API. Every layer has machine-readable state. Every layer can be queried, changed, and observed by code and by agents as easily as by humans. The stack does not require a human to open a UI to read or write anything that matters.

This is not a futuristic vision. It’s the bar set by every other mature infrastructure category. Cloud infrastructure. Databases. Observability. Communications. Payments. You can stand up, operate, and tear down any of these from the command line without ever opening a browser. The revenue stack is the last major infrastructure category where that’s not true, and it’s starting to cost companies real money.

The six layers

A functioning GTM stack has six layers. Different companies slice them differently. Different vendors claim to cover more than they actually do. But at the concept level, the layers are distinct and the interfaces between them are the real product.

System of record. The database or warehouse. Where canonical state actually lives. Every signal, event, interaction, and transaction eventually settles here. This is the layer that doesn’t care which tool generated the data. It’s where analytical queries run and where the settled truth of the business lives. Most companies have been casually calling their CRM the system of record for years. The CRM is a surface. The database is the record.

System of signals. The inputs. Intent data, product usage, enrichment, web signals, email engagement, call transcripts, support tickets, billing events. Everything that tells the GTM system that something happened in the world. Signals flow in continuously. The stack’s ability to act on them depends on how fast and how completely they reach the layers that reason about them.

Surfaces of work. Where humans do their work. The CRM is the biggest surface for the field. Prospecting tools, engagement platforms, and communication channels (email, calling, chat, meetings) are surfaces too. The field lives here, directly or indirectly. These surfaces read from the system of record and write back to it. They are not the record. They are windows into it.

Workflow engine. The orchestration layer. Runs the code that reads from signals and state, decides what to do, writes back to the system of record, and kicks off engagement. This is where the operations-as-code artifacts from v0.03 actually execute. Scoring runs here. Routing runs here. Deal inspection runs here. The full lifecycle automations I'll unpack in a future post run here.

Intelligence layer. Where reasoning and modeling happen. Agents that research prospects, compose email sequences, classify transcripts, infer territory from ambiguous data, summarize calls. Models that score leads, predict conversion, flag deal risk, identify expansion. Some of this is deterministic (scoring math, rule evaluation). Some of it is agentic (anything requiring natural language, semantic judgment, or generation). The split between the two is structural and matters a lot, which is its own post.

Programmability layer. How humans change the system. How agents change the system. The surface area through which work flows into and out of the other five layers. Today this is usually fifteen different vendor UIs, each with its own login, its own permission model, its own change management process. In the agentic RevStack, it’s a unified layer: APIs, MCP servers, natural language access, consistent authentication. One surface for all of the stack’s operational work.

Six layers. Each distinct. Each with its own best-in-class vendors, its own data model, its own way of being accessed. The stack works when the layers compose. The stack fails when they don’t.

The programmability problem

Five of the six layers are in reasonable shape. The database has matured for decades. Surfaces of work have matured over the last two. Signals, workflow, and intelligence have all gotten materially better in the last three years. The tooling is not the problem.

The programmability layer is the problem.

Dear god, please just give me an API.

Every ops leader who’s spent the last two years trying to wire agents into their stack has muttered a version of this. The frustration is specific. The industry knows it needs to be programmable and hasn’t figured out how to ship that at the level the work requires.

Most revenue tools were built for human users clicking through UIs. Programmatic access was retrofitted, usually incompletely, usually expensively, usually gated behind enterprise pricing tiers that exist specifically to prevent the kind of usage the agentic RevStack requires. The result is a stack that is technically accessible by code, practically hostile to code, and economically untenable for agents.

Most “APIs” are read-only or near-read-only. You can query for an account. You can’t always create one. You can read a lead’s fields. You can’t always write a custom field. The write paths that exist are often subset-limited, rate-limited, or restricted to specific object types. The write paths that matter are the hard ones, and vendors know it.

Per-seat pricing models punish programmatic usage. The modern revenue tool is priced per human seat. Agents don’t have seats. Either you buy a seat for every agent (bankrupting the agentic approach) or you smuggle agent actions through human seats (violating the license agreement). Neither works. Most enterprise contracts explicitly price API usage separately and expensively, because vendors figured out that agents are the use case that will eventually dwarf human usage and they’d like to capture that now.

Data lives in walled gardens. The signal providers sell you data that lands in their UI, with an “export to CSV” button and a half-finished API. The CRM’s activity history is complete in the UI and patchy in the API. Engagement platforms record every email in their database but expose aggregate metrics through the API rather than the underlying events. You can see the data you paid for. Your agents often can’t.

MCP support is barely emerging. Model Context Protocol gives agents a standard way to query and act on tools. A small number of vendors have shipped MCP servers. Most haven’t. The ones that have often expose a subset of functionality, or gate it behind the same enterprise pricing that makes agentic workflows expensive. The category is roughly 18 months behind where it needs to be. The good news is it’s catching up fast. The first wave of MCP implementations shipped in the last year. More are in flight. The real question is whether vendors ship complete MCP surfaces or token-gated teasers, and whether the pricing catches up to the architectural reality.

Every tool has its own UI. That’s the tax. Ops leaders adopt tools one at a time, each solving a real problem, each adding training burden to the field team. A rep today can have eight different UIs open across a normal workday: CRM, engagement platform, calling tool, intent data tool, content tool, forecasting tool, chat, LinkedIn. Every new tool the ops team adopts means a new thing to train the field on and a new place for work to get lost. This is not a UX complaint. It’s a structural failure of the stack. The field shouldn’t have to know which tool the work happens in. The system should know, and the field should interact through the one or two surfaces they already use.

This is what “dear god, please just give me an API” actually means. Give me a real write-capable API. Give me an MCP server. Price it like infrastructure, not like SaaS seats. Stop requiring my team to learn your UI to do work that should be invisible to them.

What first-class programmability looks like

The agentic RevStack is not a revolutionary concept. It’s the application of standard infrastructure practice to a category that missed the memo. When it exists, it looks like this.

Every tool has a real API that covers its full surface area. Not a read-only mirror. Not a rate-limited teaser. The same capabilities exposed to UI users are exposed to programmatic callers, with the same data model, the same permission structure, and the same consistency guarantees. If you can do it in the UI, you can do it through the API.

Every tool has an MCP server. Agents can query state, invoke actions, and report outcomes natively. The server is maintained by the vendor, keeps pace with UI functionality, and doesn’t charge per tool call. MCP is the protocol. The vendor’s job is to implement it completely, not to treat it as a marketing line item.

Pricing reflects the shift. The per-seat model dies or adapts. Agentic workflows are priced on outcomes, usage, or platform tiers that make economic sense when most of the volume is coming from code. A vendor that insists on charging per agent the same as per human is a vendor that will get disintermediated.

Humans interact through agents, not tools. Ops leaders and revenue engineers work in their editor or their chat interface. They ask questions in natural language, change config in natural language, run simulations in natural language. The MCP tools behind those interfaces do the actual work against the stack. Nobody opens the intent data UI. Nobody opens the engagement platform UI. The field uses the CRM because that’s where their work lives. Everyone else uses chat because that’s where their thinking happens. The agents are the interface.

The field does not learn new tools. When ops ships a new scoring model, the field doesn’t need training on a new dashboard. The scoring output flows into the CRM alongside everything else. When ops ships a new routing rule, the field doesn’t need to learn a new tool. The right rep gets the right lead, same as before, through the same interface. New tools do not produce new UI burdens. That is the test. If a new tool requires a new UI for the field, it failed.

This is the end state. It’s not built yet, at scale, in most categories. But the math is clear, and the tooling is starting to arrive. The first wave of vendors that get this right will define the next decade of revenue infrastructure. The ones that keep selling clickable UIs with incomplete APIs will look, in three years, like on-premise software vendors did in 2012.

What comes next

The agentic RevStack is the substrate. The next post is about how work gets split across it.

Code executes. Agents reason and generate. Humans govern. The three-layer operating principle underneath everything. Which work belongs to code. Which work belongs to agents. Which work belongs to humans. And why getting the split right is the difference between a system that scales and one that collapses under its own inference costs.

If any of this resonates, if you’re building this or wishing someone would, subscribe. Or reply to the welcome email and tell me what you’re working on. I read everything.

— Andrew

If you’ve been running RevOps for more than a year, you’ve felt the moment. A leader asks you to tweak lead scoring. “Just bump the weight on VP-level titles, we want to prioritize those.” You agree it makes sense. You agree it’s a ten-minute change. Then you find out it’s a two-week project, because the scoring logic lives in five places, the change needs to be tested against recent pipeline, nobody can simulate the impact before you ship it, and there’s no safe way to roll it back if it breaks.

That gap between “ten-minute change” and “two-week project” is the tax you pay for not treating revenue operations like code. Close the gap and most of what’s slow about RevOps gets fast.

The claim

Every revenue process that runs often enough to matter should exist as version-controlled config, reviewed like a pull request, tested against production data, and deployed with a rollback path.

Call it operations as code.

Not spreadsheets. Not tribal knowledge. Not a Slack message asking someone to update a field. Code, or code-like artifacts (YAML, JSON, declarative config) that live in a repository, go through review, get simulated against real data, and deploy on a schedule a human can trust.

This is the single biggest shift between how RevOps runs today and how a product team for the GTM system would run. And it’s the prerequisite for everything else. You can’t ship a modern GTM system on a foundation of undocumented spreadsheets and verbal agreements. You can ship one on a foundation of versioned config and automated deployment. The scaffolding matters. That’s why it comes before the agentic stack, before the loops, before the org chart redesign. Get the code-first foundation in place. Then the other things become possible.

What it maps to

Engineers have known how to scale systems for decades. The practices are well-understood. They just haven’t been ported into revenue operations yet. Here’s what the translation looks like.

Infrastructure as code. Every routing rule, scoring weight, territory assignment, engagement play, and deal inspection threshold exists as config, checked into a repository. If a process runs in the GTM system, it’s in the repo. If it’s not in the repo, it’s not a real process, it’s tribal knowledge waiting to break.

Review and CI/CD. Config changes go through pull request. Another set of eyes sees what’s changing before it ships. The system runs automated checks: does the config validate against the schema? Does it pass basic sanity tests? Does it conflict with anything else in the repo? Only then does it deploy.

Dev, test, and prod environments. Config changes don’t go straight to production. They run first in a development environment where they can be validated in isolation. Then they move to a test environment where they run against recent real data. If you’re changing lead scoring weights, test re-scores last quarter’s leads with the new model and shows you what would have changed. If you’re changing routing rules, test re-runs recent assignments and shows you the diff. You see the impact before it hits production, not after.

Observability. Every decision the GTM system makes is logged with its reasoning. Why was this lead graded A? Which scoring components contributed? Why was it routed to this rep? Which rule fired? You can trace any outcome back to the inputs and the logic that produced it. No black boxes.

SLOs. The system has explicit targets for the things that matter. Lead response time under five minutes. Routing accuracy above 95%. Forecast confidence within a defined band. When an SLO breaks, the team knows, and knows immediately. The system is not healthy just because nobody is complaining.

Rollback. Every change has a revert path. Something breaks? Roll back to the last known-good config. No emergency ticket to engineering. No weekend spent manually undoing changes. The revert is a commit away.

None of this is exotic. It’s standard practice for any engineering organization that ships software at scale. It’s absent from most revenue operations functions. That gap is the opportunity.

These aren’t new ideas

The principles behind operations as code aren’t unheard of in revenue operations. Most sophisticated GTM teams already apply them in fragments. Salesforce change management with sandboxes and deployments. CPQ config that goes through approval workflows. Marketing automation with version control on specific artifacts. Compensation plans administered through tools with audit trails and approvals. The principles exist, tool by tool, in pockets.

What doesn’t exist in most companies is a coherent operations-as-code practice applied to the GTM system as a whole. The routing engine and the scoring model and the territory map and the engagement plays and the deal inspection thresholds don’t live in a unified codebase with unified review, simulation, and deployment. Each component has its own practices, its own tooling, its own review path, and often its own owner. The gaps between the components are where operations stays manual. And the system doesn’t compound because the system isn’t treated as one system.

This is the jump. Not “discover change management.” Not “invent version control.” Apply the principles that already exist inside individual tools to the system as a whole. Treat the GTM stack as one product with one codebase. Review and simulation and rollback at the system level, not just the tool level. That’s the work.

What it looks like in practice

Here’s the scoring weight example, end to end.

An ops analyst on the team decides that VP-level titles should be weighted more heavily in lead scoring. They open the scoring config file in the repo. They find the line that sets the weight for VP seniority. They change the number from 12 to 14. They commit the change with a note explaining why. They open a pull request.

The PR runs through automated checks. The new config validates against the schema. It doesn’t conflict with other recent changes. It passes the basic rule-set tests.

The change deploys to a test environment and runs against recent leads. It re-scores last quarter’s inbound pipeline with the new weights and shows the analyst a diff. Seventeen more leads would have been graded A. Forty-two would have shifted one grade higher. The analyst reviews the simulation and confirms the impact looks reasonable.

A second reviewer, usually a senior ops lead or a revenue engineer, approves the change. The PR gets merged. The system deploys the new config to production on the next release cycle, typically within the hour.

Every lead scored from that moment forward uses the new weight. The change is logged. The reasoning is in the commit message. If something looks wrong in the next few days, the rollback is a revert away.

Two weeks just became twenty minutes.

Worth flagging the quiet hard part. A real change to lead scoring rarely lives in one system. The weights sit in the scoring engine. The grade thresholds that decide what counts as an A lead sit downstream in routing. The SLA that fires when an A lead arrives sits in engagement. The dashboards that report on scoring distribution sit in BI. Every one of those tools has its own sandbox, its own release cycle, and its own idea of what’s in test versus prod. Most operations-as-code attempts succeed one tool at a time and fail at the seams. The change validates in Salesforce sandbox and breaks in Marketo because the field didn’t sync. The new routing rule works in test and produces chaos in prod because the downstream enrichment provider was mocked in one environment and live in the other. A real test environment for the GTM system tests the whole system, not each tool in isolation. That’s the part that’s hard to build and the reason most companies never get there. And it’s why treating the GTM stack as one codebase, with one coherent environment hierarchy, is not a stylistic preference. It’s the only way the test actually means anything.

Scale this pattern across every revenue process. Routing rules. Territory assignments. Deal inspection thresholds. Engagement play selection. Expansion scoring. The same workflow applies to each. Define the change in config, review it, test it, deploy it, observe it, keep or revert it based on what you see. The system compounds. Every change gets safer because the scaffolding gets better. Every analyst gets faster because the tooling gets sharper. Every decision stays traceable because the history is in the repo.

Why it’s possible now when it wasn’t before

The old excuse for running RevOps on spreadsheets was that building the alternative was expensive. You needed engineers to write the config schemas, the validation harness, the deployment pipeline, the observability layer. Revenue operations teams couldn’t staff that kind of infrastructure work themselves. Central engineering had more important things to build. So the work stayed manual, and the team grew linearly with the business.

Agentic development tooling has collapsed that cost. A single revenue engineer with modern tooling can ship in a week what used to take a team a quarter. Schemas that took a month to spec and implement can be generated from an English-language description. Test harnesses that used to require a data engineering team can be built against a CRM export in a few days. The scaffolding that used to be a multi-quarter investment is now a multi-week project.

This is the unlock. Not that AI is going to do all the operations work. That AI has made it economical for operations teams to build the code-first infrastructure that replaces their own manual work. The bottleneck used to be capacity. Today the bottleneck is context. And you get context by shipping infrastructure, not by hiring more analysts.

What you give up

Operations as code has real tradeoffs. Worth naming.

You give up some speed on genuinely one-off changes. If you need to make a single adjustment for a single customer on a single day, a spreadsheet is faster than a config file with a PR workflow. The overhead of the code-first process has a floor. For truly bespoke, truly one-time work, the floor is higher than a manual edit would be. The answer is not to abandon the system. It’s to draw the line thoughtfully between what lives in the config and what lives as a human exception.

You give up intuition-driven iteration. Some ops leaders are genuinely good at feel. They know, from twelve years of running scoring models, that a particular tweak will work. The code-first workflow slows them down by forcing them to write the change down, document the reasoning, wait for review, and run simulations. For the gifted few, this is friction on real talent. For everyone else, it’s scaffolding that produces better decisions than intuition would have.

You give up flexibility for a while. Getting the scaffolding in place takes months. During that time, the team is less flexible than it was, because it’s investing in infrastructure instead of responding to requests. This is the hardest part of the transition to sell to leadership. You’re asking for a quarter of reduced throughput in exchange for a permanent productivity ceiling raise. The math works. The patience is hard.

None of these tradeoffs justifies the alternative. The alternative is “traditional RevOps deploys and prays.” A two-week sprint to change a scoring weight is not a feature. Infrastructure determines the outcome, not the headcount. You can either pay the cost of building it or pay the compounding cost of not having it. Most companies have been paying the second cost for years and calling it normal.

Where to start

If you’re a RevOps leader who buys the argument and wants to start somewhere, three suggestions.

Pick one process. Just one. Lead scoring is the best first target for most teams. It’s high-leverage, frequently changed, and the current state is almost always a mess. Define the scoring model as config. Put it in a repo. Require PRs for changes. Run simulations before deploys. Get one thing code-first before trying to convert ten.

Invest in the test environment before the config. The review-and-deploy workflow is worth less than half its value without the ability to validate a change against recent real data before shipping. You want tooling that can take a proposed config and run it against real recent data, showing what would have changed. Without that, you’re still deploying and praying, just with more paperwork.

Hire or borrow one Revenue Engineer. Not a Salesforce admin. An actual software engineer, comfortable with config schemas, CI/CD, and agentic tooling. One engineer with the right tooling can stand up the foundation in a quarter. Without one, the infrastructure won’t exist, and you’ll be writing this post to your successor.

What comes next

Operations as code is the foundation. The next few posts build on it.

The agentic RevStack. The modern AI-forward stack of revenue tooling. What’s in it, what it replaces, and what’s still missing. (Dear god, please just give me an API.)

Code executes. Agents reason and generate. Humans govern. The three-layer operating principle underneath everything. Which work belongs to code. Which work belongs to agents. Which work belongs to humans. And why getting the split right is the difference between a system that scales and one that collapses under its own inference costs.

If any of this resonates, if you’re building this or wishing someone would, subscribe. Or reply to the welcome email and tell me what you’re working on. I read everything.

— Andrew

Who builds it?

The answer is in the tagline of this publication. RevOps is the product team. But not the RevOps you know today. Most RevOps orgs, even good ones, are not built like product teams. They’re built like service organizations that absorbed a bunch of technical work over the last decade and never got restructured to match.

This post is about what a real product team for the GTM system actually looks like. The disciplines it needs. Why today’s RevOps doesn’t have them. And what changes when it does.

The claim

RevOps is the product team that builds the GTM system.

Not a reporting function. Not a Salesforce admin team. Not a strategy group. Not a shared service. A product team, with the disciplines you’d expect to find on any serious product team building serious software.

This is a structural claim, not a seniority claim. It’s not about elevating RevOps in the org chart. It’s about recognizing that the work of building and operating a modern GTM system requires the same disciplines that any other software product requires. If you don’t have those disciplines on your RevOps team, you’re not building a product. You’re maintaining a pile of tools and hoping it holds together.

I want to be clear about who this is for. If you lead RevOps today, you already know something is off. You spend your quarters fighting for headcount, fighting for a seat at the table, fighting to not be the last person to hear about the new initiative that’s already in flight. The problem isn’t you. The problem is that you were hired to run a service function and then asked to build infrastructure. Those are two different jobs requiring two different org shapes. I’ve been there. I am there. This post is about the shape that actually matches the work.

What a product team for the GTM system looks like

A product team is a group of disciplines organized around building a thing. For a consumer app, that’s PMs, engineers, designers, data scientists, and user researchers. For the GTM system, the disciplines are analogous but named for the domain.

Four disciplines. One user population.

Revenue Engineering builds the infrastructure. The platform itself. The workflows, integrations, routing engines, scoring systems, agent prompts, and orchestration logic that make the GTM system run. Revenue Engineers are software engineers who chose to work on business systems instead of consumer products. They write code. They ship releases. They own the platform’s architecture and its roadmap.

Revenue Operations operates the system via config. Scoring weights, routing rules, engagement plays, quality rubrics, deal inspection thresholds. Territory models, account assignments, capacity plans, quota allocations. Comp plan logic. All the “how the system behaves” work that doesn’t touch the platform code but governs what the platform does. RevOps tunes the system. It doesn’t build it, and it doesn’t use it. It sits between the builders and the users, translating business intent into configuration.

Revenue Data is the analytics, experimentation, and modeling discipline. Intelligence for leadership, conversational by default, dashboards where consistency matters. Experimentation frameworks for the GTM system itself (does this routing change improve conversion? does this scoring model beat the old one?). Data science and ML on the system's outputs. Models that get shipped back into Revenue Engineering as components. Revenue Data turns what the system produces into insight, and turns insight into better versions of the system.

Field Experience is the UX discipline applied to internal GTM users. User research. Interface design for the CRM and the tools reps actually touch. Training and adoption. Feedback loops from the field back into the product team. This is the role most companies call “enablement,” and the rename matters. Enablement implies “teach them to use the thing we built.” Field Experience implies “design the thing so it works for them.” Those are different jobs. One is downstream of the product decisions. The other is upstream.

The Field is the user population. Reps, managers, CS teams, finance, leadership. They’re not part of the product team. They’re the people the product is for. Their experience of the GTM system is the product’s surface area.

Four disciplines building for one user population. That’s a product team.

What most RevOps teams actually look like today

Most RevOps orgs have some version of these disciplines, but distorted. The distortion is what makes them fail at product work.

Revenue Engineering is outsourced to central IT, or doesn’t exist at all. The actual software engineering work on the GTM stack gets done by whoever happens to have the Salesforce admin credential, supplemented by consultants and contractors when projects get too big. There’s no owned platform, no owned roadmap, no engineers who wake up thinking about the GTM system as their product. The result is infrastructure that nobody owns, built by people who’ve moved on, maintained by people who weren’t there when it was designed.

Revenue Operations is overloaded with reporting. The RevOps team ends up spending 60 to 80 percent of its cycles on recurring reports, pipeline inspection, executive dashboards, and ad hoc data pulls. Work that should be tooling becomes a permanent staffing line. There’s no capacity left to tune the system, because everyone is busy describing it.

Revenue Data is stuck reporting the past instead of improving the future. The analytics work that should drive continuous improvement of the GTM system is spent producing recurring reports for leadership, variance explanations for finance, and pipeline inspection for sales management. Almost none of it flows back into the system as experimentation or model improvement. Nobody A/B tests the routing logic. Nobody backtests a new scoring model against last quarter's pipeline before deploying it. Nobody ships a trained model back into the platform as a component. Revenue Data describes what happened. It rarely changes what happens next.

Field Experience is called enablement and scoped as training. Enablement teams are usually staffed with former reps who are great at content and coaching and terrible at interface design, because those are completely different skill sets. The team optimizes for “helping reps succeed in the system we built” rather than “making the system itself work better.” Feedback from the field gets collected but never makes it back to the product team in a form the product team can act on. The name matters. Enablement describes a training function. Field Experience describes a product discipline. Until the function gets scoped like the latter, it’ll keep acting like the former.

This is not a failure of the people in these roles. It’s a failure of structure. You cannot build a product with an org chart designed to run a service function.

The honest version

If we’re being honest with ourselves, a lot of what today’s RevOps teams do is people filling gaps in manual processes that should be automated. Analysts running queries because there’s no dashboard. Admins clicking through record updates because no workflow exists. Ops managers maintaining shadow spreadsheets because the CRM doesn’t capture the signal. Enablement building slide decks to explain a process that should be self-evident from the system’s interface.

This isn’t anyone’s fault. It’s what you do when you’re staffed like a service function and asked to produce the outputs of a product team. You plug the gaps with headcount because you don’t have the tooling to close them.

Until recently, this was roughly a rational tradeoff. Building the tooling was expensive. Engineering capacity was scarce. The RevOps team couldn’t staff its own engineers, so the work lived as manual process, and the team grew linearly with the company. That was the deal.

The deal is changing. Agentic development tooling has collapsed the cost of turning a manual process into code. A single Revenue Engineer supported by modern tooling can ship in a week what used to take a team a quarter. The unlock isn’t that AI does the work of ops. The unlock is that AI makes it economical for ops to build the infrastructure that replaces its own manual work. The gap between “we have a process” and “we have a system” used to be measured in engineering roadmaps. Now it’s measured in weeks.

This is why the product-team shape for RevOps suddenly makes sense when it didn’t before. The math has flipped. A small team of builders, tuners, data people, and UX can produce more system, more quickly, than a large team of analysts ever could. The service-function org chart was a response to a real constraint. That constraint is gone.

What changes when you structure it as a product team

Treating RevOps as a product team is not a cosmetic change. It shifts how work gets prioritized, how people are hired, how success is measured, and how the GTM system evolves over time.

Work gets prioritized on a roadmap, not a queue. When Revenue Engineering has an owned platform and a real roadmap, ad hoc requests stop being the default. Field requests become feature requests. They get prioritized against each other and against the team’s own platform initiatives. The CRO doesn’t get to jump the line because they asked first. They get to jump the line because the item they need is highest ROI.

Hiring shifts toward builders. A product team hires product-shaped people. Revenue Engineers instead of Salesforce admins. Data scientists instead of report analysts. UX researchers instead of former reps. The talent bar goes up, and the talent mix shifts. Some of the people on today’s RevOps team are a perfect fit for the new structure. Some will need to grow into new roles. Some will be happier on a different team. This is the hardest part of the transition and the one most leaders underestimate.

Success is measured on system outcomes, not task completion. A service function is measured on response time and ticket volume. A product team is measured on what the product produces. For the GTM system, that’s things like lead-to-close conversion, forecast accuracy, rep productivity, time-to-ramp, retention, and expansion velocity. The team wins when the system performs, not when the team is busy.

The system compounds. Every quarter a service RevOps team exists, it produces about the same amount of value. Every quarter a product RevOps team exists, the system gets better. More automated, more instrumented, more explainable, more leveraged. The difference compounds. Two years in, the gap between a product-team RevOps and a service-team RevOps is enormous. Five years in, it’s the difference between a company that scales efficiently and a company that scales by adding headcount until the margin goes away.

The transition is hard. Do it anyway.

If you lead RevOps today and you want to make this shift, I’m not going to pretend it’s easy. You probably don’t control the budget to hire Revenue Engineers. You probably don’t control where Field Experience reports. You probably don’t have the mandate to pull Revenue Data out of Finance and into your team. Most of the structural decisions that created today’s RevOps shape were made by people above you, and most of the reasons they stay in place are political, not logical.

But the direction is clear. The companies that treat the GTM system as a product, built by a product team, will have asymmetric operating leverage over the ones that don’t. The first RevOps leaders to make that case inside their companies, and to actually restructure when given the chance, will end up running something that looks much more like a modern engineering org than a traditional ops function. That’s the job worth doing.

What comes next

This post named the disciplines. The next few posts will go deeper on how the work actually gets done.

Operations as code. Version control for revenue infrastructure. The engineering practices that make revenue systems testable, reviewable, and safe to change. What it looks like when scoring weights and routing rules live in Git instead of tribal memory.

The agentic RevStack. The modern AI-forward stack of revenue tooling. What’s in it, what it replaces, and what’s still missing. (Dear god, please just give me an API.)

Code executes. Agents reason and generate. Humans govern. The three-layer operating principle underneath everything. Which work belongs to code. Which work belongs to agents. Which work belongs to humans. And why getting the split right is the difference between a system that scales and one that collapses under its own inference costs.

If any of this resonates, if you’re building this or wishing someone would, subscribe. Or reply to the welcome email and tell me what you’re working on. I read everything.

— Andrew

Operations as code. The agentic RevStack. New commits every two weeks. Subscribe to follow along.

Subscribe now

The thesis has three parts. The GTM system is a product. RevOps is the product team. Revenue engineering is the discipline. Future posts will unpack each one.

This one starts at the foundation. Before we can argue who should build the GTM system, we have to agree on what it is.

The claim

The GTM system is a product.

Not a service function. Not a collection of tools. Not a set of processes. A product, with users, a roadmap, specs, releases, performance metrics, and a team accountable for its evolution.

Every company that sells software to other companies already has a GTM product. They just don’t run it like one. It ships inconsistently. Its features conflict. Its users (reps, managers, CS, finance, leadership) complain constantly and get told to file tickets. It has no version control, no testing, no rollback. Changes happen through Slack messages and tribal memory. When it breaks, nobody knows why, because nobody instrumented it.

If you built software like this, you’d be out of business in a year. But we build GTM like this at every company, and somehow we’re surprised when it doesn’t scale.

What the product actually is

Let me be specific about what “the GTM system” includes, because vague framing lets people opt out of the claim.

The GTM system is everything that, together, takes a potential customer from a signal in the world to revenue on the P&L, and then keeps that revenue and grows it. Concretely:

• The infrastructure that ingests and enriches signals: intent data, product usage, web visits, inbound leads

• The scoring logic that decides which signals matter and why

• The routing rules that assign prospects to the right owner (human or agent) at the right moment

• The segmentation and territory models that define who owns what

• The outreach systems that generate, personalize, and send engagement

• The deal inspection and forecasting logic that surfaces what’s at risk and what’s real

• The onboarding workflows that drive new customers to first value

• The expansion signals and scoring that identify where accounts can grow

• The compensation logic that pays all the humans doing all the parts

• The reporting that tells the business what happened and what’s coming

• The feedback loops that allow the system to learn and improve

Each of these is a component. Each has inputs and outputs. Each can be tested, versioned, and improved, or left to rot. Together, they are the product that produces revenue.

Call it the GTM system. The point is that it exists, it has components, it has interfaces between those components, and it either works as an integrated whole or it doesn’t.

Why this framing matters

The reframe isn’t semantic. It has concrete consequences.

It changes how you prioritize. Products have roadmaps. Products ship on cadences. Products have specs before code gets written. When you treat the GTM system as a product, you stop running it as a queue of field requests (”can you change the territory assignment for this one account?”) and start running it as a planned, versioned release process. Ad-hoc requests become feature requests and get prioritized against everything else.

It changes how you staff. Products have product teams. Product teams have PMs, engineers, designers, and data scientists. They don’t have “analysts” whose job is to run reports on demand. The shape of the team that builds a great GTM system is not the shape of the team that most RevOps functions have today, which is one of the core arguments this newsletter will make in future posts.

It changes how you measure success. A service function is measured on response time and ticket volume. A product is measured on user outcomes: revenue productivity, forecast accuracy, time-to-value, retention. Different targets drive different work.

It changes what you build. A service function builds reports. A product team builds systems that compound. Every week a service function exists, it generates the same amount of output. Every week a product team exists, the system gets better. More leveraged, more automated, more explainable. One is a headcount cost. The other is infrastructure that appreciates.

What breaks when you don’t do this

I’ve watched the same pattern play out at company after company. GTM scales. The number of tools grows. The number of people grows. The volume of work grows. And the coherence of the system degrades, quietly and continuously, because nobody owns it as a whole.

Routing rules accumulate exceptions until the rules are gone. The original logic was set up by someone who left two years ago. Nobody knows why it works the way it does. When a rep complains, someone adds an exception. A year later, the exceptions outnumber the rules. Nobody can tell you what would happen if you changed them, so nobody changes them, so they get worse.

Scoring models disagree with each other. Marketing scores a lead one way. Sales scores it another. The CRM has a third score. None of them reconcile. Leadership asks why pipeline conversion dropped and nobody can give a straight answer, because the answer depends on which score you believe.

Territory maps are frozen snapshots of a company that no longer exists. They’re refreshed once a year in a frantic two-month sprint. They’re wrong the day they’re published because the company grew during the sprint. Mid-year adjustments happen via email threads and never make it back into the source of truth.

Sales channels fight each other for the same revenue. Direct, partner, and self-serve all surface the same account and start competing. Deal desk adjudicates each one individually. There’s no rule, no model, no system. Just a human refereeing an overlap that the infrastructure should have prevented.

What got planned isn’t what got deployed. A territory model gets approved at the start of the year. Three months in, the deployed version in Salesforce doesn’t match the plan. Nobody notices until compensation disputes expose the gap. No diff. No audit trail. No way to roll back to the intended state.

None of this is inevitable. It’s what happens when the most important product at the company, the one that produces its revenue, is the only product at the company that isn’t built, owned, and shipped like one.

Design principles

If the GTM system is a product, then building it well looks different from how most companies build it today. The principles below aren’t aspirational. They’re the floor. The ones you need in place before any of the harder work is worth doing.

Every process is version-controlled. Scoring weights, routing rules, territory assignments, engagement plays, deal inspection thresholds: all defined in config, not tribal knowledge. If a process exists, it exists somewhere readable, diffable, and reviewable. Spreadsheets and Slack messages are not configuration.

Every change is reviewable, simulatable, and reversible. Config changes go through review, simulate against production data to show projected impact, and deploy with a rollback path. No more “change it and see what happens.” No more irreversible updates that take a quarter to unwind.

Every decision is explainable. Routing assignments, lead grades, deal risk flags, expansion scores: each carries reasoning and confidence. When a rep asks “why did this lead get routed to me?”, there’s an answer. When leadership asks “why did forecast accuracy drop?”, there’s an audit trail, not a guess.

Code executes. Agents reason and generate. Humans govern. Deterministic work (scoring math, rule evaluation, territory matching, workflow orchestration) runs as code. Cognitive work (research, prose, semantic judgment) runs as agents with confidence scores and human escalation paths. Humans set thresholds, write specs, and review the edge cases. Each layer does what it’s best at.

The system is instrumented. Every component has inputs, outputs, SLOs, and observability. Lead response times. Routing accuracy. Scoring distribution. Forecast accuracy. When something breaks, you know immediately, and you know why.

The infrastructure compounds. Every decision generates data. Every override is a signal. Every config change is testable against history. The system gets better with use, not because you add headcount, but because the architecture was designed to learn.

These are not radical ideas. They are standard practices in any engineering organization that ships software at scale. They are absent from most GTM systems. That gap is the opportunity.

What comes next

This is v0.01. The first post of many.

This one made the claim: the GTM system is a product. The next ones will argue the consequences. Among them:

• Who builds this product. If it’s a product, it needs a product team. That team is RevOps, but not the RevOps you know today. (v0.02, probably.)

• How it gets built. Operations as code. Version control. Specs. The engineering practices that transfer from software to revenue infrastructure, and the ones that don’t.

• How humans and agents divide the work. Code executes. Agents reason and generate. Humans govern. The operating principle underneath everything.

• How the team is structured. Revenue engineering, revenue operations, and the field. Three roles, one platform, clean interfaces.

• What scales and what breaks. The failure modes. The moments things work. The compounding effects that make this model asymmetrically better than the old one.

If any of this resonates, if you’re building this or wishing someone would, subscribe. Or reply to the welcome email and tell me what you’re working on. I read everything.

— Andrew