Look at the tools your marketing team already pays for. In the stacks we work in, the CMS has a writing assistant, the analytics dashboard has a chat box, the email platform generates subject lines, and the design tool has started suggesting layouts. None of them talk to each other. None of them knows your brand rules, and none of them knows who is allowed to approve a page going live. You end up with a dozen AI features and no way to run them.
What fixes that is not a thirteenth feature. It is a shared workspace: one folder your team opens, holding the rules your designers already carry in their heads, the page patterns your site already uses, and a connection to your CMS and your analytics. An assistant reads that folder before it does anything.
We built one for a client marketing team. The useful thing to say about it is that the work split cleanly into two halves, and the halves are done by different people.
The two halves, before anything else
| The marketing half | The engineering half | |
|---|---|---|
| What it is | Writing down the rules, patterns and approvals your team already runs on | The content model, the reusable page sections, and the wiring that lets an assistant reach them |
| Who does it | Your own team, in meetings you already have | Someone senior and technical |
| What it costs | Calendar time | Depends entirely on what your CMS looks like today |
| When you can start | This week | Once someone owns it |
| Who has it | Almost every team | Very few marketing teams of this size |
The order matters. The documentation half is worth doing on its own, it is the half nobody can do for you, and doing it first is what tells you how large the second half actually is. So this piece starts there, then describes the other half plainly enough that you can tell whether you have anyone who could do it.
Is your team ready for this?
Five questions. All of them are about your company rather than your stack, and you can answer them in one meeting with the people you already work with.
- Can you name the person who signs off before a page goes live today?
- Are your design rules written down anywhere, or do they live in one or two people’s heads?
- When you need a new page, is it assembled from sections that already exist, or does someone build something new each time?
- Is a fact like a price or a product name stored once, or copied across a dozen pages?
- Has anything other than a person clicking in the CMS ever edited your website’s content?
If most of your answers are the second option, the work in front of you is mostly documentation, and it is worth knowing that before anyone demos an AI product at you. Questions two and five are the ones that decide how long this takes. Questions three and four are the ones that tell you how big the engineering half is.
What can you start on without an engineer?
Question two, the design rules, is the one you can close yourself this week. Here is how the rulebook in the workspace we built came into existence, and there is nothing in the method you cannot copy.
There was no design document. What existed was a designer who knew, page by page, why the site looked the way it did. So a designer talked through real pages out loud, screen recorded, explaining each choice as they went. Someone watched the recordings afterwards and wrote the rules down. That is the concrete answer to “our design system lives in one person’s head”: you record the head, then you transcribe it.
You need a screen recording app and an hour of a colleague’s time. Three things to get right when you write it up.
Write rules as short statements someone can check
A rule that needs judgement to apply is not a rule yet, and it is useless to a new hire, a freelancer, and a model alike.
- Useless: “keep the page on brand and visually interesting.”
- Testable: “body copy never sits directly on a photograph.”
- Testable: “a page uses at most two typefaces.”
- Testable: “a section heading never runs past two lines.”
You can hear the difference. The second kind can be checked by someone who has never opened your design files.
Write down which document wins
Most teams end up with two: the human-authored rulebook the design team owns, which is intent, and a technical reference grounded in what the live site actually does today. Colours, type, the real list of sections available. Those two drift apart, and almost nobody has ever written down which one to believe on the day they disagree. Deciding that costs one line and a conversation. It is also the single artefact that stops every future argument about it.
Say out loud which parts are unfinished
The rulebook we built is not finished and it admits it. Several sections are marked as waiting on the design team. That turned out to be the better shape: everyone can see what is decided and what is still one person’s opinion, and the team could start using the document before it was complete. A half-written rulebook that admits which half is missing beats a polished one that quietly guesses.
None of the above needs a CMS change, a connection, or a developer. If you stop reading here and do only this, your team is better off, because the document is worth having whether or not an assistant ever reads it.
What actually changed, and why a chat tool alone is not it
The thing that moved recently is not that models write better prose. It is where the assistant sits. A chat box lives in a browser tab, sees only what you paste into it, and hands you text that somebody then has to place, format and check. An assistant that runs on your own machine can open a folder of your team’s files, and it can talk to the systems you already log into, using your own account, with your own permissions.
Once those two things are true, a different kind of work becomes possible for a marketing team. Not better sentences. A page that gets planned, built as a draft in the real CMS with real sections, previewed, and published by a named person, without a ticket in anyone’s queue. And the same assistant can go and look at what your pages already rank for before you decide which one to build.
That is also the answer to why a chat tool on its own produces copy someone has to rewrite. It is missing three things, and they are the same three things a new hire would need: context, a tone of voice guide, and examples. Two of them are documents your own team writes. The rulebook you built out of the designer’s recorded walkthroughs is the tone of voice guide, for layout as much as for copy, and the shared notes about how your site is put together are the context. The third one is neither a document nor a task for you. It is a standing instruction the assistant follows: before building a new page of a given kind, it opens a real existing page of that kind and mirrors how that one is built. Which sections, in what order, how long the copy runs. Copying a good page you already have beats inventing from a blank field, and a model is unusually good at that particular kind of copying.
What is the difference between an AI feature and a workspace your team runs on?
An AI feature lives inside one tool, does one thing, and answers to nobody. A workspace is the place the work happens, and it carries the constraints with it.
| An AI feature in a tool | A shared team workspace | |
|---|---|---|
| Where it lives | Bolted onto one product | One folder every person on the team opens |
| Scope | A single task: write, summarise, suggest | From the idea to a published page |
| What it knows | Whatever that one tool can see | Your design rules, your sections, your history |
| Governance | Per-tool settings, if any | One publish gate with a named person on it |
| Failure mode | Output you paste somewhere and hope | Output that sits in draft until someone looks |
What is actually in the workspace?
The most useful thing to understand is what is not in it. The website’s code lives somewhere else entirely, in a place the marketing team never opens and does not have to think about. This workspace holds three things: the AI setup, the shared design knowledge you just wrote, and the wiring to the CMS and the analytics tools. That separation is the whole trick. It is what makes it reasonable to hand the folder to someone who does not write code, because there is nothing in it that can break the site.
Building that workspace is a job of its own, and it is done once. After it exists, each person on the marketing team joins in about ten minutes: install the desktop app, open the folder, connect the CMS with their own account, sign in to the analytics connections they want. Be precise about what those ten minutes buy. They buy joining a workspace that already exists, and the workspace only works because the structured CMS underneath it and the page sections it builds from were built first.
Two details in the setup matter more than they look.
- Every person uses their own credentials, stored on their own machine and never saved into the shared folder. So every change on the live site traces back to a named human, and access can be revoked for one person without touching anyone else.
- The workspace deliberately ships no shared connection to the CMS. A pre-configured connection with an empty credential in it would sit there half-working and failing quietly. Either your own connection is there and works, or it is obviously absent.
What does building a page look like from the marketer’s side?
Someone types what they want. From there the loop is fixed.
- Understand the goal. What the page is for, who it is for, and whether there is an existing page worth modelling it on.
- Plan the sections from the ones that already exist, and show that outline to the person before building anything. Correcting an outline costs nothing. Correcting a finished page is real work.
- Build it as a draft in the CMS, with real copy and real images, following the rules.
- Preview it. Most marketing leads do not care what happens in the CMS internals. They care about the preview and whether the editor is easy, so the preview is where the actual review happens.
- Publish only on a person’s yes.
The second standing rule, after “learn from an existing page”, is reuse rather than invent. The assistant builds only from sections that exist already. If a page needs something that is not there, that is a request to engineering, described clearly, rather than a workaround improvised out of a rich-text field. This is the rule that keeps a fast tool from slowly wrecking a design system, and it is also why the engineering half never quite finishes: new sections keep being worth adding.
The decision about what reaches the live site stays with a person, and the categories that stay with a person do not move: strategic judgement, and anything where a human being can come to harm. Legal copy, claims, pricing. Our hard lines for an agent working in a client CMS go through that list properly, so this piece will not restate it.
What stops an AI agent publishing something embarrassing?
This is the question that decides whether a marketing lead tries any of it, so here it is directly. Four mechanisms, none of which relies on trusting the model:
- It works in draft. Output exists as an unpublished version until a person acts on it.
- It shows the plan first, so mistakes get caught as an outline rather than as finished copy.
- It can only reuse existing sections, so it cannot invent a layout nobody approved.
- Publishing and deleting need a person, using their own login, which makes every live change attributable.
Running this on a real marketing site, nothing broke. That is a low bar, and it is the one the question is really asking about.
Can it tell you what to build next?
The same workspace connects to Search Console and to the analytics, because “build me a page” is the second question and “which page is worth touching” is the first.
So it can answer things like which queries a given page already ranks for and at what position, and where the traffic on it comes from. The useful part is the instruction attached: turn the research into a specific edit on a named page, not into advice. Not “improve your meta descriptions”. Instead: this page ranks just off page one for this query, the query does not appear anywhere in the page’s first section, here is the rewritten first section.
So what is the engineering half, exactly?
Everything above assumes three things exist. They are the whole of the other half.
Content in named fields. For an assistant to write reliably into your site, a page has to be stored as parts that mean something: a heading, a list of sections, an image with its caption. Not one large block of text per page. If your CMS stores a page as a single blob, there is nothing dependable to write into, and reshaping that is a build project rather than a documentation one. We made the longer case in structured content vs structured data and in your website now has two audiences.
A set of page sections worth reusing. The hero, the feature grid, the pricing table, the testimonial row. Built once, properly, so assembling them in a new order is safe. This is what makes “reuse, do not invent” a real constraint rather than a hope.
The connection and the workspace itself. Each person’s login wired to the CMS and the analytics, the rules and patterns laid out where an assistant will actually read them, and the workspace kept working as things change. Your CMS probably already supports the connection part. We have written up how we connect an assistant to DatoCMS and the same pattern for Storyblok if you want to hand something concrete to whoever looks after your stack. If you have read the shared setup that keeps content consistent across markets, this is the same argument with the physical thing described.
Notice the shape of that work. It is not a big launch project. It is a few days a month, indefinitely: sections get added, the content model gets extended, an integration breaks, a new person needs access. That shape is why it falls between the chairs at most companies. Internal developers are on the product. Agencies quote projects and go quiet between them. Freelancers move on. Nobody is short of the skill, and everybody is short of a person whose standing job this is.
What does it cost?
The documentation half costs nothing but calendar time. A recording app, an hour of a designer, and a few hours of somebody writing carefully. You can do all of it before you talk to anyone.
The build half depends almost entirely on what your CMS looks like today, and we are not going to invent a number for it here. A site whose content already sits in named fields, with a set of page sections that get reused, is a short piece of work. A site where every page is one block of text and every layout was built from scratch is a content model rebuild first, and the assistant is the last thing you would do, not the first. That is why this piece opens with five questions instead of a figure. Answer them and you will know which of those two you are, which is the thing that actually moves the number.
The ongoing half is easier to price, because it is a role rather than a project. One senior engineer on your marketing team’s work, with nobody on your payroll. We call that a fractional marketing engineer. The tier that carries this build and keeps it running afterwards is Ownership. Month to month, cancel or pause with 30 days notice.