---
title: "Which Part of Your AI Marketing Setup Still Belongs to You in a Year"
description: "Your competitor can be running the same AI tools by this afternoon. What separates a marketing setup that compounds from one that resets with every model release is the part you own: the files, the wiring and the approval gates that stay yours when the model or the vendor changes."
date: 2026-09-08
author: "David Wippel"
tags: ["ai-ops"]
url: https://www.essentialcode.eu/blog/which-part-of-your-ai-setup-belongs-to-you/
---

# Which Part of Your AI Marketing Setup Still Belongs to You in a Year

> Your competitor can be running the same AI tools by this afternoon. What separates a marketing setup that compounds from one that resets with every model release is the part you own: the files, the wiring and the approval gates that stay yours when the model or the vendor changes.

**TL;DR.** The agent is the commodity. What compounds is everything you own around it: the context files an agent reads, one written job spec per agent, the systems it can reach, and a person approving every significant step and the final one. Owning those four things also makes swapping the model a cheap experiment rather than a rebuild, and switching the model is the first thing I change when a setup is not working. Six questions at the end tell you which of it you would keep if the contract ended.

Your competitor can be running the same AI tools as your team by this afternoon. They buy the same subscriptions at the same price, and nothing in the purchase takes long enough to count as procurement. Whatever advantage sits inside the tool itself is available to anyone with a credit card, and that will still be true next quarter.

So the useful question for a marketing lead is which part of an AI setup still belongs to you in a year. My answer is everything around the agent: the files it reads, the systems it is allowed to reach, and who approves what ships. The setup is more important than the agent.

Greg Isenberg, who has been teaching the marketing engineer role to a large audience since late August, closes his argument with this: "The agents are going to be a commodity at some point. Your judgment about what to point them to is the moat." The first sentence is plainly right, and the second one correctly names where the value shows up. Judgment also has a property that makes it awkward as a company asset. It sits in somebody's head, it leaves when they leave, and you cannot hand it over on a Friday afternoon. The setup around the agent is built, owned and improved by the company that has it, and that difference decides what you should be buying.

## What do you actually own in an AI setup?

What you own is everything around the model. The context files an agent reads before it starts work, the written job spec that says what it does and what it is not allowed to do, the systems it can reach and under whose login, and the human approval points that decide what actually ships. A model produces text. Those four things decide what it draws on, what it may touch, and who says yes. Builders call the bundle a harness, and the name matters less than the property: you own it, and you can take it with you.

Isenberg describes the same object from the builder's side and calls it a growth repo: a folder of markdown files holding customer truth, founder voice, past experiments, and a rolling note on what the market is telling you. His claim about it carries the whole argument: the repo, rather than the model, is what makes the output good.

His own illustration of the gap is a prompt. One version says "write me 10 LinkedIn posts". The other says read the customer truth file and the founder voice file and the last five posts that drove qualified replies, then draft five posts about pains buyers named this week. Identical tool, identical minute of work, and what lands on your desk is a different category of thing. What separates the two is whether those four files exist.

## Which parts of an AI setup actually compound?

Line up what a setup is made of and ask, for each layer, who supplies it and what survives the next model release.

| Layer                                                              | Who supplies it                             | What happens on the next model release  | How long the advantage lasts    |
| ------------------------------------------------------------------ | ------------------------------------------- | --------------------------------------- | ------------------------------- |
| The model                                                          | A vendor, the same one your competitor uses | It is replaced, by you or by the vendor | Until the next release          |
| The prompt somebody typed                                          | Whoever was at the keyboard                 | It closes with the chat window          | One session                     |
| Context files: buyer language, voice, what worked and what did not | Your own team, written once and maintained  | Read by the next model unchanged        | Years, and it improves with use |
| A written job spec per agent                                       | You                                         | Carries over                            | Years                           |
| Tool wiring into the CMS, analytics and CRM under named logins     | Built once by someone technical             | Carries over                            | As long as those systems live   |
| The approval gates                                                 | Your organisation                           | Carry over                              | Permanent                       |

The top two rows are what most teams are buying today, and they are the two rows with no durability in them. The bottom four are the ones no vendor sells you, because four of them are documents and one of them is a decision your company has to make about who is allowed to publish.

