How to build an AI-native publishing system

I started building Editorial Intelligence as a website for publishing ideas. Somewhere along the way, it stopped behaving like a normal blog.

The change was not that AI began writing the articles. That would be the least interesting version of this story. The change was that AI started operating across the publication itself: retrieving previous arguments, finding overlap, challenging whether a new idea deserved a new page, updating live pieces, preserving relationships between them and changing the website when the editorial model demanded it.

That has changed what publishing feels like.

A conventional personal publishing workflow is roughly:

idea → draft → edit → publish → next post

Mine is becoming closer to:

signal → retrieve what I already know → compare it with the existing corpus → extend / correct / merge / split / create → human judgement → AI-supported implementation → versioned publication → new evidence → back into the system

I wrote about the first time I noticed this in I could not have published like this before AI. At the time, the striking thing was the reduction in coordination cost. I could return to live arguments, develop them, correct them and preserve their history without spending half a day reconstructing where everything lived.

This guide is the practical version of that observation.

It explains how I would build the system again from scratch, what parts matter, what parts are just my current choice of tools, and where I think the model breaks if you automate the wrong thing.

The important point at the start is this:

An AI-native publishing system is not a content factory. It is a publishing system designed so AI can work across the history, evidence and relationships of the publication rather than only helping produce the next asset.

The shortcut: give this guide to your AI

Before section one, there is a faster route than reading the whole thing start to finish.

You can hand this guide to a capable AI and ask it to use it as an implementation spec, not as an article to summarise.

Do not ask it to copy my architecture. Your corpus, your stack, your evidence and your appetite for structure will be different from mine.

Ask it to interview you first, then propose the smallest version that fits what you actually publish.

Use this bootstrap prompt:

I want to build the AI-native publishing system described in this guide.

Use the guide as the architecture, not as content to reproduce.

First, interview me only for information that materially changes the system:

- what I currently publish, and on what platform;
- where my research, evidence and working notes live today;
- roughly how much existing published content there is;
- what AI tools already have access to my work;
- what should never become public;
- whether I already make any extend / correct / merge / split /
  create decision before publishing, even informally;
- who besides me has editorial authority over this corpus;
- what my publishing and deployment stack actually is.

Then:

1. propose the smallest durable knowledge layer worth creating;
2. propose the minimum metadata a published piece needs;
3. draft a short AI instruction file covering source-of-truth
   and routing;
4. propose one publishing route to test first, not the whole
   workflow at once;
5. define what requires my approval before anything changes;
6. explain what you deliberately left out for now.

Do not implement until you have shown me the proposed structure
and I have approved it.

Once you approve the structure, the next instruction can be as simple as:

Implement it.

If the AI has repository or filesystem access, it can create much of the structure directly. If it does not, it can generate the files for you to add by hand.

Writing this guide as a numbered sequence rather than one long argument is partly for that reason. It can work as both something a person reads and something a model can execute against. A well-designed publishing system should be legible to both.

1. Start with the problem, not the AI stack

Most blogs are optimised for publishing pages.

That makes sense. A content management system stores titles, bodies, categories, dates, images and URLs. You write something, publish it and move on.

The problem appears once the publication becomes a body of thought rather than a collection of posts.

You begin to have questions such as:

Have I already made this argument?
Is this genuinely new, or does it belong inside something I wrote six weeks ago?
Has new evidence weakened a claim that is still live on the site?
Which article owns this idea now?
If I change the argument, what related pieces should change too?
How do I show that an article developed without pretending it was newly published?
What research led to this conclusion?
What did I reject on the way here?
What would another AI need to know to continue this work if I switched provider tomorrow?

A normal CMS can store the pages. It does not solve those questions.

Before adding AI, write down the knowledge and publishing problems you actually want the system to solve.

For me they became three related problems:

Memory: I did not want important context trapped in one AI account or one conversation.
Corpus management: I did not want every new thought to become another slightly overlapping article.
Maintenance: I wanted published arguments to be able to change as my thinking and the evidence changed.

Those problems determine the architecture. The models come later.

