The 2026 B2B marketing ops stack is three layers joined by explicit contracts: a system of record (Salesforce or HubSpot CRM), a system of engagement (Marketo or HubSpot Marketing Hub), and, for teams that need one, a warehouse where identity and metrics get defined. The logos changed less than the write paths did. Software agents now write into every layer, so the connectors between systems, and the rules about who may overwrite what, have become the most important part of the stack. They are also the part that nobody owns.
What changed between the 2020 stack and the 2026 stack?
Four years ago the stack diagram was a row of logos and the connector was a line between them. In most portals we open, that line still carries no documentation. What moved underneath it:
| Layer | 2020 default | 2026 default | What marketing ops now owns |
|---|---|---|---|
| System of record | CRM, written by reps and one MAP sync | CRM, written by reps, the MAP, enrichment tools, routing tools and agents | Write authority per field |
| System of engagement | MAP holds its own copy of truth | MAP increasingly reads audiences from the CRM or warehouse | Which fields the MAP may overwrite |
| Joined data | Spreadsheets and BI extracts | Warehouse (Snowflake, BigQuery, Databricks) or native datasets (HubSpot Data Hub, Salesforce Data 360) | Metric definitions and identity keys |
| Connectors | Native sync, set once at implementation | Native sync plus reverse ETL, iPaaS and API-level agents | Sync rules, direction, conflict handling |
| Automation | Workflows and smart campaigns | Workflows plus agents acting through APIs | Permissions, audit trail, kill switch |
Two renames tell the story. HubSpot’s Operations Hub became Data Hub, and Salesforce’s Data Cloud became Data 360 as part of its Agentforce 360 branding (Salesforce Ben, October 2025). Both vendors now pitch the data layer as the thing agents need. They are right about that, and it means the data layer has to be correct before an agent reads it.
What is the system of record now, and who is allowed to write to it?
Start with a write-authority map rather than a tool list. For every field that matters to revenue reporting (lifecycle stage, lead source, original source, owner, account, opportunity amount, close date), list every process that can write to it.
In the audits we run, a single revenue field usually has several writers: a form, an import, the MAP sync, an enrichment tool, a routing tool, a rep, a workflow and now an agent. The damage comes from the sync rules between them.
HubSpot to Salesforce. Every mapped property carries one of four sync rules: Prefer Salesforce unless blank, Always use Salesforce, Two-way and Don’t sync (HubSpot Knowledge Base). Two-way means the most recent update wins in either direction. That is fine for a phone number. On a field like lead source or lifecycle stage, a HubSpot workflow and a Salesforce flow can overwrite each other in a loop, and the property history shows alternating values a few minutes apart. The check: open the Salesforce integration settings in HubSpot (Connected Apps → Salesforce), go through the field mappings on each object tab, and flag every Two-way rule on a field that feeds a report.
The inclusion list. If the Salesforce integration syncs every contact, marketing-only records (webinar attendees, newsletter subscribers, students) end up as Salesforce leads with owners and SLA timers. The Salesforce inclusion list in the HubSpot integration settings controls which contacts sync. We check whether it exists, what list it points at, and whether that list’s criteria still match the current definition of a sales-ready record.
Marketo to Salesforce. Marketo syncs with Salesforce through its sync user, and by default it will write to any mapped field the sync user can edit. Two controls do the work. The first is Salesforce field-level security on the Marketo sync user’s profile, which decides what Marketo can touch at all. The second is Block Field Updates under Admin → Field Management, which stops specific sources from overwriting a field. Many instances we open use neither, so Marketo’s value for lead source lands on top of whatever the rep entered.
The rule we apply is one writer of record per field. Other processes may fill a blank, but only one may overwrite. Write that down in the field dictionary. Every change to a sync rule then becomes a decision you can find again later, rather than a setting someone once clicked.
Does a B2B team actually need a warehouse?
Sometimes. The warehouse-native pitch says identity resolution and metrics should live in the warehouse, and the CRM and MAP should read from it. For a company joining product usage, billing, support and ad spend to answer revenue questions, that is correct. For a company that cannot yet agree what counts as an MQL, it is an expensive way to copy the argument into a new system.
Our test before recommending a warehouse:
- The join test. Does the question you keep failing to answer need data the CRM cannot hold cleanly? Product events, billing line items and ad-platform spend at campaign-day grain are the usual candidates.
- The two-numbers test. Do two teams produce different numbers for the same question? If yes, trace why. If the cause is an undefined field or a Two-way sync, fix that first. A warehouse will reproduce the disagreement with better charts.
- The owner test. Is there a named person who will own the models, the refresh schedule and the definitions? A warehouse without an owner goes stale within a quarter.
- The native-first test. HubSpot Data Hub datasets and Salesforce Data 360 now cover joins that needed a warehouse a few years ago. Check whether the native layer answers the question before you add a system.
If the answer to 1 and 3 is yes, and 2 traces to a real data gap rather than a definitions gap, the warehouse earns its place. Then the reverse-ETL path (warehouse to CRM) needs the same discipline as any other sync: which fields it writes, on what schedule, and whether it may overwrite.
What does “composable” mean in practice?
Composable is a property of the contracts, not the tools. A stack is composable when you can replace one component, whether the MAP, the enrichment vendor or the routing tool, without rebuilding the others. That is only possible when four contracts are written down:
- The identity key. Which ID each system joins on: the Salesforce 18-character record ID, the HubSpot record ID, the Marketo lead ID, and email as the fallback. We look for the Salesforce ID stored on the HubSpot or Marketo record, because that is what makes a clean re-sync or migration possible.
- The field dictionary. Internal name, label, type, allowed values, writer of record and the reports it feeds. HubSpot internal names (such as
hs_lead_status,lifecyclestage,hs_analytics_source) and Salesforce API names are the join; labels are not. - The sync specification. For every mapped field, the direction and the rule, plus what happens on conflict and on delete.
- The owner. A named person for each contract, not a team.
A practical test: could you swap your MAP within a quarter without losing reporting history? If the answer involves “we’d have to work out what the fields mean,” the stack is not composable yet. Our HubSpot–Marketo migration guide walks through what that inventory looks like when the swap is real.
Where do agents sit in the stack, and what can they touch?
Gartner predicts that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025 (Gartner, August 2025). In marketing ops that already means native agents inside the platforms (HubSpot Breeze, Salesforce Agentforce) and external agents acting through APIs and MCP connections.
An agent is a new writer. Treat it exactly as you would an integration:
- Its own user. Never let an agent act as a named admin. In Salesforce, an integration user licence with a minimum-access, API-only profile plus permission sets for the objects it needs. In HubSpot, a dedicated private app or app user with only the scopes the task requires. In Marketo, an API-only user with a custom role.
- Field-level limits. Restrict which properties the agent can write. An enrichment agent writes firmographic fields; it has no business touching lifecycle stage or owner.
- An audit trail. HubSpot property history records the source of each change. In Salesforce, Field History Tracking covers up to 20 fields per object, so choose them deliberately and make sure the fields agents write are on the list.
- A way to stop it. Revoking the token or deactivating the user should stop the agent within minutes, and someone should know how to do it.
The failure mode we see most often is not a rogue agent. It is an agent given an admin’s credentials for a pilot and never moved off them. Every write then looks like the admin made it, and the audit trail is useless.
The flagship chapter, The AI-Native RevOps Blueprint, sets out which workflows agents should run first. This chapter’s point is narrower: before any agent runs, you should be able to say what it can write and how you would know it had.
What does marketing ops own in 2026?
The job has moved from administering tools to owning contracts. On the stacks we work in, the ownership that matters looks like this:
| Artefact | Owner | Reviewed |
|---|---|---|
| Field dictionary with writer of record | Marketing ops (with sales ops for shared objects) | Quarterly, and on every new integration |
| Sync specification (every mapped field, rule, direction) | Marketing ops | Every change, plus quarterly |
| Integration and agent user register (user, scopes, fields, owner) | Marketing ops with IT or security | Quarterly |
| Dedupe and data-decay cadence | Marketing ops | Monthly |
| Stack map (this chapter’s artefact) | Marketing ops | Quarterly |
If nobody owns a row in that table, that row is the likely source of your next reporting dispute.
How do you map your own stack in an afternoon?
This is the artefact the chapter hands you. Open a spreadsheet with these columns and fill one row per connection, not per tool:
Source system · Destination system · Connector (native, iPaaS, reverse ETL, agent) · Objects synced · Direction · Sync rule or overwrite behaviour · Filter (inclusion list, sync filter, smart list) · Running as (user) · Owner · Last reviewed
Then run five checks:
- Two-way on reported fields. Any Two-way rule on lifecycle stage, lead source, original source, owner or amount is a finding.
- No filter. Any connector syncing all records with no inclusion list or sync filter is a finding.
- Shared credentials. Any connector or agent running as a named person rather than a dedicated user is a finding.
- Unknown owner. Any row where the owner cell is blank is a finding.
- Unused connections. Any connected app with no sync activity in 90 days is a candidate to disconnect. Old connections keep their permissions after nobody remembers them.
Most teams find more connections than they expected. That count, and the number of fields with more than one overwriting writer, is a better read on stack health than the number of tools.
What have we seen in the field?
- The loop nobody saw. In a HubSpot and Salesforce stack, lead source was mapped Two-way and written by a HubSpot workflow on one side and a Salesforce flow on the other. Property history showed the value alternating for months. Reported source mix depended on which system you pulled from, and at what time of day. The fix was one sync rule change and one retired workflow.
- The inclusion list that drifted. The list controlling which contacts synced to Salesforce had been built around a lead-score threshold that had since been rescaled. Marketing-only contacts flowed into sales queues and SLA reports for a year.
- The pilot credentials. An enrichment pilot ran under a departed admin’s user. When that account was deactivated, enrichment stopped silently, and records created afterwards had blank industry fields that broke territory routing.
None of these needed a new tool.
What did we get wrong, and what is still open?
We used to recommend a warehouse earlier than we do now. Native datasets in HubSpot and Salesforce have closed much of the gap for mid-market B2B teams, and several warehouse projects we saw added a reconciliation problem rather than removing one. We now run the four tests above first.
Still open: how much agent write access should flow through native agents versus external ones. Native agents inherit the platform’s permission model and audit trail. External agents are more flexible and harder to govern. We do not yet have a rule we would defend in every case; for now, we default to native for writes and external for reads.
Sources
- Gartner, press release, 26 August 2025: “Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026, Up from Less Than 5% in 2025.”
- Salesforce Ben, October 2025: “Salesforce Data Cloud Renamed to ‘Data 360’ As Part of ‘Agentforce 360’.”
- HubSpot Knowledge Base: “Map HubSpot properties to Salesforce fields” (sync rule definitions).
Want your stack mapped for you?
The stack map above is the first thing we build in a GTM Systems Audit: every connection, sync rule and writer of record across HubSpot, Marketo and Salesforce, with each finding ranked by what it costs you in reporting trust. Audits start from USD 1,500. If you would rather run it yourself first, start with the GTM Systems Audit Checklist. If the map turns up a sync loop, our sync work is where it gets fixed.