Building a Human-Approved GPT Writing Workflow for My Portfolio CMS

I try to write regularly for my portfolio and blog.

Most of the time, the starting point is not a polished article. It is a rough thought from real work, a practical example, something technical I learned, something I am building, or an opinion I want to capture before it disappears.

That raw context matters because it carries the original intent. But raw notes are usually not ready to publish. They need structure, a clear title, better flow, and sometimes a calmer tone.

For a while, my workflow was useful but repetitive.

I would write the rough context myself, send it to ChatGPT, ask it to improve the article, copy the result, open my CMS, paste the content, select the content type, add tags, verify the article, and then publish it manually.

It worked, but it had too much manual glue.

The problem was not writing. The problem was the friction around writing.

So I built a small workflow around my portfolio CMS: a custom Writer GPT connected to a controlled API that understands my writing system.

The goal was not to let AI publish for me. The goal was to remove repetitive steps while keeping human approval as the final gate.

Context and operating problem

Writing becomes easier when the capture process is lightweight.

When an idea comes, I do not want to think first about CMS fields, slug formatting, article type, tag selection, or whether the post already exists. Those details matter, but they are not the first thing I want to handle when I am trying to preserve an idea.

My older process had a few repeated steps:

1. Write the rough idea in my own words. 2. Ask ChatGPT to convert it into a clean article. 3. Copy the response manually. 4. Open the CMS admin panel. 5. Paste the content. 6. Choose the content type and tags. 7. Check whether this is a new article or an update to an existing one. 8. Save or publish after verification.

None of these steps are difficult individually. But repeated friction changes behavior.

If writing takes too many operational steps, I start postponing it. If publishing requires too much copy-paste, the habit becomes harder to maintain.

That is usually where a small internal workflow can help.

But the architecture still needs to be careful. Removing friction should not mean removing responsibility.

Architecture starts with the real user behavior

A useful architecture is not always the most automated one.

It should fit how the user already works.

In this case, I am the user and the customer. That makes the requirement clearer. I am usually already planning, thinking, or discussing something inside ChatGPT. Many article ideas start from that discussion.

So the workflow I wanted was not this:

open CMS -> write article -> click AI improvement button -> review

It was closer to this:

discuss idea in ChatGPT -> send it to my Writer GPT -> create a reviewable CMS draft

That difference matters.

If the thinking is already happening in ChatGPT, forcing myself to move into a CMS editor too early adds friction again. The CMS is important, but it is not where the initial thinking usually happens.

This is the kind of detail that matters in architecture.

A technically good solution can still be the wrong solution if it does not match the user's natural path.

The right architecture should respect that behavior.

Options I considered

There were three practical directions.

Option 1: Add AI improvement inside the CMS editor

This is a natural idea.

The CMS already has the article editor. So one approach is to add an AI action inside the writing section:

write rough draft in CMS -> improve with AI -> review improved article

This can be a good design for many products. It keeps the user inside the CMS and makes AI feel like a native editor feature.

But for this project, it was not the best fit.

To make it work properly, the CMS would need more AI-specific integration. It would need provider configuration, credential handling, request and response management, model settings, prompt management, and extra UI states for generation, retry, errors, and review.

It may also need a place to store or configure prompts, a way to handle failed generations, a way to preview changes, and a way to compare the original draft with the improved draft.

That is not impossible, but it adds a different responsibility to the CMS.

For this project, I did not want the portfolio writing app to become an AI editor product. I wanted it to remain a clean CMS with a safe integration boundary.

Also, this option still starts from the CMS editor. My ideas usually start from a ChatGPT conversation, not from an empty CMS form.

So this option solved part of the problem, but not the actual workflow friction I was feeling.

Option 2: Create an autonomous agent to update the CMS

Another option was to build an agent that can manage writing updates more independently.

For example:

agent watches tasks or notes -> generates articles -> updates CMS drafts

An agent can be useful when there are repeated background tasks, multiple steps, scheduling needs, external inputs, or long-running workflows.

But that was not my requirement here.

I did not need a background agent deciding what to write. I did not need it to monitor sources or keep content updated by itself. I also did not want the system to feel separate from my thinking process.