2. Separate the knowledge system from the public website

This is the biggest architectural decision I made. My public website is not the canonical home of everything I know about Editorial Intelligence. I now use separate layers.

Editorial Intelligence Core
method, evidence, research, working knowledge, decisions
        ↓
human judgement + AI-supported routing
        ↓
Editorial Intelligence website
public articles, frameworks, pages and tools

The distinction matters because a finished article is a terrible substitute for the knowledge that produced it.

The article usually does not contain:

the rejected angle;
the contradictory evidence;
the working question that is still unresolved;
why one source was trusted over another;
the operational rule that should apply to the next piece;
the relationship to material that is not public.

If all of that only exists in chat history, your AI may remember it today and lose it tomorrow. If all of it is shoved onto the public website, you are publishing your working memory rather than publishing for readers.

So create a durable knowledge layer.

Mine happens to be GitHub. Yours could be another system, but it needs to satisfy a few conditions:

you can inspect the underlying material;
important knowledge survives a change of AI model;
information can be retrieved predictably;
you can distinguish current authority from old working material;
you can maintain provenance;
another model or person can understand where to start.

This is the practical consequence of the argument in Context is capital: if accumulated context improves AI-assisted work, then that context needs somewhere durable to live.

It is also why I now think an AI project needs a save point. The system should contain enough durable state that the work can resume without reconstructing months of conversations.

A simple folder model

You do not need my repository structure. Start smaller.

knowledge/
  evidence/
  ideas/
  decisions/
  workflows/
  research/

site/
  articles/
  pages/
  assets/

The key is not the folder names. It is that the distinction between working intelligence and public delivery is deliberate.

3. Make the public corpus easy for machines to read

Once AI can inspect the publication, structure becomes much more valuable.

A visually beautiful page is useful to the reader. A predictable content record is useful to the system maintaining the reader’s experience.

My site uses Astro and MDX. Articles are files with structured frontmatter. A simplified version looks like this:

---
title: "Raising the floor is not building a ladder"
date: 2026-08-15
updated: 2026-09-01
status: published
tags:
  - ai
  - editorial-intelligence
type: article
relatedArticles:
  - the-unit-of-capability-is-changing
  - editorial-jobs-are-moving-upstream
---

This looks mundane. It is one of the most useful parts of the whole system.

The model does not have to infer whether a date is the original publication date. It does not have to guess whether a draft should appear publicly. Relationships do not exist only because two pages happen to link to one another in prose.

The structure makes editorial rules executable.

At minimum, I would give substantial pieces:

a stable slug or file name;
a title;
original publication date;
material revision date;
publication status;
a small controlled tag vocabulary;
content type;
explicit relationships to other important pieces.

You can add more later. Do not begin with fifty metadata fields.

The test is simple: could a fresh AI session inspect the repository and answer what is this, is it live, when did it originate, has it materially changed and what else does it belong with?

If not, improve the structure before adding more automation.

4. Tell the AI how the system works

A repository-aware model is much more useful when it does not have to reverse-engineer your operating rules every time.

I keep an AGENTS.md file in the website repository. It explains what the repository is, where canonical knowledge lives, how new article ideas should be handled, how revision dates work, what counts as a substantial editorial change and what prose behaviours to avoid.

You can create a much smaller version.

For example:

# Publishing rules

This repository contains the public website.

Before drafting a substantial new article:
1. Search the existing corpus for overlapping arguments.
2. Decide whether the idea should extend, correct, merge, split or create.
3. Retrieve the relevant evidence from the knowledge repository.
4. Preserve unresolved disagreement for human review.
5. Do not publish a material new claim without human approval.

Publication history:
- `date` is the original publication date.
- `updated` is used only for material revisions.
- Do not change dates for copy edits.

Source of truth:
- Method and evidence live in `/knowledge`.
- Public copy lives in `/site`.
- A detailed old file is not authoritative unless its status says so.

That little file changes the relationship with the model.

Without it, you repeatedly prompt:

