The state most teams are actually in

AI-assisted operations do not arrive through a procurement cycle. They arrive because one operator automates a recurring task, it works, and six months later a meaningful share of the marketing operations calendar is executed by scripts and agents that nobody has inventoried. That is not a failure. It is usually the highest-leverage work happening in the function. But it has three properties that make it a liability the moment anyone looks closely:

• No registry. Nobody can answer what automation exists, what systems each piece touches, or what it is permitted to write.
• Key-person risk. The capability lives in one person's head and one person's repository.
• No change record. For anything adjacent to lead assignment, scoring, or territory (SOX-relevant surfaces at most public companies), that is an audit gap, not merely an efficiency gap.

The market has now named the role that closes this. Postings for AI transformation owners, marketing AI operations leads, and directors of GTM systems all describe the same charter, with published bands well into the $200Ks. Stripe lists building working AI prototypes as a minimum requirement for senior marketing operations leadership. The 2026 update to the standard four-pillars marketing ops framework folded agent infrastructure into its engineering pillar. This stopped being a side-of-desk experiment.

The charter

Five components, in the order they earn their keep. 1. Automation and agent registry. A versioned inventory: every automation, its named owner, what it reads, what it writes, and its measurable output. This is unglamorous and it is the foundation: every other component references it. During a stack consolidation it doubles as the integration inventory, and without it, consolidation decisions get made blind. 2. Write policy. An explicit statement of what runs unattended, what requires human review, and what change record is required for anything touching revenue-path systems. The distinction that matters is read versus write: read-only automation is nearly free to permit, and write access to scoring or routing deserves a named approver. 3. Use-case backlog. Automation candidates ranked by frequency, documentation readiness, and risk. Documentation readiness is the underrated axis: a process nobody has written down cannot be automated reliably, so the backlog doubles as a forcing function for documenting the process inventory. 4. Audit program. Scheduled, read-only audits on a cadence: lead flow from form fill through routing and assignment, taxonomy compliance, data hygiene, scoring drift. The measure of success is problems surfaced before a stakeholder files a ticket. 5. Enablement. Structured training so the capability multiplies across the team rather than bottlenecking on whoever built it. This is the component most often cut, and cutting it is what preserves the key-person risk the charter exists to remove.

Why this belongs to operations, not to a platform team

A central AI or platform engineering team can build infrastructure. It cannot know that a particular routing rule exists because of a 2019 territory dispute, or that a scoring field is load-bearing for a report the CRO reads weekly. The judgment about what is safe to automate is domain judgment, and it lives in the operations function. The pattern that works is a partnership: a function-embedded owner who holds the registry, the policy, and the backlog, working with central engineering for infrastructure and security review. The reference designs in the market, GitLab's AI transformation owner model in particular, are built exactly this way.

Metrics that survive a second quarter review

Vanity metrics here are easy and useless. "Number of agents built" measures activity. These measure the thing:

• Hours of recurring work returned per week, measured per automation, before and after
• Issues surfaced by audits before a stakeholder ticket: count, with examples
• Registry coverage: percent of running automation documented and governed
• Adoption: automations used by people other than their author
• Zero ungoverned writes to revenue-path systems

That last one is binary and it is the one an auditor will ask about.

The takeaway for your stack

If AI-assisted work is already happening in your operations function, and it almost certainly is, the question is not whether to allow it. It is whether you can produce, today, a list of what it touches. Start with the registry. The policy argument gets much easier once the inventory is on a page.