Most of the time, I already know what I want to write. I am already discussing the idea in ChatGPT. I only need a clean way to push that thinking into my writing system as a draft or revision.

For this use case, an agent would be more architecture than the problem needs.

It would increase complexity without improving the main experience.

The problem was not lack of autonomy. The problem was copy-paste friction between where I think and where I store reviewed writing.

Option 3: Use a custom Writer GPT with a limited CMS API

This is the option I chose.

The Writer GPT lives where my thinking already happens. It can take the rough idea from the conversation, ask the CMS API for the writing rules, check whether the article exists, and then create a draft or update a working copy.

The CMS does not need to become an AI writing interface.

The GPT does not get publishing power.

The API becomes the controlled boundary between the two.

That makes the design simpler and more aligned with the actual user journey.

Why I chose this architecture

The final decision was based on fit, not just technical possibility.

As an architect, the question is not only:

Can this be automated?

The better question is:

Where does the user already work, and what is the smallest safe system that removes friction from that path?

For me, the answer was clear.

I already use ChatGPT to think through technical ideas, articles, architecture notes, and opinions. So it is easier to send the final thought to my Writer GPT than to open a separate CMS flow and recreate the same context there.

This architecture also keeps responsibilities clean:

• ChatGPT remains the thinking and drafting surface.
• The custom GPT applies my writing rules and CMS workflow.
• The API exposes only safe writing operations.
• The CMS stores drafts, revisions, metadata, and approval state.
• The admin panel remains the only place where publishing happens.

If I had added AI directly inside the CMS, the CMS would need to own more AI concerns than I wanted for this project.

If I had built an agent, the system would become more autonomous than necessary.

By choosing a custom GPT plus a narrow API, I got the workflow I actually needed: fast drafting from an existing conversation, without turning the CMS into an AI product and without giving AI the final publishing decision.

That is the architecture lesson for me.

Good architecture is not only about adding the most advanced component. It is about understanding the job, the user, the constraints, and the point where the system should stop.

Common mistake: automating the wrong part

The tempting solution is to fully automate the workflow.

For example:

rough idea -> AI article -> direct publish

That looks efficient, but it creates the wrong risk profile.

A personal blog or portfolio is not just a content feed. It is a public record of thinking, judgment, technical opinions, and learning. I do not want unreviewed AI output to become public automatically.

Even if the model usually writes well, it can still add assumptions, overstate claims, or make something sound more confident than it should be.

So I did not want a publishing bot.

I wanted a drafting assistant.

The better boundary is:

rough idea -> AI-assisted draft -> human review -> publish

This keeps the useful part of automation while preserving responsibility.

The mistake is assuming that the most complete automation is always the best product decision.

In this workflow, the best automation is the one that stops before publishing.

Better architecture direction

The architecture is based on a simple principle:

The GPT can help prepare content, but the CMS remains the source of truth and the admin panel remains the approval gate.

The custom GPT only needs safe, limited capabilities:

• read available writing metadata
• read supported content types
• read writing style rules
• understand allowed tags and series
• search whether an article already exists
• create a new draft when the article is new
• create or update a working copy when the article already exists
• never publish directly

That last rule is the most important one.

Publishing stays out of the GPT workflow.

The GPT can prepare. The CMS can store. The admin panel can approve. The human can decide.

Those boundaries keep the system useful without making it risky.

Architecture diagram

flowchart TD
    A[Planning or rough idea in ChatGPT] --> B[My Writer GPT]

    B --> C[Portfolio Writing API]

    C --> D[Writing context]
    D --> D1[Allowed content types]
    D --> D2[Writing style rules]
    D --> D3[Allowed tags and series]
    D --> D4[Validation limits]

    C --> E[Article lookup]
    E --> F{Article already exists?}

    F -- No --> G[Create new draft]
    F -- Yes --> H[Create or update working copy]

    G --> I[Portfolio CMS]
    H --> I

    I --> J[Admin panel review]
    J --> K{Approved by me?}

    K -- No --> L[Edit, reject, or regenerate]
    K -- Yes --> M[Publish from admin panel]

    B -. blocked .-> N[Direct publish]

    O[CMS-side AI editor action] -. not chosen .-> P[Would add AI provider logic to CMS]
    Q[Autonomous writing agent] -. not chosen .-> R[More autonomy than needed]