Don’t make a new article if I’ve already written this. Check the old stuff. Don’t change the publication date. Remember that the core repo is the authority.

With it, those instructions become part of the environment.

This is an example of editorial judgement becoming infrastructure. A decision you make once can shape the next hundred sessions.

It also reduces dependency on one provider. Claude, ChatGPT, Codex or another repository-aware system can enter the same project and encounter the same operating rules.

5. Replace “write a post” with a routing decision

This is probably the most important behaviour to introduce.

Do not make the default response to a new idea:

Write me a blog post.

Ask:

What should this do to the body of work?

I use five basic routes: Extend when the existing argument still stands and the new material makes it more useful. Correct when new evidence shows the existing claim is wrong, too strong or outdated.

Merge when two pieces are substantially doing the same job. Split when one piece has developed into two genuinely separate arguments. Create when the new material adds an argument that deserves its own page.

This sounds like a small editorial distinction. It changes the economics of the publication.

Before AI, returning to old work often carried enough friction that writing another article was easier. Find the old piece, reread it, reconstruct the argument, work out whether the new material fits, edit it, update the metadata, check the links, publish it again.

Now an AI with repository access can do much of the retrieval and coordination work. That means not publishing something new can become the efficient route. A good AI-native publishing system should therefore be able to produce this answer:

This idea does not justify a new article. It strengthens section four of an existing piece, contradicts one sentence in another and creates one unresolved research question.

That is much more valuable than 1,500 plausible new words.

It is also why prompting is becoming routing. The important question increasingly is not only how to ask a model for output. It is where the work should go, which context it needs and what check should happen before it is trusted.

6. Give AI systems different jobs

You do not need several models. I have found role separation useful.

My current pattern is roughly:

me
 ↓
exploratory conversation
 ↓
durable knowledge / existing corpus
 ↓
repository-aware challenge and implementation
 ↓
Git history
 ↓
published site

ChatGPT is often useful to me as an editorial conversation. I can arrive with half a thought, argue with it, connect it to earlier work and work out whether there is actually an idea there.

A repository-aware coding environment is better at encountering the literal state of the corpus: the real files, current metadata, actual overlaps, implementation constraints and build failures.

Another model can act as a challenger.

The important idea is not “use ChatGPT for X and Claude for Y”. Model capabilities change too quickly for that to be a durable rule.

Define roles instead:

develop — explore the idea;
retrieve — find the relevant context;
challenge — attack assumptions and duplication;
verify — check claims and implementation;
build — make approved changes;
publish — execute the final route.

Then use whichever tool currently performs that role well enough.

This is also how you avoid turning “multi-model” into theatre. A second AI is not useful because two logos are better than one. It is useful when it has an independent job.

7. Keep the human gate where the meaning changes

This entire system becomes dangerous if the AI quietly acquires editorial authority.

There is a difference between:

Update the metadata so this approved article appears correctly.

and:

Decide whether this new evidence invalidates the argument I have been making for six months.

The first is implementation. The second changes what the publication believes.

I keep the human gate around questions such as:

Is this evidence strong enough?
Does this really contradict my previous position?
Is the new argument actually different?
Which disagreement survives?
Should a live public page be corrected?
Does this experience belong in public at all?
Is the model noticing a real inconsistency or manufacturing one?
Would I defend this claim under my own name?

You can automate the work around those decisions without automating the authority itself.

This is one reason I prefer version-controlled publishing to invisible autonomous editing. The system can propose or make a bounded change, and I can see the diff.

The human gate is not the final spelling check.

It is the point at which responsibility stays attached to a person.

8. Use version history as editorial memory

Git turned out to be more important to my publishing system than I expected. Not because writers need to become software engineers. Because every meaningful change can leave a record.

If an AI updates an article, I can see what it changed. If a model makes the prose worse, I can restore it. If I want to know when an idea entered the publication, I can find the commit. If two sessions work on the same area, there is at least a visible history to reconcile.

This changes the trust model.

The website is not a document that an AI has silently rewritten. It is a versioned corpus.

