Mary Shelley’s gothic-era classic Frankenstein is a prime read every Halloween. This year, though, the story of a scientist whose greatest creation gains a mind of its own and turns against him hits home a little differently.
AI integration came up at every conference our team attended this year. At MAICON 2026, the conversation moved past adoption to what happens after. Over three days in Cleveland, I heard marketing and technology leaders describe the same problem: AI tool sprawl and siloed agent development are turning martech stacks into frankenstacks.
Dissecting the frankenstack
The frankenstack is the late-stage consequence of assembling a marketing and revenue stack one tool at a time, without a shared data model or a single owner guiding implementation and usage. Where well-defined martech works together, a frankenstacked system creates silos that operate independently of each other. Best-case scenario, nothing breaks and tribal knowledge prevails in keeping the system working. Worst-case scenario, the stack produces duplicate records, conflicting reports, tech debt and broken automations when someone changes an API key.
Why AI makes the frankenstack possible: building in silos
In her MAICON session, “Becoming AI-Native: Getting Everyone Building Agents, and What Comes Next,” Holly Chen hit the proverbial nail on the head. We know teams are excited to use AI. But if we don’t bridge the silos and tell other teams, departments and lines of business what’s being built and why, we end up with a frankenstack of AI-enabled tools that are redundant, hard to manage without the builder and expensive once token usage is thrown into the mix. The problems Holly identified in her role as vice president of growth marketing at Samsara include:
- Duplication: Two people built separate agents for the same job, writing better copy.
- Upkeep: If the builder goes on leave without leaving notes, the team has to either reverse engineer the setup or rebuild it from scratch.
- Cost: Spend arrived in two waves, one for the tool and one for the rollout.
The lesson from that session was blunt: a prototype is not a product. Once a second person depends on an agent, tool or workflow, it needs documentation, an owner and a maintenance plan. Anyone who has run a production website already knows this rule, and AI agents need the same discipline.
We’ve lived this one ourselves. When our marketing team switched AI platforms this year, everyone rebuilt their own event agents and processes. Each one worked for its builder, but together they produced inconsistent brand voice, off-template assets and more rework than they saved. So we pulled those separate systems into a single agent the whole team can use, built on a few key data sources with clear owners and a quarterly refresh. Now project plans, logistics messaging and proposed assets come together in a few hours, and the team spends its time on higher-value, strategic work.
How do we stop the frankenstack? Strategize like a developer
The marketing teams that are successfully using AI to drive productivity are the ones who’ve adopted DevOps and WebOps practices into their own tool enablement. They keep data sources few and let tools multiply on top of them. As Andy Crestodina of Orbit Media covered in his MAICON session, “From Process to Prompt to Automation: How a Marketing Job Becomes a Marketing Tool,” avoiding a frankenstack starts with feeding your data lake with rivers instead of buckets. A river is a governed, continuous connection. A bucket is a one-off export that someone uploads and forgets.
That kind of architecture doesn’t happen by accident. It takes strategy, and teams need to be comfortable spending real time on it before anyone opens a builder. Before you connect a new data source or tool, ask two questions:
- Does this get me what I need to get the job done?
- Does this roll up to a larger, related initiative, or is it a one-off?
For anything beyond a personal agent, add a third: how will this tool drive results other people on the team can use? A team or org agent should produce work that colleagues can pick up and build on without the builder in the room. That is the difference between an experiment and part of the stack.
We saw this with our own reporting. Everyone on the team had their own agent analyzing monthly results, and each was fed different context, so the interpretations didn’t line up. A single report builder with a shared first-pass analysis prompt put everyone on the same page, and the talk tracks it kickstarts now build on each other month over month.
When it comes to execution, keep it simple. Dan Slagen of Zapier laid out the model in his MAICON session, “From AI Users to AI Builders: Leading Marketing Teams Into the Next Phase”: sources feed agents, a check reviews the agents’ work and a brief comes out the other end. Nothing in the source of truth changes unless the owner decides it should. That rule protects the data every agent depends on.
For most revenue teams, the source of truth is the customer relationship management (CRM) platform. A HubSpot portal with clean properties, clear ownership and documented workflows gives every AI tool the same starting point. A cluttered portal gives every tool a different version of the truth.
Process plus tools equals a system. Without the process, you have a table full of parts.
How do you govern AI agents without slowing teams down?
There’s always a concern that too much process prevents innovation. Locking everything down pushes people to build rogue agents in the shadows and puts pressure on a few people to build solutions that work for everyone without having the right context. How sustainable is that? Claire Potter-Schneider, head of marketing AI transformation at Dynatrace, made this point in her MAICON session, “The Playbook for Marketing Transformation.”
Instead, take Holly’s tiered approach and create gates based on usage:
- Personal agents: Anyone can build freely.
- Team agents: Each one is reviewed, registered and hosted in a central repository.
- Org agents: These are owned and maintained centrally.
The more people rely on an agent, the more structure and transparency it gets.
Where should you start this week?
Audit the existing stack, and make it a team exercise. Ask everyone to list the AI tools, agents and automations they rely on, then split the list the way we split our own work: the platform and the pipeline.
- Platform (your website and CMS): content agents, chat and search tools, publishing automations and anything else that reads from or writes to the site.
- Pipeline (your CRM and revenue stack): reporting agents, lead scoring, enrichment, email and workflow automations, and anything else that touches contact or deal data.
For every item on the list, answer these questions. The first four come from Claire Potter-Schneider’s playbook:
- Who owns it, and who uses it?
- What does the contract say?
- Is AI already built into it?
- Which large language models (LLMs) does it use?
- What data source does it read from, and who owns that source?
- Is that source a river or a bucket? A governed, continuous connection is a river. An export someone uploaded once is a bucket.
- Which tier does it belong in: personal, team or org?
The answers tell you where to start. Anything in the team or org tier with an unclear owner or a bucket for a source is your first fix. Personal agents can stay personal, as long as nobody else depends on them. Tools that duplicate each other across the platform and the pipeline are candidates to consolidate, the same way we folded our event agents into one.
Frequently asked questions
What causes AI tool sprawl? Low build costs combined with no shared data model or ownership rules. Each new agent or tool solves one problem and adds one more thing to maintain.
Should companies limit who builds AI agents? At Samsara, Holly Chen’s team lets everyone build personal agents. Review and central ownership come in only as more people rely on an agent.
What is a single source of truth in marketing? It is one governed system, usually the CRM but sometimes the CMS, that every tool and agent reads from. Changes to it require a named owner’s decision.
The fix starts with architecture
Victor Frankenstein’s mistake was building first and figuring out what came next later. A frankenstack comes from the same habit: dozens of reasonable choices made without strategy or architecture behind them. Fix the data model and the ownership first, and AI tool sprawl turns into a set of tools your team can actually run.
Before you build your next agent, talk through your stack with our team. Book a strategic AI session today.
