Marketing never had a system of record. Agents make that a problem.

Ask a marketing team what they ran last year and what they learned, and watch what happens. Someone opens Slack search. Someone else finds a deck from the quarterly review. A third person remembers a Notion page that was accurate in March. Nobody opens a system, because there isn’t one.

Marketing has never had a system of record for what was tried and what was learned. The CRM is the record for contacts and deals. The ad platform is the record for spend. The planning tool, if you have one, is the record for budget. The campaigns themselves, the actual unit of work, the thing you set out to prove and whether you proved it, have no home.

That gap has been tolerable for twenty years because the people proposing campaigns were the same people who ran the last ones. Their memory was the record. Agents break that. An agent proposing next week’s campaign has no memory of last year’s, and unless the record exists somewhere it can read, it will confidently propose the thing you already tried.

This article is about that gap, why the agent era makes it urgent, and how we designed Growth Method around one rule: the campaign is the record, the conversation is the log.

What a system of record actually is

The textbook definition is short. A system of record is “the authoritative data source for a given data element or piece of information”. Geoffrey Moore’s 2011 paper Systems of Engagement and the Future of Enterprise IT drew the line that most software has followed since: systems of record hold transactions and state, systems of engagement hold the conversations around them.

In practice a system of record has three properties. It holds one row per thing. It is where corrections are made. And other systems read from it rather than keeping their own copy. When two tools disagree, the record wins.

The record is not the same thing as the audit log, and the distinction is the whole point of this article. The record answers what is true now. The log answers how we got here and who did it. A HubSpot contact is a record; its property history is the log, one line per change with the value, the time and the source. Salesforce calls the same thing field history tracking. Nobody calls the Slack thread where a deal was discussed the system of record, even though it holds far more detail than the deal record does. The detail is the log. The verdict is the record.

The engineering tools that marketers increasingly borrow from get this right by design. A Linear issue is a small structured record with an activity feed behind it showing every status and assignee change and who made it. A GitHub pull request has a description and a verdict at the top, and a Conversation tab that GitHub’s own docs describe as showing “the description, timeline, comments, and reviews”, with the commits and the diff behind separate tabs. Small record in front. Big log one click behind.

Where marketing’s records stop

Marketing does have systems of record. They just stop short of the campaign.

The CRM owns people and deals. Google Ads, Meta and LinkedIn each own their own spend. Planning platforms such as Uptempo and Planful own plans and budgets, and Uptempo positions itself as marketing’s system of record for planning. Airtable and Notion hold the calendar. Optimizely holds content operations. Each is authoritative for its slice.

None of them records what a campaign set out to prove, what happened, and what the team concluded. The closest marketing ever came was a worksheet. Strategyzer’s Learning Card exists precisely because the record did not: we believed this, we observed that, we learned the following, therefore we will. It is a good format. It is also a PDF, filled in by hand, filed in a shared drive, and never read by another system.

So the learning lives in people. When they leave, or when a new channel owner arrives, the team starts again. Every marketing leader has watched a campaign get re-run because the person who ran it the first time had moved on.

Why agents make the gap urgent

For years this was a cost of doing business. Three things change once agents are proposing and running campaigns.

Agents will propose what was already tried. A person with two years in the seat filters their own ideas against memory. An agent filters against whatever it can read. If the record of past campaigns is a Slack thread and a deck, the agent cannot read it, and the duplicate check that a human does without thinking becomes impossible. We built Growth Method’s duplicate check to read past campaigns, including ones archived in the last 90 days, for exactly this reason. It only works because the campaigns are records.

Agents amplify whatever state they read. Jamin Ball put this better than anyone in his December 2025 piece on why systems of record survive the AI wave:

“If an early step in a quote to cash flow grabs the wrong price list, or the wrong contract term, or a stale ARR number, the rest of the workflow is now confidently automating the wrong thing.”

Jamin Ball, Clouded Judgement, Long Live Systems of Record

Swap the price list for a baseline conversion rate or a goal that changed last quarter, and that is a marketing agent. Ball’s conclusion is that what weakens is “the familiar SaaS front ends” and what remains are “state machines with APIs”. A campaign that moves Backlog, Planning, Live, Analysing, Complete in code, and only ever forward, is a state machine with an API. That is not a coincidence.

Agents cannot keep secrets, so the record has to be the guardrail. Aaron Levie’s argument on the Foundation Capital podcast is that permissions become the moat once agents outnumber people, because you cannot trust a model’s context window to hold something back:

“If I’m running mission-critical transactions on an ERP system powering my supply chain, I can’t get anything wrong. A hundred times more agents means the system that traffic-cops those agents becomes more valuable. Guardrails, what agents can access, and what they can execute within the supply chain all matter more.”

Aaron Levie, CEO of Box, on The case for context graphs

His shorter version is that “agents can’t keep secrets”, so access has to be enforced by a deterministic system, not by asking the agent nicely. Anthropic’s own guidance on writing tools for agents frames tools as “a contract between deterministic systems and non-deterministic agents”, and tells builders to enforce that contract “with strict data models”. The record is the deterministic side of the contract.

Put the three together and the picture is clear. The AI era does not make the marketing system of record optional. It makes it the thing everything else depends on. Even a16z, which backs the AI-native challengers, made the same point in a September 2026 piece on why incumbents are coming back:

“The bullish case for incumbent systems of record is that AI makes systems of record get more important, not less.”

Seema Amble, a16z, The Incumbents Are Coming