The diagram includes the selected path and the alternatives I considered.

The blocked direct-publish path is intentional. The GPT-assisted workflow can prepare content, but it cannot bypass review.

The CMS-side AI editor action could work in a different product, but it would pull model configuration and AI interaction concerns into the CMS.

The autonomous agent could work for background workflows, but it would be more independent than this use case needs.

The chosen path keeps the GPT close to the thinking process and keeps the CMS focused on content storage, review, and publishing.

How the workflow works

The new workflow starts the same way as before: I provide the rough context.

The difference is what happens after that.

Instead of asking a general-purpose chat to write something and then manually moving it into the CMS, I give the task to my custom Writer GPT.

The GPT first asks the CMS API for writing context. That context includes available content types, allowed tags, series names, expected content shape, validation limits, and style rules.

This prevents the GPT from guessing CMS details.

Then it checks whether the article already exists.

If the article is new, it creates a draft.

If the article already exists, it updates the working copy instead of creating a duplicate article.

After that, I open the admin panel and review the generated draft or revision before anything becomes public.

The result is a smoother workflow:

idea already discussed in ChatGPT
  -> send to Writer GPT
  -> Writer GPT checks CMS context
  -> draft or working copy is created
  -> admin review
  -> publish only after approval

This removes the repetitive middle steps without removing review.

API responsibilities

The API is not just a database wrapper. It defines the safe operating boundary for the GPT.

For this kind of system, the API should expose enough information to make the GPT useful, but not so much that it can cause damage.

A practical shape looks like this:

GET  /writing/context
GET  /writing/articles/search
GET  /writing/articles/{slug}/working-copy
POST /writing/drafts
PUT  /writing/articles/{slug}/working-copy

The exact routes do not matter as much as the responsibilities.

The context endpoint should answer questions like:

• What content types are allowed?
• What tags already exist?
• What series names can be used?
• What tone and structure should articles follow?
• What validation limits apply?
• What actions are allowed for the integration?

The search endpoint should help the GPT avoid duplicate articles.

The working copy endpoint should protect existing articles by creating reviewable revisions instead of silently changing public content.

The write endpoints should be draft-only.

That means the API can accept a new article draft or a pending revision, but it should not expose a public publish action to the GPT.

This is a useful pattern for AI integrations: give the model narrow tools, not admin power.

GPT responsibilities

The GPT is responsible for turning rough context into structured writing.

It should improve clarity, flow, grammar, title, excerpt, and organization. It should also choose the best content type from the allowed list and select relevant tags without inventing new taxonomy unnecessarily.

But it should also follow strict writing rules:

• Do not invent project claims.
• Do not invent metrics.
• Do not invent client names.
• Do not publish directly.
• Do not store secrets in article content.
• Do not create duplicate drafts for existing articles.
• Prefer practical engineering language over hype.
• Keep the original intent of the note.

This makes the GPT less like a free-form writer and more like a controlled writing assistant inside a product workflow.

The GPT is useful because it understands the workflow context. It knows the available content types, the expected tone, the tags, and the difference between creating a new draft and updating an existing working copy.

That context is what makes the experience better than a generic copy-paste prompt.

CMS responsibilities

The CMS should stay responsible for content ownership.

It should store articles, drafts, revisions, metadata, slugs, tags, series, and approval state.

It should enforce validation rules even if the GPT already tried to follow them.

The backend should not trust the model as the only validator.

For example, the CMS should still check:

• whether the content type is allowed
• whether the slug is valid
• whether the markdown length is acceptable
• whether the requested tags are allowed
• whether the article should remain draft or pending revision
• whether the integration is trying to publish directly

This keeps the safety rules close to the system of record.

Admin panel responsibilities

The admin panel is the human review layer.

That is where the final decision should happen.

The admin panel should let me read the generated draft, adjust the tone, remove weak claims, fix technical details, change tags, and decide whether the article is ready.