None of this is out of reach for a team that wants to build it. Writing the context files needs no developer and no budget line, only time from people who already work there, and a team that does only that is better off than it was.

## Why my first fix is to switch the model

When one of our own setups stops producing what it should, the first thing I change is the model. Prompting, task decomposition and tooling all come after that.

That is the opposite of what most guidance recommends, which starts at prompting and works outward. The argument for that order is that it is the cheapest test in the list. Models are not interchangeable in practice, which one suits a given job is not something you can reason your way to from a spec sheet, and finding out takes a minute.

Switching the model is a one-minute experiment only when everything that matters sits outside the model. If your buyer language, your voice rules, your job specs and your publishing gate live in files you own, changing which model reads them is a setting you can flip and flip back before lunch. If those things live inside one vendor's product, or in a fine-tune, or in a long prompt somebody typed six weeks ago and has since edited, you cannot run the test at all.

Owning those files buys you that option, and the option is worth more than picking the right model today. Being able to re-pick every few months outlasts any single correct choice.

## How our own marketing setup is built

This is how our own marketing runs, so here is the mechanism described plainly enough to copy. Four parts.

1. **A context repo.** Positioning, the tone of voice rules, the content strategy, and a growing file of my own recorded positions on questions that come up. Every agent reads what it needs from this before it does anything.
2. **One written job spec per agent.** What this agent does, what it reads first, what it hands on, and what it is not allowed to decide. Isenberg suggests writing these like a hiring document, which is exactly the right instinct: you would not put a new person on a task by describing it in a sentence.
3. **A defined set of tools each agent can reach.** The search data, the analytics, the repo. Nothing outside that list, and everything under a named account.
4. **A human gate after every significant step, and a human gate as the final step.** This is the part I want stated rather than implied.

The fourth point is where descriptions of setups like ours tend to go quiet. A person approves the direction before the work starts. A person approves again at every point where the work changes shape, which in practice means several times in a single piece. And a person approves the finished thing before it reaches a live page, by name, using their own login. Nothing publishes on a machine's decision.

The gate belongs in the description of the mechanism, in the same way the context files do. A setup described as running unattended is a different setup from the one we actually run. If you build one of these yourself, the gates are the piece I would put in first and the piece I would refuse to trade away for speed.

Each of those four parts is portable. Change the model, the vendor, or the people doing the work, and all four stay where they are. That is the property judgment on its own has never had.

## What to ask before you buy any of this

If somebody is selling you an agentic marketing setup, six questions will tell you what you are actually getting.

1. **Where do the instructions live, and can we read them?** Ask to see the files. If the answer is that they live inside the product, you are renting behaviour rather than owning a setup.
2. **Can the model be swapped without a rewrite?** If not, you have bought a bet on one vendor's roadmap.
3. **What does the agent read before it starts, and who keeps it current?** An agent that has read nothing about your company writes what it would write for anybody.
4. **Which systems can it reach, and under whose login?** Named accounts mean every live change traces back to a person and access can be withdrawn for one person without touching anyone else.
5. **Where are the human approval points, and who is named on the final one?** If there is one gate at the very end, the earlier mistakes have already been paid for by the time anybody sees them.
6. **If we stop working with you, what do we keep?** That answer is the whole test on its own. Files and wiring stay with you. Rented behaviour ends with the contract.

## What this changes about the buying decision

Most teams think they are buying access to a capable agent. That access is not scarce and it is getting less scarce every quarter, which makes it a poor thing to build a plan on. The purchase worth making is the part that stays yours, and the test of whether you got it is whether the setup still works after you change the model, change the vendor, or change us.

That is how we build them for other people too. [Agentic marketing automation](/services/agentic-marketing-automation/) is the build itself, the control room over your headless CMS with the design rules, the job specs and the gates that go with it. A [fractional marketing engineer](/services/fractional-marketing-engineer/) is the same skill set on a monthly basis, keeping it running and extending it as your content model and your team change. If you are still working out whether that role is what you need at all, [what a marketing engineer is and what changes when you have one](/blog/what-is-a-marketing-engineer/) covers who the role is for. That piece answers what the role is. This one answers where the durable part of it sits.

There is a test you can run this week without buying anything. Take the last thing an AI tool produced for your team and ask what it read before it started. In most companies the answer is nothing, and that one is fixable without a budget line.