Her reasoning is that “the customer can now pipe the system’s data into Claude or Codex and skip the AI-native app”. Which is true, and is only a threat if the system of record you are piping from exists. For marketing campaigns, it mostly doesn’t.

How chat-first tools get this backwards

The AI-native answer to record keeping has been the conversation. In a chat-first tool, whether that is a Claude or ChatGPT project, a Cursor session or a Devin run, the conversation is the unit of work. Decisions live in the transcript. Ask what was decided and the honest answer is to read the thread.

That works for one person and one week. It fails for a team and a quarter, because a transcript is easy to write and hard to read. It has no fields, no current value, no way for a manager to see the verdict without scrolling past the working. You cannot share it with a CFO. You cannot correct it, because it is a history, and editing history is a different kind of problem. And another agent cannot look up what it needs without loading the whole thing into context, which is slow, expensive, and makes the agent worse.

The protocol that connects agents to tools assumes the opposite design. The Model Context Protocol architecture lists as a core principle that servers “should not be able to read the whole conversation”. Full conversation history stays with the host; the tool gets only what it needs. MCP is built on the assumption that the record and the transcript are separate things. A tool that made the transcript its record would be fighting the protocol it speaks.

How we built it: the campaign is the record, the conversation is the log

Growth Method has two objects that matter here, and the rule about which is which shaped almost every design decision.

The campaign is the record

A campaign is a small, structured, auditable record: the hypothesis, the plan, the metrics with their baselines, the cost, the stage, the owner, the result. One row per campaign. It is where people edit, comment, share and review. It is what a manager opens on a Monday and what a stakeholder gets a link to. It says what is true and what we learned, and it is cheap to read, so every agent run starts by reading it rather than by reading everything that came before.

Because it is the record, the rules on it are strict. The five stages move in code, only forward, never skipping. A campaign cannot be marked Complete until its test result is filled in, so the learning is captured or the campaign does not close. Iterating on a finished campaign creates a new version with the result carried over as the starting point, so the family of versions reads as one line of learning rather than five disconnected attempts. And every change to a campaign field is logged, with who or what made it and when, so the record covers a person editing the plan on a Tuesday and an agent writing the analysis on a Sunday night with the same rigour.

The shared campaign page is the stakeholder artefact: the short verdict, the metrics, and a derived timeline. Derived is the important word. The story of the campaign is assembled where it is read, from the records underneath. Nothing is stored twice.

The conversation is the log

Every piece of agent work on a campaign happens in a conversation, and that conversation is the log. There is one thread per phase: one for creating the idea, one for planning, one for launching, one for analysing the results, each named for the campaign and the phase. The agent’s actions and the results it got back are written into the thread in order, from what the system observed, never from the agent describing its own work.

Once a conversation is attached to a campaign it cannot be deleted, because deleting it would take a stage out of the story for everyone. Open any of them and the campaign’s earlier conversations appear above it, read-only, so the whole campaign reads as one account from idea to verdict. Every change an agent made in a connected tool is recorded the moment it runs, successes and failures alike, and that record survives even if its conversation is later archived with the campaign.

The log is where agents act and interact. It is the authoritative account of how we got here. It is also big, and slow to read, and expensive to load, which is exactly why it is not the record. It sits one click behind the campaign as evidence, in the campaign’s Agent activity list: one line per conversation showing the phase, the date, whether the agent acted without review, how many queries it made and which data sources it consulted.

Two levels, not three

We deliberately stopped at two levels: the campaign, and the conversations behind it. Jakob Nielsen’s guidance on progressive disclosure is that “designs that go beyond 2 disclosure levels typically have low usability because users often get lost when moving between the levels”. A manager reads the campaign. If they want to know why, they open the thread. There is no third layer of summaries of summaries, and no separate audit product to buy.

The discipline this imposes is that the record must stay small. Facts stay where they were recorded, in the thread. Stories are derived where they are read, on the page. The moment we let the campaign grow into a second transcript, we would have two logs and no record. Keeping the campaign short is not a cosmetic choice. It is what makes it a system of record at all.

What to ask of any marketing tool

If you are choosing where your team’s campaigns will live in an agent-heavy stack, four questions separate a record from a log dressed up as one.

1. Is there one row per campaign with fixed fields, or is the campaign whatever the last chat said it was?
2. Can a person and an agent both edit it, and does the tool record who changed what? If only agents write to it, it is a log. If only people do, agents will re-propose what they cannot read.
3. Is the history derived from records, or is it the storage? A timeline assembled from records can be redesigned. A timeline that is the storage cannot.
4. Can a stakeholder read the verdict without reading the working? If the answer involves the phrase “just scroll up”, it is not a system of record.

Marketing spent two decades without a record of what it tried and learned, and got away with it because people remembered. Agents do not remember. They read. The teams that run more campaigns with agents will be the ones that gave them something worth reading.

Growth Method is the agentic marketing platform for B2B teams, built so the campaign is the record and the conversation is the log. Get started: your first month is free.

We are on-track to deliver a 43% increase in inbound leads this year. There is no doubt the adoption of Growth Method is the primary driver behind these results.

Laura Perrott, Colt Technology Services

Further reading

• Context Engineering for AI Agents: Why Less Beats More (Growth Method)
• Agentic Work Management: What It Is and How It Works (Growth Method)
• Automate campaigns with a custom agent (Growth Method docs)
• Long Live Systems of Record (Clouded Judgement)
• The Incumbents Are Coming (a16z)
• The case for context graphs, with Aaron Levie (Foundation Capital)
• Writing effective tools for agents (Anthropic)
• Architecture (Model Context Protocol specification)