For a one-person publisher, GitHub is a convenient implementation. In an organisation, you might use a CMS with proper revision history and approval states instead.

The principle is broader:

AI changes should be reviewable, attributable and reversible.

If the publishing platform cannot show you what changed, it is a weak foundation for increasingly autonomous AI use.

9. Let published articles remain alive

A normal blog treats publication as completion.

I now treat publication as a state.

The original article remains a historical event: it was first published on a particular date. But the argument may later gain evidence, lose confidence, split in two or require correction.

So I use two different dates:

date = when this piece was originally published;
updated = when the piece changed materially.

That prevents a common trick where an old article gets a fresh date and masquerades as new. It also prevents the opposite problem: a genuinely improved argument remains buried because its URL is old. A material update should normally change at least one of these:

the argument;
the evidence;
the mechanism explaining why something happens;
the limits of the claim;
its relationship to the wider corpus.

Changing three adjectives does not count.

Cheap AI editing creates a real danger of endless revision. If every reread becomes an excuse for the model to “improve” the prose, the system generates churn rather than knowledge.

I use a simple test:

Did I learn something, or did the model merely find another way to say it?

Only the first usually justifies reopening the publication.

10. Automate the boring parts of publishing

Once the editorial rules are explicit, automate the repetitive implementation around them.

My current public site is an Astro project. Content lives as MDX. GitHub holds the repository. Vercel deploys changes.

The practical loop is:

approved file change
      ↓
Git commit
      ↓
build / schema checks
      ↓
deployment
      ↓
live website

That means changing an article does not require opening a visual CMS, finding the page, pasting text, repairing formatting, updating a separate list of related pieces and pressing a series of buttons.

The exact stack is not important.

You could build the same logic with:

a static site generator;
a headless CMS;
WordPress plus a structured API and revision workflow;
a database-backed site;
a docs platform.

The requirement is that approved changes are cheap enough to make maintenance normal. If a factual correction still takes 45 minutes of administrative work, the old publish-and-forget behaviour will win.

Use automation to remove that friction. Do not use automation to decide what deserves to be true.

11. Add structural checks before adding autonomous agents

One of the easiest mistakes is jumping from “AI can read my site” to “I need a swarm of agents.” You probably do not. A surprising amount of reliability comes from boring constraints:

controlled tags;
required metadata;
publication status;
build validation;
explicit source-of-truth rules;
stable file paths;
human approval;
version history.

My site uses typed content collections. If an AI invents a tag that is not in the controlled vocabulary, the build can fail rather than quietly adding entropy to the taxonomy.

That is a useful design principle.

Where possible, turn editorial rules into system constraints rather than reminders.

A model can forget a style note. A schema cannot decide that a required field is optional because it is in a hurry.

Start with those constraints.

Agents can come later if repeated work proves that orchestration is the bottleneck.

12. Close the loop after publication

An AI-native publishing system should not stop at deployment.

Publication creates new information.

A useful post may attract a counterargument. A customer conversation may reveal that the model’s framing is wrong. Search behaviour may show that people use different language. A new piece of research may strengthen an old hypothesis. Another model may catch a contradiction. A reader may ask the question you should have asked in the first place.

Capture the useful part.

The loop becomes:

evidence
  ↓
interpretation
  ↓
publication
  ↓
response
  ↓
new evidence
  ↓
stronger interpretation

This is where a publishing system starts becoming a learning system.

It is also the part most content operations miss. Analytics are collected, but the learning rarely travels back into the argument or the underlying knowledge.

The output gets measured.

The corpus does not get smarter.

13. A minimum viable version you can build this weekend

You do not need to rebuild your entire website.

If I were starting with an ordinary personal blog today, I would do this first:

Put the important source material and working notes somewhere durable.
Export or mirror the most important published articles into machine-readable text if the CMS makes corpus retrieval difficult.
Add simple metadata: title, date, updated, status, tags and related pieces.
Create one AI instruction file explaining where truth lives and how publication works.
Before every substantial new piece, make the AI search for overlap.
Force a route: extend, correct, merge, split or create.
Keep a human approval step for material claims and revisions.
Make revisions visible and reversible.
Automate deployment or CMS updates only after the editorial route works manually.
Record one useful learning after publication and feed it back into the knowledge layer.