This is also where hallucination risk is controlled.

The GPT can make writing faster, but the admin panel makes publishing intentional.

For this project, that distinction is important.

I want a faster writing workflow, not an unreviewed publishing workflow.

Why draft-only automation is safer

The most important product decision here is that the GPT can create drafts but cannot publish.

That one constraint changes the system from risky automation to useful assistance.

A draft is reversible. A draft can be reviewed, edited, rejected, or improved.

A published article affects the public portfolio immediately.

Those two actions should not have the same permission level.

By keeping AI-generated work in draft or pending revision status, I get the productivity benefit without giving up editorial control.

This also helps with hallucination risk. If the model accidentally adds a claim that is not accurate, it can be caught during review.

The system does not assume the model is always correct. It assumes the model is useful but needs review.

That is a healthier design.

Reference implementation notes

A clean implementation can be built with a few guardrails.

First, keep the CMS as the source of truth. The GPT should not maintain its own copy of article state. It should ask the API when it needs to know what exists.

Second, keep the integration permissions narrow. The GPT should only get the actions required for drafting and revision creation.

Third, separate generated work from approved work. If an article is already published, the GPT should create a pending revision rather than modifying the live version directly.

Fourth, require an explicit admin review step. Publishing should remain a human action from the CMS admin panel.

Fifth, validate content before saving. Titles, slugs, excerpts, tags, content types, and markdown length should be checked by the API, not only by the GPT.

A simple validation boundary might look like this:

GPT proposes article
  -> API validates content type, slug, tags, length, status
  -> API forces draft or pending revision
  -> CMS stores reviewable content
  -> admin panel handles approval

This keeps the model helpful while making the backend responsible for enforcement.

Security and boundary decisions

The important security decision is not to expose unnecessary power.

The GPT does not need database access. It does not need direct admin access. It does not need the ability to publish. It does not need secrets in the article content.

It needs a narrow API with controlled actions.

That also keeps the mental model simple.

If something comes from the GPT workflow, it is draft or revision work. If something is public, it came through the admin approval path.

This separation makes the system easier to trust.

Tradeoffs and constraints

This workflow is not perfect, and that is fine.

The main tradeoff is that it still requires review. But that is a deliberate constraint, not a limitation.

Another tradeoff is that the GPT needs good context. If the CMS context is incomplete, the GPT may make weaker decisions about content type, tags, or article structure.

There is also a product design cost. Building the API and GPT workflow takes more effort than simply copying text from ChatGPT into a CMS. It only makes sense if writing is frequent enough that the reduced friction is worth it.

The design also depends on my own behavior. If I wrote most articles directly inside the CMS, then a CMS-side AI button might be better. If I needed scheduled content operations or background research, then an agent might be better.

But that is not the current need.

For me, the value is in habit preservation.

I do not want small operational steps to stop me from writing. I also do not want automation to publish things I have not reviewed.

This architecture gives me a middle path.

Checklist for review

For this kind of AI-assisted CMS workflow, I would review the design with these questions:

• Where does the user naturally start the work?
• Is the AI placed in that natural workflow, or does it force a new one?
• Can the GPT publish directly? If yes, remove that permission.
• Does the API force draft or pending revision status?
• Can the GPT read the allowed CMS taxonomy instead of inventing it?
• Does the system check whether an article already exists before creating a new one?
• Are published articles protected from direct modification?
• Is there a clear admin approval flow?
• Are validation rules enforced by the backend?
• Are secrets and private admin data excluded from the writing context?
• Can the human editor reject or modify AI-generated content before publishing?
• Is the chosen design solving the actual user behavior, or only a technical idea?

The system is only useful if the boundary is clear and the workflow matches the person using it.

Final thought

The best AI workflows are not the ones that remove humans completely.

They are the ones that remove repetitive work while keeping human judgment in the right place.

For my portfolio CMS, that means AI can help me turn rough thoughts into structured drafts. It can help with titles, formatting, content type selection, and revision preparation.

But the final decision stays with me.

That balance feels right.

I get a faster writing workflow, but the public portfolio still reflects reviewed, intentional work.

AI reduces friction. It does not remove responsibility.