That is enough to change the operating model. The minimum viable version could still use one AI model and an existing CMS.

The key adaptation is not technical sophistication. It is moving from page production to corpus stewardship.

14. The reference stack I use

For anyone who wants the literal implementation, my current stack looks roughly like this:

Layer	Current implementation	What the layer is for
Durable methodology and evidence	Private GitHub repository	Keeps research, decisions, workflows and working knowledge outside model memory
Public site and published corpus	GitHub repository	Gives AI a reviewable, versioned set of files to work against
Site framework	Astro	Builds the public site from structured content and components
Article format	MDX + frontmatter	Keeps prose readable while exposing metadata to the system
Validation	Typed content collections + CI	Stops some structural errors before they reach production
Deployment	Vercel	Makes approved repository changes cheap to publish
Exploratory AI	Conversational model	Develops ideas and tests possible connections
Repository-aware AI	Coding / repository environment	Retrieves the actual corpus, challenges overlap and implements changes
Human role	Editor / publisher	Owns claims, evidence, disagreement and publication authority

None of those tools is sacred.

The durable architecture is:

portable knowledge → structured corpus → explicit routing → specialised AI roles → human gate → reviewable implementation → learning loop

If I changed every vendor tomorrow, I would want that architecture to survive.

That is the point of Portable Intelligence and The workflow should outlive the model.

15. What I got wrong while building it

The system did not emerge cleanly.

I overcomplicated parts of it. I created routing logic that sometimes added more process than the task justified. Different AI sessions created overlapping ideas because the shared context was not always retrieved. Models developed a recognisable cadence that began contaminating the prose. Publication dates were changed when pieces were revised, which blurred history. Useful context sat inside provider accounts until I realised how expensive leaving those accounts could become.

And AI’s ability to edit cheaply creates its own temptation: endlessly improving the system instead of using it. These failures changed the rules.

The current version is deliberately less impressed by automation than the early version. I want:

the smallest useful context package, not the whole repository every time;
routing for substantial work, not bureaucracy for typo fixes;
independent challenge when risk justifies it, not ritual second opinions;
durable context, not dependence on model memory;
material revisions, not infinite prose polishing;
simple system constraints before elaborate agent architecture.

If you build this yourself, expect your operating rules to be more valuable than your first tool choices.

16. Where this model stops being simple

A one-person publication is the easy case. There is one final editorial authority: me. A company has harder questions.

Who owns the canonical position when product, marketing and legal disagree? Can an AI update an executive article because a research report changed? Which revisions require compliance review? Should old positions remain visible? What happens when two teams develop the same narrative differently? Who can change shared knowledge? How do you stop a repository-aware model retrieving information a publisher should not see?

Those are not reasons the model fails. They are reasons AI-native publishing quickly becomes a governance problem rather than a writing problem. The more consequential the publication, the more explicit the authority model needs to be.

That is why I would not sell this as “autonomous publishing.” The goal is not to remove the editor. It is to remove enough coordination work that the editor can operate across the whole system.

17. Why I think this is a different kind of blogging

Blogging historically made publishing cheap enough for one person to become a publisher. AI changes a different cost.

It makes maintaining relationships across a growing publication dramatically cheaper. That means one person can potentially do things that previously required some combination of writer, editor, researcher, developer, knowledge manager and production support.

Not perfectly. Not automatically. And certainly not without judgement.

But enough to change the shape of the work.

A blog can become more than a feed ordered by date. It can become a visible interface to a body of knowledge that keeps developing underneath it.

That is the version of AI publishing I find interesting.

Not:

How many posts can I generate?

But:

How much better can this body of work become because it can remember, challenge and revise itself without losing its history?

The model should be replaceable. The website should be rebuildable. The accumulated knowledge, decisions and relationships should survive both.

AI should not just make publishing faster. It should make a publication better at remembering what it already knows.